マネジメントの放棄を正当化するような格言めいたものがこの世には流通しているかもしれない

ちょっと前にツイッターで以下のようなことを書いた。

「自分で考えて動く」みたいなのすごい大事だとぼくも思うけれど、それをするためには「どんな役割を担ってほしいか」「達成してほしいことはなにか」「どこまで自分の裁量でやっていいか」がそれぞれ明確になってないと無理だよね。逆にそこさえ揃ってれば、よほどのタコじゃない限り自分で動くと思う

これに対して、「マネージャーがそれをやらないのはマネジメントの放棄だよね」というリプライがついて、「なるほどたしかにそうだなあ」と思ったのだけれど、マネジメントの放棄と呼ぶべき状況ってのは、これの他にも、ちょっと注意して見てみるといろいろなところで目にすることがあるかもしれない。

たとえば、たまに耳にする「社会人は結果が全て」という言葉について。ここでいう「結果」というのはなんだろう。マネジメントするひととされる人の間で「あなたが達成すべき結果はこれですよ、これに向けて頑張ってください」がきちんと合意と納得の上で設定されているのであれば、いいと思う。けど、この言葉が使われる文脈は、なんだか多くの場合「いいから売上あげろや（売上を上げるためのプロセス目標などは特に設定されない）」みたいな感じの上にあるような気がする（要出典）。

もう少し別の言い方をすると、たとえば、まだひとりで案件を受注まで持っていけないひとや、プログラマであれば、ひとりでプロダクトを完成まで持っていけるスキルがないひとに対して、「結果が全てです、あなたは案件を受注してないので結果なしです」「結果が全てです。あなたはプロダクトを完成させられなかったので結果なしです」と言ってしまうのは、マネジメントの放棄と言って差し支えないだろう。

そういう人達には、たとえば、「まずは一ヶ月にn社とアポを取って面談することを目標にしましょう」だとか、「メンターとコミュニケーションを密に取って、一日ふたつプルリクがマージされるのを目標にしましょう」だとか、そういう「会社にとってプラスになる行動だし、本人にちゃんと達成できる目標」をきちんと（相談の上）設定する必要があるだろう、というような話だ。

多分、冒頭に書いた例や今書いた例に限らず、いろんなところでマネジメントの放棄や、それがあたかも格言めいた言い方で正当化されることが起こっている気がする。なんとなくそう思うってだけで確証があるわけではないのだけれど。

ひとりひとりのメンバーに対して適切なマネジメントレベルも違う（この記事でぼくがあげたようなレベルのマネジメントが不要なハイレベル人材もいますよね）から、マネージャーってけっこう大変な仕事だと思う。だから、ついつい自分の耳に甘く響く「マネジメント放棄を正当化する格言」に逃げちゃったりしがちかもしれないけど、だからこそそういう言葉にうっかり乗っかってしまわないように気をつける必要があるよな、と感じた。

蛇足を書いておくと、もちろん、マネジメントされる側が自分を律するためにそういうの使うってのはあってもいいかもしれないけど、マネジメント放棄されてるところで無理に頑張ると心が壊れるので、そういう時は無理しないでほしい。

JavaScriptのreduceがゆるゆる型であることに助けられた話

某slackにて以下のようなお題が出されました。

お題

["a","b","c","d"] みたいな配列があった時に

{
  "a": {
    "b": {
      "c": "d"
    }
  }
}

みたく変換する良い方法を JavaScript で募集します

わたしの回答

const reducer = (acc, el) => {
  const ret = {};
  ret[el] = acc;
  return ret;
};

["a", "b", "c", "d"].reverse().reduce(reducer);

与太話

普通（普通ってなんだ？）、reduceは配列の要素をひとつひとつ舐めて、変換をしながらaccumulatorに蓄積していくような操作になりますが、静的型付け言語の場合は以下のようなシグネチャになることが多いでしょう。（架空の言語です）

class Array[A] {
  def reduce[B](reducer: (acc: B, element: A) => B, initialAcc: B): B = ???
}

畳み込みはつまり Array of A を B に変換する仕組みですから、reducerの型が「(acc: B, element: A)をとり、Bを返す関数」になるのは自然なことです。さらに、accumlatorの初期状態を必要とするので、reduceはreducerの他に「accumlatorの初期状態」を引数にとります。

しかし、JavaScriptのreduceはこの「accumlatorの初期状態」を省略することができます。

[1, 2, 3].reduce((acc, el) => acc + el); => 6

省略した場合、一回目のreducerの引数にはArrayの1要素目と2要素目が渡ってくるという親切（！）な仕様です。

しかし、この挙動は、Arrayの要素の型とaccumlatorの型(=reduceの返り値の型)が同一の場合はうまくいきますが、異なる場合は奇妙な挙動をすることになります。

たとえば、Arrayの要素の型がnumberで、accumlatorの型がobjectの場合を考えてみましょう。

一回目のreducerの引数には、numberとnumberが渡ってくることになりますが、二回目以降のreducerには、objectとnumberが渡ってくることになります。

これはかなり奇妙な挙動で、普段ならばバグの温床になりそうなものです。

が、今回に限ってはこの挙動に助けられました。

お題で得たいオブジェクト

{
  "a": {
    "b": {
      "c": "d"
    }
  }
}

の形をよくみてください。厄介そうなやつがいますね。そうです、一番深いネストの、"c": "d"の部分です。これが、

{
  "a": {
    "b": {
      "c": {
        "d": {}
      }
    }
  }
}

という形であれば、配列のすべての要素をキーに変換していけばいいだけなので話は簡単なのですが、お題では、ネストの一番深い部分だけが「キーが文字列、値も文字列」で、ほかの部分は「キーは文字列、値はオブジェクト」です。これは困りましたね。普通のreduceでは対応するのはかなり難しそうです…… 。

しかし、JavaScriptのreduceは「ちょっと普通じゃない」のです！「accumlatorの初期状態を省略すると最初の一回だけは配列の1番め、2番目の要素を渡してくる」という仕様があるのでした！こいつを悪用してやれば、「一番奥のネストは文字列と文字列のペア」「その他の部分は文字列とオブジェクトのペア」というのをうまく表現できそうです！

という発想で、前掲した解にたどりついたのでした。

JavaScriptの挙動を悪用したハックっぽい感じで、静的型付きの世界からするとかなりお行儀の悪い書き方に感じますが、たまにこういうゆるい型がうまくはまるというか悪用できるケースにあたるとガリガリくんの「当たり」をみつけたような気持ちになりますね。

こちらからは以上です。

YAPC::Okinawa感想

特別によかったトークの感想を書きます。

Kazuho Okuさんの「HTTP/2にまつわる事実と誤解」

プロフェッショナルのトーク！という感じがはんぱなかったです。

とくに面白く感じたのがTrailerというHTTPヘッダで、「こんなものがあるのか！！！」とびっくりしました。

Trailer - HTTP | MDN

Resource Timingの話と

Using the Resource Timing API - Web APIs | MDN

Server Timingの話

Server Timing

はかなり「有用な情報！！！！」という感じがしてありがたかったです。

新屋 良磨さんの正規表現のあいまい性の話

もうはちゃめちゃにおもしろかった（語彙よ……）。

形式言語とオートマトンの話については「白と黒のとびら」という名著があって、それを一通り読んだくらいの理解度でしかないのだけれど、その程度の理解度であってもものすごく知的興奮を味わえるトークだった。

おなじ文字列から複数の構文木を作ることが不可能な文法を無曖昧とよぶけど、無曖昧でない場合があって、そういう場合様々な問題を引き起こしうるという話が個人的におもしろかった。とくにプログラミング言語も曖昧性をはらむことが普通にあるけど、多くのプログラミング言語ではそういうときに別のルールなどを導入して曖昧性を解決しているという話を聞いて、「たとえば結合法則（右結合か左結合化とか）はプログラミング言語を無曖昧にするために導入されてると考えることができるんだなあ」などと思った。

まこぴーさんの 「High (Availability|Performance) WebSocket for Perl Real-Time Application」

ベストトーク賞に入れたのはこれ。弊社でもサーバーサイドからのpushは課題として取り組んでいて、共感の嵐だった。

kuiperbeltはクライアントからの送信についてはスコープ外としてサーバーからのpushだけに問題解決を限定するという判断をしているのは良いなあと思ったのだけどれど、そうなると「だったらSSEでよくね？」という話は出てくる。ので、あとで本人に「SSEにしなかったのってクライアント側のライブラリが充実してないとかそういう話なんですか？」って聞いたら「そう」っていってて「なるほど〜」ってなった。

あと、「どの接続にだれがぶらさがってるのかという情報をapp server側に持っておくと、再接続が走ったときに問題にならなかった？それはどうやって解決した？」という質問も後からしたんだけど、「そこはapp側で工夫が必要というかapp側の責務として設計している（からこそ、appがそれをハンドルしやすいようにしている）」とのことで、なるほど土管に徹するというのはこういうことかと深く納得した。

現在時刻をハイジャックする是非について

前の記事に関連して

結論、一般論としてはケース場合ケースですね、というところに落ち着くんだけど、上述のような問題点を理解した上で、個別のケースにおいては「今回雑でいいからXXで」「じゃあそれで」みたいに判断できると良いですよね。こちらからは以上です。

Joda-Timeで現在時刻をハイジャックする

Joda-Timeは便利ですが、時間を扱うプログラムあるあるとして、「ユニットテストとかどうやって書けばええんや」ってのがあります。

Rubyならtimecopなどを利用するところですが、joda-timesはDateTimeUtilsに自前で現在日時をハイジャックする機能を持っています。

Joda-Time 2.9.9 API

setCurrentMillisFixedとsetCurrentMillisDifferenceがそれですね。便利ですね。

(Java8のDate-Time APIが出てきた今joda-timeがどれだけ必要とされるのかというのはまた別の話なんで置いておきます)

ジェネリックガルボ

タイトルはブラックサンダーのことです。いや、言いたいことはわかる。正直ガルボとブラックサンダーはだいぶ違う。チョコレートの中にココアクッキーが入っていれば実質同じみたいな雑な判断やめろ！！って話である。

ところで、なぜブラックサンダーの話かというと、tmrrさんという方の「ブラックサンダー！」という楽曲について、編曲、打ち込み、ギター演奏、男声パートのお手伝いをした話をしたいからです。

きっかけ

きっかけは以下のツイートでした。

tmrrさんとは荻窪にある「アルカフェ」というアコースティックライブバーで行われているオープンマイクというイベントでお知り合いになりました。そのtmrrさんがブラックサンダーの曲を作ったと聞いて、軽い気持ちで「アレンジしたいな」と発言したのがきっかけです。なぜならぼくはブラックサンダーが好きだから……。安いのにおいしくて食べると幸せな気持ちになるブラックサンダーがぼくのこころをとらえて離さないから……。

しかし、その「軽い気持ち」はデモ音源と楽譜を頂いた瞬間に「本気」にかわることになります。

軽い気持ちが「本気」に変わる

頂いた楽譜とデモ音源は、メロディー譜と歌詞、それに一部仮のコードが振られた状態のものでした。これを受け取ってざっとさらった時点で、ぼくの気持ちは、「軽い気持ち」から「あっこれは本気やるべきだ」に急激に変化していました。それくらい良いものだったのです。

歌詞の面から

本人に確認したわけではないので、どこまでtmrrさんの意図を汲めているのかはわかりませんが、少なくともわたしは頂いたデモの歌詞の書かれ方から、あふれるユーモアと、単なるユーモアでは終わらない「表現されるべきなにか」を感じました。

「ブラックサンダー」は、言ってしまえば単なる駄菓子でしかありません（いや美味しいけれども）。それをあえて題材に選んでいる時点で、この楽曲の表現はかなり「力が抜けたユーモラスなもの」となっています。

しかしその一方で、（一聴すればわかるとおり）この楽曲は単に「ブラックサンダーのことをユーモラスに歌った歌」ではありません。注意深く聴けば、「ブラックサンダーが象徴する性質を持った誰かや何か、あるいはそれに惹かれるということ」を間接的に叙情、あるいは叙述していることが見て取れるでしょう。

ぼくはこういう手法に対して一種の信頼感を持っています。というのも、言葉を使うというのは常に無力感と向き合うことである、という気持ちを持っているからです。

ぼくたちの言葉は、あまりに明瞭で、説明的で、機能的で、端的です。明瞭で、説明的で、機能的で、端的な言葉を使って何かを語ってしまった途端に、言葉で表されてしまったその対象は「わかりやすい形に切り分けられてパッケージ化されたなにか」に堕してしまいます。たとえば、「会いたい」と言ってしまったら、それは「会いたい」という感情として切り取られ、理解されやすいパッケージに包まれてしまいます。「会いたい」という言葉の後ろには、おそらく、膨大な整理されていない感情や様々な過去などが未分化のままに横たわっているはずなのに。

それを避けるためには、対象について「直接語る」ことを丁寧に回避しながらも、その周りに共起するなにかに仮託して、間接的に語る必要があります。直接語れば常に毀損されてしまう「主観」は、ユーモアや俯瞰を取り入れたりして、とても迂遠な形で、そのまわりをウロウロとうろつくようなやり方でしか表現され得ない、とぼくは考えています。

話を戻すと、この「ブラックサンダー！」という楽曲を一聴したとき、ぼくは「あ、これは"軽い"形をしているけど、本気で取り組むべきものだ」と思ったのでした。それは、この楽曲がまさに「ユーモアとマジの間」「俯瞰と主観の狭間」にうまくボールを落としているように見えたからです（繰り返しになりますが、あくまでこれはぼくが勝手にそう感じたというだけで、どれだけtmrrさんの意図と一致しているかはわかりませんが）。

音楽的な面から

いくら歌詞が優れていたところで、音楽的に面白くなければ音楽はおもしろくありません。デモからは、音楽的にもぼくが「これは良いものだ！！！」と感じる点がありました。パッと聴いただけで、

  • 要所要所に出てくるブルーノート
  • Bメロ前半の半音で下がっていくベースライン
  • そこから続く、男声パートと女性パートが入り乱れる2拍3連フレーズ

が、気に入りました。全体的にポップでありながら、ちょっと「不安定さ」を感じさせるこのような要素が、前述した「ユーモアに仮託された、ユーモアからはみ出ていくなにか」に説得力を与えているのです。これはいい。メロディーとベースラインからも、「基本的には快活なユーモアにあふれているのにひょいとその裏に潜んでいる"表現されるべきなにか"」が顔を覗かせる。名曲じゃないか。

というわけで、結構気合をいれて編曲作業をさせていただきました。

成果物

soundcloud.com

出来上がったのがこちらです。デモ時点で素晴らしかった上述の内容をなるべく活かす形にまとめ上げることを意識して編曲、打ち込み、演奏をしてみました。

ぼく自身はあまり「イチから創作物を作ること」が得意ではないのですが、作詞作曲家として0から1を作り上げる能力のあるひとを、編曲や演奏でサポートするのはとても楽しくやりがいのあることですね。今回は本当に楽しく編曲をさせていただきました。また機会があったらやりましょう。しかしこうして聴いてみると、男声ボーカルの下手さが際立ちますね！永遠の課題です。

クソコードを別の言葉に言い換えるのあんまり意味なくて

それよりも互いに信頼関係を築くほうが大切だと思う。

たとえばおなじ「ばか」という言葉が親密な関係で発せられるときとそうでないときに発せられるので意味が180度かわるように。

「このような言い方は避けましょう」みたいな感じで言葉狩りするよりも、「ここがクソコードだから直そうぜ」「そうしようぜ」と言い合える関係を目指したいです、すくなくともぼくは。人間関係はとてもむずかしいね