組織と開発管理モデル
ウォーターフォールモデルもアジャイルモデルも、その制限は組織の制約とも大きく関係します。そこで、ここでは組織の成長という観点から、その制限や特徴を説明します。
サービスの成長と組織の成長
筆者が経験したいくつかのサービスでは、図11のように成長していきました。
最初のサービス立ち上げ時にはいろいろと分からず、経験者もおらず、混沌とした状態になることがよくあります。このフェーズでは、主に個人の知識や経験に依存し、チームを運営していきます。また、人材も時間も足りないため、組織のルールよりも個人の決定や行動の方が優先される傾向があります。
その中で、サービスの強みを強化していきます。そして、顧客が増えてくると、それらを安定して提供できるようにしていく必要があります。このフェーズになると、他部署からの人材や転職者などを迎え、組織化する必要があります。しかし、この時点では、大きな目的は依然として事業の成功であり、組織は自ずと事業を中心とする組織になります。
さらに事業が成長していくと、業界や専門の知識や経験していない人も入ってくるため、知識や経験の継承も必要になり、機能別組織のほうが管理しやすくなります。例えば、新入社員を迎え入れる場合には事業部制の組織よりも機能別組織のほうがやることが明確化しやすく、迎え入れやすいというのは、納得できるところでしょう。
また、この頃になると事業を取り巻く業界が成熟し始めているケースも多く、機能だけではなく、価格競争にもなってきます。その競争に勝つためにも、各要素の効率化がより一層求められます。ここでも機能別組織での効率化は非常に強みになります。
ここまでの成長過程では組織論として悩むほどの選択肢はあまりありませんが、サービスに新たな差別化を創造したいフェーズで既存の機能別組織のままか、それとも事業部制に変えて取り組むという選択に迫られます。どちらを選択すれば正解というのはありませんが、どちらを選択してもデメリットは生じます。
つまり、このフェーズでのプロジェクトを進める際には、
- 組織最適化のニーズから生じる縦割り管理の必要性
- 新しい価値や意見と取り入れやすくするための横断型管理の必要性
という矛盾したニーズが同時に発生していることになります。組織という前提に立ったときに生じる立場や役割から見た時により適しているウォーターフォール型モデルと、プロジェクトの目的という前提に立ったときに求められる役割から見た時により適しているアジャイル型モデルのいずれも万能ではないことが分かるはずです。
このようなことから生じる制約等を考慮しないまま、全体的に手法を導入してもデメリットだけが目立つようになります。つまり、アジャイル手法を導入する場合には、この組織構造の違いによる影響を十分に考慮する必要があります。
事業別組織のメリットとデメリット
事業別組織とは、組織が事業または、サービス単位に構成されている制度です。組織は同じ事業をさまざまな顧客に対して提供していきます。そのため、図12のように同じ業界での異なる顧客から得られる経験もたまり、それらを元により機能を便利もしくは特徴あるものとして提供がしやすくなり、結果的に、機能面での差別化がしやすくなります。
一方、各社員がカバーする範囲が広がりやすく、また、職種（開発者など）としての専門知識の経験や学習という点では課題が生じてしまいます。
機能別組織のメリットとデメリット
一方、機能別組織とは図13のように「営業部」や「開発部」のように機能ごとに分かれている組織です。一般的に大企業であれば、機能別組織であることが多いと思います。
機能別であれば、各機能（職能）の知識を共有しやすく、また、その知識も事業ノウハウよりも長く活用できます。また、機能ごとの組織なので、組織の効率化が、事業全体の効率化につながり、結果、各社員のスキル計画なども立てやすく、人材育成の面でもメリットが多くあります。
一方、各業界特有の事情や問題解決を取り込みにくいというデメリットもあります。
アジャイルモデルに求める目的
ここまで、サービスの成長プロセス、コスト、組織構造という3つの項目について個別に説明してきましたが、実際には、それぞれが他の項目に対して強い影響を及ぼします。その前提で、改めてウォーターフォールモデルとアジャイルモデルの向き不向きを見てみましょう。
例えば、「ウォーターフォールモデルは大規模開発に向いている」という意味は、機能別組織の人員をプロジェクト内にアサインする場合には、ウォーターフォールモデルが組織構造と矛盾せず計画がしやすいためです。そして、この機能別組織は、サービスの成熟期でより強みを発揮するため、自ずと影響範囲が大きく、結果、大規模開発になる傾向があります。
ウォーターフォールモデルは、組織やコスト等の制約に合わせた管理手法のため、非常に理解しやすい面があります。
一方、アジャイルモデルを導入したいフェーズというのは図14のように2つあります。
個人依存からチームとして機能させるフェーズと、組織が機能別になり、事業特有の課題などに取り組みにくくなったタイミングでの新機能（または新サービス）を創造するタイミングです。
この2つのタイミングではアジャイルモデルといっても、そこで生じる問題や課題などは大きく異なってしまいます。
つまり、図15のようにチームができあがって間もない時期は、混沌の状態をより管理された状態にするためのアジャイルです。
一方、機能別組織ができあがってからのアジャイルでは、異なる縦型組織を横断したコミュニケーションを促進したいという目的があります。例えば、営業部、企画部、広報部、開発部、顧客サポート部のように異なる組織から専任された担当者が1つのプロジェクトに参加した場合に、それぞれの部署の立場や目的を反映しつつも、利害交渉ではなく、対話を成立できるようにするためのアジャイルになります。
最後に
プロジェクト管理では、制約面から考えれば組織構造に適した方に合わせる方が容易ですが、一方で、解決したい問題や課題がその制約自体が原因であるということもあります。組織構造などから生じる課題を解決する場合に、組織構造自体を変えられるならばそれほど悩む要素はないはずです。
しかし、アジャイル管理手法を取り入れたいタイミングでは、既存の状態から新たな管理に向けて変化したい時期が多く、その矛盾を前提に進めなければならない場合が多いと思います。
つまり、プロジェクト内にはウォーターフォールモデルの方が適した課題や、アジャイルモデルの方が適した課題などさまざまな課題が混在しているのです。したがって、それぞれの手法を取り入れながら、デメリットを受け入れつつ、メリットをより伸ばすというやり方を模索するしかありません。
次回はアジャイル管理手法を部分的に取り入れる際に、その意味を理解しつつどのように応用するかという点を紹介します。
