実践！ 自己組織化プロジェクト：自己組織化プロジェクトの育て方（3）（3/4 ページ）

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

実践へのアイデア 〜混沌としたプロジェクトをいかに「カオスの縁」へ導くか？

　さて、実際のプロジェクトへの適用アイデアの話に移りましょう。

プロジェクトで押さえるべき「自己組織化」推進作業のプライオリティは？

　プロジェクトにはさまざまな「粒」が規定できますが、プロジェクトで扱う「粒」の優先度となるとどれも同じではなさそうです。

これまでの経験による感覚値でしかないのですが、おおむね「粒」に対する作業の重要度合いは以下のような順番になっているように思います。

• 1位　シンプルなインターフェイスを用意する
• 2位　データを一元化する
• 3位　要件の粒度を合わせる

　そもそも、シンプルなインターフェイスにしないとデータが集まらないので、2位のデータの一元化などできず、結果、全体が複雑になってしまいます。障害管理用の入力項目が山ほど存在するため、結局入力されたデータが間違っていたり、入力されなくなってしまうのはその典型的なパターンです。そこで、1位となるシンプルなインターフェイスの実現を手始めに行ったうえで、「自己組織化」で重要な「データの一元化」を推し進める、というやり方をします。

　実際、自分がマネージャとしてプロジェクトに参加するときは、シンプルなインターフェイスを定義して、それを順番に増やしていきます。最初の一歩となるシンプルなインターフェイスは、大抵、「朝・夕に15分行う、スタートアップ／ラップアップミーティング」です。まずはここから始めて、徐々に作業や、作業の結果などをシンプルな粒に落とし込んでいく、というのが王道パターンでしょうか。

　3位に、「障害」や「課題」ではなく、「要件」がきているのも理由があります。大抵のプロジェクトでは、「障害」や「課題」といった問題点を粒として集めることは、それほど違和感なく実施していることが多いです（それすら行えていないプロジェクトもまれに存在するようですが）。しかし、「要件」という「粒」をうまく集められているプロジェクトはなかなかありません。

　「仕様変更」だけでなく変更前の「要件」をきちんと粒として集めているかがポイントです。

　私見ですが、UMLの中で、要件の粒である「ユースケース」がなかなか一般化しない理由は、この「ユースケースをシンプルな粒として集める」ことが、システム開発の現場でなかなか難しいためではないか、と思っています。

　「要件」の「粒」というのは、プロジェクトにとって最も根幹となる単位であり、そのシステムが生き続ける限り、未来永劫その「粒」の単位であり続けます。あらゆるところで使われる可能性があるこの「要件」の粒を、うまい単位に切り分けることが、実はとても難しいのです。適当に「粒」として切り分けてしまうと、「帯に短したすきに長し」という状態を引き起こしてしまいます。

　この作業は、いまも毎回、自分の頭を悩ませるところです。ただ、ある程度確信を持っていえるのは、この「要件」の切り出しは、アプリケーションアーキテクチャがどのようにデザインされているのかに大きく依存するということです。「要件」だから、業務的な切り分けが分かっていればよいというのではなく、利用するアーキテクチャにとって自然な分割、テストや仕様変更がしやすい粒、といった視点を相当に意識する必要があるようです。

　以上の順位は、常にこの順番で正解ということではありません。状況に応じて順位は変化します。常にその場の環境に適応したやり方で、自己組織化を目指す必要があります。

プロジェクトで自己組織化を促すための実践ポイント

　ほかにもさまざまなアイデアをプロジェクトごとに考えては試しています。

（1） 意識をさせない

→自己組織化とか、アジャイルといった言葉を使わない

　初めてのメンバー、特に火を噴いて大変なことになっているプロジェクトのメンバーは、「自分が悪かったと責められる・否定される」ということに過敏になっているものです。そんなところで、いきなり「自己組織化させないと駄目だ！」などといったら、火に油を注ぐことになりかねません。そのような場合、できるだけ慎重に、何も特別なことはしないんだ、ということをわざわざアピールすることもあります。

（2） 急がば回れ

→一度にやらず、できそうなものから手を付けていく

　ついつい、さまざまなものを「粒」にしようとして、一度に多くの新しい概念やツール、プロセスを導入しがちです。これはそもそも“シンプルであるべし”という自己組織化のルールに反しています。通常、人間が何とか対応していける変化は、一度に1つか2つが限度でしょう。こなれていない、複数のプロセスを押し付けて、何もフィードバックしなかったりすると、たちまちカオスの状態に陥ります。

（3） 定着化の工夫を

→ちょっとしたことですぐカオスになってしまう

　一度に1つか2つ程度の変化を導入したら、その結果を必ずフィードバックすることが肝心です。特に結果を、いま流行の「見える化」してフィードバックすると、非常に効果的です。

　例えば、一元化して集めた進ちょくの情報から、進ちょくダッシュボードとしてチーム別EVMSグラフや、チーム別バーンダウンチャートを自動作成して提供します。これらの見える化情報は、一度進ちょく情報が一元化されると非常に簡単に抽出できるたぐいのものです。集めるだけで満足せず、いかに早く（集めたその週からが理想です）チームへフィードバックするのかを常に考えている必要があります。

チーム別EVMSグラフの一例a （クリックすると拡大）

チーム別バーンダウンチャートの一例

バーンダウンチャートとは、個数で管理できるようなものの予定個数と実績個数をグラフ化したものです。青色のラインが「予定の完了個数」を示し、オレンジ色のラインが「実績の完了個数」を示します。予定と実績の乖離度合いを一目で把握できる優れたグラフです。アジャイルソフトウェア開発の「スクラム」で取り上げられ、活用されています。

チーム別EVMSグラフの一例b （クリックすると拡大）

（4） 自分で決めさせる

→トップダウンで決めるのではなく、ボトムアップで決めてもらう

（1）につながりますが、「自己組織化！」と声高に叫んで強いるのではなく、チームメンバーそれぞれから、自然に自己組織化プロセスを決めてもらうことが理想です。そのために、回りくどいと思っても、まずは問題点の洗い出しやヒアリングから始めることが重要です。

　火を噴いて大変なことになっているプロジェクトでは、昼夜が逆転していることがよくあります。ヒアリングをすると、ほとんどのメンバーが昼夜逆転を問題視していることが分かるはずです。この事実をミーティングで伝え、どのようなルールにすればよいのか、メンバーに決めてもらいます。プロジェクトマネージャやリーダーの役割は、このメンバー自身が作ったルールを、メンバー自身に守ってもらうためのサポートをするのみです。もちろん自分たちで決めたことは、きっちりと守ってもらいますが。

（5） 良きパートナーを使いこなせ

→ツールを有効活用することの重要さ

　アジャイル開発で、テストファーストやデイリービルドを実現するためのツールが必須であるように、プロジェクトをスムーズに自己組織化させるために、ツールを活用することは非常に重要です。

　第1回目「プロジェクトを管理しないという発想」で紹介したとおり、アクセンチュアではプロジェクト用ポータルとして、WSS （Windows SharePoint Services）をよく利用します。このアプリケーション自体、利用操作が非常にシンプルで使いやすいものなのですが、このツールだけあれば済むというわけではありません。併せてよく利用するのが、ソースコードや成果物ドキュメントの構成管理を行うソフトであるVSS （Visual Source Safe）です。それぞれを別々のものとして利用するのでは芸がないので、これらをAPI経由で連動させる、マクロを組み込んだExcelを作成し、構成管理と自動連携するリリース管理台帳とします。この台帳ExcelをWSSで一元管理することで、東京の設計者と大連の開発者からは、Excelを通して、WSS（ポータル）とVSS（構成管理）があたかもシームレスに連動し一元管理されているようにみえます。

　また、そもそもこういったソフトウェアだけがツールとして有用なわけではありません。自分が必ず利用するのは、液晶プロジェクターとホワイトボードです。オンサイトチーム内のコミュニケーションおよびディスカッションのツールとして、もはやこの2つは欠かすことができません。液晶プロジェクターやホワイトボードは費用の問題や、スペースの問題からあきらめてしまうことが多いかもしれませんが、工夫をすれば何とかなるものです。なくてもいいか、と考えずに、プロジェクト必須のツールとして地道に交渉することも重要です。

　 ちなみに、ホワイトボードは、コクヨから販売されている持ち運び式のシンプルなホワイトボードを愛用しています。安くて薄く、軽いので、ミーティングがある場所に持っていって即席ブレインストーミング用ツールとして使ってもいいし、壁に簡単に張り付けることもできます。大きい場合はカッターで切ることができるので、使いやすい大きさに切り分けて使うこともできます。スタートアップミーティングでは、チームごとにこのホワイトボードを持って集まり、「昨日やったこと」「今日やること」「問題になっていること」を各人書いていきます。ホワイトボードに明示的に宣言することで、作業の「粒」を共有できるだけでなく、自らの頭の中も整理される効果が期待されます。

　このように、アナログなツールでも、時にはものすごい効果を発揮するものはまだまだあると思います。「システム化されていないためできない」「お金がないから買えない」と思うのではなく、「どうやったら、同様の効果を期待できるのか？」ということを考えて工夫することが肝心です。WSSが使えなければ、フリーのWikiや社内Blogを立ち上げてもいいし、ExcelやAccess、あるいはポストイットと壁紙を有効に利用することで代替できるかもしれません。その際、

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

という自己組織化のルールが1つの指針になるはずです。

（6） 教育だって繰り返し

→常にPDCAサイクルを意識させて見積もりをするプロセスを徹底

　最後に、教育という観点を見てみましょう。タスクの「粒」をそろえるための重要なポイントは、

1. （計画）どうなったら完了なのか？ ということを明確にする
2. （計画）そのタスクがどの程度時間がかかるか？ という見積もりを立てる
3. （実行）タスクを実行する
4. （チェック）実行後に、そのタスクの見積もりは正しかったのか？ タスク実行の際に問題はなかったのか？ といったことを検証し、対応案を検討する
5. （アクション）検証で考察した対応案を実施する

という、いわゆるPDCAサイクル （計画［Plan］／実行［Do］／チェック［Check］／アクション［Action］）を、すべてのタスクという「粒」の統一インターフェイスとして利用することです。

　作業が混乱する多くの場合、このプロセスの中の「計画」と「チェック」がおざなりにされて、がむしゃらに「実行（Do）」だけが行われています。そこで、若手のスタッフや新人がプロジェクトメンバーとなったときは、必ずこのプロセスを体に染み込むまで繰り返させることにしています。

　具体的にどうするかというと、「提案書のグラフを作る」というタスクをお願いするときに、まず、「どういうものを作成したらこのタスクが完了なの？」という質問をして、完了条件を明確にさせます。次に「これは、どれくらいでできる？」という見積もりを本人にさせます。大抵、ここでかなりいいかげんな見積もりが出てきます。そこで、次がポイントなのですが、「どういうロジックでその見積もりを計算したの？」と聞きます。この、「論理的な仮説を立てて、見積もりを行う」ということこそが、すべてのタスクの「粒」をそろえるための、いわば、標準インターフェイスといえるでしょう。「仮説検証型プロセスを経たタスク」という、シンプルにそろった「粒」が集まっていくことになります。