Boost」など、さまざまなカンファレンスを企画・運営しています。BOOKS(コードジン・ブックス)は、CodeZineの連載からカットアップした、開発現場の課題解決に役立つ書籍シリーズです。最後に組織と開発管理モデルウォーターフォールモデルもアジャイルモデルも、その制限は組織の制約とも大きく関係します。そこで、ここでは組織の成長という観点から、その制限や特徴を説明します。筆者が経験したいくつかのサービスでは、図11のように成長していきました。最初のサービス立ち上げ時にはいろいろと分からず、経験者もおらず、混沌とした状態になることがよくあります。このフェーズでは、主に個人の知識や経験に依存し、チームを運営していきます。人材も時間も足りないため、組織のルールよりも個人の決定や行動の方が優先される傾向があります。その中で、サービスの強みを強化していきます。顧客が増えてくると、それらを安定して提供できるようにしていく必要があります。このフェーズになると、他部署からの人材や転職者などを迎え、組織化する必要があります。この時点では、大きな目的は依然として事業の成功であり、組織は自ずと事業を中心とする組織になります。事業が成長していくと、業界や専門の知識や経験していない人も入ってくるため、知識や経験の継承も必要になり、機能別組織のほうが管理しやすくなります。新入社員を迎え入れる場合には事業部制の組織よりも機能別組織のほうがやることが明確化しやすく、迎え入れやすいというのは、納得できるところでしょう。この頃になると事業を取り巻く業界が成熟し始めているケースも多く、機能だけではなく、価格競争にもなってきます。その競争に勝つためにも、各要素の効率化がより一層求められます。ここでも機能別組織での効率化は非常に強みになります。ここまでの成長過程では組織論として悩むほどの選択肢はあまりありませんが、サービスに新たな差別化を創造したいフェーズで既存の機能別組織のままか、それとも事業部制に変えて取り組むという選択に迫られます。どちらを選択すれば正解というのはありませんが、どちらを選択してもデメリットは生じます。新しい価値や意見と取り入れやすくするための横断型管理の必要性という矛盾したニーズが同時に発生していることになります。組織という前提に立ったときに生じる立場や役割から見た時により適しているウォーターフォール型モデルと、プロジェクトの目的という前提に立ったときに求められる役割から見た時により適しているアジャイル型モデルのいずれも万能ではないことが分かるはずです。このようなことから生じる制約等を考慮しないまま、全体的に手法を導入してもデメリットだけが目立つようになります。アジャイル手法を導入する場合には、この組織構造の違いによる影響を十分に考慮する必要があります。事業別組織のメリットとデメリット事業別組織とは、組織が事業または、サービス単位に構成されている制度です。組織は同じ事業をさまざまな顧客に対して提供していきます。そのため、図12のように同じ業界での異なる顧客から得られる経験もたまり、それらを元により機能を便利もしくは特徴あるものとして提供がしやすくなり、結果的に、機能面での差別化がしやすくなります。図12:事業別組織のメリットとデメリット一方、各社員がカバーする範囲が広がりやすく、また、職種(開発者など)としての専門知識の経験や学習という点では課題が生じてしまいます。機能別組織のメリットとデメリット一方、機能別組織とは図13のように「営業部」や「開発部」のように機能ごとに分かれている組織です。一般的に大企業であれば、機能別組織であることが多いと思います。図13:機能別組織のメリットとデメリット機能別であれば、各機能(職能)の知識を共有しやすく、また、その知識も事業ノウハウよりも長く活用できます。事情や問題解決を取り込みにくいというデメリットもあります。アジャイルモデルに求める目的ここまで、サービスの成長プロセス、コスト、組織構造という3つの項目について個別に説明してきましたが、実際には、それぞれが他の項目に対して強い影響を及ぼします。その前提で、改めてウォーターフォールモデルとアジャイルモデルの向き不向きを見てみましょう。「ウォーターフォールモデルは大規模開発に向いている」という意味は、機能別組織の人員をプロジェクト内にアサインする場合には、ウォーターフォールモデルが組織構造と矛盾せず計画がしやすいためです。ウォーターフォールモデルは、組織やコスト等の制約に合わせた管理手法のため、非常に理解しやすい面があります。アジャイルモデルを導入したいフェーズというのは図14のように2つあります。図14:アジャイルモデルを導入したいフェーズ個人依存からチームとして機能させるフェーズと、組織が機能別になり、事業特有の課題などに取り組みにくくなったタイミングでの新機能(または新サービス)を創造するタイミングです。この2つのタイミングではアジャイルモデルといっても、そこで生じる問題や課題などは大きく異なってしまいます。できあがってからのアジャイルでは、異なる縦型組織を横断したコミュニケーションを促進したいという目的があります。サポート部のように異なる組織から専任された担当者が1つのプロジェクトに参加した場合に、それぞれの部署の立場や目的を反映しつつも、利害交渉ではなく、対話を成立できるようにするためのアジャイルになります。図15:アジャイルモデルを導入したいフェーズ最後にプロジェクト管理では、制約面から考えれば組織構造に適した方に合わせる方が容易ですが、一方で、解決したい問題や課題がその制約自体が原因であるということもあります。組織構造などから生じる課題を解決する場合に、組織構造自体を変えられるならばそれほど悩む要素はないはずです。アジャイル管理手法を取り入れたいタイミングでは、既存の状態から新たな管理に向けて変化したい時期が多く、その矛盾を前提に進めなければならない場合が多いと思います。プロジェクト内にはウォーターフォールモデルの方が適した課題や、アジャイルモデルの方が適した課題などさまざまな課題が混在しているのです。したがって、それぞれの手法を取り入れながら、デメリットを受け入れつつ、メリットをより伸ばすというやり方を模索するしかありません。次回はアジャイル管理手法を部分的に取り入れる際に、その意味を理解しつつどのように応用するかという点を紹介します。NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Technologies。執筆コミュニティ「WINGSプロジェクト」代表。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。NEW1DMM.comの施策から見る、事業をむしばむ「技術負債」への処方箋──リファクタリングの「言語化」でインシデントを予防2企業の7割超が「2025年の崖」を理解していないことが明らかに。12:00法務担当者、6割超が今後業務で「生成AIを使用したい」と回答。新着記事一覧を見るイベント今後の予定を見るCodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。