読者です 読者をやめる 読者になる 読者になる

優秀なエンジニアは

優秀なエンジニアは「優秀なエンジニアは○である」「優秀なエンジニアは□□をしない」みたいなざっくりした色分けを、他人に対してやらない。*1

エンジニアがやることのひとつに技術による問題の解決があるが、そのためには物事を細かく分割して見る '目' を養っている必要がある。例えば A という問題があってその原因が a1 == 1 && a2 == 2 であるからだ、というようなとき。

「a1 == 1 も a2 == 2 も条件のひとつなんだから、 a1 == 1 になる事をそもそも禁止するか、a2 == 2 になる事をそもそも禁止するか、どちらかを選ぶべきだ」という人と、「a1 == 1 であることも a2 == 2 であることもそれ単体では問題ではないのだから、それらが揃わないようにすべきだ」という人に分かれる。例が雑で申し訳ないがこれは経験的にそう感じる。*2

で、結論がこのどちらになるにせよ、両方の考え方を考慮した上で結論を出せる人のほうが、片方の考え方しかせずに結論づける人より、エンジニアとして優秀だと思う。"問題を分割して見る '目'" と書いたのはつまりそういう事を指している。往々にしてベストな結論というのはそのコンテキストによって決定づけられるものであろうが、ベストであって欲しい結論に一般性を持たせたいがためにコンテキストに一般性を押し付けるのは何かすごく政治的だし、エンジニアがそういう筋書きをするのはある種の思考停止だと思う。エンジニアリングというのは政治に対するカウンターパンチではなかったか。

*1:という文章が矛盾しない理由は僕が優秀ではないからだな

*2:もちろん、「そもそも a1 == 1 && a2 == 2 という条件が複雑であること自体が問題 B であり、この問題 B の抜本的解決によって問題 A のみならず将来的に A' や A'' について考える必要すら無くなるのだ」という意見もあるが、それは 'いかにして問題を発見するのか' という問題へのアプローチの中で発揮される優秀さでありちょっと別の話なので横に置いとく

新型 MacBook キーボード

 最近、仕事して家事をこなして子供の相手をして、それだけで 1 日が終わるようになって、自分の時間が全然取れなくなった。それはある意味では幸せなことなのだろうが、学生のとき、まだプログラミングを知らなかった頃は 1 日 2 冊ぐらいのペースで猛烈に読書にハマっていたし、プログラミングを知ってからは 1 日 12 時間ぐらいコーディングしていた時期もあった。学生当時に読んだ本で「起きている時間のうち 1/3 を自分のためだけに投じることができない人は総じて不幸である」的な事が書いてあったのを読んで「あぁ今の自分はそういう意味では幸せなんだな」と思ったのを覚えている。いま、妻も子供も寝静まったあと一人になって、ふっとそういう時期を思い出すとき、その落差に悶々とすることがある。これを書いている今夜はまさにそういう日で、だったら blog 書いてないでコードでも書けよって気もするが、新型 MacBook を一日使ってみた感想とかを書いてみたい。

 待ちに待った新型 MacBook が届いたのだ。届くまでの間、目に止まったレビュー記事は積極的に読んでいたので、1 ポートの不便さについての指摘やキーボードの悪評については知っていたが、いざ使ってみるとそんなに悪くないように思う。網羅的にレビューするつもりはないのでキーボードについてだけ書く。

 最初はまず押し込みの浅さに違和感を感じた。しかし少しタイプしてだんだんそれに慣れていくとこちらの方が良いなと思うようになった。というのも、最小限の力でタイプが進められるので、押し込みの弱さに起因する打ち漏れが少なく、打ち直しが少ない。普段は MacBook Pro を使っているのだが、新型 MacBook を使っていると、手に馴染んだはずのそれよりも速くタイプできるようになった。

 またタイプしているときの音がとても静かなのが良い。MacBook Pro だと妻が寝ているときにコードを書いたりすると「タイピングの音がウルサイ!子供が起きるでしょ!」と怒られたものだが、これくらい静かならまぁ許容範囲じゃなかろうか。以前 Kindle を買ったときにもページめくりの音がしない事を評価したが、とにかく静かに利用できるデバイスというのは子持ちの家庭にはとてもありがたいのだ。

f:id:kura-replace:20150428041224j:plain

 細かい話をしだすとキリがないのでバッサリ割愛するが、じゃあ総合評価でこのデバイスはお買い得かというと、割高だと思う。内部のスペックの低さや、1 ポートがいずれ 2 ポートになるであろう事も考慮すると、後継モデルを選ぶほうがずっと賢明だろう。それでもしかしこのモデルを買うというのは、信仰心とか好奇心とかの気分的な充足感にそれなりの対価を払うということであって、だったら概ねこの買い物には満足だなーと思う。

集中せずとも失敗しないのがプロだろうが、集中を呼び寄せるのもプロだろう。

生活

 仕事をしていて「今は集中できていないな」と気付くことがある。ずっと集中しっぱなしというのはあり得ないから、「後でまたペース上げて取り返せば良いか」と思うのだが、そのまま何となくその日の業務が終わることもある。

 

 さて、羽生善治のこの本が面白かった。


Amazon.co.jp: 決断力 (角川oneテーマ21): 羽生 善治: 本

 この本を端的に紹介するのは非常に難しい。説明を文章にするとこの本の良さを損なってしまうような気がするのでやめておく。

 

 この本では何度も、氏が集中することについて書かれている。その文章から伝わってくる気迫のようなものは、将棋の対局の中の緊張感や、貪欲になって学び研鑽するときの狂気などを想像させてくれる。

 そうして一通り読み終えて、本の中で書かれている「集中すること」と、最近の僕が言っている「集中すること」との間にはずいぶんと格差があるなーと気付いた。どうも最近の僕は、手が動かせているならそれは集中している、と、考えているような節がある。そのため仕事する時間の気分を少しでも良くするようにと、ラジオを垂れ流しておいたり、作業用の音楽を YouTube に探しにいったり、やたら味の濃い飲料を口にしたりしていた。しかし、そうやって仕事した気になっていた僕は、ラジオの操作をしたり、 YouTube の広告が終わるのを待っていたり、冷蔵庫を開けたりしているだけで、そもそも期待していたような集中モードの時間にありつけていない。git で、最も集中できていたであろう時期のコミットと最近のコミットを比較してみるとその差は瞭然だった。書いたコードの行数が違うとかそういう事ではなく、自分が書いたコードの密度は自分がよく分かっているものである*1。「自分の管理は(足らないところはあれど)自分でやっている」という自覚は、どうも幻覚だったらしい。

 そこで、仕事しているときにバックグラウンドで音を鳴らすのを止めて、飲料は水かブラックコーヒーに限定した。たったそれだけで、グッと集中できるようになった。思考の根がより深いところに届くようになり、時間あたりの密度が非常に濃くなる感がある。読書するときにも適用したら、本の読み込みが良くなった。

 

 「集中するためには気分をハイにするのが大切で、そのために何かを足してみよう」という発想は基本的に間違っているんだろうと思う。「集中するためには気分の善し悪しなどどうでも良くって、まずはノイズっぽいものを取り除いてみよう」という発想の方が良いようだ。気分の善し悪しが集中をトリガするのではなく、集中することが気分の排除をトリガするのだろう。

*1:コードレビューで指摘してもらうコードの品質とはまた別の話をしている

今どき帳面に日記を書く人なんて少ないだろうけども。

生活

 子供が出来てから「今考えないといけない事」がすごく増えた。まぁ充実している。その代わり、ボウッと Twitter を眺めながら思いついたことをあれこれつぶやく事はずいぶん減ってしまった。だいたい、ひどくプライベートなことはインターネットに出すわけにはいかない。「考えないといけない事」があるっていうのはつまり、それを励起するほどのインプットがあるという事でもある。でもアウトプットする場所が無いというのはとても苦しい。

 そこで、日記を書きたいと思うようになった。自分が子供の頃は、日記を書くという宿題が出されるたびにウンザリしていたし、SNS を利用するようになってからは「誰にも見られない日記を書く」なんてバカのやることだと正直思っていた。それが今になって、書きたいと思っちゃってる自分が理解できないし、だいたい日記を書いたってどうせ続かない。

 そんな事を思いつつ、一方で僕は、なかなか本を読む時間が取れなくなっていることに苛立っていた。「今考えないといけない事」とは別に「今考えていたい事」を見つけるためのインプットに飢えている状態である。時間が取れないと言ったって、探せば隙間の時間は、ある。そこで隙間の時間を読書に充てるべく、Kindle paperwhite を買った。

  電子書籍リーダーの良さについて今更細かく書こうとは思わないが、少なくとも

① 一冊の本より小さく軽い

② 子供が寝ている横でも無音でページめくりできる

③ 子供に破られる心配が無い

 という点で圧倒的に紙の本よりも便利なので子育てしている人にはオススメしたい。*1

 

 さてソフトバンクという企業がある。今では誰もが知る巨大企業*2だが、世間が注目するなかで著しい成長を見せたのはここ 10 年くらいだと思う。ソフトバンクの社長は孫正義。その参謀として暗躍した、嶋聡という人がいる。彼がソフトバンク成長の裏側を綴った本がめちゃくちゃ面白かった。

 本の中身の紹介は興味ある人が読めば良いとして、本の中でチラッと、彼がつけている日記についての紹介があった。ふつう日記というと「一日の締めくくりに書く」ものだと思うのだが、彼の場合は「一日の初めに書く」らしい。少し引用する。

私には「朝日記」をつける習慣がある。夜よりも朝のほうが昨日を省察し、今日の挑戦への意欲が湧き上がるからだ。これは二〇〇三年から始めているから、すでに一〇年以上続けていることになる。いま朝日記を読み返すと、社長室長として疾駆してきた日々がよみがえってくる。 

  睡眠は記憶の整理と定着をするというけれど、なるほど朝に昨日を振り返って書く日記なら、書いてみたいと思った。日記帳を買ってきて、何日か書いている。朝日記といえども、朝一番は子供の泣き声に起こされたりと慌ただしくなりがちで、とても書けそうにない。そこで、仕事を始める前の 5 分とか 10 分とかを使って書くことにした。

 書いてみるとやはり、「アウトプットする場所が無いがゆえの苦しさ」みたいなものはグッと解消する感がある。今はまだ書く事が新鮮だからかも知れないが、たとえばこれが 1 年とか 2 年とか続いたなら、僕の生活にとって日記というものが実は必要だった、ということになるんだろうと思う。

 まとめると「インプットを補完する Kindle を買ったら、アウトプットを補完する日記を得た」。今年はこの二つを糧にしてやっていく。

f:id:kura-replace:20150122075030j:w400

*1:「物理的な本の存在が子供の興味をひくわけだから、その点を無視してはいけない」という意見はあると思うがそれは絵本がフォローしている

*2:今日の時点で時価総額 8 兆円

プログラミングをゲーム的な演出で学ばなくても、ゲームの中にプログラミングを見出す事はできる

設計

 Final Fantasy Tactics というゲームがある。1997 年に発売されたゲームなんだけど、当時これを僕はプレイしまくっていた。

f:id:kura-replace:20140221002421p:plain

 僕はこのゲームでひたすらキャラクタの育成にのめり込んでいた。キャラクタを育成するためには経験値を溜める必要があるんだけど、経験値は何か行動をしないと獲得できない仕組みになっている。で、キャラクタ育成っていうと単純で退屈そうな作業なんだけども、当時の僕はこれが面白くてしょうがなかった。面白くしている最も大きな理由は、経験値獲得ルールにある。

 経験値は何か行動をすれば獲得できるのだが、行動したからといって何も効果を生まない場合は経験値が獲得できない、という制約が課せられているんである。例えば、攻撃してダメージを与えれば経験値獲得するが、攻撃に失敗すると経験値も無し。HP を回復させれば経験値獲得するが、既に HP が満タンなら経験値は無し。武器防具を盗んで成功したら経験値獲得するが、失敗したら経験値は無し。という具合。

 そして、経験値獲得の効率を高めるためには、何よりまず戦闘をしていなくてはならない。戦闘以外では経験値が入らないからだ。つまり戦闘は長ければ長いほど良い。戦闘は敵を全て倒すと終わってしまうので、敵を倒さないでずっと戦い続ける必要がある。だから、味方同士で殴り合ったり回復し合ったり、というのを延々と繰り返すようになる。ここで例えば、パーティに回復役がいなかったらどうだろう。そういう繰り返しオペレーションはできない。

 そういう事態にならないように、戦闘にどういうキャラクタを参加させ、それぞれにどういうアビリティを持たせるか、という組み合わせが非常に重要になる。キャラクタの育成をしているわけなんで、戦闘に参加させるキャラクタはいずれも未熟である。如何にして未熟なもの同士を組み合わせ、戦闘での経験値獲得オペレーションを成功させるか、という想像力が必要になる。そういう設定をするのが編成画面である。

f:id:kura-replace:20140226033305p:plain

 編成画面でキャラクタの細かいセッティングをした上で、長時間の戦闘をやって経験値を稼ぐ、という感じ。まぁ、このゲームの説明はこの辺で終わりにしておく。

 

 さて、総プレイ時間を配分してみると、戦闘画面が最も長くて編成画面はそれより短くなる。その一方、編成画面でやったセッティングによって、戦闘中の経験値獲得オペレーションの幅は強烈に制限される。 戦闘中はひとつひとつ行動コマンドを僕が入力しているのだけど、まるで選択させられているような気分になるんである。あるとき、この感覚はまるで C++ とか Java を書いているときの感覚に似ている事に気付いた。

 プログラムを書くときは実行するときのことを想像している。ひとたび実行が開始されれば、プログラムに書かれている以外のことはできない。別のレイヤでも似たような関係がある。例えばフレームワークのプログラムを書くとき、利用者に余計な事をさせないよう、ある種の制限を課すような設計をする。利用者側のプログラムを書くときは、その趣旨に則った上で(=課せられた制限の中で)最大の利益を引き出すような実装にする。つまり、プログラムの実装と実行の関係、フレームワークの設計とそれに載せる実装の関係は、それぞれどちらも編成と戦闘の関係と類似している。

 これに気付くと、このゲームをプレイする事自体がまるでプログラミングをする事とイコールであるかのように錯覚する。武器を装備したりアビリティをセットしたりすることはプログラミングであり、編成画面とはプログラミング言語なのだと理解する。もちろんそこにはオブジェクト指向の匂いも無いし、コード片も無いし、文字入力さえも無いんだけど、確かにプログラミング言語としての手触りが感じられる。

 

 最近、「プログラマじゃなくてもプログラミングを学ぼう!」的な機運が高まっている。RubyPython のコードを書いてモンスターを倒し、ステージをクリアする、というようなゲーム性の高い学習サイトが台頭してきたのもここ最近の話だと思う*1。そういう「プログラミングを学ぼう!」という文脈の中では、具体的なコード片の入力を促すようなサービスが量産されがちで、今後も似たようなサービスが出てくると予想している。でもそれって「プログラミングを学ぼう!」というテーマが元々やりたかった事とは少し違ってしまっているんじゃないのか。そもそも、プログラマじゃない人がプログラミングを学ぶメリットは何かというと、物事をより抽象化して捉えるようになり、より抽象化して考えるようになり、最終的に日常生活へ何らかのフィードバックが発生するという、思考プロセスの総体的な変化であると、僕は考えている。だからそのために RubyPython の文法を覚えたり、コード片でモンスターを倒したりっていうのは、実はずいぶん遠回りになっているように感じられる。

 抽象的な思考を手に入れるためにゲームをやれ、という事を言いたいわけでは無い。でも、何故かよく分からないけどプログラミングをやるのが良さそうで、何かよく分からないけどプログラミング学習サービスの中で人気があるから、という理由でコードを書くくらいなら、もっと他の面白いと思える事をした方が良いよね、とは思う。いやまぁ、顔も知らないアカの他人がプログラムを学ぼうがゲームをしようが僕にはどうでも良いんだけど、子供ができて数ヶ月が経ち、少しずつ物事を理解していくさまを見ていると、学びっていうざっくりした領域の中で横たわる「抽象的思考の獲得」っていうのはどうやるのが良いんだろうかと気にするようになった。

*1:そりゃ昔からあったちゃあったんだけど

チャットと組織

生活

 仕事では常にチャットを開いています。

 チャットベースの仕事環境っていうのは今日び珍しく無いですが、僕の場合は在宅で仕事をしている都合上、オフィスとのコミュニケーションはチャットが 9 割ぐらいだったりします。たまに仕事を終えたあとで少し時間をとって、一日のログを全て読み返すようにしてます。「この時は、この人が言ってる事がよく分からないまま話を続けてたけど、こういう事を言ってたんだな」とか「この話をしてる時、あの人はあの作業してたんだな」とか、そういう事に気付いたりするわけです。

 で、今はチャットベースのコミュニケーションが身体に染み込んじゃったんですが、もしこれが声による会話ベースだったら?と思うことがありあす。声はログに残らないし*1、その時間・その場所に居ないと情報にアクセスできない、っていう、まぁそういう側面から見るとだいぶ不便な方法です。情報が後から閲覧・検索可能な状態としてログが残っているということは、コミュニケーションをする人と人の位置的・時間的な束縛からだいぶ手っ取り早く強力に解放してくれていることが分かります。

 一方、その対価として受け入れないといけないことは、知らぬ存ぜぬっていう逃げ道の狭さであるように感じます。チャットを使えば、メッセージのユニキャストもブロードキャストもマルチキャストもできますが、そのときディスプレイにはくっきりとその内容が、そりゃもう綺麗なフォントで印字されるわけです。そいで、スルーしたのであればスルーしたという事までログとして残り続けます。いやまぁ、僕もそんなに肩肘張ってチャットにかじり付いてるわけではないですけど、でもまぁ、スルーしたよね?と。あともう一つ、これはチャットに限らないんですが、ある話題が何かあったときに、その話題が進むにつれて興味が無い人が話題の輪から退席する、ということが非常にやりにくいです。声ベースの会話だったら一部の人だけが話を詰め進める一方であまり関係が無い人は徐々にフェードアウトするっていう事ができるんですが、チャットだと自分にあまり関係が無い話題であっても最重要な話題のときと全く同じくらい綺麗なフォントでディスプレイに文字が並ぶわけです。たまにそれがちょっと面倒に感じたりもします。

 で、ここまでのダラダラした話をグルッと丸で囲って、一歩下がって考えてみるに、チャットベースのコミュニケーションには人数的な限界があるな、ってのは少なくとも思います。例えば 100 人が一緒にチャットするってなると(そんなん実際ありえないけど)、比較的どうでも良い事を発言するのははばかれますよね。だからといって少人数で private room みたいなところで話を進めるとセクト化が進むし。。。で、こういう事を言うと「そんなん、声で話してたって一緒じゃない?」って話になるんですけど、これが全くその通りで、むしろ声で話すほうが人数の制約は強いと思います。思うに、「ある程度以上の手軽さを残したままで、メッセージを組織の中に飛び回らせる状態を維持できる人の数の制限」が、チャットベースでコミュニケーションしたほうが普通に会話でコミュニケーションするよりも緩いんじゃないかなと。よく、チームを組むときは 3 〜 5 人の少人数構成が良いとか言いますけども、実際にはそんな理想的に人をグループ化できるほど人の配置は簡単じゃないと思うんですよね。だから 3 〜 5 人っていう数字が大きくなってもそのチームが大丈夫でいられるスキーマが欲しいです。(僕は少人数のチーム編成が良い、という考え方そのものが逃げ・思考停止だと思っているので少しバイアスかかった意見ではありますが)そういうスキーマが欲しい、と恒常的に思っています。3 〜 5 人っていう数字の根拠になっているものの一つがコミュニケーション上の便益にあるなら、ツールとしてチャットを使うだけで実はその部分を解決できちゃうようなケースってたくさんありそうだな、とか、そんな気がしてます。

*1:録音すれば良いとかそういうツッコミは論点ズレるのでスルー

if コードレビューの障害 == コミュニケーション能力 then ...?

 「コードレビューはどうやるのが良いか」という話を、最近チョイチョイ見聞きします。その中で参加者のコミュニケーション能力がトピックになります。レビューの中で行う指摘が参加者の心を傷つけ、萎縮させてしまい、円滑にレビューが行えなくなるのって問題だよねー、的な話です。

 

コードレビューに参加する態度

 コードレビューでは誰かが書いたコードを別の誰かが確認・指摘するワケなので、肯定的な言葉よりも否定的な言葉を使う場面はやはり多いです。指摘を受けたからといっていちいち凹んで業務に支障が出るようではレビューをやる意義が薄れるように思います。とはいえ「間違いを指摘されたときに凹まない強靭な精神を持とう」とか言うのはアレなので、いちいち凹むような状況をつくらないように最低限の配慮をしていくのがベターでしょう。

 

原因はコードレビューの方法が悪いからでは無い

 参加者がいちいち凹まないようにするため、コードレビューの方法を工夫してルールを敷設する企業があるそうです。例えばこんなの。

 △「ここは××より○○の方が速い」

 ◎「[提案]ここは××より○○の方が速くなりそうなので○○の方が良いかなと思うんですが、どうでしょう?」

  こうしたルール付けはある程度の効果を上げそうですが、あんまり長続きしないような気もします。というのも、言葉には感情がにじみ出るものだろうからです。ルールで表現の幅を狭めたとしても、しばらく運用すれば、レビュー参加者はその狭い表現範囲の中に互いの感情の起伏を読み取るようになっていくと思います。まあだからと言って「ここ、エンバグしてるよバカじゃねーの?」とか書くのは問題外ですけども。

 で、「こういうルールを敷いたら以前より上手く回るようになったよ」という成功談があるからといって、「ああいうルール敷設をやっていないからウチではレビューがうまくいかないんだ」と考えるのはちょと違うだろうと思います。多分そういう環境ではコードレビュー以外の議論の場でも同じような問題が発生してるんじゃないでしょうか。コミュニケーションがうまくいかない現実を、コードレビュー方法の選択という小さい領域の中で解決しようとするのは、問題を過度に矮小化して認識してしまっている証左であって、それってちょっと残念な感じがします。問題はもっとずっと大きい領域にあるんだっていう認識を持つ事が大事でしょうね。

 

よく語られてる問題その2

 それとは全く別の問題で、「レビュアーが居ない問題」もよく語られてる気がします。レビュイーが最もそのプログラムに精通していて、一人たりともレビュアーとしてふさわしい人間が居ない状況って割とあるよねー、という話です。こういう場合にどうするか?

 ... というのはいくら検討しても無駄なので早々に人を増やしてもらいましょう。コードレビュー云々の前にそれはトラックナンバー1、すなわち開発組織の急所です。

 

結局のところ

 コードレビューの障害がコミュニケーション能力にある場合にどうしたら良いかっていう最初の問いですが、その答えとしては「ちゃんと開発チームの空気作りをやってコミュニケーション能力をある程度まで伸ばしましょう」という凡庸な結論に着地するのが良いと思います。総論としてそうしておいて、末論として現場の実情に応じた手を打つべし、打つべし、です。