It Depends は僕が最も嫌いな言葉だ
# 雑談前言
「It depends。」
いつからか、この言葉はエンジニアの万能な答えになった。アーキテクチャはどう設計する？ It depends。マイクロサービスにするべき？ It depends。どのフレームワークを使う？ It depends。
言っていること自体は正しい。ソフトウェア開発に銀の弾丸はなく、あらゆる技術的判断は状況による。だが、この言葉はプロジェクトを前に進めるうえで何の助けにもならない。
日本では、エンジニアがこの「技術的に可能です」という言い回しをよく使う。あることが実現可能だと示す言葉だが、実はやりたくないので、婉曲的に断るために使っていることもある。
まるで自分のプロさをドブに捨てるような言い方だ。
正しいがゆえに意味がない
自分が意見を言う。相手は it depends と返す。さらに問い詰めると、相手はまた it depends と答える。最後には何の合意もないまま「合意した」ということになって、解散する。
It depends はほぼあらゆる場面で正しい。だから、この言葉は言っても言わなくても同じだ。たとえば、誰かが料理をしているときに火加減の調整を尋ねたら、「大事なのは火加減だ」と答えるようなものだ。
逆に言えば、相手が It Depends と言うのは、こちらの目的が不明瞭で、今どう判断すべきか相手に分からないため、あいまいな返答になっている可能性もある。
だから僕が議論するときは、できるだけ目的や背景を事前に共有し、互いの認識をそろえて、はじめて解決策を見つけられるようにしている。以前書いた記事——菜籃與長矛——も見てほしい。僕たちが今見ている景色は同じだろうか。それとも、一方は果樹園を見ていて、もう一方は密林を見ているのだろうか。
決められない理由
アイデアがないこと自体は悪くない。完美決定之魂 という本では、物事は通常次の3つに分類できると述べている。
- すぐに決める
- 情報不足
- 決定期限
僕は、決断できない、あるいは意見を出せない理由は、たいてい情報不足だと思っている。これは一番解決しやすい。双方で情報の差を埋めればいいだけだ。アイデアがないことも、実は意見として表明できる。「情報が足りず、判断できない」と言えばいい。その領域に不慣れなら、「この分野はあまり分からないので、まずは皆の意見を聞きたい」と言えばいい。
今後「It Depends」に出会ったら、こう聞き返せる。
- では、あなたの意見は何か？
- 判断するために、どんな情報が必要か？
- あなたがこの言葉を言う目的は何か？
どうすればプロジェクトを前に進められるか？
It Depends は、かつて僕がシニアかどうかを見極める基準だった。なぜなら、それはトレードオフを考え、要件を整理し、ただ機能を作るだけでは終わらないことを意味するからだ。
しかし、その成熟は、態度を明らかにしない傲慢さにもなり得る。考えるべきことが多すぎて、失敗を恐れるあまり、本来決めるべきことまで全部 It Depends の一言で片づけてしまうからだ。
それは自己欺瞞だ。結局、何も言わない人のほうが道徳的な優位に立ち、実際に議論している人のほうが未熟に見えてしまう。
本当にプロジェクトを前進させる方法は、It Depends の重みを責任を持って引き受けることだ。論点を整理し、ステークホルダーの要望を明確にし、優先順位をつけ、不足している情報を補い、主体的にコミュニケーションする。
- 今回はどちらを優先すべきか？
- どんな条件なら優先順位が逆転するのか？
- このトレードオフのコストは誰が負うのか？
- 判断を誤ったら、どちらの方向のほうがリカバリーしやすいか？
- これは原則の問題か、それとも今回は例外か？
議論をこの粒度まで進めてこそ、「バランス」は実行可能なものになる。そして彼らは決断し、その結果を引き受ける。間違えたら振り返って検証し、調整して、また前に進める。
同じ理屈で、「結果を重視してプロセスは重視しない」と言うのは簡単だが、それを口実にしてプロセス改善から逃げてはいけない。短期的にはスプリントで成果を出せるが、永遠にスプリントだけで乗り切ることはできない。プロセスを改善しないのは、未来を前借りしているのと同じだ。
いくつか例を挙げよう。僕が受託開発をしている中で、こんな議論に出会ったことがある。
- MySQL を使うか、Postgres を使うか？
- Monorepo にするか、Repo を分けるか？
- フロントエンドとバックエンドはそれぞれどの言語を使うべきか？
これらの議論には正解がない。このときにチームで議論すると、結論の出ない会議になってしまう。
「MySQL でも Postgres でもいい」
「Monorepo のほうが管理しやすそうだが、Repo を分けるのにも理屈はある」
プロジェクトを進めるうえで、僕が最も忌避するのは、こうした前に進まない議論だ。だから僕は事前に資料を用意してチームを説得する。表向きは Tech Stack を決める会議だが、実際には僕の結論をチームに伝えているのだ。どんな方法で評価するかについては、以前の記事を見てほしい。
僕はできるだけ It Depends の重みを引き受け、なぜその判断に至ったのかをチームに説明する。最近のトレンドや、顧客の環境でどんな技術スタックが使われているかまで含めてだ。（もちろん、自分の好みをうまく包装して、チームを望む方向へ導くこともできる）
それは決断の失敗リスクを僕が負うことを意味するが、「It Depends しか言わない人」や「ほら見ろ、僕の言った通りだ」と後出しで言う人より、はるかにましだ。
僕は以前、何度か損をしたことがある。チームの議論がよくないと分かっていても、自分の考えを出さなかったのだ。心のどこかで、言っても無駄だと思っていた。そして SNS で愚痴って、仲間内で慰め合って終わっていた。
結語
「状況による」を口癖にするのではなく、「状況」とは何かを明確に言葉にするべきだ。今の状況はどうなのか。何を重視すべきなのか。どう決めればプロジェクトの前進につながるのか。高いところから冷笑するのは簡単だが、手を汚し、自分の案が実行可能だと他人を説得し、一歩ずつプロジェクトを前に進め、It Depends の重みを背負って進むほうがずっとかっこいい。
僕はそういう人間になりたい。