PM兼アーキテクトのすゝめ

最初に登壇したのは、製造ソリューション事業部の五十嵐光来氏だ。五十嵐氏は2018年に電通総研に入社。入社後は自然言語処理やLightGBM、MLOpsなどを勉強してキャリアを積み、その後AIの製品開発に従事している。

株式会社電通総研
製造ソリューション事業部 兼
Xイノベーション本部 AIトランスフォーメーションセンター
シニアエンジニア　五十嵐 光来氏

開発2期目はプロダクトオーナーも務めたという五十嵐氏。製品リリース後は保守を経験。その後ミッションが製造システムインテグレーション（SI）に変わり、今回のテーマであるPMやアーキテクトという役割を担うようになる。「今、AI×SIの勝ちパターンを模索している途中だが、PM兼アーキテクトの長所と短所について話していきたい」と前置きし、セッションを開始した。

AIをきっかけとしたSIビジネスを展開

現在、五十嵐氏が所属する製造DXユニットのミッションは、SIビジネスの展開である。そこで五十嵐氏は得意のAIを活かし、AIをきっかけとしたSIビジネスを展開することを目指している。

AIをきっかけとしたSIビジネスの例として、五十嵐氏が挙げたのは「TexAIntelligence」。同製品は文章類似検索や教師あり自動分類、自動分類、テキストマイニングができるAI製品で、五十嵐氏たちが開発したものだ。「この製品の問い合わせをきっかけに、お客さまの本当の課題について話を深掘っていくということをしています」（五十嵐氏）

五十嵐氏はアーキテクト、PM、データサイエンティストと3つの異なる役割で、案件に参加することがあると説明する。

「各役割にはエンジニア的観点、コンサルタント観点、プロジェクト管理的観点があります」（五十嵐氏）

各役割でどんなことが求められているのかをまとめたのが次の表だ。

SIは課題ヒアリングから始め、PoC、要件定義を経て、設計・開発に至る。だが、このようなステップを踏んでも、作られない、使われないシステムができあがることも珍しくない。「これまで経験してきた案件では、さまざまな原因があった」と五十嵐氏は語り、紹介したのが次の図である。

出典：電通総研

これらの解決については、「エンジニア的観点、コンサルタント的観点、プロジェクト管理的観点を持つメンバーが密接に連携しないと解決できないものばかりだった」と、五十嵐氏は振り返る。

そこで、五十嵐氏はメンバーと連携することなく、なるべく一人でやってみることにした（この方法が使えるのは5人ぐらいまでの中小規模の案件）。

PM、アーキテクト、データサイエンティストの観点で考えるプロジェクトの障壁

最初の障壁は、課題ヒアリングからいかにPoCへ進めるかだ。PoCが開始できない最大の理由は「現場部門が問題や課題、解決策をきちんと理解・納得しておらず、ステークホルダーを説得できないことです」と五十嵐氏は説明した。

五十嵐氏たちITベンダーにできるのは、提案書を通して、顧客自身に最終的なゴールのイメージと各ステップの必要性を理解してもらうことだからだ。

では、具体的にはどうすればよいのか。「提案書はラブレターです」と、五十嵐は語る。現場部門の相談を真摯に受け止め、どんな道筋でプロジェクトを進めれば課題を解決できるのかを伝えるために、エンジニア的観点、コンサルト的観点、プロジェクト管理的観点の多角的視点で提案書を作成する。

そのときに「相手の気持ちにどれだけなれるか、というのが重要です」と、五十嵐氏。どんな業務で誰がうれしくなるのかを、きちんとヒアリングをし、As-Is業務を書く。そしてROIの算出もお客さんに任せるのではなく、支援をするのである。

出典：電通総研

だが、このようなやり方には短所もある。次のような短所が響く場合は、PoC内で方針を明確化していくという方法も必要となる。

1．時間がかかる

製品紹介→課題ヒアリング→業務理解→NDA締結→データ確認→ROI作成→提案書作成というプロセスのため、時間がかかる。

2．無駄な工数をかけることがある

どんなに頑張っても提案が通らないお客さまもいる。また、コンペで勝っても、急に社内都合で案件が消えることも結構ある。

3．顧客が課題や対策をある程度イメージしている必要がある

業務整理や課題整理が必要な場合は、UXデザイナーなどの専門家が必要になるため、PMスキルやアーキテクトスキル、データサイエンティストスキルでは対応ができない。

続いて、PoCから要件定義への障壁について解説された。要件定義が開始できない最大の理由は、PoCの結果が業務全体の効率化とつながるイメージが持てないこと。そこで、精度を上げることよりも、いかにリアルな業務を想定してPoCを実施するかを意識することが重要だという。

アーキテクトやデータサイエンティストの立場では、次のような一歩踏み込んだ分析をやりたいと思うが、短所もある。まずは、顧客の詳細なルールを聞くので、顧客の協力が必須になることだ。そのためPMが顧客とのコミュニケーションを取り、信頼を得ておくことが必要になる。

次に、進めていくうちに、どんどんやりたい内容が膨らむことである。

「業務全体を詳しく考えていくと、やりたいことが増えていく。準委任で実施したり、工数に制限があったりする場合も多いので、しっかりとPMがバランスを取って工数管理をすることが必要です」（五十嵐氏）

出典：電通総研

第三に、評価指標（正解率・再現率・適合率など）が変わることが挙げられる。この場合はどこまで変わっていいかなど、事前にコミュニケーションして確約しておくことが大事になる。

「PMとアーキテクトの両方をやっていれば、工数と成果のバランスが取りやすくなります」（五十嵐氏）

要件定義が終わり、設計開発、リリース、保守・運用、拡張開発まで丁寧に進めたとしても、「業務効果が出ない」「工数が増えた」「かゆいところに手が届かない」などの声から、使われないシステムになってしまうこともある。

なぜこんなことが起こるのか分からない面もあるが、「アーキテクト兼PMになり、コミュニケーション設計をうまくすることで、不測の事態でも対応できるようになる」と、五十嵐氏は示唆する。実際、五十嵐氏もPM兼アーキテクトとして携わった案件では、コミュニケーションができる場を作り、うまく乗り越えることができたという。

「PM兼アーキテクトは、プロジェクト全体を理解しているので、そうしたリスクに気づくこともできます。また、声をかけるべきメンバーや顧客担当も自ずとわかるようになります」（五十嵐氏）

技術は、使われなければ意味がない。次のステップに進めず、使われない。一応開発は完了したが、使われない。そんなシステムを減らすためにはどうするか。エンジニア的な観点、コンサルタント的な観点、プロジェクト管理的観点を持つメンバーが密接に連携しなければ、解決することはできない。

「だが、小規模案件ならば一人ですべてやってしまえば、顧客自身に最終的なゴールのイメージと各ステップの必要性を理解してもらうこと、リアルな業務を想定してPoCを実施すること、コミュニケーションと全体の理解で、危ないところに気づくことができます」（五十嵐氏）

自社フレームワーク開発を通して得たこと

続いて登壇したのは、金融ソリューション事業部の上野（かみの）駿一郎氏だ。上野氏は岐阜県高山市出身で、名古屋大学卒業後、2016年に電通総研に入社した。上野氏は、TypeScriptやReact、Next.jsによるフロントエンド開発、JavaやPython、Rustによるサーバサイド開発などに従事。コンテナ技術やCI/CDの知識もある。

株式会社電通総研
金融ソリューション事業部
シニアアーキテクト　上野 駿一郎氏

まず上野氏は、電通総研のマイクロサービスへの取り組み、導入背景、またマイクロサービスの特徴について紹介した。電通総研がマイクロサービスへの取り組みを始めたきっかけは、「システムのモダナイゼーションを検討するお客さまが増えたことや、当社自身がレガシーシステムに課題を持っていたこと」だと、上野氏は語る。

レガシーシステムの課題は、拡張性やメンテナンス性が低いこと、新しい技術・ビジネスに対応できないことである。

この課題を解決しているのがマイクロサービスである。マイクロサービスの特徴は、改修時の影響範囲が小さいためコスト期間が短い、新しい技術を取り入れやすく、環境変化への対応力が高い、障害影響を局所化して全体サービスダウンを防止できることなどが挙げられる。

マイクロサービスのこれらの特徴によって、「目指すシステムが実現できることが伝わってきた」ため、同社ではマイクロサービスの導入を決めたという。

出典：電通総研

とはいえ、マイクロサービスがモノリシックなシステムよりあらゆる点で優れているというわけではない。

例えば、マイクロサービスは開発難易度が相対的に高いことや、データの整合性を担保しづらく複雑になりやすい、複数サービスをまたがる処理の場合はレイテンシが発生するなどのデメリットがある。「だが、これらのデメリットをカバーできるような技術の台頭や、デメリットをうわまわるメリットもある」と、上野氏はいう。

出典：電通総研

昨今のアーキテクチャ設計では、B2CにしろB2Bにしろ、魅力的なサービスを顧客に対していかに素早く提供できるかが、アーキテクチャの重要なポイントとなっている。

技術のトレンドとしては、クラウド、REST API、マイクロサービス、多種多様性（各サービスを異なる技術で開発可能）が挙げられる。

「マイクロサービスアーキテクチャは、このトレンドをすべて抑えています」（上野氏）

出典：電通総研

電通総研が提供するマイクロサービス開発フレームワーク「M5」とは

電通総研が約3年前から提供しているマイクロサービス開発フレームワーク「M5」は、従前のシステム課題を解決すべく、マイクロサービスアーキテクチャをベーストし、システム共通機能を具備、変化容易性、拡張性、保守性を実現するための最新技術を取り入れたJava製の開発フレームワークだ。

出典：電通総研

M5の特徴は大きく4つ。第一にマイクロサービスであること。第二にマイクロサービスとして利用可能な共通機能、インフラについてはIaCを用意することで、開発コストが低減できることである。

「使用するクラウドサービスプロバイダはAWS前提となるが、AWS上に短期間でインフラ環境を構築できるIaCを用意しています」（上野氏）

第三に、マイクロサービス導入負荷が低減できることである。

「M5を使うと、最適な技術の選定や検証済みのマイクロサービスフレームワークをすぐにご利用いただけます」（上野氏）

マイクロサービスの構築では、技術選定が重要となる。その負荷を軽減するため、M5ではモダン技術を選定している。バックエンドではオラクル製のOSSであるHelidonやDoma2、Dagger2、Immutables、Gradle、フロントエンドではNext.js、Stoplight、Playwright、Jotaiを利用している。

またM5では、CI/CDの仕組みも同時に利用することができる。テストやビルド、デプロイというパイプラインをGitHub Actions上で自動化することで、人間がやるべきタスクに注力できるようになる。

第四は技術トレンドを抑え、採用技術は常に見直しを行っており、常に先進性・将来性を見据えた開発を行っているため、継続的な改善が可能になることだ。Javaでマイクロサービスを実現するための規約であるMicroProfileに準拠する思想で作られており、Javaでマイクロサービスを実現するためのデファクトを抑えられている。

出典：電通総研

電通総研では、組織をまたいで技術要素の見直しを行う専門チームがあり、上野氏はそのチームの一人である。また、開発・導入サポートチームを組成していることも、機能拡張や改善の継続実施を可能にしている。

導入イメージは次の図の通りだ。ちなみにM5は、クリーンアーキテクチャから構想を得たアプローチのアーキテクチャを実現しているという。

出典：電通総研

導入事例も紹介された。コモディティ現物取引管理システムの導入では、単純な実装の工数の約半分をM5で実現したという。

「技術選定やCI/CDといった実装基板を構築する時間などを考慮すると、より多くの範囲をフレームワークで貢献できたと思います」（上野氏）

リース契約管理システムでは、先ほどの例と同様、約半数の工数をフレームワークで実現した。

「この事例のお客さまは、APIを使って各社内のツールと連携したいという要望があり、各ソリューションからAPIコールをすることも可能としています」（上野氏）

さらに企業型確定供出年金のサポートアプリケーションは、バックエンドがAPIであることによりフロントと分離されているという事例で、例えばモバイルのページを作る際も、APIの改修を入れずに実現できるようになっている。

出典：電通総研

M5開発プロジェクトを通して、どんな価値を得たのか

上野氏はM5の案件に5年前から従事してきた。これらの案件を通して、上野氏はアーキテクトとしてどのように成長してきたのか。上野氏はアーキテクトの仕事を、企業のIT戦略を実現するために最適なアーキテクチャの設計ならびに、それを実現をすることだと定義している。

出典：電通総研

これは電通総研Xイノベーション本部プロダクトイノベーションセンターグループマネージャー、米久保剛氏の著作「アーキテクトの教科書 価値を生むソフトウェアアーキテクチャ構築」でも記述されている定義である。そして会社においては、チーム組成、継続的なコミュニケーション、メンバー育成という役割を担う。

ではプロジェクトでは、具体的にどのような役割を担ったのか。

「まずは戦略立案では、IT課題と顧客課題の橋渡しを行う能力が身に付きました」（上野氏）

出典：電通総研

技術ファーストではなく、「この技術要素で解決できるIT課題・顧客課題は何か」を中心に考えるようになり、良い意味で技術に対して懐疑的になったという。また、IT用語を使わずに説明する能力も身に付いたと語った。

「第二に技術選定を通して得られた価値としては、技術の選定を頑張ってやってきた中で、技術の目利き力が身に付きました」（上野氏）

一案件の中でしか使わない技術であれば、攻めた技術選定や枯れていない技術を試す土壌とする考え方もあるが、フレームワークを作る上では、長く使える技術が絶対条件だったという。

その観点としては、業界標準に準拠しているか、エコシステムが充実しているか、発達したコミュニティがあるか、サポート企業の貢献があるかという4点が挙げられる。

第三に実装・レビューでは、チームのパフォーマンスが最大になるためにどのように立ち振る舞うかという観点が身に付き、動けるようになった。例えば、チームメンバーのそれぞれのレベルに応じてレビューを行うこともその一つだ。いかに自分の時間を確保しつつ、チームのパフォーマンスを伸ばせるかを意識するようになった。

第四は継続的な改善で身に付いた価値である。

「継続的な改善を行うために、社内とコミュニケーションを取ってきたことで、利用者目線の要望が理解できるようになりました」（上野氏）

OSS同様、フレームワークでは利用者と作成者のモチベーションにギャップが生まれることが多い。そこでハンズオンの提供を行うなど、利用者の理解のハードルを下げるような改善を行っているという。

第五に育成では、技術者の教育方針を理解することができた。後輩への関わり方として、上野氏は心理学を参考にしている。ロミンガーの法則によると、人の成長の割合は、業務経験が70％、他者からの指導（薫陶）・関わりが20％、自己学習が10％だという。

重要なのは、人は座学ではなく、業務を通じて70％成長するという点だ。

「エンジニアの場合は、既存のプロジェクトに存在する資料やコードを読む時間が、最も成長するのです」（上野氏）

20％を占める他者からの指導（薫陶）や関わりについてはどうすればよいのか。心理学者アドラーによると、人は承認欲求の生き物だという。中でもエンジニアは能力が数値化されやすいため、「劣等感と承認欲求のせめぎ合いの中で生きている」と上野氏は考える。

アドラーはどういった瞬間に承認欲求が満たされるかも定義しており、それは賞罰教育の否定に繋がっているという。人は褒められたときに成長するのではなく、集団から感謝を得られたときに成長し、頑張ろうと思えるのだ。そこで上野氏は、フィードバックする際に、「ありがとう」など、感謝の言葉を常に投げかけるようにしていると語った。

出典：電通総研

【対談セッション】アーキテクトとは

最後のセッションは、フューチャーアーキテクトのシニアアーキテクトをゲストに迎えて行われた対談セッションだ。

ゲストとして登壇したのは、フューチャーアーキテクトのTechnology Innovation Group・製造エネルギーユニット シニアアーキテクトの渋川よしき氏と、Technology Innovation Group シニアアーキテクトの真野隼記氏。電通総研からは、米久保剛氏、金融ソリューション事業部エンジニアリングオフィス 室長の水野和大氏が登壇した。

──まずは、自己紹介をお願いします。

渋川：フューチャーアーキテクトの渋川です。直近は製造業のお客さまの技術コンサルをやりつつ、大規模な卸関係の基幹刷新プロジェクトに携わっています。好きなクラウドサービスはGCPのCloud Runです。

フューチャーアーキテクト株式会社
Technology Innovation Group・製造エネルギーユニット
シニアアーキテクト　渋川 よしき氏

真野：直近はエネルギー系のお客さまのデータ基盤の構築、データ活用の仕組み作りに携わっていました。よく書いている言語はGo。好きなクラウドサービスはAmazon S3。オブジェクトストレージも好きです。

フューチャーアーキテクト株式会社
Technology Innovation Group
シニアアーキテクト　真野 隼記氏

水野：電通総研の水野です。証拠保全するサービスをマルチテナントで提供するサービスに携わっています。好きなクラウドサービスは渋川さん同様、GCPのCloud Run。Amazon ECSも好きです。

金融事業部では今月からエンジニアリングオフィスという組織を立ち上げ、組織の技術的な意思決定のリード、エンジニアカルチャーの情勢や技術者のキャリアパス検討などを担当しています。最終的にはエンジニアの従業員体験を高められるようにしていきたいです。

株式会社電通総研
金融ソリューション事業部
エンジニアリングオフィス 室長　水野 和大氏

米久保：「Ci*X（サイクロス）」のプラットフォームや、その上で稼働する「Ci*X Workflow」の開発のリードなど、プロダクト開発中心に携わっています。今興味のあるクラウドサービスは「Amazon Bedrock」です。9月28日に開催される日本XPユーザグループの主催イベント「XP祭り2024」に登壇する予定です。

株式会社電通総研
Xイノベーション本部
プロダクトイノベーションセンター
グループマネージャー　米久保 剛氏

──アーキテクトとはどんな人か。イメージを教えてください。

渋川：技術選定をする人ですね。バックボーンや経験がバラバラなチームメンバーを教育して、書き方なども統一していくというタスクを担う。そこがこれまで経験している中で、一番思い出せるイメージです。

真野：非機能要件を担保する人というイメージです。開発生産性や品質、コストなど、いろいろ超えなければならない要件はありますが、それを引き出して整理して、実現することへの責任を持つ人です。

水野：IPAの定義的には、経営戦略と技術と処理方式をつなげるスキルを持つなどがありますが、僕のイメージは技術的な文脈で組織最適化への闘いをする人。自分のやりたいこと、顧客等ステークホルダーの各種要求の調整を行い、利益貢献は考えつつ、自分が作りたい最強のシステムを考える役割だと思います。

米久保：アーキテクトとテックリードを混ぜて捉える人もいますが、この2職種は明確に違います。テックリードは、技術力とソフトスキルを駆使してチームを率いて成果を出す役割。コードが書ける開発リーダーのイメージです。

一方、アーキテクトのメイン業務は、システムのグランドデザインを描いて実現することに責任を持つ人。特定の要素技術に固執せず、最終的にどうすればお客さまに良いものを届けられるのか、それを考えてチームを引っ張っていく人です。

──最も重要な仕事と、最も工数を使っている仕事について聞かせてください。

米久保：最も重要な仕事は、技術面での戦略作りです。持っている資源をどう配分していくか、その方針を定めることですね。リソースが潤沢にあるというケースはほとんどありません。その中でも人。優秀な技術者は枯渇しているので、人を揃えるのが難しい。そういう制約の中で何を妥協して、何を妥協しないのか、ポリシーを策定していく、それが重要な仕事です。

最も工数を使っている仕事は、フェーズによってさまざまです。例えば最初のバージョンを作っているときなど、ひたすらコードを書いているときもある。ですが、総じて調整仕事は多いですね。特に大規模なシステムになると、複数のサービスの担当者と調整をするので、コードを書く時間をどう確保するかがいつも課題になります。

水野：最も重要な仕事は、技術選定ですね。できれば攻めた技術選定をしたいとは思うものの、TPOに応じたテクノロジスタック選定をしています。例えば2～3人の優秀なアジャイルチームだと攻めた技術に挑戦できますし、医療や決済といったミッションクリティカルな領域であったり、スキルにムラがあるチームであれば、十分に実績のあるアーキテクチャ・技術スタックを選定します。

技術選定は状況によって最適解が異なります。また、本意かは置いておいて、自分の仕事で最も工数を使っているのはミーティングです。絶え間なくミーティングが入るので、コミュニケーションコストを下げていきたいです。

渋川：チームメンバーが増えるとミーティングが増えるのは仕方ないですよね。技術選定はメンバーの成長も兼ねて検討しています。契約書を書くことに工数を取られる一方で、共通部品をガリガリ書くこともあれば、仕事をメンバーに振った後の雑用もある。コードレビューを頑張ることもある。フェーズによって工数が取られる仕事は変わります。

真野：工数を取られているのは、泥臭い仕事。そもそもアーキテクトはテックリードやPM、PLと兼務することが多いですね。例えば10人メンバーがいると、1on1でかなりの時間が取られます。

テックリードだとこぼれ系のもの、静的解析のリンターを作ったり、メンバーがやりたがらなかった仕事、成長につながらないところを担当するので工数が取られます。重要な仕事としては意思決定すること。リーダーのKPIは、良質な意思決定がいくつできたか。個人的には意思決定が覆らないことなど、意思決定を何個こなすかを重視しています。

──アーキテクチャ設計のポイント、要素技術の評価手法、コードの量産手法についてはいかがでしょうか。

渋川：要素技術の評価手法でいうと、バージョンアップの工数をあまり取られないもの、世間で流行っている技術かどうか、ですね。流行っている技術であれば生成AIを活用することもできますし、メンバーのモチベーションにもなる。新しくチームメンバーになった人が、知っている可能性も高いからです。

コードの量産手法は、コーディングスタンダードを決めたりすることもあります。世間で流行っているものと差がなくなると、サンプルコードが転がっているので、困ったとき検索することもできます。あまり奇をてらわないようにすることも大事だと思います。アーキテクトがやらなくても回る。コード自動生成はあまり好きではないのですが、必要悪のようにも感じます。ただし、SIerでは大事だと思います。

水野：コード自動生成を必要悪と言われたのですが、僕はコード生成を15年ぐらいやっています。規模とチームのスキルセットによっても違うのですが、オフショアに100人、社内に100人などの体制で、開発生産性を上げ、品質を担保するにはコード自動生成はやはり必要だと思います。コード生成の活用はトータルで肯定派です。

要素技術の選定は、トレンド・時代の趨勢に乗っているか、情報を収集・相談可能なコミュニティがあるか、良質のイシューが挙げられているかなどをチェックして総合的に評価します。OSSのフレームワークであれば、エラーが発生したときのロギングの詳細度など、ドキュメントやチュートリアルで分からない部分を、実装を確認することで採用を検討します。

真野：どの技術を使うかはモチベーションやトレンドが大事だと思います。要素技術の中でもデータベースとかサーバーのサービスは、使っているライブラリなどでまったく変わってくると思います。

ライブラリに関しては、インターフェースがシンプルで使いやすければ、どんどん入れる。DBは失敗すると取り返しがつかないので、実績がないと採用しきれない状況が生まれてくると思います。とはいえ、枯れた技術でずっと続けるのは難しいので、4～5名の小さめのプロジェクトで実績を作って、大きめのところで使うという方法を用います。

コード量産手法は、前のフェーズで設計しているのをどう活かしていくかが重要になると思います。それが使えるのであれば、コード自動生成も活用していくべきだと思います。

水野：コード自動生成を使うと、設計と実装の一貫性を保ち、人為的なミスを減らすことができます。一貫性を重視するのであればコード自動生成は重要だと思います。

米久保：技術の善し悪しは、採用するコンテキストに依存すると思います。個人的には日本だけで流行っている技術に対しては、本当に大丈夫かなと問いかけるようにしています。使う側からすると、急にメンテナンスが止まるような事態になると困るからです。もちろん、日本発のプロダクトを応援したいのですが、そこはフラットな目で見ています。

コードの量産にコード自動生成を活用することについては、僕は懐疑的なスタンスを持っています。行き過ぎた自動生成やフレームワーク化によって痛い目を見たことが過去にあるからです。

ただ、統一性を持たせる、大規模システムなので型にはめるといったことは、システム開発にとっては必要だと思います。実際のアプリケーション開発する人が、業務の手続きやルールと、非機能業務をきちんと分離すること。業務は決まったやり方で、同じレベルのものを作っていく仕組み作りが必要になると思います。

渋川：コード生成が好きではないという理由の一つが、コード生成のために書かされるExcelが嫌いだからなんです。マークダウン形式のスキーマを作れば、設計書も書きやすくなってアジャイルの案件でも設計書を活かした開発ができるのではと考えています。

水野：この間Goの案件で、設計書の大半をマークダウン記法にし、このマークダウンの設計書を前提にした自動生成ツールを実装しました。これが回答だと思いましたが、追加の要件で設計書のフォーマットを変更せざるを得ないケースが発生し、合わせて自動生成ツールの修正も余儀なくされました。例外的なケースにどこまで対応するか、どこまで自動化するかは今後の課題ですが、少なくともExcelの設計書はなくしていこうとしています。

──後進の育成やアーキテクトの人口比に関して、どんな制度が必要ですか？

米久保：日本のITエンジニアの人口は約140万人。その中でコードを書く人は半分もいないので、50万人とすると、アーキテクトとして素養を持っている人はざっくり見積もって1万5000人ぐらい。3％前後だと思います。

制度よりもまず、アーキテクトの認知を高めていくことが必要です。今日のようなイベントも認知度向上に役立つので、これからもこのような活動をしていきたいですね。

渋川：アーキテクチャは考える経験がないと育ちません。仕組みを作る方にシフトしないとアーキテクトにはなれません。ではどうするかというと、小さい案件を任せてみることが必要です。人口比は米久保さんがおっしゃるように数％だと思います。

真野：アーキテクトはブラックボックスを許さないという気質の人が向いていると思います。なので、人口比は1割ぐらいかと。アーキテクトとして必要な要素、初回のPoCで青写真を描くスキルが必要だと思います。

どういう技術で作っていくのか、技術スタックを作ったり、開発の立ち上げでメンバーをレールに乗せたりする。そういう役割が担える人。もう少し業界内でジョブ・スクリプションの明文化ができるようになると育てやすくなると思います。

水野：弊社の金融事業部のエンジニアは大体200人程度、エンジニアリングオフィスやその他の部で、アーキテクトは大体10人です。200人中10人とすると、ざっくり5％です。育成のための必要な制度というより、まずは裁量を与えること、責任と権限委譲が大事だと思います。例えば、社内に技術者DAO（分散型自律組織）を作り、年次に関係なく技術的な貢献をしたメンバーにガバナンストークンを配布し、意思決定の際に貢献度に応じた投票権を与えるなど。

──アーキテクトをやっていてよかったと実感するのはどんなときですか？

真野：最初からアーキテクトチームに入っている、生まれながらアーキテクトだったので、特にないですね（笑）

渋川：アーキテクトは、ゼロから作れるところが面白さ。趣味で開発したり、アーキテクトを試してみよう、チャレンジしようという思いが満たされる。半分仕事、半分趣味のような仕事です。また、書籍を書くことなどによって、自分が流れを作っているという気持ちにもなれます。

米久保：100点満点のアーキテクチャを作るのは難しい。本当はこうしたかった、と後からいろいろ思うところが出てきます。そうした中で、以前関わっていたシステムが数年を経て、今も元気に動いているという知らせを聞くと、やっていてよかったと思います。

水野：僕がアーキテクトをやっていてよかったと実感するのは、リリース後に保守フェーズに入り、障害対応やエンハンスが入ってもコードベースが乱れていないとき。プロジェクトが始まって忙しくなると、リンターやルールを無視してコードベースが乱れることはよくあります。

各セッションの後は質疑応答タイムも

セッション後は質疑応答の時間が設けられ、次のような質問が投げかけられた。

Q．アーキテクトとは、技術的なバックグラウンドがあるだけではありません。エンジニアというポケモンがレベルアップした先にアーキテクトがあるように思います。アーキテクトで重視するスキルとは何でしょう。

水野：一つに絞るとなると、迅速な意思決定とその意思決定に責任を持つこと。意思決定をミスしても、自分で鎮火するスキルを持つことです。

渋川：エンジニアの先にアーキテクトがあるわけではありません。アーキテクトはポケモンボールを投げる側。役割分担をすればよいと思っています。ある程度技術は把握しておく必要がありますが、すべてを深く知る必要はありません。世の中の流行を見て、これは流行りそうかなどをチェックしておくことが重要だと思います。

真野：優秀なエンジニアの前で判断することは難しいので、最低限のエンジニアリングスキルは必要だと思います。個人的にはアーキテクトは孤独なロールだと思っています。リリースしても当たり前で、褒められることはほとんどありません。そういう孤独感を持ちながら意思決定に責任を持つ。そういう資質を持っていることが重要だと思います。

米久保：日々、勉強を重ねていくのが必要な職種です。それが楽しさでもありますけどね。

※本ページに記載されている会社名・商品名・サービス名は、それぞれ各社の商標または登録商標です。また、掲載されている資料などの権利は全て株式会社電通総研に帰属します。

株式会社電通総研
https://www.dentsusoken.com/

株式会社電通総研の採用情報
https://www.dentsusoken.com/recruit