前提を変える力って大事だなぁと、ふと思ったので駄文を書く。
前提を変えれないと戦略を間違う
アプリケーションコードに何百行・何千行の関数のような負債があったとする。そのアプリケーションにはテストコードがない。リファクタリングをしたいが、どうすれば良いか。
- A. 頑張ってリファクタリングする。手動でテストをする。
- B. アプリケーションを捨てて新規に作り直す。
- C. 周辺のテストコードを書く。そしてリファクタリングする。
ご存知のとおりAやBは茨の道だ。もちろん状況によっては選択しても良い。ただ、Cという選択肢を検討せずにAやBを選択するのは良くない。 Cはテストコードを書くことによって「テストコードがない」という前提を変えている。
このように前提を変えれることを知らずに、あるいは前提を変えることを考えずに判断してしまうケースは多々ある。インフラを知らないエンジニアが、インフラで解決すべき課題をアプリケーション側で無理やり解決する、あるいはその逆のパターンはよくある話だ。
フルスタックとフルサイクル
前提を変えれるかどうかの勘所は経験やスキルに強く依存している。 たとえばフロントエンドもサーバーサイドもインフラもわかるフルスタックエンジニアは前提を変えやすい。アーキテクチャを正確に理解し、解決手段の引き出しが多く、前提を変えれることを知っているからだ。
フルスタックでなくても、サーバーサイドエンジニアがフロントエンド・インフラ担当のエンジニアと密にコミュニケーションを取れれば、前提を変えることができる。企画・要件定義からリリース・分析・運用まで入れば、より大きく前提を変えることができる。これがフルサイクルエンジニアと呼ばれるロール・スキルなのだと思っている。
技術に依らない
そしてこれはエンジニアリングに依らない。ビジネス・組織・業務プロセスなどあらゆる領域で変えることができる前提がある。前提を変えるために必要なステップがある。それらの引き出しが仕事力と言われるものになるのだろうし、ビジネスを力強く推進できる能力になるのだと思っている。あるいはビジネスとは前提を変えることなのかもしれないなぁ、とか。