DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

今回のブログは技術的な観点からちょっと離れて、プロジェクトにおけるアーキテクトの振る舞いについて、人間系の話をしてみたい。本音の独白なので、ある意味”ブログらしい”かも知れないが、”設計の勘所”を期待している読者には興味のない話かも知れないので悪しからず。

私が現在までに手がけた期間1年以上のシステム開発プロジェクト数は17案件、そのうちユーザ企業在籍中に14件（内インフラ系が3）、サービス側に転向してからが3件である。インフラを除く全てのシステム開発プロジェクトにおいて、アーキテクト（内5,6件はPMも兼務）として参画した私は、多かれ少なかれ本タイトルの”葛藤”があったと記憶する。

アーキテクトが描くシステム完成後の姿は、いたって美しいものである。新システムはドラスティックな業務改革をもたらし、将来のビジネス変化に柔軟に対応でき、新しいテクノロジーをとり入れた魅力溢れるものである。そしてもちろんそれは、予算、納期を満たすものである。

プロジェクトのスタート〜要件定義を終える頃までは、アーキテクトが描いた青写真は、ほぼ原型通り推移する。経営サイドへも十分な訴求ができ、バラ色の未来が予見される。正に、アーキテクトが光り輝く時期である。

さて問題はこれからである。基本設計（外部設計）に入り、要件を実現するITの具体的打ち手を考え始めた頃、徐々に様子が怪しくなってくる。始めて構築全体の工数見積りが出た所で、その怪しさは最初のピークを迎える。怪しさの正体は、プロジェクトを平穏無事に終わらせよう！という悪魔の囁きである。そしてこの囁きの張本人はプロジェクトマネージャーに他ならない。

ベンダーによる構築のアウトソースが一般化した今日、リスクを上乗せした当初予測を上回る工数算出がきっかけとなる。全体最適を標榜するアーキテクトと、背に腹を変えられず部分最適で切り抜けようとするPMとの戦いが始まる。”戦い”と書いたが、「お互いが相手を尊重して落とし所を見出す」が正しい姿である。この事は百も承知だが、熱を込めるあまり敵対関係となること反省しきりである。

バックナンバー2016.8.29にも書いたが、そもそもアーキテクチャー管理はプロジェクトを超えるものである。従ってアーキテクトの主張は技術的側面においては優位に立たなければならない。しかしながら現実のPM的観点も同時に重要である。この段階でのアーキテクトのとるべき行動は、小さなこだわりは捨て、根本的な指針は変えないということに尽きる。このような局面を上手く乗り越える事で、ほぼ50%のアーキテクチャー品質は担保される。

PM要件を何とか満たすアーキテクチャーが確保できたと思っているのも束の間、アーキテクトにとって次なる試練がやって来る。開発後期のテストフェーズに入り、幾つかの新技術が非機能要件を満たさないという事態が勃発する。もともと枯れた技術だけで構築するのなら、そもそもアーキテクトは不要である。よって、この事態も想定内でなければならない。この試練は、前回の”悪魔の囁き”よりさらに強力な”クレーム”に近いものとなる。「だから言ったよね。難しいって。。」といった評論めいた他人事の言葉が浴びせられる。ここでも決してくじけてはいけない。今後10〜20年先まで持たせるシステムを作るのに、枯れた技術だけで構築するわけには行かないのだ。

辛抱強く、最低限枯れた技術でパフォーマンスを担保しなければならない箇所と、そうでない箇所を仕分けし、後者を残す事に勤めなければならない。オールorナッシングと全てを退化させない事が重要である。そして、レガシー技術でまかなった箇所は、プロジェクトが終了してから次のステップでリベンジする事を密かに企画すると良い。

このように、当初想定したアーキテクチャーは、プロジェクトの進捗とともに少しずつ角が取れ、丸みを帯びてくる。辛口で言えば、結果として妥協の産物が完成する。それでも当初企画した75%以上の新機能が実装できていればまず持って合格と言える。残念ながら、削りに削って真ん丸になった失敗プロジェクトを、成功と言っていないだろうか。本当のプロジェクトの成功は、コスト、納期はもとより、真のプロダクト品質（バグのないシステムではなく想定した機能が実現できているという）が満たされている事をいう。ベンダーにアウトソースする事で、品質の捉え方を間違えているケースが少なくない。

こうして、自分が手がけたプロジェクトを振り返ってみると、決して満足できる点数は得られていない。がしかし、葛藤が大きかったプロジェクト（=粘り強く最後までアーキテクチャーにこだわったプロジェクト）ほど、息の長いシステムとなっている。