働き方は変わらなかった だからこそAI前提で組み直した組織設計

生成AIの導入によって、エンジニア一人ひとりの生産性は確実に向上しています。コードの叩き台作成やレビュー観点の整理、仕様理解の補助など、開発のあらゆる工程に入り込み、作業スピードを押し上げてきました。

しかし、本質的な変化は個人の効率化にとどまりません。実装に費やしていた時間が圧縮されたことで、何をつくるのか、どの課題に向き合うのかという意思決定の重心が動き始めています。複数の役割をこなせるようになったことで、エンジニアだけでなく、プロダクトマネージャー（PdM）やプロジェクトマネージャー（PM）、デザイナーを含めたチーム全体の関係性が再設計を迫られています。

そこで今回は、株式会社エブリー 開発本部 開発1部 部長の村上将也氏に、生成AI時代におけるエンジニアの働き方の変化と、それを支える組織設計の考え方についてお話を伺いました。

※株式会社SHIFT AIでは法人企業様向けに生成AIの利活用を推進する支援事業を行っていますが、本稿で紹介する企業様は弊社の支援先企業様ではなく、「AI経営総合研究所」独自で取材を実施した企業様です。

AI導入後に直面した個人活用の壁による「スピードの差」

AIツールの導入を進めてから数ヶ月が経過した頃、エブリーでは活用状況の振り返りが行われました。そこで浮かび上がったのは、ツールが使われていないという単純な問題ではなく、活用度合いにおける個人差です。すべてのエンジニアが日常的にAIを取り入れており、短時間で試作や実装を進められるようになりました。一方で、うまく活用しきれていないメンバーも存在していたのです。

村上氏は当時を振り返り、「ツールを配布していたのに、いろんなチームを見ていっても、働き方自体はそこまで大きく変わっていなかったんです」と語ります。AIを積極的に使いこなすメンバーが生まれたことで、むしろチーム内で期待されるアウトプットの基準や開発スピードの前提が異なっていました。

あるエンジニアは短時間で試作を提示できるのに対し、別のメンバーは従来通りの調査や実装プロセスを踏んでいるため、プロダクトマネージャーやデザイナーも、どのスピードを前提に議論を進めるべきか判断がつかなくなっていたのです。

結果として、AIをうまく活用している人だけが業務改善に成功し、タスクの分配や仕様検討の進め方、意思決定のテンポそのものは従来のままでした。AIによって個人の業務効率は改善されているにもかかわらず、チームとしての働き方には変化が及んでいなかったという構造的な問題が浮上したといえます。

このままでは、AI導入が一部のハイパフォーマーをさらに加速させるだけの施策に留まります。組織全体として掲げていた「生産性10倍」という目標には到達できないという危機感が高まっていきました。村上氏も「トップの数パーセントはたくさん使っていますが、意外とみんな普段の業務のままだね、という状態になっていました」と振り返ります。

問題の本質は「ツール」ではなく「プロセス」だった

一部の層だけが活用できているという状況を踏まえ、エブリーでは「なぜAIがチーム全体の変革につながらないのか」という問いに向き合うことになりました。単にツールの利用率を高めるだけでは解決しない問題が、現場のあちこちで共有され始めていたためです。

村上氏は、「今の業務プロセスは、人の存在によって最適化されたような形で構築されているんです」と指摘します。従来の開発フローは、企画、デザイン、実装といった工程を人間同士のやりとりが前提で設計されています。そのため、AIを補助的なツールとして既存のプロセスに追加したとしても、全体の流れそのものが変わるわけではありません。

さらに村上氏は、「今までの技術を前提としてプロダクトが設計されている部分もあるので、業務にAIを活用するだけだと、本当に一部の効率化で終わってしまいます」と語ります。よりうまくAIを活用するためには、既存の業務フローやプロダクト設計そのものを見直し、AI活用を前提とした形に再構築する必要があるという認識に至ったのです。

この気づきは、AI導入を単なる業務効率化の施策としてではなく、チームの働き方や意思決定のプロセスを再設計する取り組みへと位置づけ直すきっかけとなりました。AIを前提に業務を設計しなければ、組織としての生産性向上にはつながらないという問題意識が、徐々に組織内で共有されていくことになります。

「AI前提」で業務設計を組み直す

プロセスの問題に行き着いたエブリーは、「ツールをどう使うか」ではなく、「どう組み込むか」というフェーズに移行しました。既存フローにAIを取り入れるのではなく、AIを前提とした業務設計へと発想を転換する必要があったのです。

その際、村上氏が強調したのは、まず情報の整備でした。「生成AIはとてつもなく賢いんですけど、会社固有のルールや業務知識は知らないとても賢い新人だと認識しています」と語ります。優秀ではあるものの、前提知識がなければ成果を生み出せない。新入社員に丁寧なオンボーディングが必要なように、AIに対しても「教える設計」が求められるという考え方です。

そこでエブリーは、暗黙知の言語化を進めました。これまで口頭で共有されていた開発上の判断基準やコード品質の考え方、仕様の前提条件などを整理し、AIが参照できる形に整備していきます。うまくいかなかった指示やアウトプットについても検証し、「なぜダメだったのか」を振り返りながら、ルールドキュメントを更新していきました。この試行錯誤の積み重ねが、AIの精度を徐々に引き上げていったといいます。

もう一つの柱が、人間の存在を前提とした設計です。AIにすべてを任せるのではなく、どのタイミングで人間が確認し、どこで承認し、最終的に誰が責任を持つのかを明確にしました。「AIに行動計画を出させて、それを人間が見て承認する。途中でもアウトプットを確認し、最後は必ず人が責任を持つ。この設計は今のフェーズでは欠かせません」と村上氏は説明します。

さらに、プロセスの再設計はエンジニアに限った取り組みではありませんでした。PdMやデザイナーにも同時にツールを展開し、仕様書の管理方法や情報の置き場そのものを見直します。仕様と実装をつなぐ情報環境を整えることで、AIが仕様から実装までを横断的に支援できる可能性を探りました。

AIが緩衝材になり、組織の共通理解を生み出した

プロセスを見直し、AIを前提とした業務設計へと踏み出したことで、エブリーの組織内には確かな変化が起き始めました。それは単純なスピード向上ではなく、チームの前提が揃い始めたことにあります。

象徴的だったのは、他部署連携における関係性の変化です。これまでは、PdMがエンジニアに機能の仕組みを確認し、その回答を待ってから議論を進めるという流れでした。質問する側も遠慮があり、答える側も調査というタスクを抱えることになります。そのやりとりには一定の時間が発生していました。

しかしAIを活用するようになってからは、PdMがまずAIに壁打ちし、自分なりの理解を持ったうえでエンジニアと会話する場面が増えていきました。村上氏は「今はPdMが一旦AIに聞いて、自分なりの解釈を持ってからエンジニアと話すようになりました。だから、以前よりも仕事のスピードが上がったんです」と語ります。答え合わせのような形で対話が始まるため、議論はより本質的になりました。

また、デザイナーも実装への理解を深めながら設計を進めるようになりました。AIがデザインから実装への橋渡しを担うことで、どのような設計が実装しやすいのかという視点が自然と共有されていきます。エンジニアだけが知っている状態ではなく、職種を越えて一定の共通理解が生まれ始めたのです。

村上氏はこの変化を、「それぞれの職種の間にあった壁が、少しずつなくなっている感覚があります」と表現します。PdMが軽くコードに触れることも、デザイナーが実装の前提を議論することも、以前ほどめずらしくなくなりました。

さらに重要なのは、エンジニアの役割意識の変化です。AIによってコーディングの負荷が圧縮された分、アイデアを形にするまでの距離が縮まり、今まで以上にプロダクト価値の向上に時間を使えるようになりました。

こうした変化は、まだ数字で明確に表せる段階ではありません。それでも議論の質や意思決定のスピード、職種間の認識のすり合わせといった「目に見えにくい部分」に確かな変化が起きていると、村上氏は感じています。生産性10倍という目標への到達は道半ばですが、組織の歯車が少しずつ合ってきたという実感が、その背景にあります。

なぜ生産性が2〜3倍でも前進と言えるのか

エブリーが掲げる生産性10倍という目標に対して、現時点での実感値は2〜3倍程度だといいます。数字だけを見れば、まだ取り組みの真っ最中に思えるかもしれません。それでもこのフェーズを「確かな前進」と位置づけている理由があります。

村上氏は、「10倍という目標は、小手先のテクニックだけでは絶対に達成できない数字なんです」と語ります。仮に1.2倍や1.3倍といった短期的な改善を追いかければ、局所的な効率化は実現できるかもしれませんが、それだけでは大きな目標には到達しません。10倍という大きな目標を掲げたことで、プロセスそのものを問い直す必要性が組織内に共有されました。

実際、エブリーでは細かく日次・週次で特定の指標を追いかける設計を採用していません。特定の指標を厳密に管理すれば、数値を改善するための最適化は可能です。ただ、それが本質的な変革につながるとは限りません。村上氏は「特定の指標だけを追うと、そこに合わせた動きになってしまうリスクがあります」と話します。だからこそ、3ヶ月単位での振り返りを通じて、組織全体の変化を俯瞰するスタンスを取っています。

さらに重要なのは、2〜3倍という数字の中身です。一部の業務では、AIが実装からリリースまでを担うケースも現れ始めました。難易度の高い開発をすべて代替できる段階ではありませんが、一定の範囲では人間と同等のアウトプットを生み出している場面も確認されています。これは単なる作業時間の短縮ではなく、業務の構造そのものが変わり始めている兆候といえます。

また、短期的な効率を優先しなかった点も、前進と捉える理由の一つです。AIを本格的に組み込む過程では、試行錯誤の時間が増え、かえって一時的に生産性が落ちる局面もありました。それでも取り組みを止めなかったのは、村上氏が「短期の効率を守るより、中長期で生産性を跳ね上げる基盤を作るほうが価値があります」と判断していたためです。

AIと共働するエンジニアの役割はどう変わるのか

AIを業務に組み込んだことで、エンジニアの仕事は本質に近づきました。それは「コードを書かなくなる」という話ではありません。

村上氏は「ユーザーが抱えている課題に対して、何をどう作れば価値になるのかを考える力は人間が担う部分です」と語ります。AIが実装を高速化しても、問いを立て、仮説を描き、方向性を決める役割は置き換わりません。むしろ、その領域に割ける時間が増えています。

同時に重要になるのが「見極める力」です。AIの出力を評価し、品質を判断し、必要に応じて修正する。最終的な責任を持つのは人間です。この能力はAI時代において一層重みを増しています。

さらに、複数のAIを活用する働き方も広がりつつありました。村上氏は「海外のトップエンジニアは複数のAIを活用しながら業務を進めています」と話します。活用の熟度次第で、生産性の差は大きく広がる可能性があります。

これから求められるのは、AIを「使う側」ではなく「マネジメントする側」の視点です。どの情報を与え、どのタイミングで介入するか。その設計を担うことが新たな役割になります。

AIと共働する時代のエンジニアは、実装者にとどまりません。価値を構想し、AIを動かし、成果を評価する存在へと重心が移りつつあります。

効率化を超えたAIファースト組織の到達点

エブリーが見据える3〜5年後の姿は、単に生産性が高い組織ではありません。AIによって生まれた時間を、価値創出に活用できる状態を目指しています。

村上氏は「実装の負荷が下がれば、その分、エンジニアは何をつくるべきかというクリエイティブな部分に向き合えます」と語ります。仕様を形にするだけでなく、自ら課題を見つけ、試作し、ユーザーに届ける。エンジニア発のアイデアが自然に生まれる環境を目指しています。

同社のプロダクトもAI前提へと進化する見込みです。同社は「デリッシュAI」という機能で料理の悩みを身近な存在に相談するように対話できる体験の実現に成功しました。AIは裏側の効率化ツールではなく、体験を構成する存在へと進化を遂げたと言えるでしょう。

さらに、その変化はエンジニア組織にとどまりません。最前線の知見を全社へ広げ、「この人数でここまでできるのか」と驚かれるアウトプットを生み出す組織を目指しています。

AIファーストとは、AIが特別な存在ではなく当たり前のツールになること。誰もが自然に活用し、変化を前提に試行錯誤を続けられる状態を指しています。

エブリーの事例から見えてくるのは、AI導入の本質はツール選定ではなく、働き方の再設計にあるという点です。既存プロセスの延長では変革は起きません。AIを前提に組み直す覚悟が、同社のプロダクトに大きな示唆をもたらすのでしょう。

エブリーから学ぶ5つのポイント

エブリーの取り組みは、単なるAI活用事例ではありません。個人の生産性向上にとどめず、プロセスを見直し、役割を拡張し、組織全体の構造転換へと接続させています。

その実践から、AI時代における組織設計のヒントが見えてきます。ここでは、エブリーの事例から学べる5つのポイントを整理します。

1. AI導入の壁は「未活用」ではなく「個人最適」である
エブリーでは個人のAI活用は進んでいた一方で、組織での活用の浸透度を上げるという課題がありました。

AI活用によって、個人の生産性は上がっても、チームの意思決定やプロセスが変わらなければ、組織全体の変革にはつながりません。AI活用の本当の壁は、利用率ではなく組織活用にあります。

2. 問題の本質はツールではなくプロセス
AIを既存フローに“上乗せ”するだけでは、変化は局所にとどまります。
人間前提で設計された業務プロセスをそのままにしていては、AIのポテンシャルは引き出せません。

AI前提で業務を組み直すことが、構造変革の出発点になるというエブリーの学びは明確です。

3. AIは「賢い新人」──教える設計が不可欠
生成AIは優秀ですが、会社固有の前提は知りません。暗黙知の言語化、ルールの整理、失敗事例の蓄積といった“オンボーディング設計”が不可欠です。

AI活用は、実はナレッジ整備のプロジェクトでもあります。

4. 生産性2〜3倍でも前進と言える理由
生産性10倍という目標は、延長線上の改善では到達できません。短期的な効率よりも、中長期の構造転換を優先する判断が必要です。

重要なのは倍率の高さではなく、プロセスが変わり始めているかどうかが生産性向上の鍵となります。

5. 変わるのはエンジニアではなく、組織そのもの
AIによって役割の境界が揺らぎます。PDMやデザイナーもAIを活用し、職種間の前提が揃い始めます。

エンジニアの役割拡張は、組織再設計の起点です。同社が掲げるAIファーストとは、ツール導入ではなく「組織思想の転換」を意味します。

エブリーは、生成AIを単なる効率化ツールとしてではなく、業務を再設計する前提として位置づけました。ツールを配布するだけでは組織は変わらないと捉え、既存のプロセスを見直し、AIを前提に組み替えることに踏み込みました。最終的な判断と責任は人が担うという線引きを明確にしながら、AIの出力精度を高めるための情報整備と暗黙知の言語化を進めています。

活用の主導は現場に委ねつつ、組織としてはルール設計とナレッジの蓄積、そして継続的な振り返りに注力しました。短期的な倍率よりも、中長期で生産性10倍に近づくための基盤づくりを優先したことが、個人活用を組織変革へと接続する要因となっています。

しかし、自社でこれを実践しようとすると、

「うちの組織に合ったAIの活用法が分からない」
「現場にどうやってAIを浸透させればいいのか？」
「AI導入後の定着をどうサポートすればいいのだろう？」
「効果的な研修プログラムをどう設計すればいい？」

といった壁に直面するケースも少なくありません。実際、多くの企業様から同様のご相談をいただいています。

私たちSHIFT AIは、こうした「導入したが仕組みにできない」という課題解決を得意としています。

企業の業務特性に合わせたAIモデルの選定から、社内要員のスキル育成、全社への浸透施策の設計まで、AI活用を「仕組み」にするために必要なプロセスを一気通貫で支援します。

「生成AIを導入したけど、思うように活用が進まない」「どのモデルを選べばいいかわからない」──そんなお悩みをお持ちでしたら、ぜひ一度、私たちの支援内容をご覧ください。