大企業の大規模システム開発でリアルに体験したアーキテクトの必要性

私が6人しかいない無名零細ベンチャーにいたころの話です。2010年代半ば頃ですね。私もまだ経験年数が全然一桁の頃のことです。

協力会社が大企業の、それこそCMでも日常的に見かける、日本を代表する企業の1社の案件で人を募集しているとのことで、助っ人として行ってきました（自社の業績が悪かったのもあるけど）。

このプロジェクトはとんでもない大炎上プロジェクトだったのですが、そこで思い知ったことや必要と感じたこともあります。

ちなみに社名は出しません。炎上のリスクとか辞めた会社の機密保持などがありますので。

グダグダなプロジェクトはまだ蔓延っていた

つい最近までIT業界の残業は酷かった（今もかもしれないけど）

IT業界は最近はマシになったとはいえ、ちょっと前（2010年代）までは終電や休日出勤が普通にありました。徹夜なんてプロジェクトもあり、人によっては徹夜を必殺技と言っていました。

平均残業時間は60時間くらいは普通で、200時間や300時間もの残業をしたことがある人もいました。そういう人たちは武勇伝の如く残業時間を自慢していました。

それが昨今は三六協定を意識している会社も増えてきたようなので、マシになってきたのでしょう。

名だたる大企業が160時間の大炎上プロジェクトを実施中だった

しかし私が助っ人として行った2010年代半ばの有名大企業のプロジェクトは、標準労働時間と残業時間が同じというとんでもない炎上プロジェクトでした。

8:30始業で、ほとんどの人が23～24時まで残業していました。睡眠時間は4～5時間しか取れていないでしょう。

日曜は休みのことが多かったようですが、土曜はほぼ100%出社でした。祝日は100%出社でした。

私は所属企業の意向で休日出勤を拒否し、残業も20時間程度に抑えました。

今思えば政治的事情もあったのだと思う

ここは想像なのですが、大企業ゆえに政治的事情があって、期限だけ決められていた可能性があると思っています。

そのプロジェクトでは、メンバーが「リスケしろ！」と何度も言っていました。しかしプロジェクトマネージャーの部長は「できない」と何度も返事をしていました。

どう考えても標準労働時間と残業時間が同じなんて異常です。しかもCMでもよく見かける有名大企業がこんなことをやっているのです。

まぁIT業界の方なら、誰でも知ってる有名企業でもそんな炎上プロジェクトがあるものだとよくご存じだと思いますが。

私の友人でも、誰でも知ってる日本を代表するくらいの有名企業に勤めていたときに、終電や休日出勤を何度もしたという人が何人かいます。

とにかくこういう状況ではリスケすべきなのですが、長時間労働と人海戦術で乗り切ろうとするのが炎上プロジェクトです。

どうしてもリスケできない事情の一つに政治的事情、すなわち期限を変えられないというものがあるのではないかと私は疑っています。

無理なものは無理だと言いたいですが（同意してくれるITエンジニアは少なくないですよね）。

ベテランを集めても何も手が出せないという現実

私がこの炎上プロジェクトに入ったときは、基本設計は完了しており、詳細設計が完了直前、これから実装に入るというところでした。

正確には基本設計が終わらなかったので、基本設計書をコピーして詳細設計書という名前に変えて、基本設計の続きをやっていました。これも炎上プロジェクトあるあるなのでしょう。

ところがここでとんでもない問題が発生していました。なんと新規システムの開発をやったことがある人がいないため、どう作っていいのか解らないというのです。

ちなみにこのプロジェクトは実施している大企業の方針もあって、経験20年前後のベテランを中心に集めていました。即戦力の優秀な人材を集めたいからとのことでした。

経験20年のベテランを沢山集めて、中には若手もいましたが、50人もいる大規模プロジェクトで、誰も作れませんって何なのでしょう？

これもIT業界の方ならあるあると思うかもしれません。これがあるあるなのも酷いのですが。

とはいえやったことがないことはできないのが多くの人にとって常識でしょう。だったら新規システムの開発経験がある人をアサインしろよと思うのですが。

出来そうな方法を提示すればプロジェクトは進み出す

まずはアプリケーション構造とサンプルを提示

そこで私はアプリケーション全体の構造、すなわち機能単位でどんなサイトがある、共通部品は何、DBアクセス層はこれなどの構成を考えました。

O/R Mapperは諸々の要件から選定や検証をしている余裕がなかったので、簡易的なものを自作しました。

そしてサンプルを作成して、全チームのリーダーを集めて解説しました。

当時経験10年にも満たない私が、経験年数が2.5倍もある人たちに解説するという摩訶不思議な光景ができていました。

この人たちは長年何をやって来たんだろう？何で経験の浅い私がベテランたちに解説してるんだろう？

こんな疑問もありますが、IT業界の方ならこれもあるあると思うでしょう。

むしろ私の場合は少数精鋭の会社で経験を積むことで、少ない経験年数でこういうことができるようになっていました。

前進できそうな空気感ができてきた

アプリケーション全体の構造やサンプルを提示したことで、プロジェクト内に前進できそうな空気感ができてきました。

それまではどうしていいか解らないとみんなが思っていたのが、正しいかどうかは別としてやり方が明確になったからです。

ある人は「合ってるかどうかはいいとして、詳しそうな人がこれでできそうと提示すれば、みんなが前に進める」と言ってくれました。

とはいえ大炎上中で絶対に納期に間に合わないことは明らかでした。となると頑張った証拠は作って、顧客と交渉してリスケでしょう。頑張ってもこのスケジュールじゃ無理ですと。

全体設計ができる人すなわちアーキテクトが必要

このプロジェクトは順番が逆

このプロジェクトでは全体構造の設計がなくて、実装に取り掛かれませんでした。しかしなんと機能ごとの基本設計はできていたのです。

全体の設計が解らないのに各機能の設計はできているのです。なんだか矛盾していませんか？

つまり全体設計ができるITエンジニアはとても少なく、単一機能（画面やバッチなど1個1個）の設計ができるITエンジニアはそこそこいるのです。それこそベテランならできて当たり前。

これを建物で例えると、建物全体の構造や採用技術は決まってないけど、部屋1つ1つの寸法や材料、内装は設計できているというようなものです。

あるいはマンションで、1世帯分の部屋のレイアウトや内装、水回りや空調の位置は決まっているけど、建物全体のサイズや素材、工法は決まっていないものです。

順番がおかしいですよね？

IT業界には建築士の役割を担う人材が不足している

ところで昨今のIT業界では、建設業界における建築士のような全体設計や技術選定ができる人が不足していると言われています。

幸いなことに先ほど述べた設計の順番がおかしい問題には気付いているのです。

IT業界における建築士（アーキテクト）のような人たちを、建設業界にならってITアーキテクトやシステムアーキテクトと言います。IT業界には建築士が不足しているのです。

今回紹介した大企業の炎上プロジェクトでは、画面や機能1個1個の設計はできるけど、全体設計ができていませんでした。まさしく建築士すなわちアーキテクトがいなかったのです。

ちなみにアーキテクトが何かということについては、読書記録があるので、こちらを参考にしてみてください。

アーキテクトを目指してみるのもいいと思った

私はIT業界でずっとプレイングマネージャーというスタイルでやってきました。

やっぱり私が好きなのも追求したいのもマネジメントと顧客のビジネス課題の解決です。

しかし最近はアーキテクトのスキルも身に着けた方がいいと感じています。

今回の記事を書くきっかけになったのも、今思えばあのプロジェクトはアーキテクトがいなかったんだなと思ったからです。

アーキテクトの勉強をすれば、システムの全体設計ができるようになり、顧客のビジネス課題の解決により貢献できます。

つまりマネジメントもアーキテクトもできるようになれば、顧客にとってとても嬉しいはずなのです。活躍の場はきっと増えるでしょう。

というわけで私はアーキテクトの勉強と経験を積んでみようと思います。

もちろんITエンジニアにとってアーキテクトは有力な選択肢だと思いますので、基本設計から実装、テストまで一通りの工程の経験を十分詰んだ方は目指してみてはいかがでしょうか？

終わりに

知識や経験が増えれば、過去の経験から学べることがなお増えますね。特に知識の幅を広げたときにそう感じます。

私は今までマネジメントとビジネスに重点を置いて勉強してきたのですが、技術面も強化すれば、技術面でイケていなかったことを過去のプロジェクトから学べると思うのです。

この記事はあくまでも一例ですが、キャリアの選択肢を考える参考になればと思います。

特に全体設計がイケてないプロジェクトを経験した方は、アーキテクトという選択肢を考えてみるのはいかがでしょうか？