遅いエンジニアリング

速さを求めて

ウンベルト・ボッチョーニ『立ちのぼる都市』1910。未来派の代表的な作品

大雑把に言って、近現代の技術とは「速さ」を求める営みであった。そして速さとは、技術にとって美意識の尺度であるとも言える。たとえばイタリアの詩人フィリッポ・マリネッティは、1908年の『未来派創立宣言』のなかで、現代技術の速さを次のように褒め称えた。

われらは世界に一の美なるものの加わりたることを主張する。しかして、その美なるものの速なることを主張する。広き噴出管の蛇のごとく毒気を吐きゆくレーシングカー、銃口を出でし弾丸のごとくはためきつつ飛びゆく自動車は、サモトラケのニケより美なり。^[1]

なんにせよ、現代を生きる私たちにとって技術に速さを求めるのは当たり前であるし、その思潮はますます強くなっている。そしてその潮流は私たちのビジネス環境を覆い尽くし、「より早く決断」し、「より効率的」に仕事をしようという声が高まり続けている。

一方で、見せかけの速さが失敗に繋がることもある。たとえば、業務で新たな取り組みをはじめるにあたって、「まずはやってみよう」と考えるのは一般的に良いことである。しかしその前向きな素早い決断が、思考放棄の言い訳であってはならない。たとえば、次のような経験をしたことのある人は少なくないのではないだろうか。

プロジェクトの実行責任者であるP氏は「問題は起きたら検討するので、まずはやってみて考える」という方針を崩さなかった。
その結果、「最低限採算が取れるようにラフでもよいので全体の設計を」と何度も主張したアドバイザーのN氏の提案も受け入れられず、結果としてプロジェクトの終盤ではマネタイズがボトルネックとなり（中略）、あまり良くないシナリオとなった。^[2]

このような苦い経験は、私たちに真っ当な示唆を与えてくれる。つまり、なんでもかんでも速くすればよいものではない、ということである。そのようなことだから、ここで私は、広く称揚されている「速くあろうとするエンジニアリング」に対して、「遅いエンジニアリング」の可能性を考えてみたい。

遅く考える

経済地理学者のベント・フリウビヤによれば、ITプロジェクトにおけるコスト超過率の平均値は73%であるという^[3]。つまり、たいていのプロジェクトにおいては見積もりの倍近いコストがかかるのだ。じつに大きな超過であるが、それでもまだ控えめなほうだ。下位18%のプロジェクトに絞るなら、その平均超過率は447%におよぶ。言い換えれば、見積もりの5倍以上のコストがかかるプロジェクトが珍しくないのである。実際このような惨状は、長い経験を持つエンジニアにとっては身に染みて感じていることではないだろうか。半年で完了するプロジェクトのはずが、2年が経過しても終わりが見えてこない。そのような仕事に携わった人も多くいるはずだ。そして重要なことだが、現代のビジネス環境のなかでは、このようなプロジェクトの遅延は命取りとなる。プロダクトが完成したところで、すでに時代遅れとなってしまっているかもしれない。

早く決めたいという衝動

さて、このような状況はどのように生まれてくるのだろうか。フリウビヤの主張によると、失敗プロジェクトには共通してみられる傾向があり、それは「すばやく考え、ゆっくり動く」ことにあるという。どういうことだろうか。たとえばフリウビヤは、失敗を引き起こす心理の一例として「固定化」を挙げている。それは次のようなものだ。

学者の言う「固定化」とは、ほかに選択肢があるかもしれないのに、それが唯一の選択肢であるかのようにふるまい、結果として予想以上のコストやリスクを負ってしまう、人や組織にありがちな傾向を言う。即座に行動に移れば、その後必ず問題が生じる。^[4]

総じて言うと、人には「早く決めたい衝動」がある。進捗が出ないことへの不安や、根拠のない楽観、自信過剰が、「まずはやってみよう」という安易な結論に人を飛びつかせる。それが失敗を生むのだ。そこでフリウビヤは、「ゆっくり考え、すばやく動く」ことを推奨する。少ない人数であれば、じっくりと時間をかけて物事を考えてもそれほど大きなコストは生じない。何人もの人手を使って予算を投じれば、それだけコストは高まるし、撤退も難しくなっていく。

選択しないという選択

もう少し深掘りしてみよう。ソフトウェアエンジニアリングにおいてはどうだろうか。

たとえば、アーキテクチャや技術の選定はのちのちに大きな影響を及ぼすのだから、拙速に決定することは得策とは言えない。個々の機能開発においても、安易な実装は技術的負債を生む。そのようなことだから、高名なプログラマーのロバート・マーティンは、「ソフトウェアをソフトに保つには、できるだけ長い期間、できるだけ多くの選択肢を残すことである」と述べている。

アーキテクトの目的は、方針とは無関係に詳細を決めながら、方針をシステムの最も重要な要素と認識するシステムの形状を作ることである。こうすることで、詳細の決定を延期や留保することができる。^[5]

つまり、なんでもかんでも素早く決断するのではなく、意思決定を遅らせ、選択する余地をなるべく残しておく。それが良いアーキテクトの条件だ。そうすることでより多くの判断材料が得られるし、選定した技術が時代遅れになることも少なくなる。

遅く学ぶ

現代の技術の発展は目まぐるしいのだから、より新しいことをより素早く、より効率的に学ばなければいけない。そう考えている人が多いのではないだろうか。もちろん、努力してそれを実践する人は立派な人である。とはいえ、そこにも落とし穴があることを忘れてはならない。

本を50冊読む？

面白法人カヤックの創業者である柳澤大輔は、どこかの産業に参入する際には、その産業に関わる本を50冊ほど読むことを心がけていると述べている^[6]。そうすることで、個々の著者のバイアスにとらわれない広い視座を獲得することができ、また、業界用語を身につけることで、識者との円滑な会話が可能になるという。
しかしながら、本を50冊読むというのはたいへん時間のかかることだ。月に10冊読んだとしても半年近くかかる。早く簡単に、つまり「効率的に」学ぼうという人からすると、いかにも鈍重で、古臭いやり方と思えるかもしれない。しかし考えてみよう。本当に効率的な学び方などあるのだろうか？効率的に学んだところで、それは実際に身についているのか？

早く学ぶと早く忘れる

そのような疑問に答えたのが、2024年にスマッシュヒットとなったエンジニア向けの啓蒙書『世界一流エンジニアの思考法』である。マイクロソフトのシニアソフトウェアエンジニアである牛尾剛によって著された本書には、次のようなくだりがある。

どんなに頭がいい人でも理解には時間がかかるものなのだ。頭がいい人が理解が早いように見えるのは、そうやって時間をかけて基礎を積み重ねているので、既に理解していることに関して頭のメモリにコンテキストが載っているからだ。（中略）
理解が十分でないまま手を動かして努力しても、空回りになるだけで身につかず、あやふやの試行錯誤は取り組んだことも忘れやすく頭に残らない。
「何かを早くできるように急ぐ努力」がかえって本質的な理解を遠ざけてしまうのだ。^[7]

早く効率的に学ぼうという試みは、表面的な理解に留まったり、最初に小さな「動くプロダクト」が得られたとしても、その先の大きな事業に繋がらないことが多い。そのようなことだから、新しい話題に闇雲に飛びつくだけではなく、ひとつのことに時間をかけてじっくりと学んでいくことも必要なときがあるのだ。

遅いエンジニアリングとアジャイル

ここまでの議論を振り返ってみて、アジャイルソフトウェア開発との関わりについて疑問に思う人もいるだろう。アジャイルとは「素早い」「機敏」であることを意味しており、ここまで筆者が述べてきた「遅いエンジニアリング」は、アジャイルの思潮とは真反対のことを言っているように思えるかもしれない。またアジャイルムーブメントは、ビジネスシーンに伝わって「リーン」という言葉で普及してもいる。それでは遅いエンジニアリングとは、アジャイルやリーンに対して反対するということだろうか。本論の最後に、それについて簡単に述べてみたい。

結論から言うと、両者はそれほど矛盾していない。私見ではあるが、アジャイルソフトウェア開発の目的のひとつは「早く学ぶこと」だが、それと同時に「学び続ける」ことでもある。だから結果的には、「遅く学ぶこと」と大きく違わない。実際、アジャイルソフトウェア開発を適用したフレームワークのひとつであるスクラム開発では、ひとつのスプリントのなかで決められたタスクに集中し、スプリントから漏れたタスクには手を触れない。それが、不要な意思決定を遅らせることにつながるのだ。このような小さな共通項であれば、挙げればキリがないため以上で止めておこう。とはいえ、アジャイル（素早い）やリーン（無駄がない）という言葉が、これまで誤解され、速度への過剰な期待を生んできたことは認めざるを得ないだろう。「まずはやってみよう」という言葉は、しばしばリーンを後ろ盾にして乱用されてきた。

実際アジャイルは、素早い学びを得られたとして、プロダクトの開発が早く進むようになるわけでも、効率的になるわけでもない。スクラムトレーナーのクリスティアーン・フルヴァイスらは次のように述べる。

広い意味で、スクラムフレームワークは効率的であるより効果的であることに重きを置いている。（中略）スクラムフレームワークによって効率を改善することは十分可能だが、それ自体は保証されたことでもゴールでもない。^[8]

そのようなことだから、速さや効率を求めようとする考え方には、慎重な姿勢を示さなければならない。もちろん、なんでもかんでも遅くてよいわけでもないが、ときに遅いエンジニアリングが必要になることを踏まえておくとよいだろう。

脚注

1. 森鴎外による翻訳をもとに一部を改めた。

2. 尾花山和哉, 株式会社ホクソエム 編『データ分析失敗事例集: 失敗から学び、成功を手にする』2023, 共立出版, pp69-70

3. ベント・フリウビヤ, ダン・ガードナー 著, 櫻井祐子 訳『BIG THINGS　どデカいことを成し遂げたヤツらはなにをしたのか？』2024, サンマーク出版, pp347

4. ベント・フリウビヤ, ダン・ガードナー 著, 前掲書, pp66

5. Robert C.Martin 著, 角征典, 高木正弘 訳『Clean Architecture 達人に学ぶソフトウェアの構造と設計』2018, KADOKAWA, pp151

6. 筆者は学生の頃、大学生向けイベントに登壇した同氏がそのように語っていたのを聞いている。同様のことは、右記の記事でも触れられている。 https://note.com/readhubinc/n/nd8979e3a5b20

7. 牛尾剛 著『世界一流エンジニアの思考法』2023, 文藝春秋, pp28-29

8. Christiaan Verwijs, Johannes Schartau, Barry Overeem 著, 木村卓央, 高江洲睦, 水野正隆 訳『ゾンビスクラムサバイバルガイド: 健全なスクラムへの道』2022, 丸善出版, pp40-41