エンジニアに残された最後のロール？ストラテジックアーキテクトとは

――まずは、お二人が担われている「ストラテジックアーキテクト」という職種について教えてください。 

江口： ストラテジックアーキテクトは、お客様のシステムのソースコードを解析するところから入り、ときにはコンサル、ときにはPM、ときにはアーキテクトとして関わる複合的なロールです。 

お客様のシステムを解析した結果、どのように刷新するのかを合意形成しながら、技術面も踏まえて会話をし、計画を立てていく役割です。 

――一般的なコンサルタントやPMとはどのような違いがあるのでしょうか。 

加治： PMやコンサルタントだと、案件ごとに担当する範囲が決まっていることが多いと思います。

一方でストラテジックアーキテクトは、お客様と最初に接するプリセールスの段階から、戦略策定、システム刷新、運用まで、一気通貫で関わりつづけます。お客様の最適化が終わるまで伴走していくイメージですね。 

――かなり守備範囲の広い仕事ですね。正直、大変そうにも聞こえますが、そのなかでどんなところに面白さを感じていますか。 

加治： 一番面白いのは、「ストラテジックアーキテクトだからこれをやる」という決まった枠がないところですね。

PMとしてプロジェクトを推進することもありますし、コンサルタントのようにお客様と戦略を考えることもあります。必要であれば自分で手を動かすこともあります。

お客様の理想の姿を実現するために、「自分は何をやるべきか」を考えつづける仕事なんです。 

江口： お客様の課題はシステムだけにあるとは限りません。業務や組織の課題がボトルネックになっていることもあります。

そうした背景もいっしょに読み解きながら、お客様にとっての最適な姿を考えていく。 

単なるシステム刷新ではなく、本質的な課題解決に向き合えるところが、この仕事の面白さだと思います。 

――なぜいま、このような役割が求められているのでしょうか。 

江口： AIによって代替される作業が増えたことで、各ロールの垣根が低くなってきていることが背景にあります。 

お客様と向き合いながら課題解決をリードするストラテジックアーキテクトは、これからの時代における人間がやるべき、「エンジニアに残された最後のロール」なのではないかと思っています。

真の課題はソースコードの外にある

――実際には、どのようなご相談が多いのでしょうか。 

江口：お客様が何十年も運用されてきたシステムで、担当者が退職してしまったとか、ドキュメントがなくて困っているとか、システムをどう刷新するのかわからないといったご相談をいただくことが多いです。 

課題としてみえている部分がありますが、我々がソースコードを解析するともっと大きな課題がみつかるケースの方が多いです。 

なんとなく体調に不安を感じていた人が10年ぶりに健康診断を受ける。その結果、将来的なリスクが見つかり、「要精密検査です」とお伝えするようなイメージです。 

 ――かなり危険な状況のお客様もいらっしゃる。

加治：ただ、システムはとりあえず動いているため、お客様自身が危機感を抱きにくいというむずかしさがあります。

「放置しておくと将来的に大変なことになりますよ」と、客観的なデータを示してリスクをお伝えし、いかに納得感をもって行動を起こしていただくかが、私たちの最初の重要なミッションになります。 

――客観的なデータでリスクを示せば、スムーズにシステムの刷新提案へと進めるのでしょうか。 

加治： 実はそうとも限りません。ある案件では、最初はシステムの課題だと思ってご支援に入ったのですが、深掘りしていくと、もっと組織的・体制的な問題がみえてきたことがありました。

結果として、システムの話ではなく組織体制をどう変えていくかという議論に発展したんです。

ソースコードをみると、古さや更新履歴などからシステムの状態はある程度みえてきます。ただ、その背景をお客様に聞いていくと、「実はこういう組織体制だった」「こういう運用だった」という話が出てくるんです。

そうすると、システムがこうなった原因と組織の課題が紐づいてきます。 

――システムだけをみていても、本質的な課題解決にはならない、と。 

加治：そうですね。本質的な課題解決をしようとすると、システムだけではなく、そうした部分にも踏み込まなければならないことがあります。

実際には、真の課題がソースコードの外にあるケースも少なくありません。

恵まれた環境を飛び出してでも、二人が求めた「実行の舞台」

――お二人がこうした役割を目指すようになった背景は何だったのでしょうか。 

江口：前職は尊敬できる仲間が多く刺激的な環境でした。ただ、私自身、もともと開発をしていたこともあり、「開発現場にもっと深く関わりたい」という思いがずっとありました。 

お客様の真の課題を解決するには、表面的な提案だけでなく、現場に踏み込んでいく必要があります。 

しかし当時の環境では、提案自体はできてもそれを実行に移す舞台が自分たちにない。そのことが、次のステップを考えるきっかけになりました。 

加治：私も、前職で経営層から現場まで多様なお客様に直接提案ができることに、大きなやりがいを感じていました。 

ただ、お客様の課題に対して提案やプロトタイプの提供まではできても、その先の実行フェーズに自分たちが直接介入することはむずかしかったんです。 

お客様に最後まで伴走したいと思っても、ロールの制約上そこから先は別のパートナー様に任せるしかない。そうした構造的な限界に対する歯がゆさは、私だけでなく社内でも共通の課題意識としてありました。

――そうした思いが、SHIFTへの転職につながっていったのですね。 

江口：はい。システムを提供する立場としてお客様に伴走し、かつAIを積極的に活用していくSHIFTの方向性に大きな面白みを感じました。 

加治：私は、いまのAI時代において自分がどう変化し、AIを使って何ができるのかを実践できる環境を探していました。SHIFTはまさにそれを体現できる場所だと感じました。 

また、実は前職時代から江口さんのことも知っていたので、その安心感や、人を大切にする社風にも強く惹かれましたね。 

――数ある選択肢のなかで、最後の決め手になったのは何だったのでしょうか。 

江口：私にとってAIは非常に重要なテーマでした。正直、AIを使わない仕事はもう考えられなかったんです。そのなかで、「Native AI事業」を伸ばしていくという方向性が明確だったことに強く惹かれました。

なかでも立ち上げ期にあるAIモダナイゼーションサービス部で、組織づくりに大きな裁量をもって関われる点にも面白さを感じていました。 

現実的な話として、前職からの年収アップと、70歳定年という長く働きつづけられる制度も決め手になりました。 

加治：私も、社長をはじめとする経営層自らが「AIを徹底的に使っていく」という力強いメッセージを発信していたことが最も印象的でした。

会社全体でAIを使いこなし、自由に勉強や挑戦ができる環境が整っている点に魅力を感じて入社しました。

「システムをつくる・直す人」ではなく「ビジネスを伸ばす人」

――会社全体でAI活用を推進するSHIFTですが、AIがこれほど急速に進化するなかで、エンジニアが価値を発揮しつづけるには何が必要だとお考えですか？ 

加治：AIはさまざまな情報を出し、モノをつくってくれます。しかし、それが本当にお客様のビジネスの改善に繋がるのかを判断し、納得感をもっていただくための理由づけや合意形成は人間にしかできません。 

AIの答えを鵜呑みにせず、前提や価値をしっかり伝えて支援していくことが重要です。 

江口：お客様にとってシステムはビジネスの手段でしかありません。そこにとらわれず、お客様のビジネスをいかに楽にするか、伸ばしていくかをいっしょに考えられることに価値があると思っています。 

いままでもそうであったと思いますが、AIの登場でより人間ならではの役割の必要性が増したと感じています。 

――AI時代の価値が「ビジネスへの伴走」にシフトしていくのですね。その前提のうえで、ストラテジックアーキテクトにはどんな方が向いていると思いますか？ 

加治：お客様の最適な姿を定義していくうえで、自律的に動くことが強く求められます。

技術面でもビジネス面でも「こうしていくべきだと思う」という強い信念や考えをもち、責任をもって主体的に動ける方は非常に向いていると思います。  

 江口：お客様自身も正解をもっていない課題に対峙することが多いので、「こうすればよくなるのではないか」と自ら仮説を立てて動ける力が必要ですね。 

たとえ仮説が外れても、すぐに次の手を考えられる柔軟性と前向きさがある方には、ぜひ挑戦してほしいです。いきなり全てができなくてもチームでサポートできますので。 

――最後に、これからのキャリアに悩む方に向けてメッセージをお願いします。 

加治：ITの歴史のなかで、インターネットやクラウドの登場、DX化など、大きな変化はつねにありました。

重要なのは、変化を恐れず、自分の得意なものを主軸としながら、その時代にあわせて柔軟に自分を変化させていくことだと思います。 

江口：これまでは専門性の深さが強みとされてきましたが、いまはAIを活用したプラスアルファの価値を意識していくことが大切です。 

技術だけでなく、ビジネス視点でお客様に伴走するストラテジックアーキテクトは、非常にやりがいのある魅力的な職種です。

今後のキャリアに不安や迷いがある方は、ぜひご応募いただけるとうれしいです。

（※本記事の内容および取材対象者の所属は、取材当時のものです） 

国境と組織をまたぐ、複雑案件のハンドリング

――忠田さんは現在、幅広い案件を担当されていると聞いています。まずは、現在の具体的な業務内容について教えていただけますか？ 

忠田：PM兼プリセールスとして、主にMicrosoft 365（M365）や生成AIに関するプロジェクトの提案から伴走支援までを担当しています。 

具体的には、お客様の課題や期待される成果を整理し、要件の確認や解決策の提案を行っています。

プロジェクト開始後はPMとして、現状調査やアセスメント、要件定義、運用設計、導入後の定着化に向けた伴走支援まで、一貫してプロジェクト推進に携わっています。 

直近では、国内製造業の海外グループ会社におけるM365テナント統合でPMを務めています。また、建設業のお客様におけるM365 Copilot活用に向けたDX人材育成支援では、PMと研修講師を担当しています。 

――海外拠点も絡むような複雑でスケールの大きな案件を、スピーディに推進できる背景には何がありますか？ 

忠田：こうしたプロジェクトで大きな障壁となるのは、国境や部署の違いによって生じる利害や権限を調整するコストです。 

例えば、海外グループ会社のM365テナント統合では、国をまたいだ契約手続きや、グループ会社・事業部間での利害調整など、多くの関係者を巻き込むため、検討や意思決定に時間を要するケースも少なくありません。

しかしSHIFTでは、構築や運用保守を担う部署はもちろん、ときにはグループ会社の垣根を越えて、必要な知見や人的リソースを柔軟に組みあわせられます。社内調整にかかる時間をお客様との対話や課題整理、提案活動に充てられるのです。 

こうした環境があるからこそ、複雑なグローバル案件にもスピーディに対応できているのだと思います。

提案からPMまで。自ら「現場をデザインし、動かす」醍醐味

――組織間の壁がないからこそ、迅速に動けるのですね。忠田さんは提案活動からPMまで一貫して携わっていますが、そのスタイルへのこだわりはありますか？ 

忠田：はい、あります。「PMが提案もやるの？」と驚かれるかもしれませんが、私は「どちらか片方だけやって」といわれたら、多分「嫌です」といっていたと思います（笑）。 

私は、お客様の課題整理や提案活動の段階から関わり、いっしょにゴールを描いて具現化するスタイルにやりがいを感じているんです。 

“提案は営業の仕事”と割り切っていては得られないおもしろさがありますし、SHIFTにはそうしたスタイルを後押ししてくれる環境があると感じています。 

――課題の整理から入り込んで自分で形にしたいという想いは、これまでのキャリアのなかでも感じていたことですか？ 

忠田：そうですね。それまでのキャリアでは、運用保守から運用品質管理、サービス企画・販促まで幅広い経験を積んできました。契機となったのは、販促活動を通じてお客様の困りごとを直接伺ったことが転機でした。 

お客様の生の声に応えようと組織横断の取り組みを推進するなかで、丁寧な合意形成の大切さを学ぶ一方、組織規模や事業特性による制約から、適用範囲が限定的であったり、運用が複雑化したりと、総合的な判断のむずかしさを実感することもありました。  

こうした背景から、「もっとお客様に近い場所で、いっしょに課題を整理し、事業をよりよくするプロジェクトマネジメントに挑戦したい」と考えるようになりました。

そうした想いから転職活動を行い、コンサルティングファームからも内定をいただきましたが、「幅広い案件があり、自分の可能性を広げられそう」「一番自由度が高く挑戦できそう」と感じたのがSHIFTでした。

目的を失ったプロジェクトに息を吹き込む、対話型のアプローチ

――実際のプロジェクト現場で、停滞や困難に直面したときはどのように紐解いているのですか？ 

忠田：例えば生成AI領域のプロジェクトでは、「生成AIを活用する」という方針だけが先行し、自分たちの事業をどうしたいかという目的が曖昧なまま進んでしまうケースがあります。 

そうしたときは、「何のために活用するのか」「その施策はいま必要なのか」という問いに、お客様とともに向き合います。お客様のカルチャーや立場なども考慮しながら、目指すべきゴールをお客様といっしょに再定義していきます。 

また、プロジェクトの立て直しや推進においては、「メンバーとの対話」によって目的を揃え、チーム自体の自走力を高めることを意識しています。 

――「メンバーとの対話による自走」とは、具体的にどのようなアプローチでしょうか？ 

忠田：生成AIの黎明期に担当した、自治体向けの生成AI導入PoC案件がまさにそうでした。PMとして参画した際、メンバー間の認識のズレから議論が発散し、プロジェクトは遅延していました。 

そこで、社内外のステークホルダー一人ひとりとの対話の機会を設けました。対話を通してそれぞれの期待や懸念、本音を聞き取り、発散していた意見をプロジェクトの目的に照らして整理しました。 

SHIFTのフラットな環境があったからこそ対話を最優先できましたし、それによって「お互いの強みを尊重し、同じ目的に向かえる」という安心感が生まれました。

加えて、チームが自律的に機能しはじめ、最終的には予定していたPoCを完遂することができました。その後の継続的な支援にもつながり、プロジェクトを成功へと導くことができました。 

――そうした「自走型マネジメント」は、他のプロジェクトでも活かされていますか？ 

忠田：はい。タイのお客様のM365テナント統合案件も同様でした。この案件では、日本にいる私がPMを務め、ベトナムを拠点とするグループ会社、SHIFT ASIAの技術メンバーと国境を越えて連携しました。 

国も言語も異なるチームだからこそ、細かな指示や過度な確認によるマイクロマネジメントを避けることを意識しました。

代わりに「プロジェクトの目的」「今後の見通し」「契約上の対応範囲」を丁寧に共有し、メンバーが安心して判断できる環境をつくりました。 

その結果、ベトナムのメンバーがもつ専門性とお客様視点が発揮され、タイのお客様に寄り添った対応につながりました。距離や言語の壁を越えて、お客様から感謝の言葉をいただいたときは、胸が熱くなりましたね。

曖昧な課題を解き明かす“デザイン力”こそ、PMのプロフェッショナリズム

――これからの時代において、PMが身につけるべき本質的なプロフェッショナリズムとは何だと思いますか？ 

忠田：単なるツールの知識や進捗管理のテクニックではなく、曖昧な課題を正しく捉え、実現に向けた道筋を描く“デザイン力”こそ、これからのPMに求められる本質的な力だと思っています。 

この“デザイン力”は、複雑な課題を「分解して描く力」と、状況の変化を捉えて「評価し、描き直す力」の2つで成り立っていると考えています。 

まず、複雑な課題を「分解して描く力」とは、お客様が抱える課題に対し、それぞれの立場や本音を対話で紐解きながら、前提条件やリスクの関係を細かく要素分解するとともに、「何を実現すべきか」「何を基準に判断すべきか」という道筋を描く力です。 

そして、状況の変化にあわせて「評価し、描き直す力」とは、計画は流動的なものだと捉えて、「前提は変わっていないか」「解釈にズレはないか」を絶えずたしかかめながら、状況の変化にあわせて素早く道筋を修正する力です。 

――チームの自走も“デザイン力” の一部ということですか？ 

忠田：はい、チームマネジメントもまさに“デザイン”の領域です。PMの役割は樹木が育つ環境に整えることに似ていると思っています。木が育っているか心配だからといって、毎日根元を掘り返して確認する人はいませんよね（笑）。

プロジェクトも同じで、細かく管理しすぎると、メンバーは自ら考えて動く機会を失ってしまいます。 

樹木は異なる役割をもつ高木、中木、低木が、風通しや日差しなどを調和させることで健やかに育っていきます。チームも同じで、異なる経験や専門性をもつメンバーが自律的に動き、お互いを補完しあえる環境をつくることが大切です。 

チームが自然と自走し、力を発揮できる環境を設計する。これこそが、私が考える”デザイン力”です。 

―― “進行役”としてのPMから脱却するための核心ですね。 

忠田：そうですね。生成AIが情報整理や進捗管理を支えてくれるようになるからこそ、これからのPMは”進行役”ではなく、プロジェクトにとってよりよい意思決定につなげていくことが重要になると思います。 

関係者の背景や感情を捉え、複雑な利害関係のなかから進むべき道筋を描くこと。そして、状況の変化を評価し、道筋を柔軟に描き直していくこと。

これら人間ならではの”デザイン力”の価値は、AI時代において高まっていくはずです。

（※本記事の内容および取材対象者の所属は、取材開催当時のものです）

このページの閲覧には JavaScript を有効にする必要があります。

]]> https://recruit-wp-prod.shiftinc.biz/career/library/id1557/ Wed, 05 Aug 2026 00:00:00 +0000 https://recruit-wp-prod.shiftinc.biz/?post_type=library&p=57388 JaSST’26 Tokyo 登壇レポート

不確実性の時代、品質管理はどう変わるべきか

近年、品質管理の難易度は飛躍的に上昇しています。この状況を、簡単な算数に例えてみましょう。 

30年以上前のメインフレーム全盛期は「3＋？＝9」という問題に似ていました。ゴールも実現方法も決まっているなかで、穴埋め式に正解（6）を導き出すプロジェクト管理でした。 

約10年前、オープンソースやパッケージが普及しはじめた時代は、問題が「？＋？＝9」へと変化しました。複数の選択肢から最適な組みあわせを選ぶ“最適解”を見つける時代です。 

しかし現代は、DXやAIの台頭により「なんでもシステムで実現しよう」という世界観になりました。これは「？□？＝？」という状態です。足し算なのか引き算なのか、どのような条件で答えを出すのかさえ決まっていません。 

ゴールもルールも決まっていないなかで、関係者間でしっかりと合意形成を行い“納得解”を導き出すマネジメントが不可欠となっているのです。

プロジェクトマネジメントの世界標準であるPMBOK®も、この変化に対応しています。

第6版までは「決められた順番で工程を進めれば一定の成果が出る」というアプローチでしたが、第7版では「原理原則を指針とし、状況に応じてテーラリング（最適化）しつづけること」へと大幅に変更されました。 

固定の正解に従うのではなく、つねに状況に適応しつづける行動が求められているのです。

さらに、テクノロジーの多様化や、リモートワークの定着による「組織カルチャーの形骸化」など、プロジェクト進行や品質管理の妨げとなる要素が多数存在しています。

こうしたことから、私は現代の品質管理において極めて重要なのは、プロダクト品質はもちろんのこと、上流工程からプロセス品質をしっかりと保つことだと考えています。 

継続的に品質に焦点を当てながら、ユーザーのニーズに合致した成果物を、関係者全員が納得する形で構築していく。これこそが、現代の開発現場に求められる原理原則なのです。

【事例1】「品質より納期」と一蹴される現場での先回り戦略

ここからは、私がどのように品質管理を行ってきたか3つの事例を交えてご紹介します。 

最初の事例は、関係者2,000名以上、数百ものサブシステム群のうち約200システムに手を入れる超大型プロジェクトです。このシステムは災害対策や人命救助に関わるため、最高ランクの品質が求められていました。 

しかし同時に、急な法改正に伴い10ヶ月間での納期必達という至上命題も抱えていました。 

私は、プロジェクト全体の品質総責任者（品質PgMO）として参画しました。ところが、初日に渡されたプロジェクト計画書には「重要視すべきは品質ではなく納期である」と明記されていたのです。

「品質の重要性を啓発しても、納期優先だと一蹴される」。これが、このプロジェクトにおける最初の壁でした。

また、現場の状況は混沌としていました。

2,000名が関わるなかでコミュニケーションツールは統一されておらず、Microsoft Teams、Slack、口頭連絡が入り乱れる始末。不具合の報告もMicrosoft ExcelやBacklogなど各社が好きなツールで行う状態でした。 

いざテスト工程に向けた準備を進めようとしても、約200ものシステムを最終的に組み上げるステージング環境すら用意されていませんでした。

さらに、数十年前から稼働しているシステム群であったため、人によっては昔の略称でシステムを呼ぶなど、呼称が統一されていなかったのです。 

こうした状況下で、「口を開けて待っているだけでは、テストがはじめられない」と、私はテスト担当の枠を大きく超えた行動に出ます。

自らデプロイの承認フローやルールを定めたデプロイ戦略を策定。システムの名称を統一し、不具合の管理計画を一元化してプロジェクト全体に適用しました。

「テストをはじめる前にPMやPMOが組み立てておくべきプロセスをも自ら巻き取って構築する」。この“品質を創る”という観点に立った先回りの準備が功を奏し、このプロジェクトは無事にリリースへと至りました。

【事例2】諦めムードの現場を動かした、“役員への通知表”

2つ目の事例は、数百万人が利用するコンシューマー向けシステムを運営する事業会社での品質組織立ち上げです。 

利用者の急増に伴い、1年間で従業員を倍増させた結果、独自のやり方で開発を進める人も増えて不具合が多発。アジリティ（俊敏性）とガバナンスを両立させる横断的な品質専門の組織づくりが急務でした。 

しかし、品質改善コンサルタントとして参画した初日、開発部門の責任者からこう告げられます。「過去にコンサルが2社入って失敗している。SHIFTさんで3社目だね」。 

現場は「また別の会社が来たか」と諦めている状態、つまり“期待値ゼロ”からのスタートとなりました。 

私たちがそれまで方向性などをすり合わせていたお客様側の役員たちと、現場の気持ちには乖離があることを肌で感じた以上、トップダウンの方針をそのまま押しつけても現場は絶対についてきません。

そこで私は、現場の心をつかむべく、ボトムアップの組織構築へと舵を切りました。 

1ヶ月間、毎日2〜3人ずつ、計50名の現場担当者と対面ヒアリングを敢行。

「企画部門から渡される企画書の情報が不足している」などの現場のリアルな声を拾い集め、日々の業務フローに紐づく「100個以上の不満と課題」を洗い出しました。 

この不満と課題を役員陣へと確実に伝えたい。役員陣の心を動かす方法を模索した結果、2ヶ月目にして私は現場の不満と課題を“通知表”という形で役員に提示しました。そこで示した評価は“最低”です。 

その上で、理想と現場の課題を解決するハイブリッド戦略を提案し、合意形成しました。この本気の姿勢が役員や現場の心を動かし、結果的に5ヶ月という短期間で強固なガバナンスとプロセス品質の構築に成功しました。

【事例3】自由を愛するエンジニアに“規律”を。反発を乗り越えた定量化のプロセス改善

3つ目の事例は、100万人近くの国内利用者を擁するシステムの開発プロセスを刷新するプロジェクトです。SHIFTは開発プロセスの刷新、開発成果物のフォーマット、ガイドラインの策定を依頼されました。 

最大のハードルは、企業カルチャーでした。CTOが採用時に「うちに入れば自由に何でもできる」と謳っていたため、エンジニアたちは自由を求めて入社してきていました。

そこに、開発フォーマットやガイドラインといった“規律”を導入しなければならないという、ジレンマを抱えたプロジェクトでした。 

自由を愛するエンジニアにルールを押しつければ、猛烈な反発を招くのは火を見るより明らかです。そこで私が着目したのは、「彼らは自由を求めるが、無駄な作業は嫌う」というエンジニアの特性でした。 

スキルアップの妨げになる業務は切り離し、有意義なプロセスだけを構築する。そしてその意義を、感覚ではなく定量化して証明しました。

現在の傾向を分析するとともに、新しいプロセスのトライアルを行い、結果をデータとして提示しながらPDCAを回していきました。

具体的な成果も現れました。エンジニアたちはテスト工程に入った際、QAメンバーからの質問への対応を煩雑に感じていたのです。 

そのため、「質問が来ないように上流工程のプロセスを改善しませんか？」と提案し、その結果、質問対応が半減しました。

自らの業務効率化というメリットを実感したことで現場の意識が変わり、結果的に上流工程の生産性は1.3倍に向上。いまではお客様自身でPDCAを回し、自走するカルチャーが確立されています。

誰も疲弊しないプロジェクトへ。QAに求められるのは「PMと同等の視座」

ここまで、プロダクト開発に関わるすべての方々に向けて、私たちが手掛けてきた事例をお話ししてきました。

これらの事例の根底にあるのは、私のなかにある「品質を創る」という信念です。これはSHIFTの品質に対する想いと似通ったところがあります。 

どんなに丁寧にテストをしてバグのない状態をつくっても、なぜか現場のエンジニアは土日出勤を強いられている。子どもが生まれて家族と過ごしたいと願う優秀な若手たちが疲弊し、会社を去っていく――。

そんな状態を私は許したくありません。

上流工程からスムーズな開発ができるプロセスを構築し、品質を創る。そのためには私たちが「テスト専門のベンダー」という枠にとどまっていてはいけません。

後工程へのしわ寄せを防ぐためにも、調達などの一部を除き、弊社の品質管理担当者はPMやPMOと同等のスキルと視座をもつ必要があると考えています。 

プロジェクト全体を俯瞰し、リスクや品質に関しては誰よりも高い感度をもち、上流工程からプロジェクトを牽引していく。そうして健全に開発できる環境を築くことこそが、私たちが目指す真の品質マネジメントです。 

SHIFTの挑戦は現場のプロセス改善だけにとどまりません。

近年では、24時間365日稼働する品質AIソリューション「ネムラナイ」の立ち上げや、AIを用いて品質をどのように構築していくかという新たなサービスの開発・運用にも着手しています。

品質保証の新たな可能性を切り拓きつづけている私たちに、ぜひ今後もご注目いただければと思います！

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

能力はアップデートされているのに。60歳で新たな打席を求めた原点

――石井さんは長年、大手メーカーでIT系のコンサルティングに従事してこられました。そんな石井さんが、60歳という節目で転職を決意した原点はどこにあったのでしょうか。 

石井：役職定年がきっかけでした。60歳を迎えると役職が外れ、部下もいなくなります。しかしその一方で、会社から求められる売上ノルマは、現役時代と変わらない規模で課されつづけるのです。 

私自身の能力や気力が衰えた感覚はまったくなく、むしろこれまでの経験を統合して自身のケイパビリティは日々バージョンアップしているという自負すらありました。 

それなのに役職定年によって第一線から引きはがされる感覚に、違和感と悔しさを抱きました。さらに、年収がそれまでの半分以下にまで激減したことも拍車をかけました。 

――周囲からは、どんな声をかけられましたか？ 

石井：友人たちからは「これからはゆっくり過ごせばいいじゃないか」といわれました。 

しかし、私は第一線に立ちつづけたかったのです。同じ領域に固定化され、将来の成長曲線が平坦になっていくことへの恐怖もありました。

もう一度打席に立ち、自分の立ち位置を自らの手で確保したい。そう思い、転職活動を開始しました。

心を震わせた“コールオプション”の教えと、SHIFTにあったウェルカム感

――とはいえ、日本の転職市場における年齢の壁は厚かったかと思います。そんななかで、石井さんに未知の領域へ飛び込む覚悟を決めさせたものは何だったのですか？ 

石井：転職活動の前に通っていたビジネススクールで、ファイナンスの教授から贈られた一言です。 

「石井くん、人生はコールオプションだよ」。 

金融のコールオプションとは、「損失は限定的（支払ったオプション料まで）利益は大きく伸びる可能性がある」という特徴があり、これを人生に置き換えると「小さなコストやリスクで挑戦し、大きな可能性を取りにいく生き方」という意味になります。

教授は「リスクは限定的なのだから、どんどんチャレンジしなさい」とおっしゃいました。 

私の場合、子供たちは独立し、物理的なリスクは極めて限定的でした。一方で、新しい環境に飛び込んで得られるリターン（成長の可能性）は無限に広がっているはず。「失敗したって、なんとかなる」と思えたのです。

―― そこからSHIFTとの出会いに繋がっていくのですね。最終的にSHIFTへの入社を決めた最大の理由は何だったのでしょうか。 

石井：一言でいえば、圧倒的な“ウェルカム感”を感じたからです。他社は「来てもいいよ」といった雰囲気。 

一方、SHIFTの面接は全く温度感が違いました。

「ぜひ来てほしい」という温かさがあり、面接官の方からも「一緒に働けるのを楽しみにしているよ」といった雰囲気で声をかけていただくなど、歓迎されていることを強く感じました。 

また、思いがけずAI領域を打診され、「実務経験はないですよ」と正直に伝えたときも、背中を押してくれたのです。 

私をいっしょに働く仲間として迎え入れてくれる空気を感じたこと。そして、自分でも気づいていなかったポテンシャルを引き出そうとしてくれたこと。それが、SHIFTへの入社を決断した理由です。

3つのAI案件を同時牽引。自身の主戦場を再定義し、最前線で戦う

――先ほどお話に出ましたが、配属先はAIサービスグループ。配属に対して戸惑いはありませんでしたか？ 

石井：本当に想定外の打診でしたから、驚きましたよ。しかし入社から3ヶ月が経った現在、私はまったく性質の異なるプロジェクトを3つ同時に牽引しています。 

1つ目は、お客様社内のAI開発を統合・統括するCoE（Center of Excellence：目的や目標を達成するために、優れた人材、技術、ノウハウなどを集めた組織・グループ）のPMO支援。

２つ目は、金融機関における業務整理とAI導入に向けたコンサルティング。 

そして３つ目が、大手メーカーのシステム子会社における「SHIFT DQS for リバースエンジニアリング（ソースコードを基にシステムの内部仕様と外部仕様をAIで可視化し、ドキュメントを生成する）」のプロジェクトマネジメントです。 

―― AIの技術的なスペシャリストではないご自身が、この最前線のプロジェクトにおいて、どのような強み（ケイパビリティ）を期待されてアサインされたと認識していますか？  

石井：自分の主戦場である“上流工程の課題抽出”に対する期待だと思います。現在のAI市場は技術の基礎研究フェーズから、いかに企業の既存業務に組み込んで利益を創出するかという“実用化・成熟期”へシフトしています。 

つまり、お客様が直面している本質的な課題は、技術そのものではなく「自社のどの業務を、どう整理してAIに落とせば、期待する効果が得られるのかがわからない」という上流工程のプロセス不全。 

本当に必要なのは、お客様の業務を構造化し、課題を分析・分類して、プロジェクトのゴールを指し示してあげることです。このプロセスにおいて必要とされるのは、長年のキャリアで培ってきた傾聴力とPM力です。 

もちろん、技術的な知識も習得しますが、お客様の真意を言語化することに徹するようにしています。

ニーズよりペイン（お客様の困りごと）をいかに引き出すか、nice to haveではなくmust haveを見出していくことが重要だと思っています。

若手の技術力×シニアの大局観。互いをリスペクトしあって生まれる、最強のシナジー

――大企業からSHIFTへ移って、組織の推進力や文化の違いは感じますか？ 

石井：もっとも驚いたのは、スピーディーな意思決定でした。前職では、1つのAI案件を立ち上げようとしても、要件定義や稟議に時間がかかり、最終的にドライブがかからず実を結ばないケースもあって。 

さらに、小さな案件にリソースを割くことに慎重になることで、お客様が本当に困っている細かな課題をこぼし落としてしまいがちでした。 

――SHIFTのアプローチはそこが全く異なると。 

石井：はい。SHIFTは「まずは短期・少額でスモールスタートしてみる」という柔軟なアプローチをとっています。 

まずは1〜3ヶ月という短いスパンでお客様のオフィスで、文字通りお客様の隣に座って伴走するのです。これによりプロジェクトがスピーディーに立ち上がります。 

特に変化の激しいAI領域やアジャイル開発においては、この「まずは一緒にやってみる」というスタイルが有効に機能しています。営業・アサイン・デリバリーが役割分担されている仕組みも、大企業にはない強みですね。 

――AIサービス部は若いメンバーも多いですよね。どのように協働されているのでしょうか。 

石井：20代の若いエンジニアたちとの間に、補完関係を構築するように努めています。 

彼らの技術力には、目を見張るものがあります。お客様の要望に対してすぐに手を動かしてプログラムやプロンプトを組み、目に見える形でお客様にパッと提示してみせます。 

私の役割は、彼らがディテールに没頭しすぎたり迷い込んだりしたとき、「いまそのリスクは考えなくていいんじゃない？」とか、「今回のプロジェクトのゴールはここだから、このプロセスは大胆に端折ろう」と、大局的にプロジェクトをみながら推進のための勘所をおさえていくこと。 

技術の最前線で手を動かす役割は若手が担い、全体の視座を引き上げ、お客様と相対する際の傾聴力やPM力を私が担保する。この役割分担があるからこそ、SHIFTでお客様の課題を切り崩していけるのだと考えています。

眠っていた潜在能力が引き出される快感。キャリア後半戦に挑む同志へ贈りたい言葉

――石井さんがこれからSHIFTで実現したいことを教えてください。 

石井：短期的な目標としては、AIサービスグループのなかに業務改善とプロセス分析を軸としたコンサルティングチームを新しく立ち上げ、若手を育成していきたいと考えています。

AIを真にお客様の利益に変えるためには、上流の業務プロセスを整理できる人間が不可欠だからです。 

そして長期的な展望としては、お客様企業のCIOクラスの片腕となり、経営戦略とIT戦略をシームレスに結びつけるアドバイザーとしてのポジションを確立していきたいですね。

――かつての石井さんと同じように、定年前後でこれからのキャリアの身の振りに悩んでいるビジネスパーソンへ、メッセージをお願いします。 

石井：50代、60代まで企業で一線を張って生き抜いてきた方なら、本人が気づいているかどうかにかかわらず、どの会社に行っても活きる強みや人間力が必ず備わっていると思います。 

ただ、それが何なのか。自分のどんなスキルが他者から高く評価されるかは意外とわからないものです。私自身、AIソリューションの門を叩くことになるとは想像すらしていませんでした。 

しかし、一歩を踏み出してみたことで、自分の潜在能力が引き出される快感を味わえています。 

「人生はコールオプション」です。限定的なリスクを認め、未知の可能性へ向かって大胆にスイングしてみませんか。 

（※本記事の内容および取材対象者の所属は、取材当時のものです）

お客様が目の前で解約しているのに動けない――。提供価値と成長を止めないための決断

――田邉さんは前職にて、非常に大きな成果を上げられたと伺っています。具体的にどのような挑戦をされていたのですか？ 

田邉：当時はシステム開発を行うチームで、技術レベルに関わらず誰でも安全かつ素早くシステムへ変更を加えられる共通基盤をゼロから提案し、構築しました。 

それまでは、お客様から変更要望をいただいてから本番環境に反映するまでに1週間以上かかっていたのですが、簡単なものであれば即日・最短で1時間以内システムに反映できるようになりました。 

――1週間が1時間に……！お客様もすぐに対応してもらえるようになって喜ばれたでしょうね。 

田邉：ええ。はやさという観点以外にも、システムに対して変更を加える作業は、実務を担うメンバーにとっても非常に精神的な重圧がかかる仕事だったんです。

安全な仕組みを提供したことで、「非常に簡単にできるようになった」と大きなメリットがありました。自分でゼロから提案して会社に認められて進められたのはいい経験だったと、やりがいを感じましたね。

新しい挑戦を通じて、お客様への提供価値が高まり、会社の利益が拡大し、自分も成長する。この循環がエンジニアとしての私の原点でした。 

――そこから、なぜ転職を考えられるようになったのでしょうか？  

田邉：会社のグループ化を契機に、組織の巨大化に伴う“構造的な停滞”に直面したからです。意思決定のスピードが鈍化するとともに、先進的な機能へのリソース投資の蛇口が徐々に絞られていくのを感じていました。 

例えば、あるシステム刷新のプロジェクトでは、提案から実際に動き出すまでに1年近くの歳月を要してしまいました。このスピード感では競争力を維持できないと、強い危機感を覚えたのです。 

――1年近くも。それは、やきもきさせられそうですね。 

田邉：はい。意思決定の遅れは、すなわち「お客様に価値を提供できなくなる」期間が長くなることを意味します。そうなれば他社の方が有利になり、市場における相対的な競争力は低下してしまいます。

1年待っている間にも、古いバージョンを使いつづけているお客様がどんどんサービスを解約して離れていってしまっているという事実があったんです。

大企業のアセット×機動力。「なんでもやってやる」の熱意に惹かれて

――転職活動の折、SHIFTから連絡が届いたそうですね。SHIFTにはどんな印象をもたれましたか？ 

田邉：正直にいうと、数年前に取引があった当時の「ソフトウェアテストを非常に緻密かつ頑健にやり遂げてくれる会社」という印象で止まっていました。 

SHIFTを改めて調べ直したときには驚きましたね。IT業界のあらゆるバリューチェーンを網羅する総合DX企業へと変わっていたからです。 

―――大きな企業になっていて、意思決定のスピードが遅くなっているのではないか、とは思われませんでしたか？ 

田邉：面接や面談でお話するうちに、その懸念はなくなりました。

お会いした方々が、会社の掲げる野心的な目標や利益に対して強烈な当事者意識と、「自分がこの組織をさらに大きくしてやる」という熱量をもっていたからです。 

面接資料にも、成長のキーワードとして“スピード”が明記されていました。元々は、前職のような特徴ある自社サービスを持つ小規模な開発会社やベンチャー企業を候補に考えていました。

でもSHIFTは大企業としての圧倒的なアセットをもちながら、ベンチャー企業よりも遥かにベンチャーらしい機動力と貪欲さを失っていない。 

大きい企業なのに、誰もが会社のことを自分ごととして考えていて、「そのために必要なことは恐れないで、何でもやってやるぜ」という熱意。

それを感じたときに、こういう熱意ある仲間が集まっている会社であれば、「事業会社」にこだわる必要はないし、新しい挑戦もできそうだと感じました。 

会社の成長速度を自分のエンジンに変え、お客様の利益を最大化していく。私のキャリアの軸が、SHIFTなら叶えられるなと思い入社を決めました。 

――実際に入社してみてスピード感のギャップはありませんでしたか？ 

田邉：むしろ「やっぱり早いんだな」と確信に変わりましたね。プロジェクト全体の方向性はお客様とのすり合わせになるのでSHIFTだけで勝手に決められない部分もあります。

ただ、SHIFTとして「どういう体制やアプローチでお客様に挑むか」という、社内の意思決定がとにかく早いんです。

 社内での方針決定が迅速に行われるため、それをベースにしたお客様への新しい提案や、報告内容の決定もスピーディーに展開できます。

社内の根回しや何重もの稟議で待たされる時間が極めて少ないのは、PMとして本当に動きやすいですし、入社前に期待していた以上のスピード感ですね。

年齢や立場の壁はない。 CxO向けAIからRAG開発まで、フラットに「ベストな引き出し」を出しあう

――現在はAIサービスグループで、具体的にどのようなプロジェクトに関わっているのでしょうか。 

田邉：エネルギー業界のCxO向け業績分析AIシステムの構築から、自動車業界の「部品調達・在庫最適化のための製造業システム」のマニュアルを全学習させた高精度なRAG搭載AIアシスタントの開発まで、担当プロジェクトは多岐にわたります。 

お付きあいするお客様の多くは、企業内でAI活用を推進する専門部門の方々。お客様自身もAIの知識が非常に高く、技術的な知見が豊富な方ばかりです。

だからこそ、私たちは常にその一歩先を行く提案をしなければならず、知識のアップデートは欠かせません。 

――高いレベルの提案が求められる環境なのですね。チームの雰囲気はいかがですか？ 

田邉：上司や同僚、若手メンバーも含めて、非常に優秀な方が多いですね。常に高い視座で本質的な議論に集中できるため、 不毛な悩みなしに仕事を進められるやりやすさがありますね。 

特に、いまの若手メンバーは最初から「AIを使うのが当たり前」という環境で育った「AIネイティブ世代」です。 

あるプロジェクトで、AIに自律的にコーディングさせる開発環境を導入しました。

実務での本格的な運用は私自身はじめての経験でしたが、若手メンバーたちが、自発的に高度な開発環境を構築しスピーディに成果を出していきました。 

――そんな若手メンバーたちを前に、PMとしてどう振る舞ったのでしょうか。 

田邉：私たちは年齢は違っても、同じ目的のために集まっているフラットな関係です。 

だからこそ、私が疑問に思うことがあれば、先行して環境を構築してくれた若手メンバーに「これってどうやってクリアしたの？」と率直に教えてもらいました。 

それぞれがもっているベストな引き出しを出しあうのが一番合理的ですから。若手が最先端の技術で突き進むのであれば、私は「責任は僕が取るよ」というスタンスでプロジェクトを支えればいい。

そうやって互いをリスペクトしあえる関係が、一番いいチームの形だと思っています。

時代は“利益を出すAI”へ。自身の引き出しを増やし、お客様への価値を最大化する

――田邉さんはITの新しい技術だけでなく、マネジメント手法のアップデートも日々意欲的に行われているそうですね。自身の成長も、あくまでお客様への最適な提案のためなのですね。 

田邉：はい。もし私自身の引き出しが少なければ、お客様の課題に対して「自分が知っている狭い解決策」しか提案できず、ベストではない方法を押し付けることになってしまいます。

それは結果として、お客様の利益を減らすことにつながるのです。 

いま、AI市場は劇的な成熟期を迎えており、実証実験（PoC）のフェーズは終わりました。現在の経営者が求めているのは、既存業務への正確な影響度と、導入に伴う投資対効果（ROI）です。 

だからこそ、私たちの存在価値が高まっています。事業成長に直結する果実をお客様に届けるために、私自身が「技術」「プロジェクト管理」「コミュニケーション」のすべての引き出しを増やしつづける。

それがプロとしての誠実さだと考えています。

――お客様に対し、どこまでも誠実なのですね。最後に、大企業や事業会社でPMを務め、SHIFTへの転職を考えている方々に向けて、メッセージをお願いします。  

田邉：SHIFTは規模の大きな会社でありながら、大企業にありがちなスピードの鈍化とは無縁の組織です。 

また、周りのメンバーが非常に優秀で協力的なため、 私たちが本来集中すべき「お客様への価値提供」に真っ直ぐに向きあえる体制が整っています。 

AIという変化の激しい分野で、自分が成長することで、お客様の利益、会社の利益に貢献する。この「Win-Win-Win」を追求したいという方と、ぜひいっしょに働きたいですね。

（※本記事の内容および取材対象者の所属は、取材当時のものです）

孤独とキャリアの壁。PMを追い詰める「つらさ」の正体

司会：本日のトークテーマでもある「なぜPMはつらいのか」。お二人はこの「PMのつらさ」の正体は何だと思われますか。

白木：今回の登壇に先立って複数のPMのかたにヒアリングをしたのですが、「不確実なプロジェクトに一人で向き合う孤立感」が際立っているように感じました。

でも深掘りしてみると、本当の理由は「システムの構造」にたどり着くのかなと。 

長年運用されているシステムでは、ドキュメントが整備されていない、または仕様を把握している人がいないことが多い。

ブラックボックス化した状況に一人で向き合わなければならず、孤立感や人間関係の悪循環にもつながっていると感じました。 

司会：構造の不明瞭さが、現場をギスギスさせてしまうのですね。竹村さんはいかがですか。

竹村：日本のベンダー業界では「プログラマーからSEになり、経験を積んでPMになる」というキャリアパスが一般的です。 

私自身もそうだったのですが、「技術的な分野でスキルを伸ばしていきたい」という方にとって、PM以外の選択肢がない一本道のキャリアは、非常につらいものなんです。 

司会：「自分の志向性をキャリアに反映しづらい」。共感してくださるPMの方は多いのではないでしょうか。

ブラックボックスを可視化する。DQSでPMの“構造的な悩み”が解消する理由

司会：そうした「PMのつらさ」を、まずはシステムの構造的課題という観点から打破するために、SHIFTが採っているアプローチを教えてください。 

白木：「AIモダナイゼーション」というサービスを提供しています。 

全体像としては、レガシーシステムの仕様を解析するリバースエンジニアリング（以下、DQS for RE）と、そこからモダンなシステムへ再構築するフォワードエンジニアリングの2つのパートにわかれています。 

サービス名にもあるDQSとは「Development Quality Standard」の略で、高品質なシステム開発を実現するための標準化されたSHIFT独自の開発フレームワークおよびプロセス群を指しています。

参考：「SHIFT DQS for リバースエンジニアリング」プレスリリース 

司会：DQSはどんな課題を解決するために生まれたのでしょうか？ 

白木：最大の目的は、システムのブラックボックス化からの脱却です。DQS for REでは、外部仕様と内部仕様をともに解析してドキュメントを生成し、システム全体を可視化することで現状を把握しやすくします。 

またもう一つの重要なメリットに、ベンダーロックインの解消があります。

フォワードエンジニアリングではオープンソースや標準的な技術を採用したボイラープレートを用いるため、特定ベンダーへの依存を防ぐことができます。 

竹村：ここに対して私たちは、AIによる現状の可視化を先行し圧倒的な短納期と低コストを実現することで、ベンダーロックインの牙城にも切り込んでいくことができると考えています。 

司会：システム構造がスムーズに可視化できることで、PMもつらい思いをせずにすみますね。 

白木：ええ。可視化の最大のメリットは、認識合わせの土台ができることです。 例えば「200画面だと思っていたら実は1,000画面あった」という事実が最初に可視化されます。

もちろん実際は年1回しか使わない画面などの濃淡があるとにせよ、まず1,000画面あるという客観的な事実が土台としてそろいます。

それをもとにお客様と認識合わせができるためPMも安心でき、後々のトラブルや認識の相違を減らせるのが非常にいいポイントです。 

また途中からプロジェクトに参画するPMやチームの負荷も激減されます。

私はエンジニアとして途中参加することもありますが、全体像を俯瞰しつつ、具体的に踏み込んだ「内部仕様（ソースコードの中身）」までツールで見られるため非常にありがたいものだと感じています。 

司会：視聴者の方からも「動いているソースコードしか信頼できない場合が多い」とコメントをいただきました。 

竹村：最近はアジャイル開発を採用するケースも増え、それに伴いドキュメントをつくらないことも多いです。

しかし、発注側である事業会社のお客様はベンダーに任せる以上、ドキュメントがないと困るため「アジャイルを進めながらドキュメントもつくりたい」というジレンマを抱えています。  

また保守運用のなかでソースコードだけが修正され、ドキュメントの更新が止まって乖離していくケースも非常に多いです。

こうした課題に対しても、ソースコードからリバースエンジニアリングで正確なドキュメントを生成する仕組みは有効で、ソースコードと合致した信頼できる状態をつくりだせます。 

ストラテジックアーキテクトという次世代キャリア、AI時代のPMが選べる未来

司会：AIモダナイゼーションが進むと、PMのつらさが解消されるだけでなく、仕事自体も変わってきそうですね。 

白木：はい。これまではエンジニアに依頼しないとできなかったシステムの課題特定やデータ抽出などを、AIを使うことでPM自身ができるようになってきています。

AIのサポートによって、エンジニアとPMの垣根がどんどん少なくなっていくと思います。 

竹村：そうですね。例えばPM業務の大きな比重を占めている、各エンジニアへの進捗確認や、それをもとにした報告書の作成などの管理業務は、今後AIが代替していくかもしれません。 

白木：すでにSHIFTのPMのなかにも、タスク管理ツールとAIを連携させ、遅延タスクや会議のネクストアクションが一目でわかるダッシュボードを自作して進捗管理をしている方がいます。  

竹村：AIを使うことで業務負荷が軽減され、より本質的な人間による判断や、お客様とのコミュニケーションに集中できるようになると思います。 

司会：PM本来の業務に集中できるようになるのですね。一方で、これまで「技術を極めたいのにPMになるしかない」というキャリアの壁もPMを苦しめてきました。AI時代において、この一本道のキャリアはどう変わるのでしょうか。 

 竹村： 技術を追求したい方向けに、新しいキャリアパスとしてSHIFTの「ストラテジックアーキテクト」というポジションにぜひ挑戦してみてほしいです。 

司会：ストラテジックアーキテクトはどんな役割を担っているのですか？ 

竹村：「この課題を解決するためには、システムをこう変えていきましょう」というTo-Be（理想の姿）の設計と、そこに至るまでのロードマップを策定するのが主な役割です。 

 SHIFTのストラテジックアーキテクトの特長は、「AIを多用する」点です。AIを使って現行システムのソースコードを高速かつ横断的に分析し、セキュリティの脆弱性やコードの複雑化といった課題を抽出します。 

レガシーとモダン両方のアーキテクチャを理解していないと具体的な改善策は提案できません。

常に最新技術をキャッチアップする必要があるため、技術志向の方には非常に面白い仕事だと思います。 

司会：お客様は具体的にどんな課題を抱えているのでしょうか。 

竹村：65社以上のソースコードを分析した結果分かったのですが、96％ものお客様は「テスト基盤の欠如」と「コードの複雑化によるメンテナンスの煩雑化」に苦しんでいます。 

さらにセキュリティ課題も多く、脆弱なフレームワークやライブラリを使いつづけたり、パスワードが平文になっていたりするケースが、74％のお客様で発生しています。 

司会：そのようなお客様に対して、どのように提案をするのでしょうか？ 

竹村：AIが抽出した客観的なデータで現状を可視化し、To-Be（理想の姿）を描きますが、究極の理想像を一足飛びに実現できるわけではありません。実際にはお客様の予算に収まるかという問題があります。 

脆弱性対応など緊急性の高いものから優先し、お客様と相談しながら「まずは中間地点まで行きましょう」と現実的な落とし所を探っていく泥臭さも、ストラテジックアーキテクトの重要な役割です。 

PM業務で培ってきた「お客様との調整力」や「プロジェクト推進」の経験に、最新の技術知見を掛けあわせるからこそ、ストラテジックアーキテクトとして大きな価値を発揮できるのです。

現状を説明すると「大事に育ててきた子どもをけなされたようだ」と感じるお客様もいらっしゃいます。

でも私は、「大事な子どもだからこそ、つぎはぎだらけの服ではなく、新しい服を着せてあげましょう」と内心にそんな思いを抱えながら、客観的なデータをもとに真摯に向き合っています。  

AIとともに新しい道を。技術者本来のやりがいを取り戻す

司会：AI時代に新しいキャリアを描く場として、SHIFTという環境にはどんな面白さがありますか？ 

竹村：AIを活用して新しいことに挑戦できる面白さではないでしょうか。SHIFTには、やると決めたらすぐに実行に移す文化があります。  

白木：竹村さんがおっしゃった文化ですが、創業者である丹下がいまもトップでクイックに意思決定をしているのがいいポイントですね。

AIを全力で推進するという経営方針のもと、最新のAI技術を使いながらお客様の課題解決に取り組むことができます。 

新しいことに挑戦したいエンジニアやアーキテクトにとって、非常に面白くやりがいのある環境ではないかと思います。 

司会：では最後に、かつての竹村さんのように「本当は技術を極めたいけれど、一本道のキャリアの中でPMをやっている」、そんな悩みを抱えている方々へメッセージをお願いします。 

竹村：AIの登場で、キャリアは一本道ではなくなりました。

マネジメントを極める道もあれば、AIの知見を深めてとことん業務を効率化する道、技術志向の方はプログラマーのまま、もしくは私たちのようなアーキテクトやストラテジックアーキテクトになる道もあります。 

白木：加えていえば、「もう一度、エンジニアリングの世界に戻る」という選択肢もいまの時代なら大いにあり得ると思っています。

PMを務めている方の多くは、かつてコーディングや設計をとことん経験されてきたバックグラウンドをおもちのはずです。 

いまはAIがコーディングを強力にサポートしてくれる時代だからこそ、PMで培ったプロジェクト推進や全体把握の経験を武器に、再び技術の最前線に立つことも十分に現実的です。

実際に、スタートアップでCTOを務めた方がエンジニアに戻るのを拝見したことがあります。 

竹村：SHIFTには、そうした構造的なしがらみを壊し、自身の志向にあったキャリアパスを歩める環境があると考えています。 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

技術進化に取り残される日本のITマネジメント

森實氏：エンジニアリングの世界はAIの登場などによって猛スピードで進化していますよね。現場は新しい技術を追いかけ必死に食らいついている。しかし、マネジメント手法のアップデートがそこにまったく追いついていないように感じます。 

渡会：おっしゃるとおりです。例えば、昔は「Kstepあたりのバグ密度」や「設計書の厚さ」「レビューの回数」などで価格や品質を管理していましたよね。 

しかし、AIがコードを書く時代に、Kstep単位の管理に何の意味があるのか？と。

ものづくりのスピードは上がっているのに、マネジメントだけがオールドスタイルのまま。このギャップが、いまの日本のIT組織にゆがみを生み出しています。 

森實氏：多くの国内企業では、自社の「ソフトウェア開発標準」をモデルにしてプロジェクトを回しています。

開発標準はPMBOKなどをもとにつくられているわけですが、最新の内容をどう取り込めばいいのか悩んでいる企業が多い印象です。 

渡会：歴史の長い会社ほど、古いバージョンのPMBOKをベースにした開発標準を使いつづけています。しかし、PMBOKは時代にあわせて約4年ごとに改訂されているため、本来は自社の開発標準もアップデートする必要があります。 

森實氏：一度つくったルールを変えるのは大変だからと、放置されがちですよね。 

渡会：欧米では「アジャイルか、ウォーターフォールか」という二項対立をすでに終わらせて、スピーディーに業務を変化させています。いま求められているのは、両者を統合し変化に適応することです。 

例えるなら、世のなかではステルス戦闘機やドローンといった最新の武器が使われだしたにも関わらず、日本は刀で戦おうとしている。だから「デジタル小作農」なんていわれてしまう危機的状況にあるのだと思います。 

森實氏：ここで視聴者からの質問です。『SI型（受託開発）と自社開発で、変化への対応力に差はあるのか？』という疑問ですが、これはいかがでしょう？ 

渡会：自社製品の方が自分ごとにしやすく、時代についていきやすい面は確かにあります。しかし本質的には、自社開発か受託開発かはあまり関係ありません。

つくったものが「どういう価値を生み出すのか」という中身は同じはずだからです。受託だからむずかしいというのは、自分で壁をつくってしまっている状態なんですよね。 

森實氏：同感です。たしかに自社開発の方が、企画から実運用まで見通せる分、変化に対する「感度」は高まりやすい面はあります。

一方で受託開発は、プロジェクト範囲が切り出されているため、感度を高めるのがむずかしいのも事実です。

しかし大切なのはOODAループを回しつづけ、状況の変化を感じ取ること。その感覚の重要性は、自社開発でも受託開発でも変わらないですよね。 

渡会：ええ。根本的な問題は、お客様と開発企業が「発注者と作業者」のように固定化された関係になってしまっていることにあります。

本来は、ビジネスのプロとつくるプロが協働して一つの価値を生み出すべきです。本気で思考し提案すれば、受託開発でもうまくいくと思いますよ。 

辞書から経典、そして実践書へ。PMBOKの変遷を辿る

森實氏：ここでPMBOKの歴史を振り返りたいのですが、第6版から第7版、そして第8版への変化をどう見ていますか？ 

渡会：第6版は「辞書」、第7版は「経典」のような存在でした。第6版まではプロセスが詳細に定義されていて、「このプロセスに従っていれば成功する」という誤解を生みやすい、分厚い辞書でした。 

森實氏：プロセスを守ることが正義、というのは現場にとってはわかりやすかった面もありますよね。 

渡会：それに警鐘を鳴らしたのが第7版です。プロセスではなく原理原則や価値の創出に大きく舵を切った方針書であり、精神論に近い“経典”のようになりました。 

森實氏：第7版が出たとき、あまりの急激な変化に現場は戸惑ってしまいましたよね。私も当時、「まずは第6版のプロセスを理解してから第7版を読むと腑に落ちるよ」とアドバイスした記憶があります。 

渡会：ソフトウェア開発宣言の精神に戻るような大きな視点に行きすぎて、実務を担う現場の人たちが少し置いていかれてしまったのは事実ですね。 

森實氏：そこで登場したのが第8版です。第8版は何に例えられますか？ 

渡会：第8版は、いわば“実践書”です。第7版で描かれた原理原則をちゃんとやっていくためのルールブックのようなもので、40のプロセス群に分けたモデルケースが載っています。 

これは「この40のプロセスを使うならば、自分たちのプロジェクトにあわせてテーラリング^※して使いなさい」という実践的なガイドラインになったと受け取ってもらうのがよいと思います。 

※プロジェクトの特性にあわせて手法やプロセスを最適化すること 

「真のテーラリング」は、プロセスの取捨選択ではない

森實氏：第8版でプロセスが復活したことで、「なんだ、やっぱりプロセスに従えばいいんじゃないか」と安心してしまう人もいそうですね。 

渡会：そこは誤解してほしくないですね。「プロセスに戻ったから安心だ」と盲従してはいけません。

スクラムガイドのとおりにやっても、自分たちの文化や目的にあわせてテーラリングしなければ効果的なスクラムが組めないのと同じです。 

森實氏：現場ではテーラリングのことを、プロセスの「いる・いらない」を選ぶことだと勘違いされがちです。

でも私はそういった取捨選択ではなく、用意されたプロセスを「自分たちなりにどう解釈し、どう使うかを言語化すること」こそが真のテーラリングだと考えています。 

渡会：まさにその通りです。わかりやすい例として、「トンカチ」というツールがありますよね。家を建てるときは「釘を打つ」ために、家を解体するときは「釘を抜く」ためにトンカチを使います。 

何のためにこのツールを使うのか、そしてどう使うか。それを自分たちでしっかり考えることがテーラリングです。

第8版で示された40のプロセスも、ただのトンカチと同じです。自分たちのプロジェクトの目的にあわせて、どう扱うかを考えてほしいですね。

ルールを守るのではなく、価値を創れ。新時代のプロジェクトマネジメント

渡会：プロジェクトの成功指標は何かといえば、第7版でも明記されている通り「価値を生み出すこと」です。

プロセスに従っていれば安心なのではなく、「このプロセスを使うことで、私たちは本当に価値を生み出しているか？」をつねに問いかけなければなりません。 

森實氏：ルールを守ることが目的化してはいけない、ということですね。「価値実現」という本質から目をそらしてはいけないと。 

先ほどのトンカチの例えでいえば、チームビルディングも同じですね。

「トンカチ担当」という固定の役割をつくるのではなく、いまは打つのが得意な人が使い、次は抜くのが得意な人が使う。1対1の固定された関係ではなく、必要なときに必要な人が臨機応変に関わっていく。 

渡会：ええ。ツールも役割も、自分たちで解釈して適材適所で使っていく。そういう流動的で目的志向のチームのあり方が、これからの時代には求められています。

森實氏：最後に、これからのプロジェクトマネジメントはどうあるべきだと思いますか？ 

渡会：学んでいくというよりは、「価値実現から逆算していく視点」をもつことです。そして、冒頭でも触れましたが、ビジネス側（発注者）と開発側（受注者）が本気で協働すること。 

相手の要望をただ実現するのではなく、同じ目的に向かって「自分ごと」としてプロジェクトを推進する。そのためのガイドとして、PMBOK第8版のプロセスを利用してほしいですね。

外部の権威ある実践書として、組織や上司を説得するためにもうまく使うことで、真の価値創出に向かいやすくなるのではないかとも思います。 

森實氏：古いルールや主従関係に縛られず、ビジネス側と開発側が協働して価値を生み出す。今回の内容が、変化の激しい時代に立ち向かう皆様のプロジェクトマネジメントのヒントになれば嬉しいです。 

渡会：森實さん、本日はありがとうございました！ 

イベント全編をご覧になりたい方はこちらから  

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。 

5,000名を超える登録者数！技術イベント SHIFT EVOLVEをチェック 

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです） 

完遂と育成の混同が、PMを疲弊させる

私はこれまで15年以上、主に金融領域のSIに携わり、その後いくつかの事業会社を経験して現在はさまざまな 企業やプロジェクトの支援を行っています。

ただ、どこの領域においても「プロジェクトマネジメント」は切っても切り離せないものだと感じています。 

ただ、プロジェクトの話をする前の大前提として、現場で混同されがちな「マネジメント」という言葉への誤解を、まずはっきりさせておきたいのです。

私たちが普段何気なく使っているマネジメントには、プロジェクトの完遂を目指す「プロジェクトマネジメント」と、人材の育成を重視する「組織マネジメント」という、そもそも狙いの異なる2つの視点が存在します。 

しかし、「マネージャー」という言葉で一括りにされることでこれらが混同されがちです。 

組織からはマネージャーとしてのさまざまな能力を期待されるかもしれませんが、 プロジェクトの最大の目的が完遂であるならば、完遂する方法はいくらでもあるはずです。

一人の優秀なPMがすべてを抱え込むのではなく、「チーム全体で完遂する」という選択肢があってもよいのではないでしょうか。 

リスクを分散して完遂の可能性を高めることを考えると、メンバーがいかに生き生きと働けるかが 、チームの最高のパフォーマンスにつながると私は信じています。

メンバー個人が自らの得意を活かして価値発揮を最大化できる環境をつくり、主体性を引き出すこと。それこそが、チームでプロジェクトを成功させるための大前提となるのです。

脱・受け身！説明責任はPMに、実行責任はチームに

チームの総合力を引き出すためには、従来のガチガチに固められた役割分担から脱却する必要があります。 

例えば「インフラ担当はインフラの作業のみ行う」「週次の定例会議はどんな状況でも絶対に開催する」といった、これまで当たり前とされてきた型にこだわる必要はありません。

状況に応じて柔軟に動ける体制をつくることが、チームの能動性や自主性を引き出す第一歩です。 

また、チーム全員にマネジメントさせるうえでもっとも重要なのは、責任の所在の明確化です。プロジェクトにおける「説明責任（Accountable）」は、これまで通り組織に対してPMがもちます。

しかし、「実行責任（Responsible）」までPMが一人で負う必要はありません。実行責任はチーム全員で共有するのです。 

これは、タスクの責任分担を明確にするRACI（レイシー）チャートの考え方に基づいています。実行責任を共有するための具体的なアプローチには、役割の分散があります。 

例えば、会議のファシリテーターや、アジャイル開発におけるスクラムマスターといった役割を、特定の一人に押しつける必要はありません。

全員がファシリテーションを持ち回りで経験し、「今日は私が議事録を担当します」「私がタイムキーパーをやります」といった小さな役割をチーム内で分散させるのです。 

こうして一人ひとりが役割を担うことで、プロジェクトマネジメントの視点がチーム全員に宿り、「これは自分たちのプロジェクトだ」という当事者意識が浸透する、より自律的で強いチームが形成されていきます。

参考にしたい3冊の書籍

ここまでは、プロジェクトマネジメントの視点をチーム全員に宿すという、私の著書『ゼロから始めるチームプロジェクトマネジメント』の根底にある考え方をお話ししてきました。 

さて、今回はさらに2冊の本を紹介したいと思います。同イベントに登壇されている渡会さんの著書『アジャイルに困った時に読む本』と、最新の『PMBOK®第8版』です。

この3冊はそれぞれ立ち位置こそ違いますが、ベースとしているところは同じことを言っていると私は思っています。

それは、単なる方法論ではなく、「チームと価値をどう動かすか」というところが、それぞれの本の共通の軸になっているということです。

自律的なチームをつくる3つのアプローチ

ではこれら3冊の共通項から見えてくる「自律的なチームをつくるための3つのアプローチ」を紐解いていきましょう。

１つめ：プロジェクトは「人と関係性」でできている

プロジェクトを実際に動かしているのは、無機質なタスクやスケジュールではなく、「人」と「関係性」です。

特定のリーダーに依存せず、互いに支えあう関係性を築くことが重要と考えており、私の著書でもチーム内に「小さなリーダー」を増やすことをお伝えしています。 

渡会さんの著書でも、アジャイルがうまくいかない原因はフレームワークの構造自体ではなく、それを実行する「人の解釈」に対するアンチテーゼとして書かれています。

そして最新のPMBOK第8版でも、従来の「管理する」という領域から一歩抜け出し、リーダーシップなどチームのあり方に踏み込んだ内容になっています。

２つめ：万能なやり方は存在しない（テーラリング）

プロジェクトには「これさえやっておけば必ず成功する」という万能なやり方は存在しません。

だからこそ状況にあわせて役割を柔軟に変え、メンバーの体調不良などの不測の事態にもチーム全体でカバーしあう準備と心構えが求められます。 

「これは私の役割」「それはあなたの役割」と線を引くのではなく、「これは“私たち”の役割」と捉える「オーナーシップの共同所有」を私は提唱しています。

渡会さんの著書でも「プロダクトオーナーは一人でなくてもいい」というように、やりたいことに対して手法を踏襲する必要はないと説かれています。 

これはPMBOKが提唱する「テーラリング（※）」の考え方そのものであり、現場のリアルな課題に立ち向かうための強力な武器となります。 

（※）プロジェクトの特性にあわせて手法やプロセスを最適化すること。

３つめ：価値とは成果物ではなく「変化」である

プロジェクトの価値とは、単にシステムやドキュメントといった成果物を納品することだけではありません。プロジェクトを通じて生まれる「変化」こそが真の価値です。 

チームがプロジェクトを進めるなかで、メンバー一人ひとりが成長し、チームも成熟していく。その変化の積み重ねが重要です。

そのためには、プロジェクト完了後の世界観を共有するだけでなく、「自分たちは正しい方向に進んでいるか」をチーム全体で確認しあうことが不可欠です。 

真のチームプロジェクトマネジメントを実践するためには、個人とチームの成長や変化をリンクさせていくことが重要です。 

例えば、プロジェクト全体の「プロダクトゴール」だけでなく、1ヶ月単位の「スプリントゴール」、さらには「このプロジェクトを通じて自分はどのようなスキルを身につけたいか」という個人のゴールなど、複数のゴールを同時に設定します。 

設定したあとは、ときにバックキャスト（※）でふりかえり、それぞれのゴールがリンクしているかを確認することで、納得感をもってプロジェクトに取り組むことができます。 

（※）未来の目標から逆算して現在すべきことを考える手法。 

渡会さんの著書では、この部分を「アウトカム思考」や「継続的な価値創出」という言葉で表現しています。

プロジェクトを単発の有期的なものとして終わらせるのではなく、もっと継続性のある営みの一部として捉える視点を謳っています。 

最新のPMBOK第8版でも、プロジェクトを単なる一時的な活動ではなく、「継続的な価値創出（Value Delivery）のシステムの一部」として捉え直す必要がある、と語られています。

つまり、継続性のなかの一部分だけを切り出すと有期性のあるものであるということを謳っています。 

こうしてみると3冊それぞれが、個人の変化、チームの変化、プロダクトの変化、そして生み出されるアウトカム（成果）の変化について語っているなというのが読みとれます。

まとめ

プロジェクトマネジメントにおいて、一人の優秀なPMにすべてを依存する時代は終わりました。マネジメントの目的を正しく理解し、実行責任をチーム全員で共有することが、現代のプロジェクトを成功に導く鍵となります。 

興味をもたれた方は、ぜひ今回ご紹介した3冊を手に取ってみてください。そして、明日からあなたのチームにも変化を起こし、チームがもつ総合力を最大化していただけたらと思います。

イベント全編をご覧になりたい方は こちらから

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。次回以降もぜひお楽しみに。

5,000名を超える登録者数！技術イベント SHIFT EVOLVEをチェック

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）

求めるのは、あなたの現場力。次世代の開発プロセスで躍動する「AI駆動開発PM」募集