2007-04-16

近況

最近の私はもっぱらサンプルからのコピペが仕事. コピペといっても Ctrl+C, Ctrl+V より少しだけインテリジェントだけれど, ライブラリが強力な上に文書の出来が良いから, 多くはサンプルの改変で済んでしまう. 面白くはないが生産性は高い.

コピペ・ハイウェイの渋滞にぶつかり, サンプルのないパターンに出会うこともある. そういう時は自分でコードを書く. でもだいたい動かない. Getting Started や入門書はざっと読んである. それでもわからない. 文書化されていない不具合や common pitfall だったりする. (間抜けな間違いもあるけれど...) こんなとき Google はあまり役にたたない. 使っているライブラリやフレームワークがよほどメジャーでない限り, 解決方法はなかなかみつらない. せいぜい自分と同じところで悩んでいる人がみつかる程度. 私が仕事で使っているライブラリもメジャーでない類に入る. リファレンスや入門書があるだけで, Web に記録された庶民の実体験は少ない. Java に対する C# みたいなかんじ.

仕方なく誰かに相談するのが次のステップ. ML や newsgroup に投稿する手もあるけれど, 幸い今回は専門家の同僚がいる. 私はいつも彼を頼りにコピペの穴を埋める. その同僚はプログラムの症状やコードからぴたりと原因を言いあてる. アイデアを出す. 私は両目からあふれるウロコを拭い, 感謝の言葉をつぶやきながらコードを修正する. 今度は動く. ばんざい. 日々これを繰り返し, 仕事は片付いていく.

パラサイト・プログラミング

かつて "おしえてくん" と呼ばれる初心者がいた. 私はその会社員バージョンかもしれない. Google はするしマニュアルも眺める. チュートリアルやサンプルの物色もする. でも頑張るのはそこまで. 実装内部のコードを追い試行錯誤を繰り返すよりは先人に尋ねるのを好む.

他人頼みをよしとせず, 自力での解決を好むプログラマもいる. そもそも頼れる相手がいないことだってある. 古参に囲まれた新人は忙しい先輩達に遠慮をしがちだ. 若者に囲まれた年寄りは自意識が邪魔をする. 面倒と遠慮の分岐点は時と場合によって異る. 図々しい性質の私は遠慮の重みが小さい. 面倒さが先にたって他人を頼る.

私のように他人頼みの傾向が強いプログラマことを "パラサイト・プログラマ", その様式を "パラサイト・プログラミング" と呼ぶことにしよう. 以下 PP と省略.

PP は仕事がはやく片づく. 検索結果から大量のハズレページを眺める時間, 見当外れのステップ実行をする時間はとても長い. (くたびれてサボる時間も長い.) これらをスキップできるから仕事は速やかだ. 一部には, こうした "ハズレ" の作業を貴重な経験と重視する向きもある. PP の価値観からすると, これは無駄なばかりか悪習ですらある. 10m の距離に音速で到達できる正解があるのに, 何ホップも遠くのサーバや数千数万行のコードを探るのは不合理に思える. 私はそんなスパルタを好まない. ラクできる時はラクをしたい. 同僚が知らないことは結局自分で調べるのだし.

とはいえ世の中タダメシは無い. 私の生産性はパラサイトされる同僚の労働時間と引き換えになっている. 私の場合は互いの給与に大差がないから, トレードオフはいまのところ割に合う. ただし黒字ラインの判断を誤ると PP は組織の生産性を奪うおしえてくんに戻ってしまう. 組織の生産性より定時退社を優先することもできるけれど, 労働倫理に適わない. 良い PP のためには自分の利益とパラサイト先の負担を最適化する必要がある. そのためのプラクティスを少し考えてみたい.

PP のプラクティス

PP をするとき, 自分の目的は問題の解決にある. あまり調整の余地がない. 一方でパラサイト先の負担は融通がきく. これを減らすのが基本になるだろう. メーリングリストでの質問プラクティス "技術系メーリングリストで質問するときのパターン・ランゲージ" や "質問の仕方" は似たような話題として参考になる. ML と違い, PP は相手を知っていて, しかも近くにいる. これは概して都合がいい.

ヒマをみはからう

相談するときは, 相手が休憩したりサボったりしているタイミングを見計らおう. 相談相手の負担はかかった時間だけではない. 集中しているところに割り込むと勢いを削いでしまう. さぼっている最中の割り込みならダメージは少い. むしろ気分転換になるかもしれない.

PP に相談される側の対策としては, 集中していることがわかるポーズをとるといい. ヘッドホンで耳を塞ぐ, 眉間に皺を寄せて画面を睨むなどがわかりやすい. "集中している時は邪魔をしない" プロトコルができあがるとお互い幸せになれる. もっともプロトコルに凝る必要はない. プログラマのサボりはふつうわかりやすい. ブラウザに 2ch/bloglines/youtube などが表示されていたら遠慮はいらない.

午前中や深夜は話しかけないプロトコルの亜種もある.

round-robin と failover

パラサイト先は複数あった方がいい. 一人が作業中なら別の人に相談することができる. チームや部署や違ってもかまわない. 広く先達を持とう. 一人がわからくても他を頼れる. 別の相手と相談して席に戻ると, さっきまでは集中していた近所の同僚が フィードやブックマークサイトの誘惑に屈しているかもしれない.

チームメンバを優先する

パラサイト候補が複数いるとき, 最初に相談する相手は誰だろう. いちばん詳しそうな人を選ぶのが確実だけれど, それ以外のチームメンバを頼るのもいい. PP で仕事を早く片付ければ, 相談された側はこちらに仕事を振り直せるかもしれない. 同じチームのメンバは PP の生産性向上から恩恵をうけやすく, そのぶん取引も円滑になる. チームが同じならやっている仕事も似通っている.

もしチーム内で問題を解決できなくても, メンバが問題にとりくんだ事実は残る. 他のメンバが同じ問題にぶつかる時(仕事が似ていればよくおこる), チームは解決方法の在処を既に知っている. チーム内での PP はアドホックなペア・プログラミングや デスクレビューだと考えることができる.

とりあえず聞いてみる

逆にパラサイト先をでたらめに選ぶ手もある. 仕事の内容が偏っていると相談相手が固定されがちになる. これは負荷分散の観点から望ましくない. ふだんアピールしないだけで物知りなプログラマは案外多い. 相談相手が直接答えを知っていなくてもいい. "僕のチームの XX さんがそのへん詳しいですよ" という風に 別の権威を紹介してくれることもある.

ただ, 忙しい時にこの方法をとると時間を浪費しがちだ. パラサイト候補とランチで一緒になったら, ふと思いだした風に相談するくらいでいい.

テディベア

でたらめに選ぶ戦略の亜種として, 後輩や新人を選ぶという手もある. 相手が答えを知っていることは稀だけれど, とりあえず説明してみよう. 新人が相手だと説明も丁寧になる. 丁寧に説明していると自分の中で問題が整理される. アイデアが浮かぶ. 達人プログラマに登場する "テディベア" 効果がうまれる.

"このトラバースが再帰...いや相互再帰になっていて...相互再帰っていうのは A が B を... あ! そうかそうかわかったありがとう!" などとつぶやきながら嬉しそうに立ち去る中年を前に新人は唖然とするだろうから, 後のフォローは忘れずに.

現物指向

相手に問題を伝える時は, 自分の推理は交えず事実(症状)を正しく示そう...というのは一般論. ソフトウェアで事実を伝えるのは簡単だ. 症状を再現してみせればいい. 再現したら, 怪しいと睨んでいるコードを示そう. 相談相手に思いあたる節があれば, "その関数の中を見せて" とか "あの設定は有効にしている?" というように何か具体的な指示をもらえるだろう.

画面を所有する

相談をする時はパラサイト先までノート PC を持っていこう. 症状を再現して見せるのに都合がいい. ノートがないなら自分の席まで来てもらう. そのときは席の近い相手を選びたい. 離れた席からおいで願うより, 椅子をひきずってこられる方がずっと気楽だ.

早めに辞退する

先達にもわからないことはある. 質問の答えに困っているようなら, 頭を下げてすみやかに撤収しよう. 好奇心旺盛で負けず嫌いなプログラマは, 知らないことや解けない問題を放置したがらない. だから質問に答えようと調査を始めてしまうことがある. でもそれは相手の時間を奪ってしまう. パラサイトできていない. 自分で調べた方がいい.

このとき画面の所有権が自分にあると都合がいい. ノート PC ごと撤収してしまうか, 画面で別の作業を始めてしまおう. (メール確認とかね.) それが諦めた合図になる.

なお, この挫折体験がつづくとパラサイト先にネガティブな印象を持たれてしまう. 難しそうな問題はうまく分散しよう.

感謝を示す

問題が解決してもしなくても, パラサイト先にはお礼を言おう. 問題が解決した時は, 喜びと驚きをもってそれを迎えよう. ふつう感謝をされるのはうれしい. 逆に "あー, やっぱり. 私もそう思ってだよ." などと知ったかぶるのは印象が悪い. じゃあ最初からそうやれと不満を持たれるだろう. ちょっと悔しいときもあるけれど, PP にエゴは余計だ. 目からウロコでしたよさすが親分ありがとう! と素直になろう.

支援を公にする

ミーティングなどで上司や同僚に進捗を報告する際には, パラサイトで受けた支援を大々的に acknowledge しよう.

誰が何を知っているのかは, 情報として共有しておく方がいい. それに自分の仕事能力を過大評価されるほど恐しいことはない. ほぼ間違いなく過労を招く. 単なる謙遜は消極性のあらわれと取られがちだが, 助けを借りたことを明らかにするなら悪い印象はない. ミーティング以外にも機会をみつけて積極的に先人を讃えよう.

記録を残す

パラサイトの力で問題を片付けて一息ついたら, 事の次第をメモしよう. 日報, Wiki, 適当な媒体を選ぶ. あまり真面目に書くとラクをした有難味が打ち消されてしまう. 深追いの過程は省き, 結論だけをさっさと書こう.

おいしい話

不具合の相談ばかりを持ち込むと, パラサイト相手に "自分はドメイン固有のバッドノウハウ集として利用されている" といった悪印象を持たれてしまう. もっと広く, たとえば設計上の意思決定なども相談に織り込もう. 設計上のモデリング, 各種トレードオフの決定などは プログラマにとっては "おいしい" 仕事だと言える. そうした相談は "自分はプログラマとして頼りにされている" と 前向きな印象につながるだろう.

相互寄生と巡回

他人のパラサイトには積極的に応じよう. PP の経済はパラサイト先がいないと成り立たない. だから自分のまわりには PP に寛容な文化を作る必要がある.

相談をうけたら快く応じるだけでなく, そもそも寄生しやすい雰囲気をつくりたい. 一日中ヘッドホンで耳を固めていては声をかけにくい. 仕事がはかどり集中している間はさておき, さぼっている/休憩している時はヘッドホンをはずしてオープンな姿勢を示そう. 画面を睨みながら唸る同僚に声をかけよう.

お茶やコーヒーを淹れたあとはカップを片手にフロアを一回りしよう. いかにもヒマそうにしていると声をかけてくる人はいるものだ. (上司の側は迂回すること.) この習慣をもつプログラマはこれまでにも何人か見たことがある. 彼らは冗談まじりにこれを "視察" や "巡回" と呼んでいた.

PP のスケーラビリティ

PP はスケールしない. 多くのパラサイト・プログラマが一人の博識凄腕に寄生すると, その人が枯れ果ててしまう. 一方で, そこそこ健全な組織ならスケーラビリティの問題は起きにくい. 文書化された知識や代々伝わる口伝があるなかでこそ PP は機能する. 賄いきれない PP が溢れている状態は, 知識の生態系が崩れている兆しだと言える. そんなとき PP は役に立たない.

それでも多くの職場で PP は有効だ. PP はコミュニケーションに体温をもたらす. グローバル化がフラットでアウトソースが分散でも, あなたの隣にはきっと, あなたの頼れる誰かがいると思う. グループウェアの隙間に息を吹き込もう.

まとめ