プロジェクトを管理しないという発想：自己組織化プロジェクトの育て方（1）（4/4 ページ）

[山根圭輔，アクセンチュア]

4. いきなり話がでかくなる〜カオスと秩序の間には

　それでは、『粒同士のネットワーク爆発が、複雑で、手に負えない問題プロジェクトの引き金になっている』と書きましたが、粒同士が無秩序につながっている状態から、整然と秩序を保ってつながった状態にするために、高いハードルを越えるしか道はないのでしょうか？ 変化が激しい分野はどうすればいいのでしょう？

　もう1度、図を見てみましょう。

　いままで、混沌とした無秩序の状態と、整然とした秩序の状態のみ注目していましたが、その間はいったい何なのでしょうか？ 実は、まさにこの中間状態こそ、驚くべき可能性を秘めているということが、近年、プロジェクト・マネジメントとはまったく異なる生物科学や社会学、コンピュータ科学の分野などから次々に明らかになりつつあるのです。

　混沌のことをカオス、といいます。そう、ひと昔前、一世を風靡した『カオス理論』のカオスです。このカオス（混沌）と秩序の中間点であるから、この状態を一般に『カオスの縁』といいます。

『カオスの縁』でプロジェクトは『自己組織化』する

　プロジェクトをさまざまな『粒々』が無秩序につながって混沌とした状態から、ほんのちょっとだけ『カオスの縁』に動かしてやること。ランダムで無秩序な状態でなく、最適化された完全な秩序でもない状態にすること。これができると、プロジェクトにいったい何が起こるのでしょうか？ 結論からいうと、プロジェクトが『自己組織化』します。この記事のタイトルである、聞き慣れない言葉、『自己組織化プロジェクト』はここに由来します。

　『カオスの縁』にプロジェクトを動かしてやること、なぜ『自己組織化』するのか、ということを、次回以降、さまざまな例を紹介しながら説明していこうと思います。ただし、その前にこの聞き慣れない『自己組織化』という言葉を説明しなければなりません。

5. 『プロジェクト』に対する新しい視点〜自己組織化プロジェクト〜

　世の中は『プロジェクト』に満ちあふれています。プロジェクトを簡単に定義してみましょう。

• 始まりと終わりがあること
• 目的があること
• それがルーチンワークでないこと

　大まかにいって、これがPMBOKなどでいわれる一般的なプロジェクトの定義でしょう。この定義に当てはまるものは、何もシステム開発プロジェクトだけではなく、旅行やダイエットだって立派なプロジェクトの1つです。

　ここで、ダイエットを例に挙げましょう。目的はズバリ『夏までに5キロやせること！』です。始まりはいま、終わりは夏です。もちろん、ダイエットなどルーチンワークとして続けたいはずもなく、れっきとしたプロジェクトです。

　例によって、ダイエット・プロジェクトに登場するものを『粒』として挙げていきましょう。朝、昼、晩の食事はイベントとしてそれぞれ数えられる『粒』です。食事メニュー自体もそれぞれ『粒』として挙げられるでしょう。

　普段はこの粒同士の連携をコントロールしていくことで、「5キロやせる！」という目的に近づいていきます。たまに、『パーティーでイタリアンを食べる』なんていう、突発的イベント（＝『粒』）が発生する場合もあります。全体のバランスに応じて判断しなければなりません。

　ダイエット・プロジェクト中盤で、「ダイエットのためには、食べ物をコントロールするより、代謝を良くするため筋肉を付けた方がいいらしい」という情報が入ったとします。これは環境の変化ですね。目的が『3キロやせたうえで、代謝を上げて筋肉を付ける』に変わります。今度は筋トレという『粒』がプロセスの中心になります。

　このダイエット・プロジェクトが成功するか、はなはだ疑問ですが、「『粒』同士の関係をコントロールすること」、これこそがプロジェクト管理（マネジメント）として行っていることにほかなりません。プロジェクト管理（マネジメント）の本質といっていいでしょう。

でも、『プロジェクト管理（マネジメント）』って本当に必要か？

　では、「『粒』同士の関係をコントロールする」ことは、本当に必要でしょうか？ 普通に考えると、当然必要に思えます。『粒』同士の関係性が無秩序になると、問題プロジェクトになってしまいます。何らかのコントロールをして、一定の秩序を保つ必要がある気がします。

　しかし、もし『粒』自身が、ある程度秩序だって関係性をコントロールできたらどうでしょうか？ 無理な話ではないでしょう。開発プロジェクトの『粒』は人であったり、プログラム・コンポーネントであったりするので、「プロジェクト管理（マネジメント）」というコントロールがなくても本来動けるものです。むしろ、『粒』が多くなり、勝手に連携しすぎると、もはやプロジェクト管理としてコントロールすることが不可能になるということは、『粒』のネットワークが指数関数的に増えていくことを示した、2章を見ても明らかです。そこで、プロジェクトを管理（マネジメント）することで、プロジェクト自身をコントロールするという方針から、プロジェクトを管理しなくても、『粒』自身が秩序だっていくように仕向ける、という発想の転換をしてみます。

　『粒』自身（＝自己）が勝手に秩序を保つ（＝組織化する）プロジェクト、これこそが、『自己組織化プロジェクト』です。自己組織化プロジェクトでは、『粒』をコントロールするのではなく、コントロールの必要ない状態にすることがポイントです。もちろん『自己組織化』という概念は、プロジェクト管理という1分野にとどまりません。『自己組織化』の具体例は、とても興味深いものなので、次回説明したいと思います。

大火事プロジェクトで自己組織化を促すために具体的にやったこと

　話が大きくなり過ぎたので、ここで最初に戻りましょう。私が大火事プロジェクトで自己組織化を促すという実験を行った際に実行したことを以下に列挙します。

• 朝は遅刻厳禁：朝バラバラに出社して、深夜まで仕事をする、という習慣をやめさせました
• 朝のスタートアップミーティングと夕方のラップアップミーティングの実施：定刻に始まり、きっかり15分で終わる朝／夕のチームミーティングを、1日も漏れずに行うようにしました
• WSS（Windows Sharepoint Services）を導入し、情報を一元化：WebポータルアプリケーションであるWSSを導入して、情報を一元管理しました。進ちょく／仕様／課題／障害管理データベースはここに作りました
• 進ちょく／仕様／課題／障害管理で必要とされる項目を必要最低限に：複雑になりがちなこれらの管理情報項目を大幅に削減しました。進ちょく率などは、85％完了、といった細かな管理を一切やめ、未着手（0％）、作業中（50％）、完了（100％）、中止のみとしました
• 進ちょく／仕様／課題／障害管理で必須項目はすべて最新であるように徹底：管理情報項目を最低限のものにする代わり、それらの項目は絶対に漏れがなく最新ステータスであるよう、徹底しました
• 課題／障害管理データベースに、どんな問題でもとにかく起票するよう徹底：課題や障害の起票ルールを最低限とし、とにかく起こったことはすべて起票するように全員に徹底しました

　このリストの上の方は、アジャイル開発の1つであるXPで有名なプラクティスと同じです。リストの下の方は、ちょっと変な感じがするでしょうか？ このほかにもいろいろと行ったプラクティスはありますが、これらはすべて3つの目的を意識して設定しています。それは、

1. 大きさのそろった『粒』をできるだけ増やすこと
2. 『粒』と『粒』との連携は可能な限りシンプルにすること
3. 『粒』と『粒』との連携方法に例外をなくすこと

この3つです。私は、プロジェクトの最中、この3つを実現するためにはどうすればよいか、ということだけにほぼ集中していました。それ以外のことは、自己組織化したプロジェクトチームが自ら解決していったことになります。

　そして、大火事で手の施しようがない状態からわずか4カ月間で、優良プロジェクトとしてカットオーバーすることができました。『粒』が多くて複雑になったのが問題の原因なのに、なぜわざわざ『粒』を増やすのか？ など疑問に思うところも多いのではないでしょうか？ 次回は、『カオスの縁』『自己組織化』『（粒が）多いことは違うこと』というキーワードを中心に、この自己組織化プロジェクトの本質に迫ってみたいと思います。