ある状況下において、特定の開発者たちが他の人の10倍生産性が高くなることがあるのはなぜかについて議論してみましょう。
ヒント : 開発者の話ではなく、状況が大きなカギ。
生産性が非常に高いことにウキウキした気分になるのはいつでしょうか。新しい機能が指先からあふれ出てくる時？それは、私たちが関わるツールのことを知り尽くしている時、あるいはもっと決定的に言うと、自分がシステムを変更しつつある時に起こるのです。自分のバックパック、それも自分で詰め込み、そしてひとつひとつの小袋の中まで何年にもわたる旅行を経て調整してきたバックパックの中身を知っているように、システムを知ることです。それぞれのモジュールの中身、それもそれがどんなもので、リファクタリング完了後にどうあって欲しいのか知ることです。システムの端っこまで知ること、つまり誰がそれぞれのAPIを使っているのか、どんな変更が誰に影響するのか。そしてあらゆる利害関係者と友達になるのです。基礎部分を知ること、つまりデータベースのどの列にインデックスがあるのか、何がもう使われていないのか、特別な扱いを要する値はどれか。インフラを知ること、つまり本番環境はどこで動いているのか、どうやってSSHしてそこに入るのか、テスト環境はどこで動いているのか、どのバージョンがデプロイされているのか、どんな時なら新しいものをプッシュしても安全なのか。出力を知ること、つまりログの何が正常を表していて、何が問題の手がかりなのか。私たちは、3台の本番インスタンス全部からログをtailしてきてターミナルに表示するワンライナースクリプトを作ったので、異常を発見することができます。
私たちはそれを知っています。なぜなら普通は自分たちでそれを書いたからです。すでにそこにあったシステムに対してこのような深い知識のレベルまで持つのは至難の技です。Braitenbergはこれを、「下りの発明、登りの分析の法則(Law of Downhill Invention, Uphill Analysis)」と呼んでいます。複雑なシステムは、動き始めた後にそれを解明するよりも、作る方が簡単であるということを表しています。
私たちがそれを知っているのは、私たちがそれを変更しているから。システムは私たちの頭の中で生きているのです。これは共生関係のようなものです。システムが動き続け成長するのを私たちが手助けし、システムは私たちの望むように動いてくれる。1ヶ月か2ヶ月そこから離れて他のシステムとの関係を始めると、この魔法は失われてしまい、また親密さを取り戻すまでに時間がかかります。
ただし、私はここの記述に疑問があります。「私たち」は複数形です。このレベルのシステムとの親密さや快適さは、個人的なもの、つまり通常ひとりしかそういう人はいないのです。その人とは、解決策を考え出した人であり、現在の状態と今後の行き先の両方を頭に入れている人なのです。
もしあなたがそんな人なら、 あなたがやっているような仕事ができる人は誰もいない ということに気づいてください。他の人にとっては、何が起こるかわからないのであらゆる変更を加えるのが怖いのです。彼らは、それぞれの部分がどのように動くのか時間をかけて理解していき、それから経験を通じて確認するのに大変です。あなたがやったようにテストできるわけではないのです。彼らは、関係なさそうなログをざっと見たり、あなたがもう見もせずにスキップしてしまうようなログメッセージをひとつひとつ確認しています。時間が経って彼らが理解し始めた頃には、もうあなたは変更を加えてしまっています。彼らには、あなたが変更を加えるのと同じスピードでシステムの理解度を上げることはできないのです。彼らがシステムに変更を加える時には、何がどのような問題を引き起こすのかをよく知らないので、その変更の影響範囲を小さくするのに長い時間をかける必要があります。もしそれが失敗したなら、それは彼らがユーザーを知らないせいです。コミュニケーションは難しいのです。
もしあなたがそんな人なら、他の人にやさしくしてあげてください。あなたは合成化学者でDNAを内部から変えることができるのに、彼らは外科医であり皮膚に切り込みを入れて触ったこともない臓器を傷つけないように手術する必要があると考えればよいのです。
もしあなたがそんな人と仕事をすることになったら、残念なことです。それは大変なポジションで、常に劣等感を持ち、触るものすべてを壊しているかのような気分になるでしょう。私は、システムのある部分に関しては、今そんなところにいます。そのソフトウェアの作者であり操作者でもある共同作業者は、とてもいい人で協力的です。彼は、彼がやるのと同じような方法で仕事することを私に期待してきたりはしません。
もしあなたのチームがそんな風になったら、以下のステップをたどってみましょう。
- まず、(今のやり方自体は)変えないことです。これはソフトウェアを最も高速に開発する方法です。システムが一定規模より小さいなら、他の開発者と調整する必要がない開発者1人は、チームでやるよりもずっと素早く動けます。ただしこれは、システムをより大きくしようと考え始めるまでのことです！あるいは、そのシステムがビジネスに不可欠なものになる前までです！(たったひとりの人間だけがそういったシステムに対する権限を持っているのは許容できないリスクです)
- あなたがそのシステムに熱中しているその人なら、「〜なだけ(just)」「簡単(easy)」「明白(obvious)」「単に(simple)」「分かりやすい(straightforward)」といった単語は辞書から消してしまいましょう。これらの単語には背景が必要で、その背景を理解している人などいないのです。
- テストを書いてください。テストは、意図せず何かを壊してしまうことを恐れている人が、今からやろうとしていることを試す方法です。システムがどう動くかを学習するのに、実験してみるのはとても重要なことです。そしてテストはそういった実験を可能にしてくれます。またテストは、意図する動作とは何なのかを示すドキュメントとしても役に立ちます。
- ペアプログラミングしましょう！システムに関する理解を他の人に教えるのに間違いなく一番いいのは、一緒にそのシステムを変更することです(あるいはチームみんなで一斉にプログラムに取り付いてみましょう！)。
- 他の開発者のためにREADMEを書きましょう。システムの目的を簡単に書き、どのように開発するか、どのようにテストするか、どのようにトラブルシューティングするかを書きましょう。テストを実行するコマンド、デプロイするコマンド、ログにアクセスするコマンドを書きましょう。必要なパスワードを知る方法を詳しく書きましょう。システムが動く全ての環境を書き、その環境を変更する方法を書きましょう。
- ユーザーのことを誰よりも知っているのはあなたですか？それは改めましょう。他のチームメンバーを議論に参加させましょう(あるビジネスユニット内で開発者ひとりで仕事ができてしまうスイートスポットが存在します。しかしソフトウェアがこのスケールに対しては重要すぎる存在になった時には、難しくなってきます)。全ての開発者がユーザーのことを知れるようにしましょう。ハッピーアワーもやりましょう。コミュニケーションチャネルを複数持ちましょう。あなたが知り得なかった形で効果があるはずです。
- スピードを落としましょう。実際、プロジェクトであるひとりが全速力で開発していたら、それについていける人などいません。最高速で開発しつつ共同作業者を追加するのは無理です。誰か新しい人を連れてくるのが重要なら、ひとりでやってしまっていいことは何もないと考えましょう。なんでもペアリングしましょう。そう、そうすればあなたのスピードは落ちます。一方で、彼らのスピードを上げます。それでもあなたがひとりで作業するよりも全体としては遅いでしょう。これは、人間同士の調整が必要になる大規模なシステム特有の性質です。あなたとあなたのプログラムのことだけ考えればいい時よりもずっとオーバーヘッドがあるのです。でもそれでOKです。高速さから、安全とスケールを得るためのトレードオフです。
他の人の10倍の生産性で動ける開発者と状況の組み合わせが本当にあり得るということを知っておきましょう。そしてそういう状況はスケールしないということを知っておきましょう。ローカルあるいは個別の自動化のスイートスポットの恩恵に預かれるのはいつなのか、バス係数(訳注 : 何人が「突然」いなくなってもプロジェクトが回るか)が1であるには重要すぎるシステムを作っているのはいつなのかの判断をしましょう。
変更スピードと素早い進路変更が重要な実験的プロトタイプと、後方互換性を保証することとドキュメントとそういったあらゆる深刻さが要求される本番アプリケーションとを区別しましょう。後者には、しっかりしたチームが必要です。
最も生産性高く開発できるのは珍しい場面であることを認識しましょう。多くの場合、既に誰かが書いたシステムを触る必要があります(「誰か」は「数ヶ月あるいは数年前の自分」の可能性もあります)。書き換えてしまえば理解できるので、書き換えたくなる衝動は大きいでしょう。
つまりは、10倍の生産性で開発するべき時と、チーム開発すべき時があるということです。真剣に開発したい時には、10倍の生産性で開発する開発者は邪魔になります。そういった時には、この記事に書かれた提案のことを考えてみてください。
