論理的に考え伝える – SEA関西「開発現場で役立つ論文の書き方のお話」 -

論理的ということは論理的な構造を持つということで、人に伝えるということは物事を論理的に整理して、伝わる構造あてはめるということだ。ソフトウェア開発現場において、伝わらない事で生じるトラブルは少なくない。それは説明の順序であったり、端的に表現できないからだったりする。私が社内外で論文の書き方を説明しているのは、論文にはトラブルを未然に防ぐ「論理的に考え伝える」構造が含まれているからである。
論理的な構造に整理する方法は数多くあり階層的に表現するものから、目的に応じて記法を変えるTOCｆE http://sakaba.cocolog-nifty.com/sakaba/toctocfe/index.html のようなものもある。しかし、ソフトウェアと同じように大きな情報を扱うには、構造化プログラミングのように1種類の構造だけでなく、クラスや関数のようにある程度の塊でさらに構造を持つ必要がある。論文においては論理的な構造を実現する方法として、パラグラフライティングが用いられる。
パラグラフライティングは「各まとまりの先頭には最も重要な文を置き， それ以後にはその文の補足説明のための文を置く」（パラグラフライティングの作法 -書き手にもメリットのある文配置ルール-）というもので、主に要旨＋詳細で段落（パラグラフ）を構成する。YES/NOをはっきりさせる英語文化を感じさせる構造である（日本の小学校では起承転結が教えられるが、これでは最後まで聞かないと結論がわからない。いかにも日本語的だ）。
パラグラフライティングの良いところは、初めに伝えたいことの方向性を示しているので、内容をミスリードしないことだ。パラグラフライティングで書かれた文章は、要旨がなくても各段落の1行目だけを読むことで概要を把握することができる。逆に文章を書くときは、各段落に書くべきことを1行ずつ書いておいて、それを膨らませば良い。
初めに伝えたいことの方向性を示というのはミスリードを防ぐ良い方法で、これは開発現場でも大いに役立つものなので、今回の講演（第74回 SEA関西プロセス分科会 「開発現場で役立つ論文の書き方のお話」）をおこなった。論文で採用されているIMRADという技術文書の構造がこのような構造を持つだけでなく、わかりやすい論文は各章の段落もこのような構造を持っており、論文の書き方を説明することで、開発現場でも役立つと考えたからだ。

追記： 今回の分科会はソフトウェアシンポジウムの投稿者を増やす目的で開催されました。

改訂版：開発現場で役立つ論文の書き方のお話 from Makoto SAKAI

Tweet

ザ・ゴール2 コミック版：TOCの思考プロセスは、ツール、知識、考え方から

TOCの思考プロセスには３つのツールが登場します。“ものごとのつながりを考える「ブランチ」、意見の対立について考える「クラウド」、目標を達成する方法を考える「アンビシャス・ターゲット・ツリー」”（教育のためのTOC 日本支部）の３つです。

TOCfE(教育のためのTOC)勉強会でのモヤモヤ

これらのツールについては引用元のTOCfE勉強会が関西でも開催されていて（facebook）、そのワークショップへの参加を通じてだいたい知っていました。

でも、正直なところ少しモヤモヤしていました。それは、どのような局面で使うのか、問題をモデル化しても結局はアイデア勝負ではないのか、そのモデルは正解なのか、といった疑問です。

しかし今回、 ザ・ゴール2 コミック版を読んでようやくすっきりしました。まずは３つのツールから説明します。

意見の対立について考える「クラウド」

前作のザ・ゴール コミック版 でもCCPMに繋がる家族のストーリーがありましたが、今回は親子の対立をクラウドで解決します。

クラウドでは対立する意見の理由（なぜ）に共通する同じ目標をモデル化します。共通の目標と考え方の違いを明確にすることで、互いの理解が深まり、対立を解消する解決策を考えることができます。

目標を達成する方法を考える「アンビシャス・ターゲット・ツリー」

コミック中では「前提条件ツリー」と呼ばれています。これは、目標を達成するために必要な「中間目標」をはっきりさせるためのツリーです。

まず、目標を達成しようとするときの障害を挙げ、その障害をかわせる中間目標を考えます。そして、現在から中間目標をたどり目標まで論理的につなげることで、障害をかわして中間目標を達成する手順を考えていきます。

ものごとのつながりを考える「ブランチ」

UDE（ Undesirable Effects: 好ましくない現象）を明確にして、因果関係から現状ツリーを作成します。問題の全体像を示して「何を考えるか」をはっきりさせます。現状ツリーができれば、全てのUDEの原因がわずか一つかふたつの根本（コア）となる問題がわかります。

現状ツリーのUDEをひっくり返してDE（Desirable Effects: 望ましい現象）を考えて図式化し、「何に変えるか」を考えるために 未来現実ツリーを作ります。

現在から未来に向かって実行していく移行ツリーを作る例や、 アンビシャス・ターゲット・ツリーを使ったお話も出てきます。

知識と考え方

この本ではツールの使い方がストーリーで示されています。そこにはワークショップではわからない、知識や考え方にポイントがあると思いました。

まずは知識の重要性です。今回は財務のスペシャリストの女性が問題を整理していましたし、家族の対立の際も子供がどのような考えを持つかを大人が知らなければ理解が進まなかったでしょう。

次に「コア」根本の問題を見つけていることです。表面的にはたくさんの問題があっても、まず解決しないといけないのはそんなに多くはありません。セーフウェアの根本原因やなぜなぜ分析にもつながるポイントだと思いました。

最後にUDEからDEに反転させていることです。論文の書き方でも同じようなことをしています。物事を裏側から見ると意外とシンプルになりますし、考えも広がります。

つまり思考プロセスというのは、物事を知り、現実を深め、アイデアを広げることで、３つのツールはそれを支援している。なので、ツールはあくまでも考える道具なので、本業の腕を磨き、考えを深め、広げる際に、必要に応じて使えば良いと思いました。

思考プロセスが単なるツールではないと理解したとき、この本がより素晴らしく感じました。

ボトルネックはお早めに！ -- CCPMのワークショップに参加して TOCcafE@OSAKA -

CCPMのワークショップ、TOCcafE@OSAKA おりがみで学ぶチームワークを最強にするプロジェクトマネジメントを身につけるワークショップに参加しました。

目的とワーク

このワークショップの目的は「CCPMを実際にやってみる」です。実際のソフトウェア開発を短時間で実践できないので、折り紙のワークをCCPMのバッファ傾向グラフで管理しました。

バッファ傾向グラフは、X軸に進捗率、Y軸にバッファ消費率をとったもので、「TOC/CCPM標準ハンドブック―クリティカルチェーン・プロジェクトマネジメント入門」によれば

• (進捗率0％、バッファ消費率15％)-(進捗率100％、バッファ消費率75％)
• (進捗率0％、バッファ消費率30％)-(進捗率100％、バッファ消費率90％)

の2本の線が引いてあります。ここに、ワークの進捗とバッファの状況をプロットしていきます。

ワークは4種類の折り紙を５つずつ作るというもので、１０分のイテレーションを2回と10分のバッファの1回を実施しました。

ワークの状況

最初の10分間のワークで、４つのワークのうち３つは 1.6-1.8個完成しましたが、１つのワークが10分でも終わらず、0.9個という状況でした。進捗は完成品だけを数えますのでバッファを除いて半分が過ぎた時点で進捗は15％でした。

ここで各チームの状況確認と増員が必要かどうかの確認が行われました。難しいワークは10分でもできていませんでしたので、増員をお願いしました。

５人体制になっても、簡単な折り紙の進捗は進みましたが難しい折り紙は2.7個しかできていませんでした。そこで、難しい折り紙を３人体制にしてリカバリを図り、最終的になんとかおさまりました。

良かった事

やはり見える化は強力です。バッファ傾向グラフでどんなに頑張っても間に合わない事が明確になって増員をお願いしました。増員していないチームでもチーム内で助け合いましたし、早く終わったチームの人たちは遅れているチームを助けていました。

制約論値(TOC)に基づくCCPMでは、単位時間あたりのリソースとスコープはそのままにデリバリータイム（完了日）が変化します。ボトルネックになっている作業を支援する事で、デリバリータイムを短縮できるように調整します。

今回のワークは作業に順序の依存関係がなかったので、単純にボトルネックに対してリソースを集中させる事ができました。シンプルに実施できたので、より明確に助け合う状況が作れたと思います。

課題

その一方で課題もあったと思います。

• 作業に対してイテレーションが短いので、増員の要否を決める際に仕掛り分の考慮が必要だった
• 折り紙が得意な人とそうでない人の生産性が大きく異なり、それがチーム毎の差になっていた
• 折り紙毎に必要な作業時間が大きく異なり、わたしのチームでは手分けして作業を始めたのでリカバリがうまくいかなかった
• 折り紙の手順書が難しかった

ヒント

解決法までには至っていませんが、今後のヒントがありました。

• 折り紙の手順を考慮して進捗報告すればより現実を把握できたかもしれません。反面、完成品のみを数える事で遅れがより明確になるというメリットもありました
• 作業者が見積もりをしていないので、理想見積もりになっていませんでした。より正確な見積もりができれば、もっと効率を上げる事ができたかもしれません
• ボトルネックは積極的に攻めるべきでした。ナップザック問題の簡便な解決法は大きな荷物から詰め込む事です（プロセスのムダを取る３つの方法）。最初からボトルネックにリソースをつぎ込めば、作業完了にばらつきが出なかったと思います。
• 最後になって気付いたのは、手順書を見ないで一緒に折り紙を折ると明らかに生産性が向上しました。ペアの作業は文書のボトルネックを無くす効果もあるという事でしょう。

ワークショップの善し悪し

正直なところ、わたしはワークショップは苦手です。ワークショップは、

• ノイズが少なく
• ポイントを絞り
• 雰囲気を共有できる

という長所がある反面、

• 現場と異なる
• 知識が局所的、一面的
• わかった気になること、仲良しクラブになりがち

という欠点があると思います。

つまり、うまくいけば理解の壁を越えられる反面、時間がかかる割に得るものが少ないと思っています。

今回の場合、TOC/TOCfE、ザ・ゴール　コミック版 で基本的な知識を得ていたので、具体的なイメージや全体の関係性がよくわかりました。特に、うまくいかなかったプロジェクトにあたったので、上に挙げた課題を実感できました。現場で実践する際は失敗できないので、失敗して学ぶ事ができたのはラッキーでした。

おわりに

TOC/TOCfEの勉強会に出ていて、ザ・ゴール ― 企業の究極の目的とは何かに感動したというお話を良く聞きましたが、ザ・ゴール　コミック版 を読んでようやくその意味が分かると共に、わたしも感動しました。

今回のワークショップでは、エクセルを用いた簡単なツールでそれを体感でき、しかも失敗して、より理解を深める事ができました。

これは、講師の水野さんや主催者の井上さんが、ポイントを絞って環境を用意していただいたおかげだと思います。本当にありがとうございました。

[#TOC] 答えをみつける機会 - 「考えろ！」だけでは考えられない -

先日、TOCfE関西のTOC/TOCfE関西分科会～ごちゃごちゃすっきり！ブランチ講座～に参加してきました。

TOCとは

最近、トヨタ生産方式の流れを汲むTOC/TOCfEがじわじわと広がっています。TOC/TOCfEは知らなくても「ザ・ゴール」という全米で２５０万部売れたベストセラー小説ならご存じの方がおられるかもしれません。

TOCというのは著者のゴールドラット博士がまとめた制約理論を基礎とするものです。中でも、個々の作業ごとに持ってしまいがちな作業のバッファをプロジェクトでまとめて管理することで高い生産性を実現するCCPMが有名です。

TOCfEとブランチ

そしてその２作目の「ザ・ゴール２」で書かれたのが、TOCをベースにした思考法であるTOCfEです。TOCfEには３つの有名なツールがあります。

• ブランチ：なにを変えるのか
• クラウド：なにに変えるのか
• アンビシャスターゲット・ツリー：どうやって変えるのか

今回はブランチです。

ブランチでは、次に用に考えます。

１）隠れた思考の要素を導きだす。
２）「なぜならば」にあたる隠れた推論を導きだす（下から出る場合もれば、下から出る場合もあります）。
３）ブランチは正しいのか、内容を明確にし、存在有無、因果関係、十分な条件、から？因果関係を確認する。

気になった言葉

分科会ではいつものように、TOC/TOCfEの説明、ブランチの説明、演習、とあって、演習では付箋を色分けしているチームもあって、勉強になりました。

いつものTOC/TOCfEの説明でしたが、今回はゴールドラット博士の言葉が気になりました。

「学ぶことの最大の障害は答えを教える事ではないか？それは、自分で答えをみつける機会を永久に奪ってしまうからである。」

この「答えをみつける」とは、一体、どういう意味なのでしょう。ゴールドラット博士は、TOCfEの思考のツールを与えて、答えをみつけることの重要性を語られています。つまり、ツールを使ってもっと大切なことを考えさせようとしているのだと思います。

「考えろ！」だけでは考えられない

プロジェクトにトラブルがあったとき、「考えろ！」と言ったり、「考えさせろ」（あるいは「ちゃんとやれ！」）という指示をされていませんか？それは答えをみつける機会を与えているでしょうか？

指示する側から見ると、こうすれば良い、それぐらいわかるだろう、そんな思いがあるでしょう。でも、なぜそう思えるのでしょうか。どんなやり方があり、それぞれの特性を知っているから、適切な方法を思い浮かぶのだと思います。

もし、やり方を色々知っていて、考えないでいつも通りやっているなら、「考えろ！」は的確だと思います。でも「考えろ！」と言う人に限って、どのような方法があるかを教えずに、考えさせようとしていないでしょうか？

「考えろ！」という人も、多くの場合は過去の経験やどこかで知ったことを状況に合わせて適用しているだけなのですが、それを自分で考えたと思っていないでしょうか。

車輪の再発明をさせてはいけない

「答えをみつける」ということは、先人の知恵をどのように活かすかを考えることです。何もない所から、車輪の再発明させることではないと思います。

もちろん、工夫をしていたら同じようなことをしていたということもあるでしょう。でもそれは、知っていれば苦労せずに長所短所を知ることができて、さらに高度に発展させられたかもしれないのに、汎用化されていない似た様な事しかできていないのです。

いまだに、NIH症候群は根強いのでしょうか。

魚を与えるのではなく、魚の釣り方を教える

ゴールドラット博士の言葉は「考えろ！」というのではなく、「教えろ」と言われているのではないでしょうか？

たしかに「俺の若い時は」と思うことも多々あると思いますが、昔と今は違います。かつては、言語の本かマニュアルを１冊読んで、一通りのアルゴリズムを知っていれば良い時代でした。しかし、いまや言語はもちろんのこと、フレームワーク、アーキテクチャ、レビューやテスト技法、開発標準、法律、などなど、しかも、業務によってニーズは大きく異なります。

答えをみつける機会を与えるには、先ずその方法を教えることが必要だと思います。ポイントは「教える内容」であって、「教えないこと」ではないと思います。方法やツールを与えて解決策を考えさせる。TOCfE分科会で行われているような教え方が必要だと思います。

CCPMから考えるボスのあり方 - マイクロマネージメントより親分肌 -

リーダーに求められる大切な事 - 100人のプロが選んだソフトウェア開発の名著 -で紹介したハンフリー氏の「TSPガイドブック：リーダー編」は、上に立つ人（ボス）がどのようにすべきかという事がたくさん書かれています。

その内容を考えていると、CCPMとよく似ている事に気付きました。

ハンフリー氏は、「TSPガイドブック：リーダー編」でアイアコッカの言葉を引用して「ボスのスピードがチームのスピードだ」(p.9)と書かれています。これは、ボスがCCPMでいうクリティカルチェーンになり易いという事です。

このような場合、CCPMではリーソースの競合を解消します。ハンフリー氏の表現でなら、管理するのではなくリードしてメンバーの能力が発揮できる「自律的なチーム」を構築せよ。という意味だと思いました。

また、ハンフリー氏は「その最大限の能力を最大限発揮できるようメンバーを動機付け、コーチし、後押しする」と言われています。これは、CCPMのバッファコントロールにつながると思います。

上の人が細かく口を出して、マイクロマネージメントすると、それぞれの担当者は身を守ろうとしてバッファを持とうとします。それよりは、どっしりと構えて「責任は俺が取るから、任せたぞ！」と親分肌でいる方が良いということでしょう。

CCPMでは、各作業を理想見積もりで計画して、全体でバッファを取ります。つまり、親分肌の全体バッファはボスが持っておいて、メンバーは自律的に最善を尽くすことで、全体最適ができるのです。

さらに、ハンフリー氏は「チーム全体を巻き込み、チームを働きがいがある楽しいところに」と言われていますが、これはCCPMが、プロジェクトを見える化して、効率的にプロジェクトを運営することとつながるでしょう。

このようにハンフリー氏が考える上の人のあるべき姿と、CCPMにつながる点があるのは、共にサーバントリーダーシップを目指しているからだと思います。TOC/TOCfEの東さん（@oyukun）が、「ザ・ゴール」を読んでTOCに惹かれたというのは、このような事なのかと思いました。

私もいつか読んでみたいと思います。

オプションを維持するためのアソビ - CCPMのバッファを考える -

リーンソフトウェア開発には決定を遅らせるというプラクティスがあります。拙速に物事を決定するのではなく、最終責任時点と呼ばれる、それ以上遅らせると問題が生じるタイミングまで決定を遅らせて、オプション（選択肢）を残しておきます。

Leanとは贅肉がなく引き締まった様子を表す言葉ですが、オプションを維持するにはアソビが必要だと考えています。しかし、それはリーンやその元となったトヨタ生産方式ではどのように考えられているのだろうと、ずっと疑問でした。

CCPMとの出会い

最近CCPMを知って、というか簡単には知っていたのですがTOC/TOCfEの勉強会に出るようになって、CCPMでは理想時間で見積もって計画を立てておいて、全体のバッファを管理するというイメージがなんとなくわかりました。そこで、CCPMもトヨタ生産方式の流れなので、リーンのプラクティスと合わせて考えてみました。

考えてみて気づいたのは、実はバッファは予想外の問題に対処する余裕でなく、プロセス設計上のアソビなのではないかということです。オプションを維持する目的で、個々のタスクにバッファを取らせず、バッファをまとめておくのではないかということです。

CCPMでは、普通に計画すると人間は各作業にバッファを取りながら見積もってしまうので、それらを取り払ってまとめておく事で効率的に作業できる。と説明されることが多い様ですが、実はそれだけではなく、もっと理論的な面があると思います。

従来の見積もり

リスクの定義を考えると

　　リスク＝発生時の影響 × 発生確率

とされていて、これを各作業と共に積み上げて見積もるというのが、従来の方法です。

問題が発生しないなら、早く作業が完成するはずです。しかし、滅多にそのような事はありません。

もしかすると、よく言われる様に人間は楽な方に流れがちなので、問題が起きない場合もリスク込みの計画でゆっくり作業をしてしまうのかもしれません。あるいは、仕様変更など本来は計画にない作業を、別の問題用のバッファの工数で実施してしまうのかもしれません。

問題が発生した場合を考えてみます。リスク用の工数から作業を実施しますが、リスクには１以下の発生確率が掛けられていますので、これだけでは不十分です。そこで、残業やスケジュールの延長によってこの工数を確保する事になります。

このように、従来のリスク見積もりを各作業に割り当てる方法では、うまくいかないのです。

バッファをまとめる

そこで、各作業でリスクを見積もってもそれを各作業に積み上げるのではなく、プロジェクト全体のバッファに積み上げます。このようにすると、以下のようなメリットがあります。

• 理想時間に合わせて作業するので、問題が生じない場合には理想時間で開発できる
• 理想時間を超える理由が示されるので、問題解決や仕様変更の工数が明確になる
• リスクの見積もりが正しければ、複数のリスクが統計的に扱える様になって、問題の発生時にバッファの工数で解決できる可能性が高くなる

つまり、CCPMは理想時間で見積もられる本来の作業と、関連するリスクの見積もりを分離し、リスクを統計的に扱う手法だと思います。

CCPMのバッファを試算する

たとえば、25%の確率で発生する問題の解決に4人日が必要なリスクが４つあるとします。それぞれのリスクを単独で見積もるなら１人日なので、作業の見積もり誤差の解消や細かな仕様変更によってすぐに消えてしまうでしょう。

もし、見積もり通りに４つのうちの一つの問題が発生しても、確保できるのは1人日しかないので、３人日の工数があふれてしまうことになります。

しかし、リスクをまとめておくならば、全体で４人日を確保できます。もし、見積もり通りに１つだけ問題が発生すれば、バッファの工数で問題を解決できますので、計画通りに作業が完了します。

このように、リスクの定義からバッファの取り方を考えると、CCPMがなぜうまくいくかが説明できると思います。

オプションの確保を考える

ここで、オプションを確保する事を考えてみます。オプションを確保する場合もリスクと同様に考える事ができます。

まず、計画を立てる場合には最も少ない工数ですむ場合の工数で計画を立てておきます。そして、最も多くかかる場合の工数との差分をバッファに積んでおきます。

こうすると、必要に応じてバッファを取り崩して全てのオプション（選択肢）を実現できる様になります。リスクではないので複数を集めて統計的に扱う必要はありません。

ここで大切なのは、オプションを問題にしてしまわないことです。最終責任時点よりも前に決定して作業を開始すればバッファ工数内で納まりますが、仮決定で進めると手戻りが発生します。このような場合はオプションとしてではなく、予めリスクとして見積もるべきでしょう。

アソビは設計するもの

アソビはただの余裕ではありません。鉄道のレールとレールの隙間や、橋脚と橋桁隙間、などの様に熱による膨張や地震の揺れを計算して設計するものです。

開発の見積もりではリスクやオプションを計算して積み上げていました。しかし、それを計画する際のバッファの取り方や最終責任時点の考慮が足りず、うまく実践できなかったのです。

これは人生でも同じです。計画的にアソビを作って勉強をしていれば、多くのオプションを確保できます。しかし、アソビを余裕と考えて無駄に過ごしたり、アソビは要らないと仕事ばかりしているなら、未来はないでしょう。

リーンやCCPMなどトヨタ生産方式につながるもの、それは技術者が本来知っておくべきものかもしれません。

CCPMのグッときた話 - TOC/TOCfE関西分科会 -

「TOC/TOCfE関西分科会～CCPMでもっと工期短縮！！～」に参加しました。

CCPMは以前から記事などで知っていたのですが、大きく誤解していました。工期短縮が目的なので、乾いた雑巾を絞るような方法ではないかと勝手に思っていました。

そんな誤解があったものの、今回はアジャイル開発に興味を持つ人も多く参加されていて、なによりアジャイルラジオの東さんがされていて、なかなか楽しそうなので参加してみました。

CCPMCCPM（クリティカルチェーン・プロジェクトマネジメント）は質的なスコープ変化がなく、外部的な不確実性が少なく、期間とリソースのボリュウムがある程度あり、タスクに依存関係があるプロジェクトに向いている方法です。

CCPMの概要については「情報マネジメント用語事典」、「知っておきたいIT経営用語」、BeingManagementのマンガなどを見ていただくとして、今回の勉強会に参加してグッときた話を私なりの解釈でまとめます。

見える化である

見える化というのは単ある可視化ではなく、問題点が見える様にする事です。CCPMではスコープ(仕様)とリソース(人の割当？)を固定しておいて、納期（期間）を調整します。開発の効率化を実践すべく、目標とすべき計画とバッファを見える化し、時間軸の管理によって問題を明確にします。

従来の見積もりでは、理想的な開発期間と何らかの問題が生じた際のリスクをあわせたおおよその工数を見積もりとしています。CCPMでは理想的な開発期間を目標として線を引き、リスク分はプロジェクト全体の余裕バッファとして管理します。目標とリスクを分離して見える化することで、スケジュールに合わせてだらだら開発する事や、よかれと思って不要な作業をしてしまう事を防ぎます。

また、プロジェクト開始が遅れた際も、プロジェクトバッファはいじらないそうです。これはグラフを用いた管理を容易にするほか、プロジェクトの状況を見える化することが重視されているからでしょう。

計画時に工期短縮がきまる

特定の作業間のボトルネックであるクリティカルパスではなく、プロジェクト全体の期間を決めるクリティカルチェーンを管理します。また、クリティカルチェーンを守るために、チームで協力します。

柴山さんらのインタビュー記事にもありますが、プランニングポーカーを活用されるようです。フィボナッチ数列になったトランプ状のカードを見積もりに応じて示す事で、仕様の認識ずれをなくすだけでなく、より良い方法を発掘します。

計画時に作業の依存関係を認識し、作業の平準化をしながら計画します。それは私がイメージした乾いた雑巾を絞るのではなく、小豆と大豆が入った升をトントントンとつめていくようなイメージを感じました。そこでできたバッファは可視化され、管理されますので、浪費される事なく、結果的に工期が短縮されるのでしょう。

メンバーを活かす

講師が市谷さんと柴山さんだった事もあるかもしれませんが、アジャイル開発の話を聞いているような気がしました。リーンもスクラムもCCPMを包含するTOCもTPS(トヨタ生産方式)から生まれたと言われていますので、当然かもしれません。

マルチタスクになるのであれば、分割してシリアル化します(スクラムでも良く言われる事ですね)。また、理想の開発時間とバッファを分離する事で、リスクを個人の責任からプロジェクト全体の責任へ移します。スクラムを組む様にチームが一丸となり開発に立ち向かいます。

そして、柴山さんの説明の中にあったボスが責任を持つというスタンスは、サーバントリーダーシップそのものだと思いました。

全体を通して

アジャイル開発が納期とリソースを固定し、スコープを調整して機能を積み上げるボトムアップな開発方法であるのに対して、CCPMはスコープとリソースを固定し、納期の調整可能な計画を立てて効率化するトップダウンな管理法です。

ボトムアップな方法は共通化が容易な反面、全体をきれいに構成する事が難しいと言われています。たしかに、アジャイル開発でアーキテクチャが重要だと言われています。

一方、トップダウンな方法は全体がきれいに構成できるものの、冗長なモジュールができ易いと言われています。そこから類推すると、プランイングポーカーを利用してより効率的な方法の発見を目指すことは、トップダウンでは全体を効率化し難い中で、非常に重要な方法なのかもしれませんね。

さて、これまでの思い込みだった「乾いた雑巾をしぼる」イメージですが、すくなくとも柴山さんの発表からは感じられず、どちらかというとより良いチームを構築されている様でした。

そういえばCMMブームの際にも私はCMMにあまり良いイメージを持ちませんでした。しかし、実際にはそれをより良い方向に活かされた方も多くおられました。プロジェクト管理の方法はプロセスプログラミングのツールにすぎず、その方法をどのように実践するかにかかっているのでしょう。

おまけ

最後に、懇親会での話題を書いておきます。CCPMによって工数がかからなくなった場合、その利益はどこに行くのか？という話題がありました。請負なら受けた側の利益になって良いはずですが、お客様が期間短縮のメリットだけで納得していただけるか難しいところがあるかもしれません。

そもそも契約上の見積もりは最長をとるのか、最短か、あるいは平均か、どれがよいのでしょう。また、準委任(期間)契約の場合、売り上げが減る事になりますし、効率化へのモチベーションが低くなる可能性もあります。このように考えると、単純な人月だけではない契約が必要なのかもしれませんね。

そのあたりも含め、今後も実践されている方からもっと色々と聞いてみたいと思いました。