その本の「はじめに」には、著者の「伝えたいこと」がギュッと詰め込まれています。この連載では毎日、おすすめ本の「はじめに」と「目次」をご紹介します。今日は石井大地さんの『 AI駆動開発チームの作り方・育て方 生産性20倍アップのソフトウェア開発 』です。
【はじめに】
なぜ「個人のAI活用」では生産性が上がりきらないのか？
AI（人工知能）を活用したソフトウェア開発ツールの進化が止まりません。2022年末にChatGPTが登場して以降、大規模言語モデル（LLM）を用いたプログラミング支援サービスが登場し、ソフトウェア業界に大きな衝撃を与えています。
ソフトウェア企業グラファーの経営者である筆者は、経営業務と並行して今も業務時間の多くをソフトウェア開発に費やしています。2023年初頭、プログラム支援サービスの先駆けであるGitHub Copilotをいち早く業務で使ってみて、そのコード補完能力の高さに舌を巻きました。早速、自らが経営するグラファーの開発チームに対し「原則、全員がGitHub Copilotを利用することとし、利用しない場合はその理由を説明せよ」と指示を出し、全社を挙げてのソフトウェア開発の「AI武装」を開始しました。
これまでのソフトウェア開発の現場では、開発者がプログラミングを行う上でぶつかる様々な課題に対し、用いているフレームワークやライブラリのドキュメント、Stack Overflowなどのサイトを検索しながら閲覧し、解決策を探るやり方が一般的でした。どんな開発者もあらゆる技術に精通しているわけではないので、ソフトウェア開発の現場の実態は、調査と実装のループを回すことで成り立っていました。
しかし、ChatGPT登場以来のLLMの発展により、開発者は自らがぶつかる技術的な課題の解決にLLMを用いるようになりました。アプリケーションの設計や仕様を詰めるために、LLMと対話するような手法も当たり前になりました。
その後もAIを用いたソフトウェア開発ツールの進化は続きました。GitHub Copilotのようなコード補完サービスだけでも大きな生産性インパクトがあることが感じられましたが、その後はCursorなど、AIが組み込まれたIDE（統合開発環境）が登場。またDevinなど、非同期で動作するコーディングエージェントも実用化されました。さらに、Cline、Claude CodeやGemini CLI、Codex CLIなど、CLI（コマンドラインインターフェース）ベースのコーディングエージェントやその活用ツール群が登場し、急速に普及しました。その過程で、IDEとして始まったCursorもコーディングエージェントを独自開発したり、米Microsoft（マイクロソフト）傘下の米GitHub（ギットハブ）が、これまたMicrosoftが提供するIDEであるVisual Studio Code（VSCode）と連携してコーディングエージェント機能を強化したりするなど、発展の速度は著しいものがあります。
このようなコーディングツールの発展により、開発者はこれまでとは全く異なる次元の高い生産性を実現できるようになりました。何日もかかっていたような複雑な実装も、コーディングエージェントに依頼すればものの1分で仕上げてしまいます。AIが書いたコードを読み解き、レビューする手間を考えても、自分一人で実装していたのとは数十倍もの生産性の差があります。
このような状況に応じて、既にソフトウェア開発者の雇用にも影響が出ているという情報があります。米国では、コンピューターサイエンスの学科を卒業する大学生の就職が非常に厳しくなっているといいます。また主要なテクノロジー企業は、AIによる生産性向上を踏まえて開発者の人員削減に踏み出してもいます。このような混沌とした状況が、本書を執筆している2026年初頭の段階でも続いているようです。
グラファーの開発チームは従前から、徹底した少数精鋭主義を採り、一人の開発者が課題の発見からソフトウェアの設計・実装・リリース・運用までトータルで担当し、かつフロントエンド・バックエンド・インフラなどの様々な技術スタックを一人の開発者が横断して開発する「フルサイクル・フルスタック開発」を旨としていました。創業から8年、二十数人の小規模な開発体制ながら10を超えるプロダクトをリリースし成長を続け、250を超える自治体・官公庁と、大企業数十社にサービスを提供しています。その背景に当社ならではの開発手法が寄与している自負はありました。
そんな当社がAIを活用した開発スタイルをいち早く取り入れたところ、開発ペースはさらに加速しました。2023年前半の段階で、AI適用前と比べてプルリクエストの作成数やコミット数などの指標で2倍の生産性を実現しました。その結果、当社は2023年、2024年の2年連続で、エンジニア求人サイトFindyが主催する「Findy Team+ Award」を受賞しました。
ただ、ソフトウェア企業の経営者としてAIの導入・活用を進めているうちに、単にエンジニア個人の開発スタイルを変えただけでは、チームの生産性は想定ほど高まらないのでは？との懸念を持つに至りました。そこで、コーディングエージェントの発展に合わせ、AIを前提とした最適なチーム編成と人員のアサイン、業務分担を模索してきました。
この結果、開発チームの「少人数化」がさらに進み、ソフトウェア開発の生産性が向上しました。直近の新規事業立ち上げのプロジェクトでは、事業開発担当が1人、プロダクトマネジャー1人の2人チームが、1カ月強の期間で新規プロダクトの初期バージョンをリリースしています。このチームにはその後、開発者が1人アサインされて3人体制になりましたが、その後も人員を増やさずにプロダクトを成長させています。従来であれば、事業開発担当が1人、開発者が3人規模のチームで、最低でも3カ月、通常は半年程度の開発期間が必要であったことからすると、極めて大きな生産性の向上が実現しています。
当社ではAIを用いたチーム開発が効果を発揮する一方、同じようにコーディングエージェントなどを取り入れているにもかかわらず、多くの企業や組織において、ソフトウェア開発の生産性は期待されるほどには上がっていないようです。様々な企業と話す中で、AIによる生産性の向上効果を明らかに実感している企業は少ないことが分かりました。実際、筆者はここ最近、AI前提の開発プロセスについて教えてほしいという要望を受けることが増え、AIを前提とした開発プロセス、すなわち「AI駆動開発」に関して多数の講演や研修を実施しています。このことが、本書を執筆する動機となりました。
本書を執筆した目的は、企業内の様々な組織において、実際にチーム開発の生産性を高めるために、AI駆動開発をどのように取り入れ、実践すべきか、その指針と具体的なノウハウを共有することにあります。
ソフトウェア開発に関わる組織には様々な段階があります。実際に特定のシステムを作る業務に携わるプロジェクトチームやプロダクトチームといったレベルもありますし、またそうしたチームの中に、さらに特定の技術スタックを担当する、より小規模なチームが設けられていることもあるでしょう。また、会社全体や事業部など大きなくくりに所属する開発組織というレベルもあります。混乱を避けるために、本書では、案件や製品ごとに設定されるプロジェクトチームやプロダクトチームといった、おおむね数人から十数人程度の単位を「チーム」と呼びます。複数のチームが所属する、企業もしくは企業内の事業部など、事業単位に設定されている開発者の集合体については「開発組織」と呼ぶことで区別します。
本書の主眼はチームにおけるAI活用にあり、ほとんどの内容はチームに関するものですが、内容によっては開発組織あるいは企業全体で取り組むべきことについても触れていきます。また、チームの中には、顧客コミュニケーションやプロジェクトマネジメントを担当する開発者以外の人材も含まれるケースがあると思いますが、本書はあくまでチーム内でソフトウェア開発業務に関与する人に焦点を当てています。直接的にコードを書く仕事をしていなくても、プロジェクトやプロダクトの意思決定を担うマネジャーやリーダーに関わる話は多々ありますが、開発工程に関わらないセールスやカスタマーサクセスに関する話題には主眼は置いていないことをご了承ください。
私の考えでは、AI駆動開発を取り入れることで、ほとんどのチームの生産性は数倍、あるいは数十倍にまで高められる可能性があります。ですが、その可能性はいまだ十分に開拓しきれていません。もちろん私自身も、開発者として、また経営者として、「生産性向上は道半ば」という思いを抱えています。それでも、外部から一定の評価を受けている私たちグラファーが培ってきたAI駆動開発のノウハウを言語化し、現場で開発に関わるチームの皆さんに共有することで、ソフトウェア開発の世界がさらに進歩する一助になれないかと考えています。
本書は、ソフトウェア開発の現場で培った日々の実践経験と、年間数十本もの講演・研修・セミナーへの登壇とそこで得られた聴衆の皆さまからのフィードバックや質問を踏まえ、AI時代の開発チームの作り方とその育て方について、体系的にまとめたものです。
このノウハウを展開するに当たり、ここではまず、前述の通り「なぜ、AIコーディングツールを導入しても、チームの生産性は思うほど上がらないのか」という問題について、より構造的な分析を行いたいと思います。
「チームでのAI活用」を阻む壁
個人の仕事とチームの仕事を分ける根本的な違いは、前者がタスク処理によって仕事が進むのに対し、後者はコミュニケーションによって仕事が前に進むことです。
個人で特定の仕事を完了させるには、単純に、必要なタスクを順番に片付けていくだけです。AIを用いれば、このタスクはほとんど自動的に終えることができます。ソフトウェア開発に関して言えば、実装したい内容を言語化し、AIに指示を出せば、9割くらいの完成度までは数十秒から数分で作ることができます。そのあと、AIが書いたコードを1行1行読み解いて必要な改修を加えたり、AIに指示を出して内容を改善させたりしたとしても、人間が1からコードを書くよりも圧倒的に早くコードが仕上がるのは間違いありません。
他方、チームで仕事を完了させるには、各自がただタスクを片付けるだけでは全く不十分です。チームでの仕事は、達成したい大きな仕事を分割し、各自に対して割り振る「業務分担（≒プロジェクトマネジメント）」が必要になります。この業務分担を行うには、チームを率いるマネジャーやリーダーが、配下のメンバーのスキルや知識に応じて仕事を分割してタスクに切り出したあと、ミーティングや個々のメンバーとの1on1などを通じて分割したタスクをアサインし、その進捗を確認する必要が出てきます。進捗が芳しくなければ、仕事が早く終わった別の人間、あるいは助っ人として別部署や外部の人間を追加でアサインする必要があります。
このような分業体制においては、前工程を担う人間の仕事が終わらないと、後工程の人間が仕事に着手できない、ということも起こります。当然ながらアプリケーションコードの実装が終わらない限り、品質保証（QA）担当のエンジニアは何もできないわけです。
マネジャーやリーダー自身がボトルネックになることもあります。システムの全体を左右するような重要な仕様をどうするか、全体の進捗を遅らせる大きな問題が発覚した際にどのような対処をするか。こういった様々な難題に対し、リーダーの意思決定が遅れると、その間、そのリーダーの下で仕事をするメンバーは手が止まってしまいます。
このように、チームの仕事においては、個々人が行うタスク処理が全体の生産性に与えるインパクトはそれほど大きくありません。むしろチームでの仕事では、「意思決定」「コミュニケーション」「作業の同期」が工数の相当な割合を占めます。個人がタスクを処理するのに比べ、ミーティングのための時間と待ち時間が大量に必要になることは避けられず、その時間はチームの規模が拡大するにつれて指数関数的に増えていきます（図表0-1）。
仮にメンバーがAIを用いてコーディングを30倍の速さで終えられたとしても、「次に取り組むタスクは来週のミーティングで伝える」とか、「リーダーが重大な仕様について意思決定できていない」ということになれば、次のミーティングやリーダーの意思決定までのあいだ、メンバーの手は止まってしまいます。これでは、AIでいかにコーディングが速くなっても、待ち時間が増えるだけで全体の開発速度は上がりません。
自戒の念を込めて書きますが、開発者はそのような待ち時間に、必ずしも今すぐやる必要のない技術検証などをしがちです。それがいけないというわけではありませんが、本来実現すべき開発ペースが速まらず、成果に直結しない動きが相対的に増え過ぎてしまうのなら、AI活用のために投下した工数や費用が合理的に使われているとはいえないでしょう。
AIコーディングツールの多くは有償であり、これらを使い込むとエンジニア1人当たり月額で数万円程度の費用がかかることが多いです。仮にこれらの費用によって開発チームにかかる総コストが10％上昇しているとすると、生産性の向上が10％や20％程度では導入の意味がほとんどありません。
AIがもたらす生産性向上をチームに取り込むためには、「意思決定」「コミュニケーション」「作業の同期」というボトルネックをなくす必要があります。そのためには、単にチームメンバーが個人としてAIを使うだけでは全く十分ではありません。そうではなくて、チームのコミュニケーションや意思決定、業務分担の仕方そのものを変えなければならない、ということに私たちは気づく必要があるのです。
生産性2000％アップを実現する私たちのチームの実例
「意思決定」「コミュニケーション」「作業の同期」というボトルネックが生じる根本原因は「分業」です。
一人で仕事をする際には、意思決定は自分自身で完結していますし、他者とコミュニケーションや作業のタイミングを合わせる必要はありません。そのため、仕事時間の大半をタスクの処理に投下できます。このタスク処理にAIを使うことで、生産性を飛躍的に向上させることができます。
このことから、AIを活用した生産性向上の効果を最大限に発揮するには、チームで働く一人ひとりのメンバーの働き方を、できるだけ「タスク処理」に寄せ、そのタスク処理をAIで効率化すればよい、ということがわかります。
そのために最も重要なことは、チーム内の「分業」をできる限り減らすことです。分業がなくなればなくなるほど、チームとしての意思決定・コミュニケーション・作業の同期の発生頻度を大幅に減らせることになり、その結果、個人の開発速度の向上がチームの開発速度の向上に直結しやすくなります。
当社は常々「AIを活用すれば生産性は20％ではなく、2000％向上できる」と主張していますが、その理屈は、まさに「分業」をできる限りなくし、一人ひとりが担当し意思決定をする範囲を広くすることによって実現します。
この例として、当社の開発組織が採用している「フルサイクル・フルスタック開発」の考え方を紹介したいと思います。
通常、開発組織では、業務プロセスごとに、そして技術スタックごとにメンバーが分かれ、高度な分業体制が敷かれています。
業務プロセスごと、というのは例えば、要件定義や設計などの上流工程を担うプロジェクトマネジャーやプロダクトマネジャーがいて、その配下に、実際の開発（コーディング業務）を行うエンジニアがいます。そして実装が終わったあと、品質保証（QA）のためのエンジニアがいたり、あるいはリリースや運用を担う運用担当やSRE（サイト信頼性エンジニアリング）といった職種が控えていたりします。
技術スタックごとの分業もあります。一般的なウェブシステムを開発することを考えると、フロントエンドでUI（ユーザーインターフェース）を設計するデザイナー、デザイナーが描いたUIをコードに落とし込んだり、複雑な挙動を実装したりするフロントエンドエンジニア、バックエンドのビジネスロジックやデータベースとのインタラクションを受け持つバックエンドエンジニア、それからサーバーリソースやパフォーマンスの最適化を担うインフラエンジニア、その他、セキュリティエンジニアやAIを用いたシステム開発の専門家であるAIエンジニアなど、挙げればキリがないほどの様々な専門職種があります。
このような分業は大規模なシステム開発を行う上では避けられないものですが、分業が進めば進むほど、異なる職種間で認識をすり合わせたり、スケジュール調整を行ったりするためのコミュニケーションの時間が増えていきます。システム開発業務に従事したことのある方なら誰もが同意するでしょうが、「チームの人数が2倍になっても、チーム全体の生産量は2倍にならない」ということは常識です。状況によっては、チームの人数を増やしても生産量はほとんど変わらないか、むしろ悪化することさえあります。
人間が組織を作るときの複雑さは、人数の2乗に比例します。例えば、チームが2人なら、その2人の間の関係性（＝コミュニケーションライン）は1つしかありません。チームが10人いれば、チーム内の2人間の人間関係は10×9÷2＝45も存在することになります。この例では、チームメンバーが5倍になると、2人間のコミュニケーションラインは45倍になっています。このように、メンバーが増えれば増えるほど、メンバー間の情報流通が飛躍的に複雑化し、どこかで制御ができなくなります。
当然、このようなことは何千年も前から変わらない人類社会の抱える構造的な問題であり、解決策は確立されています。それが組織を縦割りにして上意下達のコミュニケーションを行う「官僚制」の導入です。マネジャーからメンバーへの「上から下」の連絡や、メンバーからマネジャーへの「下から上」の連絡、の2つに業務上のコミュニケーションを集約し、メンバー層同士の横の連絡をなくせば、コミュニケーションラインは少なくて済みます。先ほどの10人チームの例では、1人のマネジャーから残る9人のメンバーへのコミュニケーションラインを立てるだけなら、関係性は9本で済み、それまでの45本もの連絡体制と比べて大幅にスリム化されます。
実はこの「9本」というコミュニケーションラインが、10人のチームにおける最少のコミュニケーションライン数になります。このことを説明しましょう。10人のメンバーを1人のマネジャーと、3人のチーム3つに分け、その3つのチーム内で1人をリーダーに任命します。このとき、マネジャーからチームリーダー、チームリーダーからメンバーへのコミュニケーションラインを引いていくと、最終的なコミュニケーションラインは9本になり、これは、マネジャー1人とメンバー9人の際のコミュニケーションラインの数と変わりません。組織をどの粒度でどのように階層化しても、上下のコミュニケーションラインに集約すれば、コミュニケーションラインを最少規模に抑制できます。
人間社会の歴史は、集まった人間を階層的な組織に編成し、コミュニケーションラインを最少化することでうまくまとまってきたのであり、この法則は今後も変わることはないでしょう。
このように、縦の階層によってコミュニケーションラインを最少に抑える組織構造が「官僚制」です。あらゆる国や企業が最終的に官僚制を採用するのは、それが最もコミュニケーション効率が良いからです。一般的に「官僚主義的」という言葉は悪い意味で使われますが、実際には官僚制は、歴史の荒波を乗り越えてきた、人類史的な意義のある有益な仕組みです。
しかし、官僚制にも弱点があります。それは、現場のメンバー同士が臨機応変に協力することが難しい縦割りの体制を採用するために、スピーディーに物事を動かすことや、変化し続ける状況に柔軟に対応することが難しくなる、という点です。「その話はうちの部署では対応できません」といったセクショナリズムが多かれ少なかれ生じてしまうため、組織横断的に対処するのが難しく、何をやるにも上下のコミュニケーションラインを通してしか話が進まないため、決裁や承認に時間がかかります。
この弱点を解消するには、原理的には、現場のメンバー層に近いところでコミュニケーションラインを増やす以外に解決策はありません。
例えば、フロントエンドエンジニアとバックエンドエンジニアが常にマネジャーを介してコミュニケーションを取れば、チーム全体のやり取りの経路はシンプルになりますが、何をやるにもいちいちマネジャーを通すので時間がかかります。
この場合、フロントエンドエンジニアとバックエンドエンジニアが互いに密にコミュニケーションを取ってすり合わせれば物事はずっと早く進みます。ただし、このようなことを許容するとチーム内のコミュニケーションが複雑化し、なにか問題が起きたときにマネジャーがそれを把握し解決するのが遅れます。マネジャーを通さないコミュニケーションが増えれば、チーム内の他のメンバーに対する情報共有も遅れてゆき、チームが自らの状況をつかむのが難しくなります。
結論から言えば、チームの人数が一定であるとき、コミュニケーションの効率を最大にすると速度や柔軟性が失われ、その逆に、速度や柔軟性を重視してコミュニケーションを複雑にすると今度はチーム全体のコミュニケーション効率が犠牲になります。
アジャイルな組織文化は、昨今のソフトウェア開発の世界では半ば無条件に良いものとされがちな風潮がありますが、実際にはチーム内のこまごまとした調整、合意形成などに相当な時間が取られ、思っているほど効率的ではない面があることには注意が必要です。実際、アジャイル型の開発組織が主体の業歴の浅いSaaS（ソフトウェア・アズ・ア・サービス）企業と、業歴の長い受託開発中心のSIer（システムインテグレーター）を比べると、1人当たり売上高に大きな差はありません。アジャイルだから生産的で、ウオーターフォールは非生産的、といった考えは単なるステレオタイプに過ぎません。
このようなことをトータルで考えた上で、私たちグラファーが生産性を向上するために選択した手法は、「チームの人数を減らし、一人ひとりを多能工化する」というものです。
これまで述べてきた通り、チームの規模が同じであれば、チーム内の人間同士で交わされるコミュニケーションの効率を全体として大きく変えることは難しく、ウオーターフォールかアジャイルか、という選択によって効率を大幅に上げることは難しいからです。
当社では、一人の開発者が、解決したい課題のヒアリングから要件定義、設計、実装、運用、保守まで開発プロセスの大部分を担当します。またフロントエンド、バックエンド、インフラなどの技術スタックも一人で広くカバーします。このことによって分業の必要性を大きく減らすことで、チームの人数を減らし、その結果、チーム内でのコミュニケーションや調整、待ち時間のほとんどをなくすことができます。
フルサイクル・フルスタック開発の実践例として、2025年11月に当社が発表した新プロダクト「Graffer Databridge」の開発体制を紹介します。このプロダクトは、主に食品業界向けに、商品流通の過程で必要になるデータ入力作業を自動化するAIエージェント搭載型のクラウドサービスであり、既に大手企業の現場で本番稼働しています。
プロダクトの立ち上げに当たっては、事業開発担当メンバー1人とプロダクトマネジャー1人の2人で始め、両名がニーズの発見から顧客提案に至る事業開発面に関与しつつ、設計・実装・リリースまでの開発プロセスはプロダクトマネジャーが1人で自ら行いました。その後、プロダクトの初期リリースのタイミングで開発者を1人追加し、合計3人のミニマムな構成のチームとして運営しています（図表0-2）。
開発に着手してから初期バージョンのリリースまでの期間、担当プロダクトマネジャーは全面的にコーディングエージェント（Claude Code）を使い倒し、短期集中で開発しました。初期バージョンの開発までにかかった期間はざっと3週間というところです。
この間のClaude Codeの消費トークン数を担当者に調べてみてもらったのですが、10億トークンを消費しコストは937ドル（1ドル155円換算で14.5万円）となりました。従来であればかなり早くても3人の開発者で3カ月くらいは開発にかかるところ、1人の開発者が、顧客とのミーティングなどの事業開発業務と並行しながら3週間で初期バージョンのリリースまでもっていけたのは、間違いなくAI駆動開発の効能です。
開発期間が短くなることやアサインする人員が少なくなることは、そのままコストの圧縮になります。2人の開発者を追加して3カ月かけて開発するコストと、日本円にして15万円に満たないClaude Codeの利用料では、比較にならないほどのコスト差になります。
AI駆動開発が当たり前になった世界では、1人の開発者が1カ月以内に新規プロダクトを立ち上げるのが普通になります。3人の開発者が3カ月かけて作るという、従来の常識で考えてもかなり高い生産性のチームに比べて、さらに9倍の生産性が実現するわけです。ソフトウェア業界の一般的な開発チームの生産性に比べると、間違いなく数十倍の生産性を達成しているはずです。
本書が提供する「AI武装チーム」の作り方
以上のように「AIを活用したフルサイクル・フルスタック開発（略して「フルサイクルAI開発」と呼びます）」というコンセプトが、AIによる生産性向上効果を最大限に発揮できるものであることを説明してきました。
ただし、このコンセプトは、多くの開発チームの現実の状況とは乖離（かいり）があることも否定できません。グラファーを経営するなかで様々な企業の経営者や開発部門の方と接してきましたが、こうした「フルサイクル・フルスタック」のスタンスを貫いている会社は少ないです。そしてその結果として、AIコーディングツールを導入しても、チームとして期待するような大きな効果を上げられていない企業が多い状況です。
理想としての「フルサイクルAI開発」の概念を理解できても、現状の開発チームをその領域に引き上げて日々の業務を実践することは簡単ではなく、組織文化、行動規範のレベルから解きほぐし、一つひとつ変えていく必要が出てきます。本書は、そうした組織変革の要請に応え、チームとして何をどこから始めるかを丁寧に解説したいと思います。
組織変革の詳細は第3章に記載していますが、その要点は「AIを活用してスキルとリソースを補う、多能工的に動く開発者」をチーム内で増やし、チームにその動き方が定着するのに合わせてプロジェクトマネジメント規模を段階的に縮小していく、という点です。
AIコーディングツールの現状を知り、適切なツールを選択し、導入するだけでも一定の効果があると思うかもしれません。確かに、スキルレベルの高い開発者にツールを与えればすぐに生産性が上がる面はあります。他方で、品質が担保されないAI生成コードを大量に生成するような開発者が出てくると、そのコードをレビューし、品質を担保するための工数がこれまで以上にかかる場合もあります。そうなってしまえば、AI導入がかえってチームの生産性を引き下げかねません。
単なるツール導入に視野を限定するのではなく、AIを用いた開発手法やツールに関する継続的な情報収集、チームとしての目標設定の仕方やチーム内コミュニケーション、そして何よりAIを活用する前提での適切なワークフローを構築し、チーム内に定着させていくことが不可欠です。そうした取り組みは一朝一夕ではいかないものの、組織として努力を続ければ必ず定着させることができます。
当社に入ってくるエンジニアは、必ずしも全員が「フルサイクル・フルスタック」の開発をしてきたメンバーではありません。フロントエンドやバックエンド、SREなど、これまでのキャリアで各自が担当してきた専門は様々で、メンバーにより強いところ、弱いところがあるのも当然です。そのような状況から、当社に入社し様々な技術スタックに触れながらソフトウェア開発を行い、顧客の課題解決を行う経験を積むことで、各自が担当範囲を拡大し、フルサイクル・フルスタックの開発をほとんどのメンバーが実践しています。
もちろん、従来型の分業制に慣れていたメンバーにとって、最初はギャップが大きいはずです。当社の提唱する手法を採用する場合、エンジニアにはこれまで以上に継続的な学習が求められますし、セクショナリズムに陥らず、課題解決のために自分の手を動かすスタンスが必要になります。
とはいえ、このことに何か特殊な才能が必要というわけではありません。ソフトウェア開発は、どこまで行っても人間による人間のための営みです。自然災害などを相手にするものではなく、そこに超自然的な要素は何もありません。ソフトウェア開発とは、人間の意図に沿って作られたハードウェアやソフトウェアの上で、人間が意図したプログラムを構築して所定のニーズを満たす営みに過ぎません。だから、開発の過程でぶち当たる課題のほとんどには、きちんと解決策があります。一部の非常に先端的な領域では解決策がないということもあり得ますが、日常のシステム開発の過程で、課題解決ができないことはまずあり得ません。自分に知識がないことであっても、どこかにその知識はあり、それは書籍やウェブサイトやAIを使うことでいつでも吸収できます。
AIの登場により、私たちはいきおい「一人の天才エンジニアがいればなんでも作れる」「エンジニアは仕事がなくなる」という極論に振れがちです。しかし、私は依然としてチームが協力して仕事をすることの重要性と、それがもたらす価値の大きさはいささかも損なわれていないと考えています。
バックグラウンドの異なる様々な人が集い、チームとして仕事をすることで、多様なニーズを捉え、多様な解決策を考え出すことができます。多くの人間が実際に関わることで、その人たちが様々なステークホルダー（同僚、顧客・取引先、家族や知人など）に影響を与え、そのような影響によって仕事が発展していきます。
AIを用いて個人の生産性を向上させ、それを生かすためにチームの協力の仕方を変えることは、結果的にチーム内のコミュニケーションや調整を減らす効果があります。しかしだからといって、仕事時間のほとんどを「黙々と個人で作業する時間にすればいい」と本書が主張したいわけでは全くありません。仕事を進めるために必要なコミュニケーションを減らすことができたなら、その時間を、新たな価値の創出に向けたブレインストーミングの時間や、顧客に会いに行く時間に使うことができます。
AIによる効率化を進めることで、時間の使い方が変わる―その時間をどう使うか、どう未来に向けて活用するかが、あなたの、そしてあなたのチームの一番大切な選択となります。
【目次】
