とある新人プログラマーとアクアライン、あるいは人はいかにして失敗プロジェクト研究家になるのか？
NHKの「新プロジェクトX」で、東京湾横断道路（アクアライン）の建築プロジェクトが取り上げられていた。この番組については新しい本でちょっと揶揄するようなコラムを書いたりしているので、微妙なスタンスなのだが、まあプロジェクトストーリーって面白いよね。
僕はこのプロジェクトの末端の末端に関わっていた。もちろん土木工事ではない。
新卒後、研修を終えて2ヶ月後に参加したのが「アクアラインの借金償還シミュレーター」を作るプロジェクトだったのだ。
アクアラインは道路公団ではなく、第三セクターの株式会社が発注主になって建築された。
で、完成したら道路公団から毎年お金をもらって借金を返すのだが、株式会社なので毎年の収支によっては利益が出て法人税がかかったり、お金を返す期間が長くなると金利負担が大きくなったり、大きなお金が動くことになる。
僕らが作っていたのは、30年、40年かけてどの様に借金を返すとベストなのかを探るためのシミュレーターだった。
当時は「30年後の日本がどうなっているか分からないので、シミュレーションって当たるのかな？」と思いながら仕事していたが、あのプロジェクトからちょうど30年経つ。思い出をいくつか書いてみよう。
【思い出①：アサインされたら炎上していた】
研修明け2ヶ月の段階でアサインされた。研修では机の上でCOBOLを紙に書いていただけだったので、事実上の初プログラミングである。
※ちなみにアーキテクチャとしては「スタンドアロンのWin3.1上にOracle＋SQL-Windows」という感じ。これについては後述。
で、入ってプロジェクトを見渡すと、炎上していた。
納期は1.5ヶ月後。だがプログラミングは全てこれから、という状態（設計は大体できていた）。当時は初めてのプロジェクトだったので「こんなもんか」と思って仕事に取り掛かったが、今なら発狂している。
その中で僕が担当することになったのは、システムのメインとも言えるシミュレーションバッチだった。
システムには借金の額や金利などの情報を登録する画面など、様々な機能があったが、すべてのデータは僕が担当するプログラムがシミュレーションするためのもの。システムのコア中のコアのプログラムだった。
流石に当時も、頭おかしいんじゃないかと思いましたね。
というのは、研修後に2ヶ月配属されていた小さなプロジェクトでは、僕は相当ダメなプログラマーだったからだ。
なのになぜ、俺？
ド新人でダメプログラマーだったのに？先輩だって何人もプロジェクトにいるのに？
（※このときのダメっぷりは随分前にブログに書いた）
https://blogs.itmedia.co.jp/magic/2013/04/1-e80d.html
【思い出②：謎のバグに悩まされる】
とはいえ1.5ヶ月しかない。
仕様書を読み込み、一生懸命プログラミングしていった。
ある程度順調に進捗していったのだが、納期まで3週間くらいのタイミングで、シミュレーション中にプログラムが落ちる現象が発生した。
シミュレーションプログラムなので、1年ずつ会社の収支や法人税額などを計算するのだが、10年目までシミュレーションが進むと、必ずプログラムが止まってしまうのだ。10という数字に何か意味があるのか？？
納期が迫っているのに、どうしてもこのバグは解決できなかった。
結局丸3日ほど無駄にして、ようやくミスを発見できた。
（バグの原因はとあるファイルをOEPNしっぱなしでCLOSEしなかった、という単純なミス。不思議なのはそんなミスがあっても9回までは問題なく動いたこと。10回目に耐えきれなくなって？エラーになるという挙動だった）
プログラマーとしてそれ以降もいくつもバグを作ってきたが、あれが最も悩まされ、最も情けないバグだった。
【思い出③：納品と自信】
結局、月に350時間くらいのペースで働き、最後の2日間は会社に泊まったりして、なんとか期限内に納品することができた。
僕が作ったシミュレーションプログラムが、お客さんの収支予測データを1年1年、コツコツと書き込んでいくのを見た時はちょっとした達成感があった。
そしてようやく「プログラマーとして飯が食えるかも」と思うことができた。その前のプロジェクトでは落ちこぼれという感覚を持っていたので。
【だが待てよ①：なぜこの設計？】
慌ただしくプロジェクトが終わり、別の仕事にアサインされた。だが初めての大きな仕事だったこともあり、その後折に触れて何度もあのプロジェクトについて思い出すことになった。
例えばあの頃、データベースを活用したシステムのプログラミング、設計についての本を乱読していた。
本を読む時は必ず具体的なモノに引き寄せながら理解するようにしている。「ここに書いてある設計の原則をアクアラインのシステムに当てはめると、こうすべき」のように。
だがそうやって勉強を進めながら振り返ると、「どうしてあんな設計だったんだろう？」「いま自分がゼロからあのシステムを設計したら、絶対ああいう設計にはしないな」と思うことばかりあった。
※ベテランエンジニア向けに簡単に書くと、そもそもシミュレーションのバッチプログラムをSQL-Windows（Windowsで画面を作るためのツール）で書くのが意味がわからない。Oracle使っているのならストアドプロシージャで作るべき。
そうして「基本設計のダメさはそれ以降では取り戻せない。」ということを学んだ。経営戦略の世界で「戦略のミスは戦術では取り戻せない」と言われるように。
一生懸命プログラミングしたので動くシュミレーターにはなったけれども、長持ちするシステムにはならなかったはずだ。
そして、僕はずっとプロジェクトを主戦場にしているので、この話の相似形とはずっと付き合っている。
・要件定義のダメさは、基本設計以降では取り戻せない
・施策がショボいと、一生懸命システムを作っても成果が出ない
・プロジェクトゴール設定のダメさは、それ以降では取り戻せない
【だが待てよ②：何をシミュレーションしていたのか？】
僕が必死になって作ったのは、冒頭に書いたように、巨額借金の償還シュミレーター。
だがシュミレーターを回してみると、うまく結論が出る時と、「収束しない」として、シミュレーション失敗になる時があった。
お客様も先輩も「こういうものだ」と言っていたのだが、僕は不思議に思った。
だって道路の利用料をもらい、借金の返済をして、利益が出たり出なかったりする。それをシミュレーションしているのに、「収束しない」ってどういうこと？現実の会社はどうなってしまうの？
シミュレーションの計算式に何か問題があるのではないか。
そう思って先輩に聞いてみたのだが、誰も「なぜこの計算式なのか？」について答えられなかった。
どうやらお客さんが雇った「コンサルタントさん」が導き出した計算式らしく、（お客様を含めて）誰も深くは理解していなかったのだ。
確かに僕の会社が請け負っていたのは、その計算式どおりにシミュレーションするシステムを構築すること。責任は果たしている。
だがビジネスにどう寄与するかを理解できないまま、システムを作るのはダメなんじゃないだろうか。
遅かれ早かれ「言われたとおりにプログラミングする人」から抜け出して、「どういうシステムを作り、どうビジネスに貢献するのか？」を考える人」になるべきなんではないだろうか？
みたいなことを、ぼんやりと考えるきっかけとなったのも、このアクアラインのプロジェクトだった。
【だが待てよ③：なぜ炎上していたのか？】
「1.5ヶ月後に迫った納期に対して、ド新人が例外的な活躍をすることにすべてをかける」というのは、どう考えてもヤバイ状況だ。
他にも、色々とシッチャカメッチャカだった。
ほとんど初めて参加したプロジェクトではあったが、流石にこれはおかしい、と思った。
先輩たちが怠けていたのなら、まだわかる。
そうではなく、みんなあんなに一生懸命やっていたのに。
それでもあんなにめちゃくちゃなことになっていたのは、一体なぜなのか？
プロジェクトって普通にやると大失敗するのか？
そういう疑問は拭えなかった。
いくら空気を読まない人間と言えども、先輩の前でそれは口に出さなかったけれども。
このプロジェクトはその後の僕のキャリアに決定的に影響を与えた。
良いデータベース設計者になるべきだ。
炎上させないプロジェクトマネージャーになるべきだ。
方法論の研究をするべきだ。
研究した方法論を広く世間に伝える著述家になるべきだ。
そして、失敗プロジェクト研究家になるべきだ。
みなあのプロジェクトから地続きだ。
大手ゼネコンさんの採用キャッチコピーで「地図に残る仕事。」というのがある。ぐっと来る、いいコピーだ。実際に「プロジェクトX」で紹介された、トンネルを掘った方々はそういう仕事をされていたと思う。
僕が参加したアクアラインプロジェクトの末端は、地図に全く残らない、地味でカッコよくない末端のサイドストーリーでしかなかった。
だがその後の僕にとっては重要な「プロジェクト×」だった。
いまでも房総に行くたびに、あのプロジェクトのことをチラっと思い出す。
*******************出版情報
いままでプロジェクトを成功させる方法についての教科書を書いてきましたが、初めて「プロジェクトの失敗」をテーマに「プロジェクトを失敗させる55の罠」を書きました。
いまは執筆と推敲が終わり、ページデザインとイラストのレビューなどをしています。
恐らく発売は来年の2月か3月。
「これを読まずに変革プロジェクトに挑むのは無謀でしかない」というレベルの本にはなった自信があります。