「It Depends」は僕が一番嫌いな言葉だ

はじめに

「It depends。」

いつからか、この言葉はエンジニアの万能な答えになってしまった。アーキテクチャはどう設計すべきか？It depends。マイクロサービスを導入すべきか？It depends。どのフレームワークを使うべきか？It depends。

確かにその通りだ。ソフトウェア開発に銀の弾丸などなく、あらゆる技術的な意思決定は状況次第だ。だが、この言葉はプロジェクトを前進させる上では何一つ役に立たない。

日本では、エンジニアが「技術的に可能です」という言葉をよく使う。これは「やろうと思えばできるが、自分はやりたくない」ため、遠回しに断る表現として使われている。

正しすぎて無意味

自分の意見を言うと、相手は「It depends」と返す。さらに問い詰めると、相手はまた「It depends」と返す。最終的に「何も合意できなかった」という合意だけが形成され、解散となる。

It depends は、ほぼすべての文脈において正しい。だからこそ、この言葉は言っても言わなくても同じなのだ。料理中に火加減はどうすればいいか聞かれて、「大事なのは火加減だ」と答えるようなものだ。

逆に言えば、相手が「It Depends」と口にするのは、こちらのゴールが十分に明確でないため、相手がどう判断すべきか分からず、曖昧な返答しか出せなくなっている可能性もある。

だからこそ、僕が議論を進めるときは、目的や背景を事前に可能な限り共有し、お互いの認識が揃っている状態を担保してから解決策を探るようにしている。僕が以前書いた記事——買い物かごと槍を読んでみてほしい。今見ている景色は同じだろうか？それとも一方は果樹園を見ていて、もう一方はジャングルを見ているだろうか？

意思決定ができない理由

考えがないこと自体は悪いことではない。『完美決定之魂』という本の中で、物事は通常この3つに分類できると述べられている：

• すぐに決める
• 情報不足
• 決定期限

僕が思うに、意思決定ができなかったり意見が出せなかったりする理由は、大抵は情報不足だ。そしてこれは最も解決しやすい。お互いの情報格差を埋めさえすればいいからだ。考えがないということ自体も、実は一つの意見表明として扱える。「情報が足りないので判断できない」と言えばいいし、その分野に詳しくないなら「ここはあまり分からないので、まずは皆さんの意見を聞きたい」と言えばいい。

今後「It Depends」に遭遇したら、こう聞き返してみるといい：

1. それで、君の意見はどうなの？
2. 判断するためにどんな情報が必要？
3. その言葉を口にした目的は何？

どうすればプロジェクトを前進させられるか？

It Depends は、かつて僕がシニアエンジニアかどうかを判断する基準にしていた言葉だった。トレードオフを検討し、要求を明確にし、単に機能を作るだけの段階にとどまっていないことを意味していたからだ。

しかし、その成熟さは時に「態度を表明しない傲慢さ」へと変わり得る。考慮すべきことが多すぎるあまり、失敗を恐れて、本来やるべきことをすべて「It Depends」の一言で片付けてしまうのだ。

これは一種の自己欺瞞だ。その結果、何も言わなかった人間が道徳的優位に立ち、真剣に議論していた人間が未熟に見えてしまう。

プロジェクトを真に前進させる方法——それは、「It Depends」の重みを責任を持って引き受けることだ。論点を整理し、ステークホルダーの要求を明確にし、優先順位をつけ、不足している情報を補い、主体的にコミュニケーションを取ることだ。

• 今回はどちらを優先すべきか？
• どんな条件なら優先順位が逆転するか？
• このトレードオフのコストは誰が引き受けるのか？
• 判断を誤った場合、どちらの方向がリカバリーしやすいか？
• これは原則の問題か、それとも今回の例外か？

議論をここまで突き詰めて初めて、「バランス」が実行可能なものになる。そして決断を下し、結果に責任を持つ。間違っていれば振り返って反省し、調整した上で再び前進するのだ。

同じように、「プロセスより結果が大事だ」と言うのは簡単だが、その言葉をプロセスの改善から逃げる口実にしてはならない。短期的にはスプリント（無理なラストスパート）で成果を出せるかもしれないが、永遠にスプリントを続けられるわけではない。プロセスを改善しないのは、未来を前借りしているに過ぎない。

いくつか例を挙げよう。受託開発を行っていた中で、僕は何度かこんな議論に遭遇した：

• MySQL を使うべきか、Postgres を使うべきか？
• モノレポにするべきか、マルチレポに分けるべきか？
• フロントエンドとバックエンドでそれぞれどのプログラミング言語を使うべきか？

これらに絶対的な正解はない。このときチームに議論を丸投げしてしまうと、何の結論も出ない会議になってしまう。

「MySQL でも Postgres でもどちらでもいい」

「モノレポのほうが管理しやすそうに見えるが、リポジトリを分けるのも一理ある」

プロジェクトを進める上で、僕が最も忌み嫌うのが、このようにプロジェクトを前進させられない議論だ。そのため、僕は事前にチームを説得するための資料を用意し、表向きは技術スタックを決める会議に見せかけて、実際には僕の結論をチームに伝える場にしていた。どのような手法で評価すべきかについては、僕の以前の記事を参考にしてほしい：

Boring Technology 通常有「引入某個新技術」可以解決既有問題的想法，大多代表開發還沒有想得足夠清楚而已。不過要體悟這件事，通常需要時間積累。從碰到新技術眼睛會發光的少年到變成油光滿面的中年大叔。 random

僕は可能な限り「It Depends」の重みを背負い、最近のトレンドやクライアントの環境でどのような技術スタックが使われているかを含めて、なぜこのような意思決定をしたのかをチームに説明した。（もちろん、チームを自分の望む方向へ導くために、自分の好みを巧みに包み隠して提示することもできる）

それは意思決定を誤ったときのリスクを背負うことを意味するが、「It Depends」としか言えない人間や「ほら、言った通りだろ（I told you）」と言うだけの人間よりは遥かにマシだ。

以前の僕は何度か苦い経験をしたことがある。チームの議論が芳しくないのは分かっていながら、自分の考えを言い出せなかった。言っても無駄だと無意識に思い込み、SNSで愚痴を吐いて傷を舐め合って終わらせていたのだ。

おわりに

「状況による」を口癖にしてはならない。「状況」とは何かを明確にし、現在の状況はどうなっているのか、何に注力すべきなのか、どう決断すればプロジェクトが前に進むのかを語るべきだ。高い場所に立って冷笑し、皮肉を言うのは簡単だ。泥臭く手を汚し、自分の提案が実現可能であることを他人に納得させ、一歩一歩プロジェクトを前進させ、「It Depends」の重みを背負って進むほうが、よっぽど格好いい。