Solution

道具箱の整理

＄引用＄

＄引用元＄
TOP > Solution > 道具箱の整理

はじめに

この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。

私の道具箱

ここ１ヶ月ほど、私的Ｗｅｂサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね〜」と話していたのが、非常〜に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数（アクティブな人）が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。

で、そこそこ長く開発者をやっている私としては、道具箱（引き出しとも云う）もあり、ようやく最近になって全体像が繋がってきました。どうせならば、もっと広い視野でビジネスの枠を超えて、「私がやりたいことができるプロジェクトを作る場合には、どういう道具立てが必要なのか」、という形でまとまってきています。

羅列すると、 な感じで、常に頭にいれておきます（いれておきたい）。

ストーリーカード

ストーリーカードは、アジャイル界隈（XPやスクラム）で使われる、仕事の単位を表す手法ですが、これはバーンダウンチャートと組み合わせることによって、進捗度を知るための便利な計測装置になります。

進捗を測る場合には、 なんてことをやりますが、ストーリーカードの場合は、 ということで進捗の度合いを測ります。手元に積みあがってくるカードが終わった数、まだ終わっていないものは壁に貼ってある／並べてある、という感じですね。

カードにすると便利なところは、壁に貼れるところです。カードを貼るときに、上に置けば優先順位が高く、下に置けば優先順位が低い、ということが直感的に分かります。

で、カードを使う場合、貼れる壁があったり、開発者が同じ部屋にいたりすればいいのですが、そうもいかない場合が多いです。こういう場合は、電子化して WEB で閲覧できるようにするのを、真っ先に考えると思いますが、欠点も多いことを留意してください。
おそらく、１番目と２番目は、将来的に壁に大きなディプレイを貼ることで解決できそうですが、３番目と４番目のような物理的な量を把握するのに、電子化は向いていません。電子化してしまうと、一列にリスト化されてしまうために、数を気にしなくなってしまいます。

その辺りの、「快感」や「切迫感」を感じるためには、ある程度「手作業」的な部分を残しておいたり、「完了」という文字を入れたりします。数だけを比較するのであれば、バーンダウンチャートを使って進捗度を確かめるという方法もあります。
いずれにせよ、ストーリーカード方式を使う場合には、そういう物理的な面を強調するものを入れたほうがうまくいきます。

で、カードに何を書くのかというと「仕事」を書きます。経験上ですが、１枚のカードには２，３時間で出来上がる仕事に制限します。多くても１日以内で終われる仕事に分割します。これは、朝来たらカードを１枚（数枚）取り、終わったら壁や棚に返していくという流れにするためです。
先の進捗度合いにも関係しますが、１枚のカードを数日抱えてなかなか終わらない、というよりも、２，３枚のカードを１日で終えて帰る、という「達成感」が得られます。
このあたり、FDD では、機能単位（２，３日単位）に分割するのと、ちょっと違うところです。

仕事の単位は、明確に完了を示せるものがよいでしょう。たとえば、「○○の機能を完成させること」という漠然とした書き方ではなく、「○○の機能を××に組み込み、動作させて××が出力されること」というような形です。「完成」という曖昧な言葉よりも、ユニットテスト風に、何を完成させるのか、という具体的な部分に絞ります。そうすることで、完了がはっきりするし、それぞれのカードの仕事量に粒が揃うことになります。これは、オブジェクト指向のクラスの粒度を揃えることと似ています。

ストーリーカードは、物理的なカードが原則ですが、物理的な席が離れていたり（他会社との共同作業）カードの進捗状態を把握するためには、Excel などを使っても構いません。ただし、「仕事を終えた！」という感覚を保つために、「完了日」を入れたり「完了」の文字を入れたりすると、達成感が得られます。

これは、Excel を利用したストーリカードの例です。セルが小さくなるので、普通のカードよりも情報が少なくなりがちですが、作業を細かく分けておけば、それほど気になりません。

これは、wiki を使ったストーリカードの例です。wiki の場合、１枚のページが多くなると閲覧に時間がかかるのが難点ですが、複数の人達が手軽に書き込みができるよい方法です。

バーンダウンチャート

進捗管理については、ツールがいくつかありますが、一般的なのは、MS Project のような PERT 図やガントチャートが使えるものでしょう。ガントチャートの場合には、前後のタスクの繋がりがわかり、いわゆる「クリティカルパス」を見つけることにより、工期の最短期間が分かるというメリットがあります。。。と情報処理試験的に言えばそうなのですが、経験から言うと、いわゆる大規模開発のウォータフォール方式（協力会社が数社いたり、ハードウェアの設定が含められている場合）には有効に働く可能性があるのですが、５人以下のアジャイル形式のソフトウェア開発には、あまり向きません。というか、進捗の遅れや進み具合によって、ガントチャートを改変する手間が増えてしまい、管理工数がオーバーヘッドになって無駄が多くなります。

このあたりは、 に集中したほうが、下手な管理工数が減ります。

MS Project 等の進捗管理では、「タスクの繋がり」と「進捗度合い」の２つの情報が入ってしまっているために複雑になっています。なので、「タスクの繋がり」はストーリーカードで押さることにして、「進捗の度合い」のみを取り出し、バーンダウンチャートとして見えるようにするのがベターだと思います。

↑は、とあるプロジェクトのバーンダウンチャートです。
進捗度合いは非常に簡単で、ラインよりも上が「遅れ」、ラインより下が「進み」です。この場合は、あきらかに「遅れ」ですね（苦笑）。
ここでのカウントは、ストーリーカードでも良いし、メソッドの数でも構いません。クラスの数でも、ユースケースの数でもいいと思います。要は、「数が勘定できる」ということと、それぞれの要素（カードなど）の粒が揃っていることです。粒は正確に揃える必要はありませんが、偏差は小さくしておきます。例えば、１枚のストリーカードでかける工数は、１時間〜８時間（１日）、という形で制限しておきます。
このあたりの、粒度を揃えておくと、（検証してはいませんが）納期の遅延確率がわかります。デマルコ著「熊とワルツを」に出てくる、リスクの発生確率の計算と似た結果が得られます。理論的には、アーンドバリュー分析と似た形と思われます。

さて、この遅れているプロジェクトを納期に間に合わせるためには、どうしたらよいでしょうか？　いくつかの方法がありますが（駄目な方法は「人月の神話」で言及されている通り）、機能削減をしてみます。


↑どの位の機能（カードの数）を削減すれば間に合うかと云えば、ということで、補助線を引いたものです。だいたい、このペースで開発が続くのであれば、４０枚ぐらいのカードを減らせば、完了する、という予想が立ちます。

バーンダウンチャートが有効な範囲ですが、最低限 50 程度のタスク（カード）はないとうまくいきません。例えば、10 個のタスクでバーンダウンチャートを引いても、ぶれが多くて意味がありません。チャートは、毎日眺めるのであれば、タスクの粒度は、１日以下にしないと誤差が大ききなります。毎週眺める、という進捗会議風にすることも可能ですが、スクラムやＦＤＤから考えると、１週間毎に進捗管理する（遅れが発覚する）のでは、対策を練ることができません。なので、進捗の観察間隔とあわせていくのが妥当でしょう。
タスクの上限数は、１万以上でも大丈夫そうです。勿論、１万のタスクを抽出するのが大変でしょうが。思うに、初期段階で、１万のタスク数を想定し、具体的なタスクは千程度を書き出し、進むごとにタスクを１万になるまで加えていってもぶれは少ないでしょう。

進捗度合いの吸収については、「プロジェクトバッファ方式」がよいと思いますが、このバッファ分（タスクのばらつき）は、あらかじめバーンダウンチャートに吸収されてしまいます、、、と私は思います。PERT 形式でクリティカルパスが優先する場合は、プロジェクトバッファ方式、それぞれのタスクが複雑に絡みすぎている場合（分化しづらい場合）にはバーンダウンチャート方式、という使い分けが妥当だと思います。

ユニットテスト

ユニットテスト（単体試験）は、JUnitから始まる繰り返し試験をするための道具です。4年前ぐらいから、ユニットテストを使っているのですが、肝な使い方としては、
になります。

ユニットテストを活用する以前は、Excel などで単体試験の項目を管理し、ひとつひとつ手作業で確認していました。主に確認用のプログラムを組み、なるべく再帰テストが通るようにはしていたのですが、あまり効率的な方法ではありませんでした。
この「効率的でない」方法を取るということは、イコール「時間がかかる」ということです。仕事ならば何でもそうですが、「時間」＝「作業量」という形で経費が掛かります。なので、単価基準で進捗管理を行った場合、バグが出ること／仕様を変更することは、イコール「修正による再帰テストの発生」を意味し、「時間」＝「経費」がかかる、という思考を意味します。
なので、切迫してしまったプロジェクト（費用や時間が足りない場合）や、経費削減に迫られた場合、ここの「仕様変更やバグの修正による再試験の範囲を狭める」という作業が必須になります。

で、ユニットテストが、プロジェクトの経費削減に貢献する大きな点として、この「再試験の見積もり範囲が不要」、「再試験の実行が非常に少ない」という点が上げられます。

もちろん、仕様変更／障害対応により、該当するテスト項目を追加／修正する必要はあるわけですが、従来のコードが正しく動いているか否かは、もう一度、単体試験のコードを流せばよいわけで、このあたりはコンパイルと同程度に自動化が可能です。

このあたりを踏まえた形で、ユニットテストを導入する場合、注意したい点がいくつかあります。CppUnit, CUnit, JUnit, VBUnit, NUnit と使ってきた私の経験上ですが、
が、シンプルな単体試験を実装するための必須条件のようです。コードとテストコードを同じ言語にするのは、XPのプラクティスにも書かれていますが、自分で自分のコードを試験するためです。例えば、コードは C言語で書いていて、テストコードは Java だとすると、C言語のプログラマと Java のテスターという分離が出来てしまいます。リファクタリングやテストファーストにも関わる話ですが、コードとテストコードの分離（製作と試験の分離）は、フィードバックが遅くなり、明示的なコミュニケーションが発生するために開発効率が落ちますし、情報が欠け落ちます。なので、開発のコア部分としての、コーディング＆単体試験は、同一人物が行うのがベターです。

ただし、新人プログラマのように、まだテストの感覚が薄い開発者に対しては、不足なテストコードを書いてしまうために、同一人物という原則は当て嵌まりません。こういう場合は、上司／ベテランがテストコードを書き、新人がコードを書きます。以前、これを逆にして、上司がコードを書き、新人がテストコードを書いた実例がありましたが、絶対に駄目です。単体試験は、品質保証をする砦として存在させるためには、全体に目が行き届く立場の人（上司／リーダ／顧客など）がテストコードを書きます。

私の場合、テストファーストは、それほど強要しません。しかし、クラスを利用する側からみて、いくつかのテストコードを書くことが多々あります。
DataUser user = new DataUser( cn ); Assert.Equals( true, user.Login( "masuda", "tomoaki" )); Assert.Equals( true, user.IsLogin ); Assert.Equals( "masuda", user.NickName ); Assert.Equals( false, user.Login( "masuda", "" )); Assert.Equals( false, user.IsLogin ); Assert.Equals( null, user.NickName );
という形で、利用側の想定をいくつか書き出します（まあ、これがテストファーストの真髄なんですけどね）。
この書き方は、クラスやメソッドの使い方の説明にもなります。単体のクラスにこだわらず、いくつかのクラスを使ってのテストも、こんな形で書いていきます。 ある意味で、ここのテストコードが複雑になったときは「オブジェクト指向的な分化ができていない」、ということになります。あるいは、利用するときに苦労する＝習得に時間がかかる／難しくてバグを埋め込み易い、という話です（先にある、アスペクト指向、SOA、DI）、も似たような形でしょう）。

あと、何よりも一番の効用は「動かして確認できること」でしょうか。ＸＰの場合、想定でコーディングしているよりも、動くことを大切にするわけです。このあたりは、キャッシュフローな話としてTOC（制約理論）と同じです。また、ワインバーグ氏の言う「フィードバック」を取り込み「舵取り」を行います。

ひとつ、泥臭い話を書くと、最近のISO9001や品質保証部の要求から、「バグの検出率は？」と聞かれることがあるでしょう。ある意味で、ユニットテストをすると、バグの検出率はゼロになります。品質保証部からの要求は、設計→製作→試験の流れを前提としているので、コーディングと単体試験が一体になったユニットテストには当てはめることができません。
こういう時は、品質保証部と数字で争っても仕方がないので、ゴールとしての「動作する製品を納入する」を優先するのがベターです。

ただし、ひとつ品質的には懸念点があります。ユニットテストの正確性です。つまり、何でもスルーしてしまうユニットテストをいくら書いたところで、品質は良くなりません。逆に、少しのユニットテストでも正確であれば、品質は良くなります。
これは、テストの網羅性ということで、テスト技法に関わってくる話ですが、思うに、製品として保つ品質とは、結合試験以降に要求されるものかもしれません。ワインバーグの言う通り「品質」と言っても立場上、千差万別であるので一概には云えませんが、各クラスがいくら正確に動作していても、組み合わせがまずければ意味がないわけで、やはり「顧客による受け入れ試験」という形で、品質保証部が何らかの受け入れ試験を書く（あるいは委託する、責任委譲する）という形になる必要がありと思っています。マイクロソフトのテスト部隊という感じで。

ペルソナ定義

アラン・クーパー著「コンピュータは、むずかしすぎて使えない！」の中で出てくるユーザ定義の手法です。

一般的に業務アプリケーションを作成する場合、ユーザを規定します。所謂「誰が使うか？」、「誰を対象にするか？」という規定です。UML的に云えば、アクターの抽出になります。
ただし、利用者の対象を決めているにも変わらず、画面系のアプリケーションでは機能を増やしてしまうことが多いのです。いわば、 という「思い付き」の機能を盛り込んでしまいます。マーケティング的に必須／不要という議論はさておき、本当の利用者の知らぬところで、機能が盛り込まれ、金額が膨らみ、実際利用してみれば盛り込まれた機能の20%しか使わず、50%以上は１回も使われずに終わってしまう、というところに陥ります。

ペルソナ定義は、この利用者に「名前」を付けて、ひとりの人物として扱うことで、機能の盛り込みすぎを防ぎます。
アクターと異なる点は、アクターの場合は、ひとりの人物に複数のアクター（役割）を持ったり、複数の人物がひとつのアクターを共有しますが、ペルソナは人物に１対１になります。これは、ユーザ（顧客）という漠然とした定義付けではなく、名前を持った人物として仕事の方法や好みなどを持った人格を定義するためにです。

例えば、WEBで業務アプリを作るうえでペルソナ定義として、する場合には、 という形で定義しておくわけです。

こうしておくと、何か機能を盛り込もうと議論したときに、却下できる項目（余分な機能）が割り出せます。
例えば、 という形ですね。いわゆる、本当の利用者が本当に使う機能だけに絞って実現していくことによって、無駄な機能の取り込みを避けます。逆に、開発者がいらないと思っている機能であっても、ペルソナが必要と思えば、盛り込みは必須なわけです。

「コンピュータは〜」でも言及されていますが、会議の中で「ユーザが」という言葉が出てきたら要注意です。「ユーザ」＝「自分が」という裏の意味があり、漠然としたユーザ像に各人の利害を潜り込ませてしまうためです。

利用方法としては、FDDで使われるユーザ機能駆動が、これを引き継ぎます。あるいは、UML のアクターとして引き継がせます。ただし、ペルソナ定義として１枚残しておくと、開発者として問い合わせが出来て便利です。顧客は、本当の顧客とは違う場合が多いので。

プロセス思考図

プロセス思考図は、ゴールドラット著「ザ・ゴール２」で出てくる対立図や問題解決図などの総称です。似たようなところに、「５つの何故」やワインバーグ氏の「フィードバック図」、「KI法」があります。著書「ザ・ゴール２」のあとがき（だったと思う）で示されているように、TOC理論の発端もこのプロセス思考図から始まります。法則を見つけるための道具立てという意味で、プロセス思考図は貴重な道具です。

私がよく使うのは問題解決のときなのですが、
  1. 現在の問題点を箇条書きに書き出す。
  2. 問題点に番号を振り、ポストイットに書き写す。
  3. ポストイットをひとつずつピックアップしながら、ホワイトボードに貼り、関連を確かめていく。
という簡単な方法です。
方法は簡単ですが、頭は使います。だいたい１日強は悩みますね。。。間を置いて、ちょっと考えて、間を置いてちょっと考えての繰り返しです（このあたりヴォネガットの人物交差図と似ているかもしれません）。十数個の問題点と思われていたものが、３，４個に集約できます。あるいは、集約するまで考えを煮詰めます。これは、見えている問題点は隠れている問題点の派生である、という根拠からです。なので、隠れている問題点を洗い出し、見直すことによって見えている問題点を解決しようという手法です。

いくつか電子化されているものもありますが、あまりお勧めできません。というのも、 という欠点があるためです。特に３番目は重要で、なまじ途中を電子化してしまうと、解決してしまったような雰囲気になってしまうので要注意です。これは、スケッチUMLにも言えることです。ユースケース図で代用してみたことありますが、あまりうまくいきませんでした。

で、ホワイトボードがない場合やひとりで行う場合には、紙に書いても構いません。この場合は、出来るだけ大きな紙（B4以上）を使うとよいでしょう。コピーの裏紙を利用しようとしてA4を使うと紙面が足りなくなるので、注意しましょう（苦笑）。
紙には、マジックからラッションペンのような太い線を使います。経験上、ボールペンや鉛筆は線が細い線は避けたほうがよいと思っています。自分の字で、ぐりぐりと書き足していくのがプロセス思考図の醍醐味です。

似たような図として、マインドマップがありますが、マインドマップは発散型、プロセス思考図は集約型として分類されます。発想を展開する場合には、マインドマップのように中心から全体に広がる図を使います。マンダラートも同じです。集約型の場合は、逆に全体から中心に、あるいは、点在しているものが連結していくという形を取ります。いわゆるネットワーク型ですね。

完成した図＝紙は大事に取っておきます。あるいは、スキャナで読み込むかデジカメで写しておきます。最近の高解像度のデジカメだと拡大したときにじゅうぶん字が取れます。

私がプロセス思考図を使う前は何を使っていたかというと、箇条書きなんですよね。。。KI法的な２次元に凝った時もありますが、問題をいきなり整理するのは難しいし、結局のところ集約できないために疲れてしまって問題解決に至りません（苦笑）。
「ザ・ゴール２」で示されていますが、十数個の問題点を、３，４個に絞り込むのがミソです。頭の中の思考プロセスを写し出す、後からみて再現する、皆に見せることができる、という形で有用な手法です。

スケッチUML

スケッチUMLは、ファウラー氏の提唱するスケッチングとしてのUMLの利用方法です。 最近（でもないけど）、UMLはバージョンアップをして、2.0 になりましたが、これは MDA（モデル駆動）を正確に動作させるに、UML の曖昧性を取り除くことを中心にしています。
が、UML の利用として、そのような厳密性だけではなく、システムの概要を掴んだり、矛盾を見つけ出したり、あるメソッドをどのクラスに入れようかと悩んだり、そういう試行錯誤のための道具としての面があります。つーか、そういう使い方をするのが「スケッチUML」です。

なのでスケッチUMLのポイントとしては、 という形でに留めておきます。 ようなことはしません。というのも、システム設計に対しての試行錯誤の道具としての UML を使うのですから、どんどん変更できないと困るし、妙に記法にのっとった制限を付けられても困るわけです。
なので、スケッチUMLをするときは、紙かホワイトボードに書くのが一番楽です。が、ツールを使うことによっても、先の厳密性を排除していけば、結構使えます。
私は、visio の UML テンプレート（visio本体ではないもの）
http://www.phruby.com/stencildownload.html
JUDE
http://www.esm.jp/jude-web/index.html
を良く使います。

書くときの注意点（深みにはまり過ぎない）は、 という形で、出来る限り手書きに近い形（修正しやすい形）にしておきます。

で、設計書を作る段階で、ちょこちょことスケッチUMLを直していきます。クラスから自動生成されるクラス図なんかも、納品的には便利なのですが、いろいろなプロパティやメソッドが入り込みすぎて、ちょっと辟易します。他のクラスに関連のない private メソッドとかは必要ないかな、と。

発展形としてはクラスを色分けするカラーUMLもいいと思っています。なにも白黒だけで UML を構成する必要もないので、４色のポストイットを使って並べてみるのもいいでしょう。色付けも楽しいし。

マインドマップ

マインドマップは、中心に話題を置いて、四方に広がっていく発散型の図です。プロセス思考図やKI法などのような集約型と違い、思考を発散させるために使います。なので、自由に書けること、繋がりを保ってどんどん広がること、が重要になってきます。ただし、強制的にアイデアを広げるのは、マンダラートのほうが便利かもしれません。

マインドマップも紙に書くことが多いのですが、ツールの場合は、
FreeMind
http://drikin.com/freemind/
を使っています。そのままWebなどに乗せるのが便利だし、続きを書くのも楽チンです。


…が、電子化にはやっぱり落とし穴があって、 １番目は、電子化全般に言えることですが、「作業の途中」というステータスが明確になりません。ペーパープロトタイピングで指摘されていることですが、整理された設計書の画面（特に画面のキャプチャ）を見ると顧客はそれが完成品であるかのように満足してしまいます。なので、あえて「途中」であることを強調し、何かを付け加えること（特に機能）ができることを示すために「手書き」という手段を使います。これと同じ位置に、マインドマップ、プロセス思考図、スケッチUMLがあります（と私は思う）。
２番目は、マインドマップの制限でもありますが、マインドマップはツリー構造から脱せません。なので、ネットワーク的な末端から末端への関連を示すことができません。手書きだと、このあたりのルールを外して、線を引いてしまえばいいのですが、電子化されたツールだとその制限がでてしまいます。
３番目は、でかいディスプレィが出れば、それでいいような気もするし、スライドを使えば解決できる問題かもしれません。

と、余談ですが、中上健次は小説を書くときには、ポケットに4,5枚の設計用紙（原稿用紙よりも升目が小さい青い紙のやつ）を入れておいて、いつでも書けるようにしていたそうです。１枚2000文字ぐらい（もっとかな？）になるので、4,5 枚で短編小説が１本できあがるという勘定だったそうで。
そういう形で、いつでもどこでも（というユビキタスの標語じゃないけど）、発想を書き留めることができるというスタイルが必須で、そういう点では、マラソンシステムとワンセットで揃えていくと便利です。

業務的な繋がりとしては、 という感じでしょうか。マインドマップは相互関連が薄いほう（連想的な広がりを重視するので）なので、ものごとを整理するときよりも、話を広げる（広がった話を記録する）みたいなときに使うといいと思います。

アイデアマラソン

マラソンシステムは、樋口健夫さんが提案している手法です。要は、「継続は力なり」を実行に移すための実践方法で、毎日頭を働かせて心身を活性化しよう、という方法論になります。似たようなところでは、ワインバーグ著「コンサルタントの秘密」で書かれている「５分間の日記」や、自前ですが「書評日記」という形で毎日書評書き綴った記録、WorkPad(PDA)への書き付け、などがあります。

アイデアマラソンの場合は、主に企画な発想を紙に書き付けます。１日１個と言わず、10個ぐらい書き付けます。商品化できるか、実現可能か、面白いか詰まらないか、は別として、とにかく数を書き付けます。
で、仕事でも私事でも同じノートに書き付けます。別々のノートに書くと、両方持たないと駄目だし、アイデアなんて分類できるものではありません。なので、なんでも書き付けます。
アイデアには番号をつけます。これは積み重ねをする心理的な面白さを利用したものです。どんどん数が増えるとそれだけで楽しいです。書き付けたノートも増えると楽しいのです。その楽しさが、原動力になって、あらたなアイデアが出てきます。
アイデアが出ない日でも、何かアイデアを書き付けます。無理矢理ひねり出します。これは、朝起きる、夜寝る、という間に「考える」という行為を必ず挟むようにしていきます。こうすると、何もしなかった日というのが皆無になります。

私が、マラソンシステムが面白いと思っているのは、 している。
というところでしょうか。

これは「40時間勤務」や「継続できるスタイル」にも繋がるのですが、土日の休日にという集中したスタイルよりも、毎日少しずつのほうが積み重ねる作業は有利になります（勿論、全く逆に、集中して解決しなければいけない場合は、コアタイムを作っていきます）。
「学生症候群」として言われることですが、１週間後の締め切りを設定してしまうと、６日間の作業は少なく最後の１日に作業量が集中しがちです。進捗の測定に仕方にもよりますが、1日1日のタイムボックスを決めることによって、７日間の作業量が平準化されます。
これは、生活スタイル（大袈裟に言えば生き方）にも関わってくる話なので、強制はできないのですが、私のスタイルが「マラソンシステム」に合っているという話なのです。

40時間勤務

40時間勤務は、XPのプラクティスのひとつでもあり、8時間労働×5日の標準勤務時間を守るという手法です。これは、4年前ぐらいから考えているのですが、私が裁量労働制になり（現在は年棒制）残業代を気にしなくてよくなったために、導入できる手法でもあります。

週40時間という見積もりでは、プロジェクトバッファと工数見積もりをあわせて、週40時間勤務の妥当性を検証しています。デマルコ著「熊とワルツを」で論じられる通り、プロジェクトでは、リスクの発生確率からプロジェクトの完了確率が割り出せます。リスクが発生すれば、（リソースを加えなければ）プロジェクトの完了は遅れるし、リスクが発生しなければ順調にプロジェクトは完了します。この、完了確率50%ラインをプロジェクトの目標完了日としておき、前後の進み／遅れの確率の幅を計算します。プロジェクトが早く終われば、リソースを消費せずに済む＆早期リリースによる回収回帰点が早まることにより、利益を生みます。プロジェクトが遅れる場合には、プロジェクトバッファによりありかじめ対リスク費用を加えるだけで済みます。
このとき、プロジェクト完了確率を80%の時点を、費用的にトントンの場所に置きます。つまりは、全プロジェクト中、8割は黒字プロジェクトとし2割は赤字プロジェクトとする、という経営的な判断を行います。

アジャイル型のプロジェクトの場合、何の契約が適しているかといえば、成功報酬型の請負契約が適していると思われます。これはアジャイルプロセス協議会で話されていた議論です。というのも、アジャイルの出現理由として、 というために、プロジェクト的には「短納期」のものが非常に多くなってきています。このために、以前のように作業期間（人月見積もり）という形で工数での費用を出してしまうと、優秀な人／会社が更に短期間で作業を追えた場合、安く仕上がるという矛盾が発生します。勿論、発注側としては早い／安いにこしたことはないのですが、高い技術力を駆使したため短納期にしたが故に安い報酬しか得られない、のは請負側としては大きな矛盾であり、これを回避するために、 という防御策を取りますが、あまり良くありません。
まあ、個人の作業の場合は、 ということにもなり、悪循環が発生します。

これを回避するためには、アーンドバリュー分析的な投資回収点の計算や、早期リリースや安定リリースにより高価値の計算（商品価格としての計算）を行う必要があります。 ただし、これはなかなか通らない（顧客／上司の双方に）ことが多いため、結局のところ、実工数と見積もり工数の差分により利益を換算したりします。

さて、40時間勤務に話を戻しますが、40時間という限られた時間（160h/月)という計算で見積もりをしておくと、突発的な作業に強い勤務体系になります。（やりたくはありませんが）土曜出勤という予備を取ることにより、8h の余裕が取れますし、平日でも 1,2 h の残業ぐらいならば、ほとんど作業効率を落とさずに済みます（勿論、50% 以下の確率で残業をする、という計算をしなといけません）。最初から、200h/月という工数見積もりはやめたほうがよいです。
そして、40時間以下で作業が終わった場合の余りをどうするのかといえば、先行投資に使います。決して、プロジェクトの前倒しに使ってはいけません。先行投資というのは、 などです。このあたりは、「継続できるスタイル」や「タイムボックス」、「８：２の割合で、仕事：投資をこなす」という考え方へ繋がっていきます。また、自分の仕事のスタイルを習慣化させておきます。こうすることにより、工数見積もりの勘が正確になってきます。

継続できるスタイル

継続できるスタイルですが、これは「マラソンシステム」や「40時間勤務」のベースになります。例えば、このブログの文章ですが、私の場合、正確性を極めたり、事実のリンク先をマメに張りすぎたりすると、疲れて続かなくなってしまいます。これは、理想は確かに理想としていいのでしょうが、やはり実現できない理想よりも、実現できる準理想を取っていこう、という主義でもあります。完璧主義よりも現実主義ってところでしょうか（勿論、交渉術的に、「折り合い」や「歩み寄り」よりも、「双方の利点を活かす」かつ「破談になったときのリスク（損失）を正確に計算する」という形のゲーム理論的な意味合いも必要になります）。

この「継続的な」の逆なところに（と私は常々思っている）、 があります。納品直前に徹夜をしたり、人員を集めて人海戦術的に作業をこなし、顧客へ努力のアピールをする、ということですが、私はこれに反対です。かつ、私が顧客ならばこれを高い評価として取りませんし、逆にリスクが高いと考えます。
というのも、納品直前に頑張らないといけないということは、 を表現しているわけで、平準化すれは、40時間勤務という形で残業を強いることにならなかったにも関わらず、直前にだけ高負荷がかかるのはナンセンスです。つまりは、マネージメントの不味さを、開発者（プログラマ等）の責任感で賄っているという図式になります（まあ、雇用関係がそういうものだ、というのは確かなことですが）。

なので、「計画の妥当性確認」や「進捗管理」がずさんであると、時として、直前の頑張りが利かなくなり、本当の納期厳守（1日遅れると何億円という損失が出るもの）のプロジェクトには、その会社を含めることはできません。現在のところ、70%以上のプロジェクトは何らかの赤字／遅延を出すし、日本のソフトウェア会社のほとんどが、この領域にあるので差別化がされていませんが、TOC理論を真面目に考えたり、進捗管理をきっちりとやったりする会社は、そのうち抜きん出てくるでしょう。ソフトウェア工法という形で。

で、この「継続できるスタイル」ですが、これを用いることにより、より平均的な能力で確実に実績を積むということが可能になります。以前、インテル社（だったかな）で、平均的なプログラマを集めて優秀なプロジェクトを完遂させるという話がありましたが、これのベースになります。
つまり、昔から言われるところの、 という考え方を、私は否定します。確かに、超短期／超ムズ／超混乱プロジェクトを正常に戻すには、これらは必須になるかもしれませんが、プロジェクトを正常に運営するためにこれらの要素は必須ではありません。このあたりは、役割分担型プロジェクト運営やフラッグ管理に続きます。

それで、経営層的にではですね、少数先鋭化により優秀なプログラマの使い捨て（バーンアウト）でも構わないわけですが、長期的に見れば損なわけで、そのあたりは「知的想像企業」、SECIモデルに従います。

パタンランゲージ

パターンランゲージは、デザインパターンのほうではなくて、アレグサンダー著「パタン・ランゲージ」のほうです。

パタンランゲージでは、都市計画から過ごしやすい窓の配置まで、マクロからミクロまで繋げて解説されています。勿論、パタンランゲージの功績は、アイデアの実現方法を「ランゲージ」としてまとめていった点にあり、文章で書くように、いくつかのパタンを組み合わせて文章を構成し、齟齬や矛盾のない構成を作れる、というところの実績にあります。ソフトウェアパターンへの移行／導入は、そいうランゲージの部分にあるわけですから。

ですが、私としては、パタンランゲージに描かれている自己組織そのものに有用なアイデア（当たり前だけど）が含まれているかな、と思い通読しています。分量も多いし値段も高いので、手元においておくにはちょっと、と気が引けるかもしれませんが、複雑系や自己組織化や、ＸＰの机の配置や、パソコンに向かう人々の向きや、役割分担と作業範囲の重なりや、モジュール化や、オブジェクト＆ネットワーク化、といったところに興味があれば十分、読んで面白いものとなるでしょう。

で、この表層だけではないパタンランゲージのスタイルに踏み込むと、プロジェクトを運営するための共通用語を慎重に付けることとか、暗黙知と形式知の差とか、形式知を通達する方法とかその適用範囲とか、がいかに重要であるかがわかります。
つまり、仕様の丸投げだとか、相互認識の手落ちだとか、険悪なムードとか、コミュニケーションの重要性だとか、ビジネススタイルのコミュニケートとのとり方だとか、そういう相互干渉的な部分は制御不可能であること、混沌さから自己組織化し管理下に置こうとした途端に崩壊するという社会と個人のあり方だとか、そういう社会学ちっくなところも見えてきます。情報の流れ、みたいなものですね。

そういう部分からのつながりは、 という形になります。

ピープルウェア

ピープルウェアは、デマルコ氏が提案するソフトウェア開発のスタイルです。

最近、ソフトウェア工学から一転して、人を中心としたソフトウェア開発をしていこうという流れがあります。つまりは、XPだったりスクラムだったりするアジャイル的なやり方なのですが、まあ、そういう枠を外せば、ピープルウェアというのは「工学」とは反対の視点からみた開発の提案でもあります。

例えば、ソフトウェア工学が何を主流にするかというと、 という形で、経営層から見たソフトウェアという商品を如何に遅延なく生産できるか？（製造ラインのように）、という管理を元にしています。なので、開発要員は、切り替え可能であり、一定の作業量から開発量が予想可能であり、設計→製作→試験という流れによって一定の範囲内での欠陥品しか出さない、という考え方があります。これは、「工学」というのが、そういう実務的な部分を支える学問なので、属人性が消えてしまっても仕方がないところであったりします。

で、この「工学」部分があやういことがわかり、逆の意味で属人性を求めていこう（重視していこう）というのがピープルウェアの思想でもあります。
「ゆとりの法則」にもありますが、９ピースパズルでは、９ピースはめ込めば動きが取れなくなります（当たり前！）、１マス分あけるという「ゆとり」を生むことで、動くことができます。組織のなかで、こいうゆとりが中間管理職の役割であったり、２割の自由時間であったり、フリーなホワイトボードの存在だったり、机の配置であったりします。

そして、当然のことですが、「ソフトウェア工学」のような学問的なところは、昨今の「ソフトウェアテスト技法」のように形式知化できるものもあります。また、PMBOK のようにプロジェクト管理の基礎を知っておくことにより、PM同士の共通言語ができ齟齬なくコミュニケーションが取れるようになります。そういう学問的な知識をベースにして、それが適用できない範囲に対してピープルウェアというを相互補助という形で適用していくのが私のやり方です。

舵取りレベルの組織

舵取りレベルというのは、ワインバーグ著「ソフトウェア文化を創る」シリーズの組織論のレベルの話です。順序としては、 の順で、組織としての完成度（リスクが低い）組織になっています。

無意識レベルでは、１個人のソフトウェア開発あるいは何もルールがない開発を示しています。「システム思考法」によれば、無意識レベルが一番多く、次に慣習レベル、可変レベル、舵取りレベルになります。CMMIのレベル５は適合レベルに合うことになりますが、ワインバーグに依れば「そのような組織はみたことがない」そうです。
ISO9001の品質システムを導入した場合は、慣習レベルになります。数名でのグループ開発、ＸＰ適用などのアジャイル開発は、可変レベルか舵取りレベルになります。おそらく、きちんとしたスクラムマネージャのいるプロジェクトは舵取りレベル、なんとか数名でアジャイル開発をこなしている場合は可変レベル止まりです。
この差は、「フィードバック」の測定の違いで、可変レベルでは暗黙的なフィードバック（属人性の高い知識、グループの外には示されない進捗状態、メンバのモチベーションにより開発効率が支えられている）という形でプロジェクトの運営の指針がない状態になると考えられます。暗黙知が多いため、一見効率良く動いているように見えますが、メンバの欠員（病欠、結婚、退職など）に弱く、またグループ同士の進捗状態を経営層で判断することができません。俗に言う、「部分最適化」止まりなわけで、戦略的なプロジェクト管理の判断（赤字プロジェクトを認めるなど）をはさむ余地がなくなってしまいます。

慣習レベルは、いわゆる大規模開発で使われる文書の山です。ISO9001やPMBOK、CMMI、RUP、クリスタル開発などが要求する明示的なコミュニケーション＝文書を求めていきます。属人性を極力廃して、ソフトウェア工学に則った形で進めます。
一見、効率よさそうですが、昨今の小規模プロジェクトのように短期決戦型のプロジェクトでは、これらの「慣習」が足枷になります。例えば、監査資料の準備、試験バグ率の抽出＆分析、要求仕様／設計の決定というフィールド分け、など。
ただし、百人規模の大規模開発では、このような形式知が必要で、管理もしやすいために、この慣習レベルを突き進みます。

舵取りレベルでは、この可変レベルと慣習レベルをあわせた性格を持ちます。つまり、作成する → 検査する → 問題を検討する というフィードバックがあり、問題があれば抽出し、設計や製作の見直しを行います。このため、アジャイル開発がこれに近い形になります。
ただし、（私としては）完全にイコールではないと思っています。というのも、舵取りレベルで重要視されるフィードバックは、明示的な測定を開発に戻していくという大きな目的があります。具体的に言えば、 などです。
実は、アジャイル的には、XPのオンサイト顧客やスクラムマスターの存在、プロダクトマネージャ（製品作成のマネージャの方）、キーマンの存在、などがそれにあたるわけですが、開発のみのプラクティスに集中している限りは可変レベルを脱せません。というか、脱する必要がありません。
可変レベルから舵取りレベルへ脱する理由としては、 ために、開発者だけで閉じないフィードバックの仕組みが必須なわけです。

舵取りレベルでは、そういうプロジェクトが進んだときの障害をひとつひとつ発見しては問題解決していきます。

フィードバック

ある装置の出力が再び入力に関与するのがフィードバックです。猪突猛進型のプロジェクトは現状把握をしないためフィードバックがありません。なので、舵取り組織のような目先の事象に対して対処することができず、プロジェクトはリスクへと盲目的に突入するだけになります。プロジェクト運営時の出力（ソースコード、作業時間、開発者の愚痴、バグの頻度、顧客側の文句などなど）を適切に測定し、プロジェクトの運営に役立てるのがフィードバックを行った正しいやり方になります。
・・・とかいうのは、誰でも分かっている話だと思うのですが、何故フィードバックが適切に行われないか、フィードバックを適切に利用しないのかを考えてみましょう。

スパイラル、PDCA、振り返り、は全てフィードバックを意識したものです。スパイラルは、開発時の完成品に対する意見を抽出し、次の開発に役立てる。PDCA は、Plan/Do/Check/Actionという形で、CheckをPlanに役立てる仕組みを持つ。振り返りは、KPTを使ったプロセス改善にある通りKeep/Try/Problemで問題をチェックします。
そこで、似たようなところにISO9001の審査検証があるのですが、検証は「製品が正しく作られているか途中でチェックする」、審査は「製品が正しく完成されているか最期にチェックする」という形でチェック機構（受け入れ試験みたいなもの）があるのですが、この審査検証では不良品をはじくことができるのですが、不良品を直すことは出来ません。というのも、製品の製作段階に差し戻すことは可能なのですが、何が間違っているか分からないため、設計図が間違っていれば、何度同じものを使っても審査を通らない製品ができるだけです。
つまり「間違った設計図」→「設計に沿った正しい製品」からは、「正しい審査」でははねられてしまいます。審査や検証ではねるということは確かに不良品を検出したという事実のフィードバックではありますが、何が違っているのか？というフィードバックを持ちません。これは結合試験・運用試験でのバグ票なんかでも同様で、「動かない」という事実だけではフィードバックが足りず、「期待値が何であるが、実際はこうなっている」という情報のフィードバックが必要になります。これが正しい測定結果にあたります。

よって、きちんと適切な測定結果をフィードバックしなければ、正しい舵取りができません。往々にして、プロジェクト内のコミュニケーション、数社での開発でのコミュニケーション不足は、会議や文書の多さよりも、この手の正しいフィードバックの少なさがうまくいかない原因になっています。

このあたり「正しいコミュニケーション」とは何ぞ？という話になるのですが、 という４段階にわかれます。これは、サティアの交流モデルである にあたります。このあたりを怠ると、適切なコミュニケーションが取れてるとはいえませんし、適切なフィードバックを持っているともいえません。
例えば、開発者がバグを知っていつつも黙っている場合は「取り込み」の時点で止まっているパターンであり、テスタがバグ票を出しているのだが開発者に届いていないというのは「意義付け」の失敗でもあり、バグの測定はできているがマネージャが顧客との折衝を面倒がって計画を見直さないというのは「反応」が鈍い例であります。

こういう形でフィードバックは、フィードバックしたという事実だけでなく、如何に情報を適切に伝え、如何にして相手の正しい反応（こちらが期待する反応）を起こさせることができるのか（それは自分自身かもしれないが）、が焦点になってきます。

ピーターの法則

ローレンス・Ｊ・ピーター著「ピーターの法則」です。まあ、羊飼いの度重なる嘘（警告）は、村人（メンバ）の意識を麻痺させるわけで、デスマーチパンチドランカー via せつないぶろぐ にある通り、判断力の欠如がデスマーチ状態の負のフィードバック（ワインバーグ的に言えば「悪循環が増大する正のフィードバック）にあたります。

ピーターの法則というのは、階層社会における平準化（凡化）の法則で、下位階層では優秀ではあっても上位階層では平凡の位置となり、その人にとって能力の発揮できない（能力を発揮しても平凡である）位置に留まってしまう、という話です。
もちろん、これには前提条件があって、 という２点があります。
というのも、多層社会のように評価軸がたくさんある場合は、上位下位という階層という単純比較はできず、それぞれの層の中で上位下位が決まることになります。よって別層から移管されてきた人は（例えば、開発から営業とか、出版業者からＩＴ業界とか）、その能力は改めて新しい層で評価されることになります。当然、前の層での優秀さを認められて現在の層へ組み入れられる（業種を超えた転職など）場合には、前の層の優秀さ≠現在の層の優秀さとは異なるので、ピーターの法則のように無能化へと進む場合もありますが、無能化の要因は階層をあがったことではないので、正確には異なります。私が思うに、他業種への転職の場合、前職のノウハウ（知識の蓄積）を活かせないで転職する場合には、一からやり直すために一時的に下位層に落ちる、ということでしょう。いわゆる、会社の雰囲気を読むとか、社風とか、会社ごとのノウハウとか、そういうものにより、発揮できる能力が一時的に落ちるという現象です。これは、デマルコの言う、チームに新しい人員を入れるときの、一時的な導入コストにあたります。

もうひとつは、人は学習しない、というのがピーターの法則の前提になります。つまり、大学（最近では大学院？）までは勉強して就職までは頑張るけれども、会社に入ったら一切勉強をしない。という形になると、これはピーターの法則まっしぐらになります。ピーターの法則が有効と思われるのは、世の中あまり勉強しない人が多いという事実からなるもので、逆に言えば「学習」することによって、無能の位置から脱することが可能です。これは、「今から頑張れば何とかなりますか？」に対して への私の答え（コメント）でもあり、多くの人は学習を嫌がりますから、学習すれば彼らに先んずることができます（当然、学習を嫌がる層が中央に位置する社会は、学習を嫌がっても中央に位置できる社会を意味しています。ただし、今後は「下流社会」にあるように二極化されてしまえば、学習を嫌がる層は、徐々に下層に落ちていくと考えられ、頑張ってもなんともならない大きな溝を作ってしまうかもしれません）。

あいにく「ドラゴン桜」を読んだことがないので、詳しくは知らないのですが、「オンリーワンというのは、その業界でトップということだ！」というのは正しいと思います。社会人になるときにどの層を選び生きていくのか、という選択もありますが、マーケティングの手法として「業界をセグメントに分けてしまう」という方法があります。これは「サービス・マネージメント」に書かれていた手法です。現在、既に大会社がシェアを占めている業界（携帯電話のDoCoMoとか、パソコンOSのMicrosoftとか）に参入する場合には、ユーザの対象を絞り込み、他のユーザとの差別化をはかり絞り込んだユーザに新しい価値を与えるという手法です。PHS に特化した WILLCOM の手法に等しくなります。

という訳で、頭を使わない、過去から学習しない、人の話を聞かない、とピーターの法則に陥ります。これでもなんとかなっているのは、その階層が非常に多いためで、周りに多く存在するため階層にスライドしている速度が遅いために気付きにくいのです。

最近思うのですが、人の話を聞かないというのは、他人の経験を有効利用しないということで、非常にもったいない話です。他人の苦い経験を自ら経験する必要は全くありません（身体に訴えて、忘れぬように傷を付けるという効果もありますが^^;）。他人の苦い経験をよくよく吟味して研究して、自分の目の前の事象に対応していく、というのがベターでしょうね。少なくとも、ピーターの法則に陥らない手段のひとつではあります。

まとめ

ストーリーカードからピーターの法則まで、全15個の道具箱の紹介ですが、いかがだったでしょうか。多分、文字が多すぎて、まずはここの「まとめ」から先に読んでいる方も多いのではないでしょうか。
この道具箱というアイデアは、ワインバーグ著「コンサルタントの道具箱」からでもあり、考える道具としての「考具」、旋盤工が持っているなじんだ道具としての「治具」からの借用です。プロジェクト運営を数年にわたって考え続けてきたのですが、mymyのページの行き詰まりもあり、ひとつ自分の持っている道具を整理して、再考察をしてみようというのが発端になりました。
個人的な記録でもありますが、このお裾分けが、よいプロジェクト運営に繋がれば幸いです。
copyleft by masuda.t