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

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

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」募集 

ドキュメント主導開発が生んだ分断と属人化

ドキュメントに仕様は書かれているのに、意図が伝わらない。ドキュメントは正しいのに、チームは正しく動かない。そんな経験をしたことはないでしょうか。

私が、仕様を“書く”文化から“語る”文化へ移行する必要性を痛感したのは、ある新規プロダクトの開発プロジェクトに参画したときのことです。

そのプロジェクトは、ほぼ初対面のメンバーでフルリモート環境という、暗黙知の共有が極めてむずかしい状況からのスタートでした。

2023年8月から開発を開始し、2024年10月の初回リリースを目指すというスケジュールで、この期間、私はプロジェクトマネージャー（PM）、プロダクトオーナー（PO）のアシスタント、スクラムマスターなど幅広い役割を担いました。

開発手法は、「工程ごとにスクラムを適用したウォーターフォール型」。具体的には、基本設計は1週間ごとのスプリント、詳細設計から結合テストは2週間ごとのスプリントといった形でした。

ところが、プロジェクトが進むにつれて、度重なる要件変更やメンバーの経験不足が影響し、設計工程は遅延しはじめます。

しかし、実装メンバーの参画時期はすでに決まっており、プロジェクトを止めることはできません。

私たちは苦肉の策として、設計チームと開発チームを完全に分離しました。設計チームが残りの設計を進める傍らで、開発チームは完成した設計書から実装を先行開始する。

これは「ファストトラッキング」と呼ばれる、納期を短縮するための手法です。

チームの分離は、無意識のうちに「仕様を考える人（設計チーム）」と「コードを書く作業をする人（開発チーム）」という役割の分断を生み出しました。

設計チームから開発チームへは、ドキュメントという形で仕様が一方通行で受け渡されるだけ。そこには、開発チームによる仕様検討というプロセスが抜け落ちていました。

このドキュメントはリリースするための納品物としての役割は果たしていましたが、チームが仕様を理解するうえでは不十分なものだったと思います。

実際に、ある開発メンバーにAPI設計書を渡したところ、「設計書を読んでも、よくわからない」という言葉が返ってきました。

それもそのはず。設計書にはデータベースの論理名で仕様が記述されていましたが、開発者にとってコードを書く際に必要なのは物理名です。

「考える人」と「つくる人」が分断されたことで、ドキュメントが実装の役に立たなくなってしまった現実を浮き彫りにしました。

後になって、私たちはこの状況が『チームトポロジー』という書籍に登場する「コンウェイの法則」に当てはまることに気づきました。

同書は、「システムを設計する組織は、その構造をそっくり真似た構造の設計を生み出してしまう。コミュニケーションの必要性に応じた設計活動を行うべき」と説いています。

私たちは「設計」と「開発」という分断された組織構造を選択した結果、意図や背景が伝わらないドキュメントを生み出してしまいました。

短期的な成果は得られても、このままではプロダクトの持続的な成長は望めません。私たちは、チームのあり方を根本から見直す必要に迫られました。

チーム体制の見直しで生まれた、新たな属人性

初回リリースを終え、私たちはチーム体制の抜本的な見直しに着手。チーム制を廃止して、要件定義から設計、実装、テストまでの全工程を1つの開発チームが担う体制へと移行しました。

仕様検討のプロセスも開発チームが担うことで、チーム全員が仕様に責任をもち、プロダクト全体を理解できるようになると思われました。

しかし、これまで実装を中心に担ってきた開発チームにとって、「どのようにつくるか」を考える設計プロセスを自分たちのサイクルに組み込むことは困難でした。

特に複雑な機能については、1スプリント（開発サイクル）内で設計からリリースまでを完結させることがむずかしく、実装前のスプリントで仕様検討を先行させるプロセスを採用しました。

ところが、「仕様検討」が、新たな属人化を生んでしまったのです。仕様検討は、チームの誰もが担当するものと想定していましたが、実際には「得意な人」や「やりたい人」に作業が偏ってしまいました。

複数の機能が連携する複雑な仕様について、その整合性や妥当性を理解しているのは、それを考えた本人だけ。ほかのメンバーは、自分の担当機能のことはわかっても、システム全体の動きを把握できません。

いつしかチーム内では、「ここの仕様は、あの人に聞けばわかるはず」という会話が当たり前になっていました。

『The DevOps ハンドブック』には、「作業を受け渡しすると必然的に失われる情報があります」と書かれています。私には、この言葉が刺さりました。

私たちは、チームを一つにしても、メンバー間で役割が固定化されれば、そこに見えない情報の受け渡しが発生し、コンテキストが失われる。

必要なのは、チーム全員で仕様を語り合い、ともに考えるための「仕組み」と「文化」を意図的につくることだったのです。

「語る」文化へ転換。チームで仕様を育てる4つの施策

「考えるチームを育成する」とは具体的にどういうことか。私たちは試行錯誤を重ね、日々の開発サイクルのなかに「対話」を生み出す4つの施策を組み込んでいきました。

1つ目に取り組んだのは、スプリントの最終日にチーム全員でリリース対象の機能を実際にさわり、不具合を意図的に見つけ出す「バグバッシュ」です。

目的や具体的なやり方は以下です。

これによって役割の垣根を越えた対話が生まれ、お互いの認識のズレや考慮漏れが可視化されました。

何より、「自分たちのプロダクトの品質は全員で守る」という当事者意識がチームに芽生えたことが最大の収穫でした。

ただし、リリース直前に問題が見つかるため「気づくのが遅い」という課題も残りました。

そこで取り組んだ2つ目の施策は、リファインメントとプランニングの活用です。

この施策によって、これまで特定の人物が担っていた仕様検討が、チーム全員の活動になりました。

しかし、この段階ではまだ詳細設計や実装レベルでの判断は個々の担当者に委ねられており、そこでの属人性は残っていました。

そこで行った3つ目の施策は、機能開発直後の仕様共有会です。これは、各メンバーが担当機能の開発を終えた直後に、その仕様や実装内容をチームに共有する会です。

その結果、「なぜこのような実装にしたのか」というコンテキストが可視化され、コードレベルの知識がチーム全体に伝播しました。

また、説明責任を全員が負うことで、機能仕様への当事者意識がさらに強まりました。

ただ、複雑な機能に関しては仕様の解釈にズレが生じるリスクがあるため、よりリアルタイムにズレを解消する仕組みが必要でした。

そこで4つ目。事前設計ディスカッションと同期作業といった施策をとりました。

これによって、細かな実装方針についてもチームで合意形成ができるようになり、手戻りが大幅に削減されました。

これら4つの施策は、スプリントの開始から終了までの流れのなかに組み込まれました。

このサイクルをスプリント内で繰り返すことで、「仕様について語り合う」ことが特別なイベントではなく、チームの日常となり、文化として定着していったのです。

仕様を「書く」から「語る」へ。対話がもたらしたチームの成長と今後の展望

この経験を通じて、私たちはプロダクト開発の本質を再認識しました。

『ユーザーストーリーマッピング』という書籍には、「書かれたものを投げ合うことよりも、会話をかわすことが重要なのです」という一節があります。

まさしく、私たちの学びはここに集約されます。チーム全員が対話を重ね、共通の理解を築き上げていく行為によって、自己組織化されたチームは開発され、プロダクトが育つのです。

もちろん、これですべてが解決したわけではありません。「語ること」が中心になったいま、新たな課題も見えてきました。それは、「未来のための記録をどう残すか」ということです。

対話で生まれた合意や仕様の背景を、将来のメンバーや第三者にも理解できるようにするには、ドキュメントが不要なわけではありません。

しかし、それはもはや一方的な「指示書」ではなく、対話の結果を補完する「記録」であるべきです。

仕様を「語る」文化を前提としたうえで、どのようなドキュメントがもっとも価値をもつのか。この問いに取り組めるようになったこと自体が、チーム開発が成功した証だと考えています。

私の経験が、みなさんの自己組織化されたチームの育成・開発に役立てば幸いです。

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

アジャイル文化を醸成しようと意気込んでいた私──100人の「静寂」に感じた課題

私がSEPとして担当してきた数多くのお客様は、「アジャイルの文化が社内になかなか根づかない」という課題に直面していました。実は、私も、SHIFT社内で同じ問題に悩まされたことがあります。

2024年9月、私はアジャイル推進部から製造ソリューションサービス部へ異動しました。

元いたアジャイル推進部では、メンバーが自主的に考え、活発に議論し、マネージャーはメンバーがいかに輝けるかを考える文化がありました。

異動後、最初に参加した部会では、約100名が参加するなかで、発言やリアクションが控えめで、落ち着いた雰囲気が印象的でした。

この違いにふれ、私は「アジャイル文化をつくる」という目標に向けて、まずはこの部ならではの進め方や空気を理解し、安心して意見を出せる土台づくりが重要だと感じるようになりました。

私が当時感じた部内の文化的な特徴は、大きく3つありました。

「無関心」「自分事化していない」「変化への恐れ」です。

これらは一見すると、全社的な特徴としての「SHIFTらしさ」と距離があるようにも見えましたが、決して誰かの悪意によるものではありません。

長い時間をかけて形づくられてきた、この部ならではの特性だと感じました。

だからこそ、これまでの強みや背景を尊重しながら、次の成長フェーズに向けて少しずつアップデートしていく必要があると考えました。

SHIFTは徹底した評価制度をもつ会社であり、それが急成長の原動力の1つとなっています。しかし、当時の部は「評価されるからやる」という外発的動機づけに偏りすぎているように感じていました。

人が本当に生き生きと働くには、外発的動機づけと内発的動機づけの両方が必要です。

本人の「やりたい」「楽しい」という内発的動機づけが不可欠であり、この2つが両輪となってはじめて組織は自律的に動き出します。

部のメンバーが内発的動機づけされた状態をうむことが、私の使命。社内の文化を変えることがいずれお客様にも提供できる価値になると信じて取り組みました。

アクション1：アジャイル人材100倍計画

最初のアクションは、組織全体の意識を変えるための土壌づくりです。個人の思いだけで実現することはむずかしいと考え、「アジャイル人材100倍計画」を立ちあげました。

アジャイル人材とは、不確実な時代に、お客様と対話しながら、仲間と協力して価値を届けられる人。

部の目標に「品質保証エンジニアをアジャイルQAに育てる」「アジャイル支援サービスで価値提供できる組織になる」という項目があったことを活かし、このアジャイル人材100倍計画を打ち立てたのです。

大切なのは人数ではなく、あくまでも「楽しんで働ける、成長できる人を増やす」「変化に強い人材・組織を育てる」こと。

初期段階では、部内から「そもそもアジャイルって何？」という基本的な疑問を投げかけられました。

部内のメンバーの多くは、アジャイルを「自分たちには関係ない特殊な開発手法」と捉えていたのです。 

そこで徹底したのは、「Why（なぜやるのか）」と「Benefit（どんなよいことがあるのか）」の共有です。 

アジャイルとは、特定の開発手法を指すものではない。変化に対応し、価値を届けつづけるための「あり方」そのもの。

プロセスやツールよりも、「個人との対話」「お客様との協調」「変化への対応」を大切にするのがアジャイルなんだ。 

こう説明して、アジャイルなマインドセットをもつことが、個人のキャリアにとっても、日々の業務のストレス軽減にとってもプラスになることを丁寧に説きました。

文化を変える仕掛け群──挨拶と感謝を伝え合う・雑談スレ・育成マップなど

文化を変えるには、現状を正確に認識することが必要です。私は組織会議で「我々の文化はどういう状態なのか」という問いかけを行い、全員で現状を見つめ直す機会をつくりました。

「意見を言いづらい雰囲気はないか？」「挑戦よりも、正解をだすことや失敗しないことが大事になっていないか？」といった問いを投げかけ、「こういう文化は、我々の組織としてよいものか？」という本質的な問いかけを行ったのです。

そして、改善のために最初の一歩として提示したのが、「ありがとう」や「挨拶」といった基本的な行動の徹底です。

文化はいきなりつくられるものではなく、日々の小さな行動の積み重ねで醸成されるもの。助けてもらったら「ありがとう」、朝は「おはようございます」と伝えあうことからはじめました。

さらに、メンバーがSHIFTという会社をより深く知るための機会も設け、提供しているサービスの価値や意義を共有することで、帰属意識と誇りを高める取り組みも行いました。

活動をはじめた当初はコミュニケーションが一方通行になりがちでした。それをなんとか打破しようと、Teamsに雑談スレを作成しました。メンバーが人に興味をもつ「きっかけ」が必要だったからです。

「マネージャー以外のメンバーのことを知らない」という人も多かったので、横のつながりを生み出す場をつくりました。

また、メンバーの成長意欲を刺激するため、ファンタジーRPGのような「育成マップ」を作成。

島国をイメージした地図上で、メンバーがスキルを獲得していく様子を視覚化し、学びを楽しいものに変える工夫をしました。

外部のカンファレンスやイベントへの参加も積極的に促し、組織外の刺激を取り入れる機会も提供しました。

重要だったのは、単に施策を全体に告知して終わりにしないことです。新しい取り組みをはじめても、告知だけでは人は動きません。可能な限り、メンバー一人ひとりに声をかけつづけました。

アクション2：上司との関係構築。活動を数値化し、組織のKPI達成に寄与することを明示

次のアクションは、上司との関係構築です。個人の想いだけでは持続的な変革を促すことはむずかしいため、組織のKPIと私自身の取り組みを連動させる工夫も施しました。

具体的には、私の活動がいかに組織のKPI達成に寄与するかを数値化し、上司に説明したのです。

「アジャイル人材が増えること」が「組織の利益」や「お客様満足度」に直結するロジックを組み立て、活動に対する公的な承認を得ました。

活動が公式に承認されることで、継続性と影響力を高められたと考えています。

アクション3：東日本、西日本の文化の違いを考慮した施策展開

また地域によって文化の違いがあることも考慮し、東京とは異なるアプローチで西日本のチームでもアジャイル文化の浸透を図りました。

「西は西のやり方で」という柔軟性をもたせ、カードゲームなども活用して関西の文化に合った形での展開を行ったのです。

蒔いた種が確実に芽吹いた。明らかな組織の変化

約1年間の取り組みの結果、会議や日常のコミュニケーションにおいて、これまでとは異なる変化が見られるようになりました。

マネージャー以外のメンバーからの発言が増え、チャット欄でもリアクションや意見が活発に交わされるようになっています。

会議は次第に、「参加しているだけ」の場から、「自分たちの意見をもち寄る場」へと変わっていきました。

アンケートにおいて「挑戦することを後押ししてくれる風土がある」という項目が高いスコアを示したことは、こうした日々の変化がメンバーにも実感として届いている証だと感じています。

さらに驚くべきことに、メンバー主導の勉強会が立ちあがりました。自発的に学び、共有しようとする動きが出てきたのです。これは、私が蒔いた種が確実に芽吹いた証拠でした。

部内のアジャイル人材の割合も40％から60％へ増加しました。

アジャイルというアプローチを取り入れたことによって、事業部という大きなくくりで文化を変えていけたことが1つの成果です。

部の成長は、SHIFT全体の成長につながります。今後は、これをほかの部門にも広げていきたいと考えています。

今回の成功は、私個人の情熱だけに起因するものではありません。SHIFTという会社がもつ「変革に対してNoといわない」組織基盤や評価制度と、私のアジャイルなアプローチがうまく融合した結果です。

アジャイル文化の醸成については、社内での成功事例をもとに、お客様への展開も視野に入れています。「アジャイル文化を根づかせることがむずかしい」と考えているお客様に対しても、実践的なノウハウを提供し、日本企業全体においてアジャイルが推進されるよう努めていきたいです。

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

AIの進化により、ご自身のキャリアに不安を感じることはありますか？ 

AIの進化によりキャリアに不安を感じるかという問いに対し、約66％が「非常に感じている」「感じている」を選択。

回答したシステムエンジニアのうち、およそ3人に2人が、自分の仕事やキャリアに影響があると感じている結果となりました。 

一方で、残りの約3割は、「あまり感じていない」「感じていない」と答えており、不安を感じている層が多数派であるものの、受け止め方には一定の幅があることがうかがえます。 

特に注目すべきは、「非常に感じている」よりも「感じている」が多い点です。「このままでいいのだろうか」という漠然とした不安が広がっている状態だといえるのではないでしょうか。 

どのような点にもっとも大きな不安を感じていますか？

AIの進化に不安を「非常に感じている」、「感じている」と回答した方に、その理由を尋ねました。もっとも多かったのは「自分の業務が今後AIに代替されそうだと感じる」で36%を占めました。 

次いで、「AI関連技術のキャッチアップについていけるか不安」「AIの進化により自身の市場価値が下がるのではと感じる」との回答が集まりました。 

この結果から見えてくるのは、単に新しい技術そのものを恐れているというよりも「自身の立ち位置や価値が変化してしまうこと」への懸念です。 

特に、業務の代替やキャッチアップへの不安が上位に挙がっていることから、取り残されることへの思いが強いことがうかがえます。 

一方で「マネジメントか技術特化かの迷い」や「自身の役割が明確でない」といった回答は少数派になりました。

キャリアの方向性に迷っているというよりも、いまの延長線上で価値を維持または向上できるのかという点に関心が集まっていることがわかりました。 

ここからは、AI時代のキャリアに対してエンジニアが抱いている本音の不安や葛藤について、自由記述の回答から一部を抜粋してご紹介します。 

AI時代に、エンジニアとしてもっとも必要になるスキルはなんだと思いますか？ 

AI時代にエンジニアとしてもっとも必要になるスキルについて尋ねたところ、もっとも多かったのは「AI・データを活用するスキル」で約4割を占める結果になりました。

次いで「要件定義・上流工程のスキル」「コミュニケーションカ・調整力」「設計力・アーキテクチャ設計」とつづきます。 

一方で、選択肢にあった「プログラミング・実装力」と「マネジメントスキル」はいずれも回答がありませんでした。 

AIの進化によって開発プロセスが変化するなかで、実装力そのものよりもAIをどう活用し、全体を設計し、価値へと結びつけるかといった上流視点の能力を重視するシステムエンジニアが増えていることがうかがえます。

AI時代において、現在の職場・プロジェクト環境に不安や物足りなさをもっとも感じる点はなんですか？ 

現在の職場・プロジェクト環境において、AI時代に不安や物足りなさを感じる点について尋ねたところ、もっとも多かったのは「AIに詳しい人材や、学べるロールモデルが周囲にいない」で、約3割を占めました。

次いで「AIを使った開発・業務改善に関われるプロジェクトがない」「AI活用に前向きな文化・方針がなく、使用しづらい」がつづく結果となりました。 

実践機会やAI活用を後押しする環境が不足しており、それがキャリアに対する不安や物足りなさを助長していることがうかがえます。 

AIに関して「これがあれば、もっと前向きにキャリアを考えられる」と思うものは何ですか？ 

AIに関して「これがあれば、もっと前向きにキャリアを考えられる」と思うものについて尋ねたところ、もっとも多かったのは「業務で使用できる環境」で、全体の約3割を占めました。日常業務の中でAIを活用できる状態が求められているようです。

次いで「評価制度への反映」が多い結果となりました。 

これらの回答が上位にきていることから、AIを知識として習得するものというよりも、実務のなかで使いこなしていきたいとの姿勢がうかがえます。 

評価制度への反映やキャリアパスの具体例といった回答からは、AI活用が一時的な取り組みではなく、自身の成長や市場価値向上につながるかどうかを重視している様子も読み取れます。 

また、「相談できるロールモデルがいない」と感じている方も少なくありません。

そんな方にとって参考になるかもしれないのが、メガベンチャー・外資などを経て、現在はSHIFTにてAI駆動開発の最前線で活躍しているPMのキャリア変遷です。 

「泥臭い合意形成力」こそAI時代の武器。メガベンチャー・外資ベンダーを経て確信するPMの真価

• AI
• PM・PMO
• 転職体験記

AIに前向きに挑戦するためには、機会だけでなく、その経験がきちんと評価され将来につながることが重要だと考えているシステムエンジニアが多いことがわかりました。 

AI駆動開発で切り拓く、SHIFTのエンジニアキャリアとは 

今回のアンケートからは、多くのシステムエンジニアがAIの進化を意識しながら、自身のキャリアのあり方を模索している様子が見えてきました。 

ここからは、AI時代のキャリア設計を考えるうえでのひとつの可能性として、SHIFTを紹介します。 

わたしたちSHIFTは、品質保証・テストサービスを軸にソフトウェア開発やコンサルティングなど多岐にわたる事業に取り組んでいる東証プライム上場のIT企業です。 

SHIFTでは幅広い領域の事業運営にAIを積極的に活用しており、その取り組みは一部に留まらず、現場発信のコミュニティ活動から職種・部門横断でのナレッジ共有、内製AIツールの開発まで広がっています。 

SHIFTならではのAI活用の実例をまとめた記事はこちら。 

「これぞSHIFT｣な熱気。楽しみながら挑戦するAI徹底活用、現場発の取り組みを一挙に紹介

• 全職種
• AI
• 開発エンジニア
• 女性が活躍中
• シニアが活躍中
• 記事まとめ・特別企画

（2025年8月期　第4四半期および通期決算説明会資料　P.48より引用）

AIを日常的に使う文化が社内に浸透するなかで、SHIFTでは内製開発による多様なAIツールを生み出してきました。

ヘビーユーザーとして徹底的に使い込み、実業務で磨かれた知見も生かして、お客様のAI活用や業務効率化に貢献する独自のAIサービスを展開しています。 

AIネイティブのSIカンパニーを目指す。ビジョンと生成AI 関連サービスの開発裏側

• 全職種
• AI
• 女性が活躍中
• 記事まとめ・特別企画

また、さらなる成長に向けて「AIを中心とした事業構造の変革」を本格化させており、生成AIを前提とした開発体制の構築を推進。その中核メンバーとなるAI駆動開発エンジニア、PMとしてご活躍いただける方を募集しています。 

AI駆動開発を前提としたプロジェクトの推進をご担当いただき、AIエージェント（Devin）などのAIツールを活用し、AI駆動開発に最適化されたSHIFTの独自フレームワーク「SHIFT DQS（Development Quality Standard：SHIFTにおける開発標準を指す）」を用いて、高品質×高生産性のプロジェクトを実現していきます。 

AIという武器を身につけてモダンアーキテクチャに挑戦し、従来の開発スタイルよりも生産性と再現性の高い開発が可能です。 

SHIFTは“AI駆動開発”の国内リーディングカンパニーへ。エンジニアが得られるものは？

• AI
• 開発エンジニア
• 記事まとめ・特別企画

AI×熟練の現場力で事業を動かす ―PMのキャリア戦略

• AI
• PM・PMO
• 記事まとめ・特別企画

AI時代において市場価値を高めるとは、最新技術を知っていることではなく、それを実務で活用し、成果に変えられること。そして、その実践経験がキャリアとして積み上がっていくことです。 

「AIに仕事を奪われる」のではなく、「AIを使いこなし、自らの役割を進化させていきたい」。AIに任せられる作業はAIに委ね、人にしか担えない役割や判断などの領域へ挑戦していきたい。 

そんなキャリアに興味のある方は、ぜひSHIFTでいっしょに働きませんか。