生成AI活用に「テストケース」ではなく「シナリオ」の作成を選ぶ理由

テスト工程へのAI導入と聞いて、「テストケースをAIに生成させるのでは？」と想像した方は多いのではないでしょうか。

例えば、「ログイン画面でIDを入力し、パスワードを入力し、ログインボタンを押下する」といった具体的な操作手順の羅列です。 

しかし、ここには大きな落とし穴があります。 

AIが生成した詳細なテストケースは、一見もっともらしく見えますが、その手順が完全に合っているとは限りません。

結果として、人間は「AIが書いた膨大なテストケースを検証したりテストしたりする」作業に追われてしまいます。これでは、かえって手間が増えてしまうのです。 

そこで、SHIFTではより抽象度の高い「業務フロー」や「シナリオテスト」といった領域へのAI導入を実証しています。

今回は、SHIFTが独自開発したチャット型AIエージェント「シナリオテストAI」の取り組みと成果を報告します。 

そもそも、シナリオテストとは、一つひとつのテストの手順ではなく「ユーザーが商品を検索し、カートに入れ、決済を完了する」といった一連の流れ（ストーリー）を指します。 

このレベルの抽象度であれば、人間は直感的に「方向性が合っているか」を判断でき、スピーディーに確認することができます。

AIのアウトプットを人間が「一つひとつ検証」するのではなく「方向性を監修」する。これにより、生成AIのスピードを活かしつつ、人間の判断力を最大限に発揮できるのです。 

シナリオテストAIがターゲットとしているのは、新人エンジニアではなく、あくまで「テスト設計リーダー」クラスの熟練者です。 

シナリオテストを組む技量のあるメンバーが使用することで、彼らが頭の中で組み立てているロジックをAIが高速に出力し、それをプロの目で取捨選択する。

つまり、人間の代替ではなく、「プロの技量をブーストさせる」ためのツールとして設計されています。

高品質なアウトプットの秘訣、SHIFTの品質標準「SQF」×対話型AI

ここからは、シナリオテストAIの概要についてお話しします。シナリオテストAIは、オープンソースのLLMアプリ開発プラットフォーム「Dify」などを活用して構築された、独自の対話型エージェントです。 

これは、ユーザーから一方的に指示を受けるだけのツールではありません。テスト設計者が行うべき思考プロセスをなぞるように、チャット形式でユーザーに問いかけを行いながら、必要な情報を引き出していきます。 

実際の利用シーンは、まるで熟練のコンサルタントと壁打ちをしているような体験です。 

AIはまず、「今回のテストの目的は何ですか？」と問いかけます。ユーザーがそれに答えると、次は「対象となる機能の仕様を教えてください」「想定される業務フローはどのようなものですか？」と、段階的に情報を整理していきます。 

この対話プロセスのなかで、AIは単に情報を記録するだけでなく、論理的な矛盾があれば指摘も行います。「先ほどの目的と、提示された仕様に矛盾があるようですが、どちらが正しいですか？」といった具合です。 

このように、対話を通じてあいまいな点をクリアにし、整理された情報を元にシナリオを生成するため、精度の高いアウトプットが期待できるのです。 

シナリオテストAIの裏側を支えているのが、ISTQ、ISO／IEC／IEEE 29119などの世界的品質保証標準と年間4,000件もの支援経験から得たナレッジを融合させたSHIFT独自の品質保証標準「SQF（SHIFT Quality Framework）」です。 

「シナリオテストAI」のプロンプトは、このSQFを整備したメンバーによって設計されています。

SQFに裏打ちされた高度なプロンプトが各フェーズに組み込まれているため、AIはSHIFTのトップエンジニアのような視点でシナリオを導き出すことができるのです。 

実証実験で証明された「数日から30分へ」の劇的な生産性向上

SHIFTでは、スマートリモコンとエアコンの連携機能のテストに、シナリオテストAIを用いました。その結果、わずか30分にして10本のテストシナリオが完成しました。 

「たった10本？」と思われるかもしれません。しかし、複雑な連携パターンの整合性を取りながら、抜け漏れのないシナリオをゼロから設計するのは骨の折れる作業です。 

現場の熟練エンジニアの試算によると、「同じレベルの品質で、自力でこれだけのシナリオを作り上げるには数日はかかる」とのこと。つまり、プロが数日かけて行う知的作業を、AIとの協働によって30分に短縮できたのです。 

「品質の高いたたき台」がもたらす開発者との早期連携

実際にこのツールを使用した現場からは、以下のような声があがっています。 

・品質の高い「たたき台」がすぐに出せるため、開発者へのヒアリングが非常にスムーズになった 

・作成時間が約半分になった感覚がある 

・このシステムを使いこなせるかどうかでQAメンバーの技量が判断できるほど、本質的な設計力が問われる面白いツールだ 

「シナリオテストAI」を導入して削減された工数で仕様上の漏れを検出していく。これはソフトウェア開発のプロセスそのものを変革する可能性、すなわちシフトレフトの実現に寄与する可能性を秘めています。

まとめ

SHIFTが開発した「シナリオテストAI」は、単なる構想段階のものではなく、実務で使える確かな実績を上げているツールです。 

「テストケース」ではなく「シナリオ」という抽象度に狙いを定め、独自の品質標準「SQF」をAIに組み込むことで、プロフェッショナルが納得する品質と、圧倒的な時間短縮を両立させました。 

「0から1を作る」苦しみをAIが肩代わりし、人間は「1を10や100にする」品質向上に注力する。これがSHIFTの考える生成AI活用の姿です。

AIと人間がそれぞれの得意分野を活かして協調する、新しい品質保証の未来はSHIFTからはじまります。

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

AIには懐疑的だった私。ひたすらさわり見えたAIの便利さと、活用の在り方

――三浦さんは今年、アジャイル推進部からAIサービス部へ異動されたそうですね。現在の役割を教えてください。

三浦：プリセールスとしてお客様のお引き合いに対して、課題を整理し、提案を行い、契約まで進めて売上を立てることが主なミッションです。

AIサービス部のプリセールスは、AIを活用してどのように業務改革できるかを切り口にお客様に提案をします。

それ以外にも、組織を大きくしていくために中途採用の面接官を担当したり、メンバーの評価を行ったりと、業務内容は多岐にわたります。エンジニア時代とは大きく変わりましたが、非常にやりがいを感じています。

――「AI」という領域への挑戦について、異動当時は率直にどう思われましたか？

三浦：不安がなかったといえば嘘になりますが、振り返ってみるとワクワクする感情の方が大きかったですね。どこにいても自分のやることは同じ。

組織で何が求められているかを考え、そこでバリューを発揮するだけだと。なので、自分が役に立てるかという不安より、どんなバリューを発揮できるだろうかという期待の方が大きかったですね。

――すでにAIにはふれていたのでしょうか？

三浦：いえ。実をいうと、異動前はむしろAIには懐疑的だったんです。当時の私にとってAIは、プログラミングを補助するもの、という程度の認識しかなくて。

「人が真心を込めてプログラムした方がよい」と本気で思っていました。

でも異動が急に決まって、当時話題だったCursor、Windsurfから入り、ClaudeやChatGPTなどさまざまなAIをひたすらさわりました。

お客様にAIの便利さを伝えるためには、まず自分自身がその価値を深く理解しなければいけませんし、そのうえSHIFTでは特定のツールを背負った提案はしません。

どんなツールにも対応できるよう、との想いで実際に使っていくなかで、「こんなに便利なんだ、ここまでできるんだ」と、AIの真価に気づかされましたね。

――「人が真心を込めてコードを書く方がいい」という気持ちにも変化がありましたか？

三浦：そうですね、それは半々です。便利なものはどんどん使っていくべきだという考えに変わり、アンチAIからいまではすっかり「ラブAI」になりました。

ただ、AIとの向き合い方には、非常に気をつけるべきだとも思っています。

AIが生成したものを100%信頼するのではなく、人間がきちんと確認するプロセスが不可欠です。組織やチームにAI活用を定着させるという目的も忘れてはいけません。

――AIをただ使うだけでなく、組織としてどう活用するかが重要だということですね。

三浦：その通りです。各企業には、組織として目指すべきプログラミングの形があるはずです。AIはあくまでそれを実現するための強力なツール。

人間が責任をもって品質を担保するという意識が、開発の現場では必要だと改めて感じています。

技術のわかる私がお客様と直接会話する。SHIFTで見つけた天職

――そもそもエンジニアからソリューション提案をする役割に変わったことは、ご自身のキャリアとしてどう捉えていますか？

三浦：一言で言うと、とても満足しています。実は、私が5年前にSHIFTに転職した一番の動機が、「お客様と直接話をしたい」ということだったんです。

前職ではエンジニア組織に属していて、お客様とのコミュニケーション窓口は別の部署が担当していて。お客様と直接対話し、技術がわかる自分が介在することでビジネスを広げていく。

そんな働き方で組織への貢献をかなえたいと考えての転職でした。異動によって、ようやくその夢がかなったと感じています。

――それはうれしいですね。ようやく夢がかなったというその仕事ぶりをより具体的に伝えるために、案件事例をあげてもらえますか？

三浦：大手金融機関様の案件をご紹介します。「Dify」というローコードAI開発プラットフォームの導入案件で、最終的に億単位という大きな契約となりました。

提案の過程で苦労したのは、工数の妥当性を見積もるところでした。

SHIFTの得意領域は、お客様の課題に対して最適なツールを組み合わせてソリューションを提供することですが、この案件ではアプリケーション構築だけでなく、インフラ構築まで求められたんです。

チームの有識者にも相談しながら工数やタスクを洗い出し、なんとか妥当性のある見積もりを立てて、無事に受注することができました。エンジニア出自の私が、大規模な提案に挑んだ、印象深い案件です。

――そもそもなぜ数あるツールのなかで「Dify」を選んだのでしょうか？

三浦：私が「Difyを推進したい」と強く提案したのですが、その根拠はアジャイル推進部時代にテスト自動化やRPAに携わった経験にあります。

「Dify」は、処理のブロックを並べていくことで、RPAのように直感的にAIアプリケーションを構築できます。

世の中の流れとしては、「Dify」のようなツールの需要が爆発的に伸びるだろうと。過去のRPAの普及を見てきた経験からの確信でしたが、エンジニアである上長も納得してくれましたね。

PDCAは、ACAサイクルに。新しい技術を無我夢中でキャッチアップする人を求む

――ほかにも、これまでのエンジニアとしての経験が活きていると感じることはありますか？

三浦：考え方の部分ですね。AIは、我々の業務を高速化するための1つの手段にすぎません。

本当に重要なのは、AIを使う以前の問題として、システム全体の構成、つまりアーキテクチャーがどうあるべきかを理解しているかです。

AIの真価を発揮させるには、人間が設計図を描けなければいけません。これまでエンジニア自身がプログラミングしてきた経験は、一切無駄にはならないんです。

――AIが出力したものが正しいかどうかの判断も、基礎力がないとできませんよね。

三浦：AI時代はPDCAがACAサイクルに置き換わると考えています。Plan（計画）、Do（実行）、Act（改善）はAIに任せられるようになる。しかし、「Check（検証）」だけは、どうしても人間が担当しなければなりません。

検証を正しく行うためには、AIに頼らずとも自分自身で作業ができるだけの地力が不可欠です。だからこそプログラミングスキルは、これからますます重要になっていくと考えています。

――AIサービス部には、どのようなマインドをもった方がフィットすると思われますか？

三浦：AIサービス部は、会社からも非常に期待されている部署です。求められる成長率に対して「どうやって達成しようか」と楽しめるマインドをもっていることが必須ですね。

採用面接で特に重視しているのは、AIに対して熱意や興味をもち、実際に行動しているかどうかです。仕事で使っていなくても、プライベートでさわっているか。

SHIFTは特定のツールに依存しないため、お客様の環境に合わせて未知の技術を素早くキャッチアップしなければならない場面が頻繁にあります。

SHIFTには「強制的に技術力が身につく環境」があるとも言えますが、それに対応できるのは探究心があってこそ。

新しい技術を無我夢中で学べる人、それによる自身の成長を楽しめる方にとっては、最高の環境だと思います。

――最後に応募を検討するみなさんにメッセージをお願いします。

三浦：これだけAIの存在感が増す世になっても、自社に適した業務効率化の具体的なアイデアをもつ企業はそう多くはありません。目的と手段が入れ替わってしまっているケースもあります。

私たちの強みは上流工程から下流工程まで一気通貫でお客様を支援できること。幅広いご相談が寄せられるなかで、課題を解決できるサービスがあれば提案し、なければ考える。

エンジニアとしての視点を活かしてAIの活用提案という新しいスキルを磨き、自らのキャリアを拓いてもらえたらと思います。

――本日はありがとうございました！

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

高難易度な「テストシナリオの洗い出し」をAIで効率化

石井：今回の狙いは、最先端の技術を5分で感じていただくことです。フォーカスするのはシナリオテストです。

シナリオテストは外部結合テストやシステムテストで使われますが、作成プロセスは非常にむずかしく、特にテストシナリオの洗い出しに悩まれている方がすごく多いです。

なぜむずかしいかというと、我々はこのプロセスを6つのステップに分解しています。

6つのプロセスに分解したうえで、シナリオを整理し、テスト観点を検討し、シナリオと観点を紐づけて、ようやくテストケースを書き出します。

シナリオテストにおけるシナリオの洗い出しはさまざまな条件やシステムが関連してくるため、難易度が高く時間がかかります。

私たちのチームでは、生成AIを使うことで、これをなんとか支援できないかと思っており、その仕組みを開発しました。

先程説明した6つのステップの1～4までのプロセスをAIで支援します。この取り組みは、現在開発・実験・実証段階のものです。

30分で10個のテストシナリオを作成することに成功

まず今回の成果ですが、スマートリモコンとエアコンの連携テストシナリオを30分で10個作成することができました。

少なく見えるかもしれませんが、これを人の手でつくると非常に時間がかかります。生成AIを使うことで30分で作成できる、その仕組みを説明します。

まずシナリオテストの対象とするフェーズは結合テスト以降、つまりシステムテストや受け入れテストです。

そのなかで、業務フローとシナリオの分析を生成AIで行います。利用者は設計リーダーで、素早くテストシナリオを洗い出して作成することが目的です。

生成AIが質問をして、それにテストリーダーが答えることでシナリオをつくることができるという形になっています。UIは一般的なチャットUIです。

このなかに実は、フェーズごとにプロンプトが含まれています。テスト目的の明確化や仕様の整備といったプロンプトが細かく設定されています。

実際のやり取りはこちらです。

概要や目的などを聞かれるのでそれぞれ答えることで、機能やルールが整理されます。

そこからさらに「通信の種類は？」「通信障害の種類は？」といったことを聞かれるので、それに答えていくと矛盾点なども整理してくれます。最終的にフローやシナリオがつくられるという流れです。

ベテラン設計者並みの高精度なテストシナリオ作成を再現

ではダイジェストです。今回は先ほど言ったとおり、スマートリモコンのシナリオを作成しました。

このようにAIが質問をしてくれるので、最初に機能や目的などを書いていきます。

そうすると、仕様やルールが抽出されるので、それに答えていきます。「通信障害の定義は？」「通信障害時にUIのポップアップでユーザーにどう通知するのか？」といった追加の質問もあります。

これらに答えると、フロー図とシナリオが出力されます。

AIによるテストシナリオ作成の試みを通して得た成果と気づき

まとめに入ります。最終的に提示されたシナリオは期待を超えるUXでした。今回のJaSST’25 Hokkaidoのテーマ「北海道は DX AI Do！！（でっかいどー）」じゃないですが、まさに「でっかいものが見えた」という感じでした。

知識のあるテストリーダーでも、これを作成するにはとても時間がかかります。30分足らずでパパッと正確なものが出てくるというのは、とても安心感があると思います。

ベテランメンバーがプロンプトを作成しているので、このツールを使っていくなかで、彼らの思考や整理のプロセスを追体験できます。

実際の現場で使ったメンバーからは、「あいまいだったプロセスが言語化されるので、後輩へのOJTに使いやすい」という声がありました。

この後、ブースでこの仕組みの詳細について説明しますので、ぜひお声がけください。ご清聴いただきありがとうございました。

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

SHIFT Agile FESレポート！AI時代における人間中心のアジャイルを語り尽くした注目セッションを紹介

「幸せに働ける組織を目指すリーダーの葛藤と挑戦」SHIFT Agile FESイベントレポート

• アジャイル
• イベントレポート
• テスト自動化エンジニア
• 開発エンジニア

「Kent Beckの思想と学びの道筋」SHIFT Agile FESイベントレポート

• アジャイル
• イベントレポート
• テスト自動化エンジニア
• 開発エンジニア

「若手中心の内製アジャイル開発で研究開発に挑戦」SHIFT Agile FESイベントレポート

• アジャイル
• イベントレポート
• テスト自動化エンジニア
• 女性が活躍中
• 開発エンジニア

ポスト5G研究開発プロジェクトの全貌と「若手中心・内製アジャイル」の狙い

李氏：このプロジェクトはポスト5G情報通信システム基盤強化研究開発事業というNEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）の委託事業の研究テーマの1つです。

産総研（国立研究開発法人産業技術総合研究所）とソフトバンクが共同で、5つのテーマについて5年間かけて研究開発を行う壮大なプロジェクトです。

目標は、ポスト5G時代に対応した高い処理能力をもちながらも、安価で誰もが簡単に利用できる「超分散コンピューティング基盤」を実現することです。

この基盤を社会実装することで、さまざまな分野のデジタル化と社会のDXを推進します。

プロジェクトには、いくつかのチームがあります。私と谷川さんが所属しているのは、そのなかの「システム統合技術」というテーマを扱うチームです。

このチームは、各研究チームの成果を文字通り「統合」する役割を担っており、プロジェクト全体の成果を形にするうえで非常に重要で、かつ大変な役割だと感じています。

革新をつくり出す先端開発プロジェクトの4つの特徴

谷川：このプロジェクトの4つの特徴を教えてください。

李氏：1つ目は、前述のとおり5年間にわたる先端技術のプロジェクトである点。

2つ目は、求められる品質レベルが商用と異なる点です。

例えば、プロジェクトの中間評価までの「トレードオフスライダー」（開発における優先順位を示す図）を見ると、品質の優先度は、実はそこまで高く設定されていません。

これは、「価値ある研究成果を出すこと」を最優先にしているためです。

3つ目は、アジャイル開発のフレームワークを活用した取り組みである点です。このプロジェクトではチーム間の連携を強化するために、さまざまなアジャイルプラクティスを導入しています。

谷川：ここはとても工夫されていましたよね。

李氏：はい。まず四半期ごとにプロジェクトのチームメンバーが一斉に集まって次の四半期の計画を行うイベントを開催しました。

こちらはスケールドアジャイルのフレームワークを参考に設計をしていますが、型通りには行わず、現場の負担が少ない形をとって進めています。

次にワークショップですが、毎月実施して各チームが自分たちの研究成果や技術調査、課題などをもち寄ってみんなでディスカッションする場になっています。

そのディスカッションを通じて新たな気づきを得たり、認識の齟齬をなくしたりする場として活用されています。

谷川：情報共有の場としても機能していると。

李氏：その通りです。次にスケールリファイメントですね。こちらは統合バックログというチーム連携のための共通のバックログを別途立てて運用しており、そちらのリファイメントをする会議です。

こちらもスクラムスケールのフレームワークを参考に計画して進めていますが、必要最低限のイベントのみ実施する形です。

そして最後、「Scrum of Scrums」（SoS）ですね。スクラムマスターが集まって、各々の悩みやいろんな議論をオープンに行う場になっています。お互い息抜きもでき、和みの場になっているところです。

谷川：本プロジェクトの4つ目の特徴は、「若手中心の内製アジャイル開発」ですね。

李氏：はい。若手従業員も高度な技術を含め、いろんなチャレンジができるプロジェクトになっています。

研究開発の最前線で立ちはだかった6つの壁と突破口

谷川：プロジェクトの輪郭が見えてきました。このプロジェクトには6つの大きな壁があったと伺っています。

李氏：1つ目の苦労は、「PO（プロダクトオーナー）と開発チームでバトル発生」です。研究しながら開発を進めるという特性上、どうしても要件が初期段階では詳細まで詰められないことがあります。

POとしては、実現したいビジョンはあるものの、受け入れ条件がやや抽象的になってしまうケースがありました。

そこで、開発チームとPOの間で落としどころを議論するのですが、ときにはお互いの認識がなかなか合わないこともありました。

谷川：どのように対処されたのですか？

李氏：メンバーと1on1を行い、それぞれの考えや懸念を丁寧に聞くようにしました。

また、技術的な不確実性が高い部分については、「スパイク」という調査タスクを活用して、要件を具体化してから開発に着手するように促し、要件を明確化できたと思っています。

つづいて、2つ目の苦労は「スプリント開発中に予想外の事象が多発し、見積もり通りに開発が進まない」です。

例えば、ほかのチームが開発した機能を自分たちのシステムに統合しようとした際、インターフェースの仕様が最新版ではないなど。

また、研究開発特有のむずかしさとして、将来的な課題まで深掘りしすぎてしまったり、未知の技術に対してどのようにアプローチすればよいかわからず、試行錯誤に時間がかかったりすることもありました。

谷川：ここは我々アジャイルコーチ陣もいっしょになって、チームのみなさんと議論を重ねた部分でしたね。

李氏：3つ目は、「長期間の研究開発プロジェクトで、ゴールや進捗状況の把握がむずかしい」点です。

長期プロジェクトであるがゆえに、メンバーが「いま、自分たちは全体のどのあたりにいて、次に何をすべきなのか」がわからなくなり、迷子になってしまうことがありました。

そこで、最終ゴールだけでなく、中間ゴールも設定し、マイルストーンを明確にしました。また、リリースバーンアップチャートといった視覚的なツールを活用して、進捗状況をチーム全体で共有しています。

4つ目は、「研究成果が各チームで出てからシステム統合するため、共通化がむずかしい」という点です。

各チームが独自に研究開発を進めたものを、後からまとめようとすると、当然ながらアーキテクチャや技術選定、データのもち方などで非互換な部分が出てきます。

そこで、開発メンバーから「早期に技術情報を共有しよう」という動きが自発的に出てきました。例えば、毎月開催するワークショップのなかで情報を積極的に発信したり、課題を早期に発見して対応したりするようにしています。

谷川：開発メンバーからの自発的な動きはすばらしいですね！

李氏：5つ目は、「大規模プロジェクトで連携先が多く複雑なため、システムの統合が大変」な点です。

統合においては、進捗管理と課題管理が生命線だと考えています。そのため、バックログ管理ツールを統一し、関連情報をなるべく一元管理するようにしています。

6つ目は、「実用化に向けた研究開発的な進め方に課題がある」です。これは、研究開発フェーズと、その先の実用化フェーズでは、求められる設計思想が根本的に異なるという課題です。

研究開発段階では、新しいアイデアを試したり、プロトタイプをつくったりすることが重視されますが、実用化となると、安定性、信頼性、保守性といった品質特性がより重要になります。

谷川：つまり、研究成果をそのまま商用サービスにできるわけではないと。

李氏：はい、ほぼ不可能だと考えています。ですから、研究フェーズから実用化フェーズへ移行する際には、チームメンバー全員が意識を切り替え、実用化を念頭に置いた開発を進める必要があります。

この意識改革をチーム全体でどのように行っていくかが、これからの課題の1つだと考えています。

次世代インフラ創造の使命感と、社会貢献への実感が生むモチベーション

谷川：このプロジェクトを通して「うれしかったこと」もたくさんあったと思います。そんな「充実の波」について教えてください。

李氏：1つ目は、「次世代社会インフラを創造しているという使命感、社会課題の解決に貢献している」点です。

自分たちが開発しているものが、ポスト5Gという次世代の社会インフラを支える技術になるんだという実感は、大きなモチベーションにつながっています。

2つ目は、「商用システム開発とは異なる開発経験ができる」点です。

「価値の実現」や「スピード」をより重視し、世の中にまだない新しいものを生み出すという、研究開発ならではのむずかしさと楽しさの両方を日々体験できています。ゼロからイチを生み出す面白さ、と言えるかもしれません。

谷川：内製アジャイルで進めていることも、メンバーの成長につながっているのではないでしょうか。

李氏：おっしゃる通りです。内製でアジャイル開発を進めているため、メンバー一人ひとりが自ら考え、主体的に動くことが求められます。

その過程で、開発スキルが身につくことはもちろん、ビジネスパートナーのみなさんとも「協働」という関係性を築けるようになったと感じます。

3つ目は、「アジャイル的発想で何でもトライでき、失敗を許容する文化がある」点です。

社内には、新しい挑戦を後押ししてくれる雰囲気があります。上司や先輩も、私たちの意見を真摯に聞いてくれますし、たとえ失敗しても、そこから学びを得て次に活かせばよいという考え方が浸透しているように感じます。

谷川：それはすばらしいですね！私はさまざまなお客様のアジャイルコーチングをしていますが、御社の挑戦を奨励し、心理的安全性が高い文化は、アジャイルを推進するうえで本当に大きな強みだと感じています。

李氏：ありがとうございます。4つ目のうれしかったことは、「SoSで、スクラムマスターの仲間感が醸成できた」点です。

それぞれの悩みや困りごとを共有したり、成功事例を共有したりすることで、安心感を覚えたり、ほかの人の経験から学んだりすることができます。和みの場であると同時に、みんなで成長する場になっていますね。

谷川：仲間がいるというのは心強いですね。

李氏：5つ目は、「グループ会社の垣根を超えた交流、心理的安全性が確保されたよいチームと働ける」点です。

このプロジェクトには、さまざまな組織に属する人が参加しています。それでも、組織の垣根を越えて、1つのチームとして目標に向かっていけるのは、上層部の方々がアジャイル開発に対して深い理解を示してくれたためです。

6つ目は、「スクラムマスターの魅力を理解できた」点です。先ほど自己紹介でもお話しした通り、私はこのプロジェクトではじめてスクラムマスターを経験しました。

正直なところ、最初のころはスクラムマスターの活動が、具体的にチームやメンバーにどう貢献できるのか、あまり明確なイメージをもてていなかったんです。

ですが、チームのメトリクスを分析し、そこから見えてくる課題に対して、さまざまな改善策を試行錯誤していくうちに、少しずつ手応えを感じるようになりました。

「メンバーに価値ある情報を提供し、チームが成果を出しやすいように支援すること」は、意味のあることだったんだと実感できるようになりました。

これは開発現場だけでなく、チームで成果を出すどんな場所でも活かせると気づいて、自分のキャリアにも少し自信がもてましたね。

谷川：最後に、今後の抱負を教えてください。

李氏：このプロジェクトはまだ道半ばであり、今後もこれまで以上にさまざまな困難や予期せぬ「波」がやってくると予想しています。

ですが、これまでの経験で得た学びやチームとの信頼関係を活かして、アジャイルを使いこなしながらプロジェクトを成功に導いていきたいと思っています。

そして、この経験を糧に、これからもアジャイルな働き方を通じて価値を提供しつづけていきたいです。

谷川：本日は、貴重なお話をありがとうございました！

（※本記事の内容は、イベント開催当時のものです）

Kent Beckが紡いだ思想の系譜を辿る

吉羽氏：Kent Beckはエクストリーム・プログラミング（XP）の父であり、テスト駆動開発の父でもある有名人です。まず、彼のキャリアをかいつまんでお話しします。

Kent Beckは1961年サンノゼ生まれで、オレゴン大学で情報系の学部に進みました。

同時期にクリストファー・アレグザンダーの『時を超えた建設の道』を読み、これがいわゆる「パタン・ランゲージ」との最初の出会いになりました。

大学卒業後はTektronixという会社に入り、プログラマーとしてSmalltalkを愛用していました。

そこでウォード・カニンガムという師匠的存在に出会い、1987年に『オブジェクト指向プログラムのためのパターンランゲージの使用』という論文を共同執筆しました。

その後Appleに転職し、Smalltalkの単体試験スイートであるSUnitを開発します。

XPが誕生したきっかけは、クライスラーのC3プロジェクトです。

このプロジェクトで、3週間のイテレーション（繰り返し）、ユーザーストーリー、テスト、ペアプログラミングなど、当時としては画期的なやり方をとり入れました。

開発手法を聞かれたときに説明しやすいよう、「エクストリーム」という名前をつけたそうです。

話をKent Beckの経歴に戻しますね。1997年にJUnitをつくり、1999年に『 XPエクストリーム・プログラミング入門 』を執筆しました。

2001年にはアジャイルソフトウェア開発宣言（アジャイルマニフェスト）の作成に参加し、2002年に『テスト駆動開発』、2004年に前出の入門書の第2版を出版しました。

2006年ごろには「説明責任と透明性が重要だ」といったほか、2010年頃は10以上のスタートアップに関わっていました。

2011年にFacebookに入社し、スケールの複雑性や意思決定の可逆性の重要を学んだようです。

Facebook時代の後半からは、3Xモデル（Explore, Expand, Extract）を提唱しました。

これはプロダクト開発には探索フェーズ、拡大フェーズ、収穫フェーズがありプラクティスがそれぞれ異なるという考え方です。

2022年には「Help Geeks Feel Safe in the World」（ギークが世界で安全に感じられるよう助けること）という自身のミッションを明確にし、2023年には「ソフトウェア設計は人間関係のエクササイズだ」と述べ、『Tidy First？』を出版しました。

現在は『Tidy Together？』を執筆中で、その次はチーム外の人々を巻き込んだ仕事の進め方について取り組む予定だそうです。

アジャイルの源流に流れる“建築の哲学”

秋葉：ご説明ありがとうございます。Kent Beckの活動を、みなさんにもご理解いただけたかと思います。吉羽さんがはじめて読んだKent Beckの著書は何ですか？

吉羽氏：『XPエクストリーム・プログラミング入門』の第一版だったと思います。当時は、ウォーターフォール開発に限界を感じて別のやり方を模索し、XPに出会いました。

私がはじめて実践したアジャイル開発がXPでした。当時は尖ったやり方だと感じ、うまくいくか半信半疑でしたが、実践してみると非常によく機能したので、アジャイルに傾倒していきました。

秋葉：XPは教条的、あるいは厳しいという印象があります。

例えばリポジトリのブランチ運用に関しても、個人のブランチ単位での話が多く、チーム全体で実践するにはむずかしい側面もあるのではないでしょうか。

吉羽氏：そうかもしれませんね。当時は私がリーダーだったので、「これをやる」と宣言し、チームメンバーに実践してもらいました。

秋葉：そのチームにいたかったですね（笑）。吉羽さんとの対談を前に、Kent Beckについてもっと勉強しようと思い、過去の書籍やインタビューを読み解きました。

加えて、最初に紹介のあった『時を超えた建設の道』を、改めて購入して読み直してみました。

著者のクリストファー・アレグザンダーは建築と都市計画の思想家で、ソフトウェア業界では有名ですが、建築学においては主流ではないようです。

元々は数学の修士号を取得し、その後建築学で博士号を取得して建築家になりました。

アレグザンダーによれば、都市計画者の人工都市は重なりのないツリー構造であるのに対し、自然都市はセミラティス構造（要素が交差し重なり合う構造）です。

このセミラティスの概念を具体的に再現しようとしたのが、その後のクリストファー・アレグザンダーの活動です。

Kent Beckはこのセミラティスのような構造を実現したくて、XPやテスト駆動開発に取り組んでいるのではないかと私は考えたんですが。

吉羽氏：そうかもしれませんね。

Kent Beckほど業績の多い人になると、私たちはいろいろロジックを積み重ねて「多分こう考えたに違いない」と推測しがちですが、大学時代に立ち読みした本を「絶対に仕事のどこかで使ってやろう」とまでは思っていなかったのではないかと思います。

秋葉：『XPエクストリーム・プログラミング入門 第2版』でも『Tidy First？』でも、アレグザンダーの名前は出てくるので、ずっと心のなかに残っているのかもしれませんね。

製造現場からソフトウェア開発へ――異分野が交差する知の回路

秋葉：Kent Beckにとってのアレグザンダーのように、吉羽さんの人生を変えた一冊を教えていただけますか？私の場合は『服従の心理』というスタンレー・ミルグラムの本で、人は強制されなくても権威に従いやすいという実験について書かれたものです。そこから「自分の頭で考えることが大事だ」と学びました。

吉羽氏：私は『トヨタ生産方式』という本です。実はKent BeckもXP本の第二版で「トヨタ生産方式」という章があって、個人的にうれしかったんです。

私はWeb開発プロジェクトで何度も炎上を経験し、仕事でおつきあいのあった方から「工場見学に行くといいよ」と誘われ、あるPCの生産現場などを見学しました。

PC工場はとても綺麗で、各工程で品質チェックがなされていました。例えば振動試験では市販のマッサージ機を台にとりつけて、PCを揺らしてテストしていたんです。いろんな方法で品質をつくりこんで、1日に何個生産できるか、いま、生産現場がどうなっているかが可視化されていて、「なんでソフトウェアはこうできないの？」と。

この製造業でのやり方についてくわしく調べはじめて『トヨタ生産方式』をみつけ、ソフトウェアの領域で近いやり方を探した結果、Kent Beckにたどり着いたんです。

秋葉：そこがつながったんですね。数学を研究していたクリストファー・アレグザンダーが建築を学び、それがKent Beckに影響を与えてXPやテスト駆動開発が生まれました。それと同様に、吉羽さんもトヨタ生産方式という工場の知識をソフトウェア開発の改善に役立てたわけですね。

このように領域を超えた交差点にこそ、新しい知が生まれているのではないでしょうか。知識体系と知識体系との組み合わせで新たな知識や価値を生むことができるというのは、当たり前のことかもしれませんが、重要な視点だと思います。

吉羽さんへの深堀り質問

秋葉：ここからは、私がさらに吉羽さんにお聞きしたいことを深掘りしていきます。

まず、吉羽さんは多くの技術書の翻訳をされていますが、翻訳する本を選ぶ基準はありますか？『プロダクトマネージャーのしごと』、『チームトポロジー』、『ダイナミックリチーミング』など、ほかではあまりみられない本を翻訳されていて、しかもシリーズのように読めるものが多いと感じました。

吉羽氏：翻訳の流れとしては、2つのパターンがあります。1つは出版社から提案いただくもので、読んでみて自分の思想と一致するかどうかで選んでいます。だからつづいているようにみえるわけです。

もう1つは、こちらから提案するパターンです。以前出た本の反応がよかったけれど、まだ語れていない部分がある場合、その部分を本として出したいと思って出版社に提案するような形です。

秋葉：思想に合うものを選ばれているというのは納得できます。シリーズのように読めるので、『Chef実践入門』からもう一度読み直してみたいと思いました。

次に、コロナ禍の話です。以前、fukabori.fmで吉羽さんが「制約があった方が工夫やアイデアが生まれるから、コロナ禍はうまく利用すればいい」とおっしゃっていて、すばらしいと思いました。私自身も対面の方が楽だと思いがちでしたが、その制約のなかでリモートファシリテーションを身につけられました。吉羽さん自身がコロナ禍で気づいてやりはじめたことや習慣化したことはありますか？

吉羽氏：コロナ禍ではみんなが集まれない分、会話する時間をつくりました。その結果、モブプログラミングをやる頻度が増えて、プロダクトの品質が上がりました。制約から新しい手をとりれ、効果を実感する。プラクティスが新しく生まれていくのを目撃しました。

秋葉：状況に応じてアイデアを出していくこと自体が大事なんですね。

吉羽氏：そうです。Kent Beckも「自分たちのプロセスは自分たちのものにしろ」といっています。マニュアルや本に書いてあることをそのままやって「うまくいかない」で終わるのではなく、自分たちでプロセスを考えるというスタンスについては、Kent Beckは変わっていないと思います。

「進捗率95%」の罠を超えて

秋葉：吉羽さんがつねづねいろんなところで話されていることですが、改めて「進捗レポートで問題ありません」というのが、なぜダメなのか改めて教えていただけますか？

吉羽氏：端的にいうと「数字は嘘をつかないが、嘘つきは数字を使う」ということです。進捗率95%といわれるとすごそうに聞こえますが、残りの5%に95%と同等の時間がかかることがあります。

例えば、アジャイルソフトウェア開発宣言には「動くソフトウェアこそが進捗のもっとも重要な尺度です」とあります。お客様との信頼関係は、進捗率95%のレポートではなく、動くプロダクトを目の前に提示しつづけて、改善を繰り返すことで醸成されます。これは、開発の基本中の基本です。

秋葉：なるほど、ありがとうございます。ところでKent Beckの『Tidy First？』は16年ぶりのコードに関する本ですが、何か新しさや変わったところを感じられましたか？

吉羽：実はあまり感じていないのですが、Kent Beckが優しくなったという印象はあります。昔はもっと尖っていましたが、ステークホルダーやチームの外側も大事にしなければいけないし、プロダクトとして成果を出さなければいけない、大規模組織では違う論理も働くなど、さまざまな価値観を尊重するようになっていますね。

秋葉：『Tidy First？』の「Tidy」は、こんまり®メソッドに影響を受けているという話もありますね。

吉羽氏：そうです。彼は自分のSubstackにそう書いています。

秋葉：それも別の領域の知識体系を活かしたということですね。

誰のためにつくるのか

秋葉：最後に、AIについて。Kent Beckはブログで「ChatGPTが出てきて、私のスキルの90%の価値は0ドルまでに成り下がってしまった」と書いていました。最初は落胆したけれど、これを機会に残りの10%を新たな方法で活用しようと考えるようになったそうです。これについてどう思われますか？

吉羽氏：これをみると、Kent Beckも私たちと変わらないなと思います。私も開発していると、AIがいままでと比べ物にならない速度で物をつくってくれるようになったのを感じます。

ITコンサルが倒産しはじめたというニュースもあり、自分の仕事がいつまであるのかと危機感を覚えますね。私もITコンサルやアジャイルコーチがいらなくなるのではないかと思うことがありますが、Kent Beckも似たようなことを思っているのだと安心しました。

秋葉：Kent Beckのスキルの90%が0ドルになったのなら、私の資産はいくら残っているのだろうと不安になってしまいますね（笑）。

吉羽氏：これは大げさな表現だと思いますが、20：80の法則で考えると、スキルの8割の価値がなくなっても、残りで稼げるからいいのではないかと考えているのかもしれません。

人手が必要なところは、AIに置き換えられることはないと思います。例えば、ほかの分野の知識を役立てたり組み合わせたりするようなことはAIにはできません。こうした発想は何物にも代えがたいものがありますよね。

秋葉：Kent Beckは、アレグザンダーの『パタン・ランゲージ』について、「本書を用いれば、家族とともに自分の家を設計したり、隣人とともに自分たちの町や近隣を改良したりすることができる」といっています。

建築家が家や建物をつくる際には、使う人、生活する人のためにつくるという点を重視していて、このあたりもKent Beckが感動した部分なのではないでしょうか。

吉羽氏：そうですね。XPにはオンサイト顧客というプラクティスがあって、そこではプロダクトを実際に使う人をチームのなかに入れて開発します。使う人への配慮、視点を大切にしているんですね。

秋葉：そうですね。そこはKent Beckの変わらない部分であり、重要な視点ですよね（Kent Beckはアジャイル宣言のなかに「対話的（conversational）」を入れたかったというエピソードからもダイアログを重視していたことがわかります）。今日は本当に楽しいトークセッションをありがとうございました。

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

自己紹介

安田氏：クリエーションラインの安田と申します。以前はソフトバンクグループで新規事業立ちあげに携わり、約20年前に独立してクリエーションラインを創業しました。

現在は「Co-Creation Sherpa®（※）」という事業方針のもと、さまざまな事業会社といっしょにサービス開発やシステム開発を行っています。

「人と組織の喜びとは何か」をつねに模索しながら、最近ではJapan Agile Collaboration Kernel （JACK)という団体の理事にもなり、日本のビジネスをアジャイルで活性化していこうと活動しています。

※Co-Creation Sherpa® …お客様が達成したい目標（山頂にたどりつく）に対して伴走し、ツールなどを駆使しながらときに導き、ときに山頂までのルートをいっしょに考えていく役割を担おうというクリエーションラインのビジョン。顧客伴走型の企画・実装力を指す。

池ノ上：SHIFTでVPoEを務めている池ノ上 倫士です。エンジニアリングのマネジメントをはじめ、ソリューション事業の責任者やAIサービス部の責任者も兼任しています。

最近は人事部門にも籍を置き、エンジニアが働きやすい環境づくりや制度設計にも関わっています。

私が入社した2017年当時、SHIFTは売上高81億円の会社でしたが、現在は1,300億円の売上高を目指すまでに成長しました。

もともとテスト会社だったSHIFTがDX支援企業へと変革するなかで、ソフトウェアテストの自動化やDevOps、そしてシステムインテグレーターとしてのサービス展開と、「技術のSHIFT」と呼ばれるチームづくりに取り組んできました。

軽視していた理念とビジョンが再起のきっかけに

安田氏：下記は、クリエーションライン創業から現在までのライフチャートです。売上ではなくエンゲージメントスコアのようなものと捉えてください。

安田氏：2回大きく落ち込んでいる時期がありますよね。最初の落ち込みは創業初期、私が売上至上主義的なマインドで経営していたころに発生しました。当時は「ビジョンや理念なんていらない」と思っていました。

問題なく案件をこなせるときもありましたが、品質担保が非常にむずかしい案件を受注したことで問題が発生。

従業員が次々と離れ、社内関係もギクシャクしてしまいました。請負開発だったため納品できず、お金ももらえない状態で、経済的にも精神的にもボロボロになりました。

しかし、一部の社内メンバーや取引先から「頑張りましょう」と声をかけてもらい、彼らのために頑張ろうと決意しました。

そんななかで、よいチームをつくる具体的な方法が書かれている『Team Geek』という書籍に出会いました。

特に、Humility（謙虚）、Respect（尊敬）、Trust（信頼）＝HRTがそろってこそよいチームになるという考えに強く共感し、自分自身が変わろうと決意。

「どういう環境で働きたいか」「どういう人たちといっしょに働きたいか」を真剣に考えた結果、共感してくれる人が増え、組織は徐々に改善されていきました。この失敗から「理念・ビジョンの重要性」を学びました。

池ノ上：SHIFTでは、業務の効率向上や標準化を徹底し、他社が真似できないレベルの競争優位性を築く「オペレーションエクセレンス」という考え方を大切にしていますが、これがときに価値観の分断を生むこともあります。

効率や標準化、型化を重視する文化はすばらしいのですが、極端に推し進めると「考えない、間違えない、悩まない」単純労働になりかねません。

一方、生産性の高いクリエイティブなチームであるためには「悩んで、調べて、試して、失敗する」というスタイルが必要です。

この価値観の違いは、仕事の取り方や人の採用方法などさまざまな場面で現れ、ときに傷つく人や悲しい思いをする人が出てきます。

しかし、価値観が違っても「会社を成長させたい」という思いは共通しています。大切なのは、不必要な痛みを避けながら、両者の想いを「翻訳」することだと感じています。

事業構造改革と評価制度改革…それぞれの成長戦略

安田氏：ライフチャートの2回目の落ち込みは、事業が順調に拡大していた時期に起きました。そのときは、依頼が次々と舞い込んでいました。

しかし、本来の強みである「いっしょに価値あるものを模索する」という姿勢を忘れ、「つくること」自体が目的化してしまいました。

お客様の表面的な要望に応えることに終始した結果、気づかないうちにお客様がいなくなっていました。

引きつづき依頼がくると思って体制を維持していましたが、実際には依頼は戻ってこなかったのです。事業方針やビジョンと乖離していたんです。

そこから事業構造改革に着手し、本質的にやるべきこと、やらなくていいことを再定義しました。その結果、売上がV字回復しました。この2回目の失敗から「事業方針の徹底と一貫性」の重要性を学びました。

池ノ上：なぜそんなに劇的に復活できたのか不思議です。いかにして、売上の落ち込みに対処したのでしょうか？

安田氏：実は2022年5月に大規模プロジェクトが終了し、社内の雰囲気が悪化していくなかで、主要なキーマンが何人か辞めてしまいました。

それまでも改善策は議論していたものの、なかの人たちがいなくなる流れが生まれた瞬間「これはもう議論している場合じゃない、いますぐ手を打たなくては」と、そこから覚悟をもって取り組みはじめました。

一部のプロジェクトを手放し、社内の雰囲気も変えました。

具体的には、私たちは「何かをつくる喜び、そしてそれが喜ばれることで得られる充実感や高揚感 （＝Joy）」 を理念に掲げていますが、いつの間にか「楽しければいい（＝fun）」のようなぬるい空気になっていたんです。

池ノ上：SHIFTは人的資本を重視し、採用に多くのコストをかけています。私たちのミッションの1つである「多重請負構造の打破」を実現するためです。

昭和時代の製造業モデルをIT業界がまねたことで生まれた構造は、現代では不都合なものになっていると感じています。

そこで私たちは、社内の相対的な立ち位置ではなく、「このエンジニアが転職市場に出たときにどれくらいの価値があるか」という考え方でエンジニアの報酬を決めるようにしました。

これはエンジニアにとって納得感があり、自己研鑽にもつながります。

一方で、この評価制度は極端な個人主義や成果主義を誘発しがちという課題もあります。現在は、チームとして提供できる価値や創造性を保つために、新しい評価方法を検討しています。

具体的には、成果を測る指標の1つ「単価」を支えるスキルやプロセスを分解して理解し合い、そのプロセス自体を称賛する仕組みをつくりたいですね。

安田氏：その評価の仕組みの変更は社内でかなりインパクトがあったと思いますが、どのように進めたのですか？

池ノ上：実は、SHIFTの評価制度は毎年変わるんです。半年に一度の評価のたびに、不都合や不整合を見直し、つねに改善しています。

フィードバックアンケートを記名式でとり、納得感やキャリアビジョンについての回答を分析しながら、新しい指標を設ける必要性を議論しています。

人的資本経営を掲げる以上、人を大事にし、人間がハッピーになる世界をつくるためのコストはかけるべきだと考え、役員一同で多くの時間を使っています。

実際、入社当時13%あった退職率が現在は6%程度まで下がるなど、成果も出ています。

安田氏：そのスピード感はリーダーが強いからこそ得られることですよね。私たちは規模を大きくすることを度外視しているので、従業員一人ひとりの成長にリーダー陣全員で時間をかけています。

どちらがよい悪いではなく、方向性の違いですよね。

池ノ上：成長しようとすると必ず痛みは出てきますが、「成長はすべてを癒す」というスローガンで乗り越えています。

リーダーたちが考える「理想の職場」の条件

安田氏：私は、幸せに働ける組織の第一の要素は、先ほどお話したHRTだと思います。HRTは、社内だけでなく社外やお客様との関係性においても重要です。

第二に「知的コンバット （それぞれの主観と主観とを徹底的にぶつけ合うこと）」ができることです。

これは野中 郁次郎先生の言葉ですが、努力している人が報われる組織には、メンバーの人間的な成長も経済的な成長も重要です。ぬるい職場ではなく、みんなが自己研鑽できる職場が幸せな職場だと思います。

第三に「透明性・検査・適用のサイクル」があり、主体性があることです。数値をはじめとするあらゆるものが透明性高く保たれている、検査・適用職場のサイクルをまわせる。

これらによって主体性が育まれていることがよい職場の条件だと考えています。

池ノ上：私はやりがいのあるミッションがあることと、成功体験を重ねていっしょに成長できる仲間がいることが大切だと思います。

そして、努力が評価と報酬に結びついていて、将来ではなく、いまリターンしたいと思える環境をつくること。そのためには組織の成長が必要で、ときには何かを犠牲にしなければならないこともあります。

産業構造を変えたい――共通の理想へ向かって

安田氏：クリエーションラインは、未来への取り組みとして「ITエンジニアの社会的地位向上」を掲げています。

現在の課題として、アジャイル開発で準委任契約、人月での見積もりになっている現状があります。これを解消し、人月ビジネスから脱却することで、産業構造の変革にもつながると考えています。

具体的には「価値創出に本当にコミットする」契約形態として、成果報酬型のシステム開発・サービス開発を進めています。

特に生成AIが当たり前になる世界では効率化が進みます。価値創出に対して対価をもらう形にしていかないと、事業としても成立しませんし、産業全体もそういう形に変わっていく必要があると思います。

池ノ上：私たちも同じように「業界構造を変革する」という理想をもっていて、そのための影響力をもちたいですね。数の力、規模の経済による業界の構造変革の一助となるようなエンジニアリングを目指しています。

安田氏：最後に一言。今日は可能な限り生々しい話をお話ししました。みなさんも今後のキャリアで人をまとめる立場になることがあると思います。

環境変化のなかでさまざまな課題にぶつかったときに、今日の話を少しでも思い出していただき、一歩踏み出すきっかけになればうれしいです。

池ノ上：本日はありがとうございました。

（※本記事の内容は、イベント登壇当時のものです）

「経営」というドラマのつづきをみたい

川口氏：私と岡野原さんは大学が同じで、岡野原さんと同様に、当時の私も自分の会社を立ちあげました。大学1、2年生ぐらいのときでしょうか。学士で卒業した私は、しばらくその会社に関わっていました。

受託開発をしたり、自分のプロダクトもつくったりして経営を軌道にのせたいと思っていましたが、いま思えば学生のエンジニアが「いいものをつくれば売れるだろう」としか考えていなかったので、うまくいきませんでした。

岡野原氏：その後、アメリカに渡ったんですね。

川口氏：はい。その会社には1年ぐらいで見切りをつけて、アメリカに渡り、Sun Microsystemsというところで働きました。いまとなっては、アメリカに行ったことでキャリアが開かれたと思っています。

この経験にも価値はあるのですが、そのまま経営をつづけていたらどうなっていただろうかとずっと思っていました。

岡野原さんは、PFNの前身となるPreferred Infrastructure（PFI）を立ちあげました。PFNは、いまではユニコーン企業になっていますよね。

私が途中であきらめてしまった経営というドラマのつづきがみたいと思い、本日はお越しいただきました。改めて、どのような旅路だったか教えていただけますか？

岡野原氏：2006年、修士1年のときにPFIを友人6人とともに立ちあげました。PFIが最初に取り扱った製品は、IPA（独立行政法人情報処理推進機構）の「未踏事業」でつくった検索エンジンです。

当時、ちょうどガラケーが人気だったので、検索需要があると踏んで提供しました。その後、特に外部から資金調達をすることはなく、2006～2010年にかけて緩やかに成長させていきました。

川口氏：立ちあげのときは、何を主力事業とするか決めずにスタートしたと聞いたことがあります。

岡野原氏：そうなんです。とがった技術には自信がありましたが、それを世の中が求めているのかということについては知見がありませんでした。

転機になったのは、2010年ごろに某EC企業の方が、「これからはビッグデータだ」と語っていたのを聞いたことです。

その後は、IoTやAI、ディープラーニングなどの技術が登場してきて、この領域でビジネスができるのではないかと考え、PFNを2014年に立ちあげました。

世の中の大きなトレンドにのること、追い風を利用することがスタートアップにとっては重要だと思います。

最初は私自身もよくわからないなかで、さまざまな人と話して、何が求められているのか感度を高めていきました。

経営者に必要な「目利きの力」を育ててきた

川口氏：いまの理系の学生さんたちが、勇気づけられる物語ですよね。岡野原さんは自然言語を研究されてきましたが、「興味」がビジネスになる面白さはありましたか？

岡野原氏：当然ですが、自分たちが得意とする領域と世間のニーズは大きく異なることがあります。

私が専門としていた言語モデルは、当時売り出すにはナンセンスでしたから、自分が強く惹かれる技術と社会や事業に貢献できる技術は、わけて考えました。

ニーズを読めるようになるまで、20年くらいはかかりました。

川口氏：最近は、さまざまな企業と共同開発をされていますよね？

岡野原氏：はい。ディープラーニングの登場とともにそれを活用する方法を模索しました。PFN初期では、自動車や産業用ロボットなど、さまざまな分野に適用できないか考えましたね。

川口氏：新しいプロダクトをつくる際は、資金が必要になりますよね。

資金がないなかでロボティクスや半導体など、いわゆる「アウェイ」の分野に参戦して優秀なエンジニアを割り当てるのは、勇気がいることではないでしょうか。

岡野原氏：アウェイの分野に参戦する流れは、大きく2つあります。1つは、お客様からご相談をいただき、うまくいった製品を世に出す場合。

2つ目は、自分たちで「これなら売れるかもしれない」と思ったものを開発する場合です。

当たり前のことですが、私たちも資金と人的リソースをみながら、開発に取り組んでいます。これまで多様なプロジェクトに関わってきたので、ある程度プロジェクトの成否を見通せるようになりました。

もちろん、すごく面白いアイディアでもビジネスにならなければ「見切る」こともあります。

川口氏：なるほど。ある意味、投資家のように「見通す力」、それによる「見切る力」「踏ん張る力」が必要なんですね。

事業に注力すべきか、それとも撤退すべきか。そういった「目利きの力」はどう手に入れたんですか？

岡野原氏：多くの案件にさまざまな立場で関わった経験がもとになっています。どんな役割で参加するかで頭を使いわけるようになりました。

プレイヤーに近い立場なら何とかしてやり切ろうとし、マネジメントレイヤーで参加するときは、冷静にプロジェクトの成功確率を考え決断することが多いですね。

「正気と狂気」のバランスで経営と投資を繰り返す

川口氏：理系の学生さんは、自分が好きな技術を突き詰めた結果それがビジネスになる、というサクセスストーリーを夢見る傾向にあるのかなと思います。

岡野原氏：私は、むしろ「特定の技術でないと」というこだわりがありません。自然言語処理で博士号を取得して、検索処理でビジネスを立ちあげ、ディープラーニングやAIへと進出している。

扱う技術に変遷があったし、パラレルにやっていると思っています。

川口氏：半導体開発も手がけていますよね。

岡野原氏：そうですね。突然手を出したとみられがちですが、私たちは2016年から半導体開発をはじめていました。PFNとして得た利益を半導体開発に捧げていたんです。

AIが将来的にどう使われたとしても、計算力は求められるし電力は問題になるだろうと思ったので。

いまは「MN-Coreシリーズ 」という深層学習を高速化する、世界最高水準の電力性能（消費電力あたりの演算性能）をもつプロセッサーの第2世代「MN-Core 2」が完成し、さらにその後継機の研究開発をしています。

川口氏：半導体はたしかに需要が見込まれますが、資金繰りの観点からいうと企業の存続がかかっているスタートアップが手を出すのは、かなりチャレンジングなことではないかと思いました。

岡野原氏：経営には、「狂気」と「正気」の両面が必要だと思っていて。合理的に判断するビジネス（＝正気）と、うまくいくかわからないものに投資するビジネス（＝狂気）。

特に「狂気」に手を出すときは、適当な説明では役員陣は納得しません。出そろってはいないながらも、自身の考えや見通しをつまびらかにする必要があります。

「正気」は短期的な計画を軸に着実に成長させること。「狂気」は5年後や10年後を見通して地道に挑戦しつづけけること。

実際には「正気」のなかにも「狂気」があったりするので、それぞれが綺麗に事業として区切られることはないんですけどね。

研究者としての顔。時間管理の工夫

川口氏：私のなかで、岡野原さんは「研究者としての顔」ももっているなと思っています。そこで、研究者としての活動についてもお聞きしたいです。

岡野原氏：そうですね。社内の研究プロジェクトの多くに関わっていますし、世界中の研究者やエンジニアと交流することで、技術の進化をつねに意識しています。

これはアカデミックではなかなか得られない経験です。「最先端の研究を知っているかどうか」はビジネスにおいても重要な要素ですし、技術のポートフォリオを考える際に役立っています。

川口氏：扱う技術分野にこだわりがない、言い換えると「何に挑戦してもいい」という状態は、「これに手を出してよかったんだろうか」という迷いが生まれませんか？

岡野原氏：そういったときは、中長期的な目線をもって熟考する時間をとるようにしていますね。

川口氏：時間の使い方も工夫しているんですね。そうはいっても、「やらなければならないことだけど、気がのらないな」ということはないんですか？

岡野原氏：私は時間管理を非常に重視しています。朝の時間を利用して集中して判断を伴う業務をこなし、その後はオートマチックにできる仕事をこなすようにしています。

人間は状況が変わると疲れてしまう傾向にあるため、同じような種類のタスクの連続した業務になるよう心がけています。

「正誤」で情報を測らない。必ずアップデートする

川口氏：事業をはじめる際には、理想と実際の世界にはギャップがあり、それを埋められるのが自分たちだというある種の思い込みが必要かなとおもうのですが、実際に岡野原さんが事業をスタートしてみて気づいたことはありますか？

岡野原氏：「事業をはじめる前に考えていることは、たいていが的外れ」ということですかね。どんなに考え抜いたことでも、頭で考えているときより事業を進めてみたときの方が得られる情報量が圧倒的に多い。

聞いていた話とは違う、これがボトルネックになっているなど、得られた情報をもとに事業をアップデートして、その結果むずかしければピボットや撤退を決断する。臨機応変さも重要ですね。

「計画だけ立てても仕方ない」という見方もあるかもしれません。ですが、計画を立てる際には、みなさんさまざまな情報を集めると思います。

たとえ前提が間違った情報が混ざっていたとしても、それらは後から再利用できる可能性があります。

「情報が正か否か」よりも「情報をアップデートする」という視点は必要だと思います。

例えば、ChatGPTが登場する前に「世の中がこう変わる」と予測した5年計画、10年計画は、いまアップデートされていないと変化に追従できないですよね。

川口氏：その通りですね。岡野原さんご自身がさまざまな知見をお持ちだからこそ、臨機応変に対応できるのかなと思いました。

岡野原氏：私自身、見通しを誤ることもあります。特に、昨今の技術は不確実性が多分に含まれますから。

いま振り返ってみれば、「失敗したらどうなるのか」がわかっていなかったから挑戦できた側面があると思います。

むしろ、何かチャレンジするときは初期のほうが失敗しやすいです。はやめに失敗しておけば、そのうち初期の失敗は失敗ではなく経験になっていると思いますよ。

川口氏：その言葉、学生や若い起業家にとって本当に励みになると思います。今日はありがとうございました。

イベント全編をみたい方はこちら

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

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

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

※SHIFT EVOLVEとは？
SHIFTグループが主催する技術イベント。エンジニアの学びの場をつくりたいという想いで運営し、メンバー登録者数は3,700人を超える（2024年12月時点）。開催予定のイベントは以下よりチェック。
https://shiftevolve.connpass.com/

SHIFTのこれまでと、エンジニアキャリアとの向き合い方

まずは池ノ上より、SHIFTがこれまで行ってきた、エンジニア組織の運営に関する取り組み内容が紹介されました。

現在、さまざまなインダストリー領域で売上を拡大しているSHIFTですが、最初は、流通などからはじまり、金融といった領域へと事業を展開。 それぞれの業界知識をもった人材を採用するという形で順調に成長してきました。

「事業成長の過程で特に苦労したのはソリューション開発のマネジメントです。市場ニーズはトレンドに食いついていくものですが、我々はトレンドにすぐ飛びつくのではなく、いまあるところから一歩ずつ踏み出して、自分たちの知識を体系化していくというアプローチでやってきました」（池ノ上）

そしてご入社いただいた方へのリターンとして、SHIFTはあるべき職場環境を整えてきたことをご紹介。

例）
・勉強会や検定試験など、学びやキャリアアップの仕組みづくり
・CoE（センターオブエクセレンス）によるノウハウのマネジメント（提案営業責任、アセット開発、プロセス整備など）を実施
・イベントや技術ブログなどエンジニア個人が社外にでる機会の提供

こうした環境のなかで遂げられたそれぞれの成長は、役割等級制度（ミッショングレード制）により年2回評価されます。

2024年9月からはじまったFY2025。SHIFTは売上成長に責任をもつ事業部と、技術の進化に対して責任をもつソリューション本部という組織がそれぞれ事業経営を行う体制になりました。 

ソリューション本部は技術面で事業部を支援することはもちろん、新たなサービスの開発も行っており、ビジネスとエンジニアリングのいい関係性が築けていると池ノ上は語りました。 

カケハシの取り組み（湯前 慶大氏）

つづいて湯前氏より、「日本の医療体験を、しなやかに。」をミッションに掲げるカケハシの事業概要などが紹介されました。

カケハシは、薬歴や服薬指導をはじめ、服薬期間中のフォロー、業務のみえる化など、薬局のDXを推進している会社です。

「我々としては、薬局業務のDXは第一ステップであり、最終的な目標としては医療全体をどうよくしていくかにあると考えています。ですから、ここからさらに医療の深いところに入っていき、医療全体の課題を改善したいと考えています」

そんななか、湯前氏は現在のカケハシが置かれている状況を説明します。

「ビジネスとして期待されている成長率を実現してきたのを示すのが上側の線です。ただ、プロダクトの成長率はそんなにすぐに上がるわけではなく、期待値とのずれが品質ギャップとなって表れているのが現状です。具体的には、UXや機能数、非機能要件、技術的負債などがあげられ、それらに対してどう向き合うかが課題になっています」

ここからは、お二人によるトークが展開されました。特に重要なポイントをピックアップしてお伝えします。

ディスカッション①プロダクトの品質はどうやったら上がるのか

池ノ上：我々の主戦場である、いわゆるエンタープライズインテグレーションのなかでいわれる「品質」は機能的・非機能的な仕様と実態のギャップを指すのに対して、湯前さんのスライドの最後で示されていた「プロダクト品質」はビジネス的な期待値を表しているじゃないですか。

これは誰からの要求で、どういうギャップなのかを教えてください。

湯前：端的にお伝えすると、投資家ですね。我々のように投資を受けているスタートアップだと、年間成長率として売上の40%ぐらいは少なくとも成長することが期待されています。

急激な成長率を実現していくための組織の整備がたとえ十分にできていない状況であっても、売上を上げていく必要がある。

それが結果的にギャップを生んでいきます。もちろん、採用を増やすというのが一つの対処法にはなりますが、人を増やすだけでできる仕事なのかというと、そういうわけでもありません。

最初はすごく小さいギャップだったとしても、年々膨れ上がっていく。そのなかで、我々がなぜここの場にいるのか、何のためにやっているのかという情熱みたいなものが、結局は一番大事だなと感じています。

いまつくっているのは薬局向けシステムだけど、実はその先にいらっしゃる患者やそのご家族のためにやっているとか。いかによい技術的な資産をつくっていくかに、ちゃんと向き合わないといけないと考えています。

池ノ上：事業会社ならではという感じがして、うらやましさも感じます（笑）。

いまお話しいただいた内容ですが、実際に現場の第一線でコードを書いているエンジニアのみなさまも同じような目線なんですかね？

正直、僕自身が現場にいたときは、そんなことは全然考えていなくて、そういう思想になっていったのは40歳を超えてマネジメントサイドにきてからなんですよね。

湯前：そうですね。それこそ「医療は誰でもお世話になっている領域だと思うので、ちゃんと恩返しをしたい」みたいに考えているメンバーが多いです。

もちろん、一人ひとりのマインドセットだけでなく、例えばエンジニアが薬局業務改善に関わる際に、現場見学や患者インタビューを通じて、現状の理解や改善点をみつけることが重要とも考えています。

実際の声や視点を共有し、業務改善の目的を明確にすることで、モチベーションの維持や業務への姿勢を高めていると思います。

人それぞれの向き合い方を尊重しつつ、6つ掲げているバリューのなかでも「高潔（自分に矢印を向け、易きに流れず、言行一致で信念をつらぬこう。）」を大切にして、最終的にいいプロダクトやサービスを生み出せればよいと考えています。

ディスカッション②エンジニアが輝ける組織はどうやったらつくれるのか

池ノ上：SHIFTでは「相対評価ではなく、その人の絶対評価として市場価値でエンジニアを評価しよう」という思想があって、その考え方をベースに施策を考えています。

個人として頑張ってきたことが認められたことで、この会社をもっと大きくしていこうとか、いろんな人にこの会社のよさを知ってもらいたいとか。そういった考えが自然と芽生えていく人をみてきました。

湯前：いいですね、そうなんですよね。難易度が高いけど、成果が出たらめちゃくちゃすごいことになるとか、マネジメントする立場としてはそういう仕事をちゃんと渡していくことも大事だなと思います。

池ノ上：僕らの職業って、ポータビリティがめちゃくちゃ高いじゃないですか。世界中どこに行っても通用するエンジニアが、自分の会社を選んでくれたらいいなという思いで、日々仕事をしています。

そのために、「エンジニアが輝ける組織って何だろう」という議論はつねにしていて、だからこそ僕らは人という資本に投資する「人的資本経営」という経営の仕方をしています。

意識がすごく高い人たちがいる一方で、そうはいってもマインドとして振り切れない人って、やっぱりいるじゃないですか。そういう人に対するケアはどうされていますか？

湯前：そもそも別に僕、人を変えたいとは思っていなくて。

変わりたいかどうかはその人自身の課題なのでいいのですが、それとは別の視点として、事業として解くべき課題は何かということを適切に提示することが大事だと思っています。

池ノ上：よく分かりますが、それと技術スタックをあわせるのってけっこうむずかしくないですか？

湯前：むずかしいですね。でも、色々な方と面接・面談をしていったなかで、技術スタック以上に「それをどういうふうに解決しようと思ったか」というスタンス・姿勢の方が、実は大事なんじゃないかなと思っています。

そういう意味だと、何かやって失敗した経験も、めちゃくちゃ大事ですよね。失敗って絶対、誰しも起こることなので、その人にとってはすごくいい経験になっていると思います。

ディスカッション③ビジネスの成功×技術への好奇心

湯前：今回のテーマであるビジネスと技術の両輪についてですが、どちらが欠けてもよくないですよね。「売上がすべてを癒す」という言葉もあるとおり、ビジネスも技術も両方が本当に大事だよなと。

池ノ上：そこに異を唱える人ってほとんどいないと思うのですが、もしもそこに対立構造みたいなものを想像する人がいるとすれば、それは単に時間軸のズレだと思っています。

つまり、どのタイミングの成功なのかの認識が違うだけなのかなと。そこのゴール設定をチューニングしてあげるような役割があれば、組織としてうまくいくと思っています。

湯前：そうですね。対立構造があった時に「時間軸ってどうなんだろう？」と考えるのは、すごくいいフレームワークだと思います。

池ノ上：とはいえ、これってけっこうむずかしい話でもあって、特に我々のような企業って、いくら大きくなってもベンチャー企業ですから、今日の売上を上げないといけないわけです。と同時に、先のことも考えなきゃいけない。

結局、時間軸が違うだけだとわかったとしても、「で、どうする？」となってしまう。すごくむずかしいテーマなんだろうなって思いますね。

CTOをやっていらっしゃると、なんのためにやっているのかという観点での話が多くなりますか？

湯前：経営メンバーとはよく、そういう話をしていますね。大事なことは、相手が普段考えているフレームワークで話ができているかどうかだと思っていまして、テクニカルにそれができることが大事だと感じています。

「BSに跳ねる話なんです」とか、「PL的にこうなんです」みたいな感じで。

池ノ上：技術とビジネスを両立させることは、今後あたり前にあるものになっていくでしょうね。

湯前：そうですね。資本主義的に短期間に成功するものにしかチャレンジしない傾向があるなかで、技術の探求はしづらいというのはたしかにあるとは思います。

だからこそ、探求によってどれだけビジネスインパクトがあるのか。そこについての対話が非常に大事になってくるだろうと思います。

池ノ上：そこのマネジメントも、すごくむずかしいですよね。純粋な技術の探究って、ある種の娯楽や福利厚生としたら、見方を変えるとやりがい搾取と捉えられることもあるだろうなと。

湯前：弊社の場合、技術的な探究とビジネスを融合させるというある種の制約は、ポジティブに捉えていますね。

ビジネスとして成功したら、また新しい技術に投資できるようになる。もっと人を増やしたり、より工数をかけたりもできるよねと。

その正のループをどうまわしていくかを考えていくことが、大事なんじゃないかなと思っています。

池ノ上：その自由度は現場のエンジニアにもあるんですか？

湯前：お客様から期待されている期間やタイミングがあるなかでも、私たちはクオリティの高いものをだしたいと思うわけです。

質が担保できているかはマネジメントしつつ、「ちょっと余裕ができたから、このスプリントは自由研究だ」みたいな感じで探究するチームもあります。

池ノ上：すばらしい。その裁量がある程度現場に任されているわけですね。やっぱり、カケハシさんの組織はレベルが高いですね。

動画全編をご覧になりたい方はこちら

―――さまざまなテーマでイベントを開催中のSHIFT EVOLVE。「エンジニア組織の未来」と銘打ったシリーズは今回が二回目。次回以降もぜひお楽しみに。

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

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

第一部：SHIFTに入社してよかったことは？

秋葉：同じ志をもった仲間が多いことです。アジャイルが好きな人、自動化が好きな人が多いので、高い目標をもって切磋琢磨できます。 

和泉：おっしゃる通りですね。僕の場合は、アジャイルに限らない話ではありますが、SHIFTに入社した理由の1つが評価制度がすごくわかりやすく、曖昧さがないという点なんです。

曖昧さがない分、厳しさもありますが、頑張りが成果として反映されやすいのでモチベーションを維持できます。 

船橋：マネジメントとプレイヤー、各々が進みたい道に進めるところもいいですね。

スクラムマスターとして成長しつづける道も選べますし、状況や心境の変化にあわせてキャリアを変えることもできます。 

さらに、マネジメント層とプレイヤーの距離が近い点もいいなと思っています。これによって、チームのことを「同じ目標を目指す仲間」と認識しやすくなります。 

また、SHIFTには、2,000社以上のお客様がいて3,000製品もの支援実績があるので、さまざまなプロジェクトに携われます。

アジャイル関連でいえば、これからアジャイル開発をはじめる企業のプロジェクトや、2〜3年アジャイル開発をしてきたけれどより高みを目指したいチームのプロジェクトに参画できます。

これは、やりがいにもつながっていますね。 

第二部：アジャイル推進部はどんな組織？

秋葉：SHIFTは基本的にお客様のインダストリーごとに部門がわかれていますが、アジャイル推進部は横串ですべての部門に入り込み、それぞれの部門がお客様にアジャイルサービスを提供できるように支援しています。

そういう意味では、アジャイル推進部は独立した組織ともいえますし、全事業部の仲間ともいえます。 

和泉：経験できるプロジェクトの幅が広いのは、領域横断で支援するからですね。

興味のある領域で経験を積むこともできるし、高い評価を得られそうなプロジェクトに関わることもできる。

新しい技術を積極的にとり入れている部門を支援することもできます。非常に柔軟な選択ができます。 

SHIFTは部署異動についても寛容で背中を押してくれる会社ですが、そもそも横串で関わるからこそ組織を俯瞰できる点が、アジャイル推進部で働く魅力だと僕は思っています。 

船橋：アジャイル推進部は、勉強会がさかんに行われる組織ですよね。SHIFT全体でも勉強会を定期的に開催していますし。

木こりのジレンマ（※）に陥らないようにしていきたい、より高みを目指したい、どんどんいろいろなものを学びたいという意欲が強い人が多い印象です。 

※木こりのジレンマ：「余裕がない」「忙しい」と目の前の作業をこなすのに精一杯で、頑張っているのに成果が出ない様子を表す。仕事の効率が悪いときに使われる。 

勉強会には、誰かが講師になって教える形で開かれるものもあれば、誰かといっしょに学びたいなど何かしらの理由で「いっしょに学びませんか」と呼びかけあって開催されるものもあります。 

和泉：ひとりで学ぶのってけっこう辛いですもんね。褒めあい、支えあい、互いに「やろうよ」といいあいながら勉強できると、前向きに継続しやすいと思います。 

船橋：IT業界には、勉強会のコミュニティが多数あります。それを社内で構築できているのはSHIFTならではの強みですよね。 

和泉：自分が得た知識を共有するものもあります。例えば認証基盤の構築案件を経験したメンバーが、そこでの学びをシェアするなど。

一人ひとりが仕事で得た知識が共有されて集合知になり、SHIFTの総合的なスキルレベルはますますあがっていくでしょう。 

秋葉：それから勉強会だけでなく、雑談での交流もしています（笑）。 

和泉：それも重要ですよね。 

秋葉：チャットでは最近こんな料理をつくったよ、とか。そういったざっくばらんなコミュニケーションがさかんに行われています。 

船橋：何でも気軽に話せる関係性を構築していることが、勉強会などにおける相談のしやすさなど、心理的安全性の確保につながっているのかもしれません。 

和泉：雑談をしているチャットもあれば、真剣な話をしているチャットもありますよね。

例えば、会社として設けているホットラインはありますが、それ以外にも相談事があった際の「駆け込み寺」のようなものが部署内にあるのはいいなと感じています。 

第三部：いま課題に感じていることは？ 

和泉：アジャイル推進部における課題は、人材の採用です。

私はプリセールスとして案件を獲得する役割を担っていますが、せっかく案件を獲得できそうでも対応できるエンジニアが十分に揃っていないと、その案件は失注してしまいます。 

それは会社にとってよくないことです。強気なことをいうと、お客様のためにもなりません。

SHIFTが支援すれば状態が改善するビジョンがみえているのに、人が足りていないがゆえに支援できないのは、お客様にとって、社会全体にとって非常にもったいないことです。 

そのために、いいエンジニアにはSHIFTにどんどん入社してもらいたい。会社にとっても私にとっても重要なミッションだととらえています。

私自身はいま、JavaとPython知見をもつエンジニアを探しているので、経験がある人はぜひSHIFTに応募していただきたいです。 

また、アジャイル開発の案件に関して、グループ会社を含めたONE-SHIFTでチームを組んでお客様を支援するという実績も積んでいきたいので、その意味でも採用はますます強化したいですね。 

秋葉：船橋さんが感じている課題はありますか？ 

船橋：昨今のビジネスは変化が激しく、企業は変化の波にのらなければいけません。そのため、経営陣の決定スピードもまたどんどんはやくなっていきます。 

現場側がその波にのるためには、アジャイルやDevOpsのようなスピードをあげられる手法をとり入れていく必要があります。トップからボトムまで波にのり、組織全体をアジャイルでよくしていくんです。 

秋葉：アメリカでは大半の組織がアジャイル化していますが、日本では会社全体がアジャイル化しているのはほんのひと握り。

組織の一部にアジャイルを導入している企業さえも全体の20％に留まるというレポートをみたことがあります。 

日本を変えるために、SHIFTがアジャイル化を先導したい。お客様の組織やサービスのアジャイル化を支援して、日本全体のアジャイル化につなげていきたいと考えています。 

今後は、日本全体にアジャイル化のムーブメントをつくっていきたいですね。

SHIFTが「アジャイル日本一」と呼ばれるようになるときには、日本が「アジャイル先進国」として認識されるようになると確信しています。 

第四部：アフタートーク①　グループ長ふたりの働くうえでのモットー 

秋葉：船橋さんは、そもそもなぜスクラムマスターをやりたいと思ったんですか？   

船橋：自らスクラムマスターをやりたい、やりますといったわけではなくて。前職にいたころ、リーマンショックや東日本大震災があって激しくマーケットが変化していました。   

会社経営はそうした世の中の変化やビジネスの潮流に追随していく必要があり、当然、現場組織もどんどんアップデートしなければいけません。

決算も昔は年次決算のみで十分でしたが、四半期決算、月次決算と求められ、いまでは週次決算も普通ですよね。   

開発もそのスピードにあわせるとなると、週次で何かしらの成果を出さなければいけない。だったら、それに順応できる開発としてアジャイル開発をやりましょうとなりました。   

ところが当時所属していたチームでまずアジャイル開発をやってみたところ、途中でこれはアジャイルじゃないぞと気づいて。

「まずは教科書通りのアジャイル開発をやってみませんか」と進言したら「ではあなたが、それをやってください」といわれ、いまの立場になりました（笑）。   

SREも同じです。別にSREをやりたいとか、テストを自動化したいとか思ったことはなくて。効率よく業務を楽にするために自動テストを導入していっただけなんです。   

和泉：ペインがあって解消しにいった感じなんですね。   

船橋：そうそう。自社サービスの状態がわからないという状態がすごく嫌だし、業務時間外に電話が鳴るのも嫌だから、つねに自分でサービスの健康状態を把握できるようステータスを可視化して社内のどこからでもみられるようにしただけ。   

その結果、それをちゃんとした組織としてやりたいからSREをやりましょう、アジャイルをやりましょう、スクラムマスターをやりましょう、自動テストの設定をやりましょうと、やることが増えていきました。   

秋葉：いまのエピソード、はじめて聞きました！　船橋さんは生まれたときからスクラムマスターだと思っていました（笑）。和泉さんはなぜ自動化をやりたかったのですか？   

和泉：実は自動化が大好き、とかではないんですよね。私は何をやるかより誰と働くかを大事に思っていて、面白い人たちと働きたいと思っています。

アフターファイブでガハガハ笑いながらお酒を飲める間柄も素敵だし、知的好奇心をくすぐられる人と仕事をするのもいいですね。   

尊敬できる人がいるとすごく自分自身のモチベーションになります。

そういう人のもとで働きたい、いっしょに働きたい、そういう人をできるだけ助けたい。そういう気持ちを、SHIFTの人と会ったときにも抱きました。   

代表の丹下さんもすごく距離が近いじゃないですか。従業員と積極的に関わる人。そんな丹下さんを尊敬しているし、近くにいるのでやる気が出ます。   

秋葉：丹下さんは、ある意味1万人を超えるグループ従業員に“素”をみせられているのだから、それ自体がすごいですよね。   

和泉：丹下さんの魅力はすごくありますよね。

知的だし「従業員の子どもは孫だと思っている」とよくいっているけれど、本当にそういう感じで接してくれる。だからこの人のために頑張りたいと素直に思えます。 

第五部：アフタートーク②　出社派？リモートワーク派？

秋葉：ちょっと雑談なんですけど、リモートワークから出社へ回帰する流れも世の中ありますが、おふたりは出社派ですか？それとも リモートワーク派？ 

和泉：僕は出社賛成派です。IT業界といえど結局は「人」同士の仕事だと思っているので、顔をあわせて働く方がスムーズに進むのかな、と思う場面も 。

ただフル出社じゃなくてもいいですね。

例えばどうしても出社できない事情があるときにはリモートワークを使うなど、柔軟に選択できる状態が理想的だと思います。船橋さんはどうですか？ 

船橋：僕は基本的にリモートワークを推奨しています。 

出社はコミュニケーションなどの面でメリットがあるのは和泉さんがいう通りです。

ただリモートワークで発生しがちな弊害は、たまに会うだけで改善できるようなものが多いと個人的には思っているんですよ。 

秋葉：それぞれの働き方にメリット・デメリットがありますね。とはいえ従業員それぞれが完全に自由に選択できるという状況にするのも、組織運営上むずかしかったりもします。 

和泉：そうですね。ガバナンスを利かせる必要がありますから。

その意味では、プロジェクトにあわせて適切なルールを定めて運用することが重要かもしれません。プロジェクトは生き物ですから。鉄の掟で出社かリモートワークかを強いる必要はないと思います。 

秋葉：その点、SHIFTの取り組みとして面白いと思うのは、従業員が出社したくなるような仕掛けをつくっているところです。 

和泉：丹下さん（代表）が麻布台ヒルズにオフィスを借りたのも、「人が集まりたくなる場所をつくるため」でしたね。 

秋葉：フル出社かテレワークかについて、私はそんなにこだわりはありません。

当然、お客様がいる仕事である以上、プロジェクトによって在宅勤務か、出社かの要請のあり方は変わりますし、会社ルールとしてもそう設けています。

ただ、そういった組織ルールを前提にしながらも、個人の都合も配慮した形でできたらいいなと思っています。

※SHIFTのテレワーク制度 
制度上、テレワークは希望制ではなく、就業場所は参画プロジェクトによって異なります。詳細は選考時にご案内さしあげます。 

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