khara@fmsc's weblog

とあることで、クリティカルチェーン(Critical Chain)の話を持ち出すことになった。

実は数年前に開発プロセス論議でいろいろと調査をしたことがあった。そこでなるほどねと思ったのが、このクリティカルチェーン・プロジェクト管理(CCPM)だった。これがどんなものであるかは、このブログの記事内容として説明することに意義を感じないので、ネット検索とか書籍を参考して頂くとして。

「なぜ、プロジェクトは予定通り進まないのか？」ってタイトルに惹かれるのであれば、とりあえず以下のURLのコンテンツが良いかな。

http://www.atmarkit.co.jp/aig/04biz/ccpm.html

さらに、実際にどのように余裕(バッファ)を管理するのかってイメージを知りたければ以下のURLとか。

http://www.soyu-ec.co.jp/toc/toc-top.htm

あとはネット検索、ググるってやつですね。

参考書籍は当然これ。
「クリティカルチェーン──なぜ、プロジェクトは予定どおりに進まないのか？」エリヤフ・ゴールドラット

えっと、ちなみにこの本、ソフトウェア開発のコーナーに行っても置いてないかもよ。生産管理とかのコーナーにいかないと。少なくとも丸善はそうだった。なので、従来のプロジェクト管理やソフトウェア工学的なものでなく、新しい視点と発想を与えてくれると思う。

クリティカルチェーンや制約理論だけでなく、生産管理とか製造業系の工程管理は、それなりに参考になる。いつまでもベルトコンベア方式(ウォーターフォール型)でやってるわけじゃないみたいだし。セル生産方式とか、多能工とかね。アジャイルに近いし。あとトヨタの生産方式とか。そのあたりはまた時間があれば記事にしてみます。

そんなことで、今日は、クリティカルチェーン、ざっくりと押さえておこう。

三位一体。普通の事ですが...今の日本のソフトウェア開発に必要な思想と思う。

三位一体とは、宗教的には

「神・キリスト・聖霊が本質的に一体であり、実体は三つの位格によって表れると考える教え(*1)」

ですが、ここでは単に、

「３つのものが結びつきがあって１つのなにかをなす(*2)」とか「三つのものが一つになる（心を合わせる）こと(*3)」

と言う考えや教えみたいな意味で、この言葉を使っています。

ソフトウェア開発で言う三位とは以下の３つ。

・管理 (プロジェクト管理/開発管理)
・仕様/ドキュメント (要件/設計/仕様)
・ソース (プログラム他、実装物)

いずれかが欠落していると全て上手く行かないとか、分業・責任範囲の明確化も大事だが一体であることの知識と認識を失ってはならないとか、みたいな。。。

誤解の無いように。ここで言いたい三位一体とは、３つを１つに統合と言うような考えではない。３つの各位はそれぞれ認められており、お互い考慮・尊重というか、相互依存の運命共同体というか、より高い視野であり、１つのことを多面的に見るアプローチや思考を指しています。

それに、普通の事なんですが、そもそも一体なはずなんです。いつの頃からか昔からか、責任という壁で分離されてしまって。責任範囲外のことは余計な精神的負担や金銭的工数になるので協力に消極的であったり拒絶したり。あるいは、一体とは程遠いので、歪みが出るの。それとも、業界の激しきモラルの低下現象なのか。

これからの日本のソフトウェア技術者は三位一体を語れるようになるべし、と思う。特に、上流ばかりに流れたり、管理型の開発ばかりに流れたり、今の日本のソフトウェア技術者は、空洞化していると感じるから。それに、３つを体得しないと、アジャイルなんて実践出来ないから。少なくともスーパーエンジニアを目指しているのなら。

上流から下流までアジャイル的に同じ人間がこなすことも１つの解。ただ、日本業界一般としては分業体制の中で解決法を探る必要があり、せめて共存共栄の精神のもとで各位の使命をまっとうするべし。

三位一体の思想。今の日本のソフトウェア開発に必要な思想と思う。

でも、普通のことなので、偉そうにアピールしても仕方ないか。説教くさいのは好きじゃないし。あとは自分で考えて。。。

*1 wikipediaなどより引用。文言は文脈に合わせて変更した。

*2 はてなダイアリーキーワードより引用。

なお、三位一体は、英語では、TRINITY(トリニティ)。
私のハマった映画「マトリクス」の登場人物の女性(NEOの恋人)がトリニティって名前。

*3 Microsoft Bookshelfより引用。

最近、弊社のラボ活動として、新しく「軽量なプロジェクト管理フレームワーク＆キット」をテーマに活動に取り組んでいます。

世の中には、プロジェクト管理の知識体系として有名なPMBOKがありますが、やはり一般的な表現になってしまいますが、「重厚」、つまり、ヘビーなわけです。ヘビーなプロジェクトには参考になるとは思うのですが、軽めのプロジェクトには、当然ながら、逆に重荷となるわけですね。そこで軽量なプロジェクト向けのマネジメントフレームワークとかが欲しいわけです。

それじゃあ、PMBOKとかをミニマムセットで使えば良いじゃん、いや、そうじゃなくって、軽量には軽量なりのフィットする枠組みがあるわけです。「大は小を兼ねる」と、心地が悪いのです。軽量という言葉がよろしくなければ、何を重視するかの観点が少し違うのです。あるいは「軽快」って用語なんてどうでしょう。

開発プロセスの領域では、ウォーターフォール型とかRUPとかの重厚(ヘビーウェイト)な開発プロセスに対して、「アジャイル」って呼ばれる軽量(ライトウェイト)な開発プロセスがありますが、別に「純粋なアジャイル」のプロジェクト管理のことを指しているわけではありません。テーマの空間領域が違いますからね。この表現でわかってもらえますかね。

どちらかと言うと、従来のオーソドックスなプロジェクト管理をベースに、軽量化したものとでも言いましょうか。少なくとも、「変化への柔軟性」とか「暗黙知」を前面に押し出すようなことはしないでしょうね。ドキュメントも書きますよ。ただし、軽量版ですが。

また別の観点で重要なポイントがありまして、「実践」で役に立つものを探求していきます。知識を身に着けたいだけであれば、本(書籍)を読めば良いわけです。本みたいな内容を活動成果としているわけではないです。出来れば、ドキュメントテンプレートなどで、「実践キット化」していく意図をもって活動しています。

そんな感じなラボ活動、テーマは「軽量なプロジェクト管理フレームワーク＆キット」。こういうものには名前を与えてやる必要があります。コードネームってやつですね。

「Ｍ(エム)」ってので行きますか。「いろは」の”い”みたいな意味で、ManagementのM、マネジメントのＭ(エム)ぐらいは、押さえておきましょうってことと、軽量なのでMぐらいでManagementの完璧な全部は入れないよってこと。（あと、ＳＭのＭじゃないよって、トーク・ネタで使えるでしょうし。）

ということで、「Project M(エム)」ですが、スコープを絞ると、今のところ、以下のような感じとなっています。

・軽量(ライトウェイト)

小規模プロジェクト。規模の定義はしていませんし、規模というより、いろんな意味で、軽めのやつです。少なくとも、人命とか社会インフラに関わるようなミッションものではないこと。

・ソフトウェア開発プロジェクト

システム/ソフトウェア開発のプロジェクトを対象領域にしています。もっと絞るなら、一般的なオーダーメイド型の受注開発、いわゆる受託開発ってやつですね。プロジェクト管理一般論では分かりづらい。

・内なる欲求からのプロジェクト管理

組織的な品質保証への取り組みとか言ったような、第三者・外部からの監視・監査的視点ではなく、開発プロジェクトのメンバとして、内なる欲求から産み出されるプロジェクト管理。管理という用語が相応しくなければ、プロジェクトの計画と運営ものが中心となるでしょうね。

ちなみに、FMSCでは、開発プロセスの領域として「Recipes」と言う体系化されたパッケージがあります。いわば、開発プロセスのフレームワーク＆キットですが、「Ｍ」は「Recipes」とダブルところもあるのですが、プロジェクトマネジメントのフレームワーク＆キットです。

今のところ、そんな感じです。。。

以上、「軽量なプロジェクト管理フレームワークへの探究」、いや、「探究心」と言うよりも、これはエンジニアとしての「向上心」を持った意識的な取り組みですぞ。