無料ブログはココログ

« 2014年11月 | トップページ | 2015年1月 »

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

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

目的とワーク

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

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

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

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

20141229_005307

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

ワークの状況

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

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

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

良かった事

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

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

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

課題

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

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

ヒント

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

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

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

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

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

という長所がある反面、

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

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

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

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

おわりに

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

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

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

このエントリーをはてなブックマークに追加


[#TiDD] プロセスモデリングの課題からチケット駆動開発を考える - きょうわたしたちに救い主が生まれた -

管理強化プロセス分割トップダウンとボトムアップ人の協力、とプロセスモデリングに関するアドベントキャンドルの火を灯してきました。

今日はいよいよクリスマス。イエス・キリストの誕生を祝う日です。神様が創ったこの世界は完成に向かっている。どんな事も神様がなんとかしてくれる。ラテン系の楽天さはそんな考えから来ているのでしょうね。

アドベントキャンドルのふりかえり

一方、ソフトウェア開発は何ともならない問題がいっぱいです。今度こそ大丈夫と思っていても、狼男のように突然暴れだします。そこで、狼男を射止める銀の弾丸が探されましたが、そんなものはありませんでした。

そこで、メトリクスによる定量的な管理で暴れだす前に見つけ出す方法や、その影響を伝搬させないようにリリースを守る事や、被害が小さくなるように少しずつ確認しながら開発する方法が考えられました。しかし、いずれの場合でも大切なのは、開発チーム内でコミュニケーションを活発にし、知恵を出し合って互いに協力する事です。

ソフトウェア開発が完成した姿に向かうのであれば、そこにはチケット駆動開発が得意とする以下の要素が含まれるのではないでしょうか。

  • 開発チーム内でコミュニケーションを活発にする
  • 知恵を出し合える
  • 互いに協力できる

プロセスモデリングの課題

これまでに書いたように、プログラムをプロセスのメタファにする事で、新しい世界が広がりました。プロセスをモデリングして記述すれば、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、といった事が可能であるとされました。

しかし、その実現は困難でした。プロジェクトのマスター計画は明らかですが、詳細なタスクの予定や履歴はヒアリングを実施しなければプロジェクトの外部からはすぐにはたどり着けません。また、CMMのレベルアップに2〜3年が必要と言われたように、第3者が記述したプロセスが根付くには長期間の訓練が必要です。

私も作業報告書から知見を得るといった研究をしていたのですが、それなりに工数がかかるものでした。そこに現れたのが、BTS(Bug Tracking System)やバージョン管理ツールの履歴を使うというリポジトリマイニングという方法でした。

リポジトリマイニングがプロセスのデータ収集には効果的です。しかし、そのデータを用いて支援するには詳細な情報を得る必要がありました。

そこでチケット駆動開発

データ収集が容易なリポジトリマイニングがリアルタイムに支援できなかったのは、分析手法が研究段階である事が一因でした。しかし、それだけではありませんでした。現場と共に改善する事が必要だったのです。

チケット駆動開発をやってみて気付いたのは、現場のチームがBTS/ITSを活用してプロジェクトの中心に置いていれば、自分たちでデータを記録し、収集し、見える化し、分析し、解決法を考案し、実施する、というプロセスモデリングの目的を実践できるという事です。

もちろん、環境の準備や技術的な支援など、トップダウンにやるべき事はたくさんあります。しかし、現場の問題を現場自身で解決できれば、より効率的に即時に解決する事ができます。

おわりに

組織の硬直化や非効率性を避けるために、もう何十年も前から「ピラミッド型組織からネットワーク組織へ」と言われていました。しかし、ソフトウェア開発だけは小規模開発を除くとなかなか進みません。

これは、トップダウンのプロセス管理だけを重視しているからではないでしょうか?組織を変えるにはボトムアップの活動も必要です。チームの問題をチーム自身で解決できるように現場のプロセスを支援する必要があると思います。

かつて新人研修のスタッフの作業が大変だった時、テストを隣同士で交換して採点すれば並列処理ができて効率的である事に気付きました。これは一種の自律的な組織で、採点方法を支援すれば結果の管理だけで良くなり、少ないスタッフで全体を管理できるようになりました。

中間管理職が大変なのは下の人が育っていないからです。可能な仕事はどんどん任せて成長を促せば、その立場が人を育ててくれるでしょう。そして任せた本人も、責任を取る度量やツール環境の整備や情報共有の支援などサーバントリーダシップを身につける事ができるでしょう。

今回はプロセスモデリングの課題からチケット駆動開発を考えてみました。トップダウンな管理では難しかった事が、現場で実践したチケット駆動開発によって実践できるようになりました。

自ら問題を見つけて解決し、改善する、そんなチームの能力を最大限に発揮させる「自律的な組織」を実現する上で、チケット駆動開発は一つの「救い」となる開発法でしょう。

Gokoutan2006

:サブタイトルについて

サブタイトルはクリスマスのアレルヤ唱からの引用です。元の新共同訳では以下になります。

今日ダビデの町で、あなたがたのために救い主がお生まれになった。この方こそ主メシアである。(ルカによる福音書/ 02章 11節)

福音というのは英語ではGood news、ギリシャ語ではエヴァンゲリオンです。そして、福音を宣べ伝える宣教師がエヴァンジェリストです。

チケット駆動開発がすべての人の救い主だとは思いませんが、プロセスモデリングにとって一つのGood newsですので、サブタイトルに使わせていただきました。

このエントリーをはてなブックマークに追加


ソフトウェアは人が協力して作る - アドベントキャンドル4本目 -

20141222_003227_2

前回の記事(トップダウンのWF、ボトムアップのスクラム、その成功の鍵)をまとめると、どのような方法であってもトップダウンとボトムアップのバランスが重要という事になるでしょう。WFのアンチテーゼとしてアジャイル開発が扱われ易い理由を歴史にふりかえりながら考えてみます。

ソフトウェアプロセスのはじまり

ソフトウェア工学の分野でプロセスが注目され始めたのは1980年代半ばです。ソフトウェアプロセス国際ワークショップ(IWSP)でオスターワイル(Leon J. Osterweil)氏が

“Software Processes are Software, Too”
(ソフトウェアプロセスもソフトウェアである)

という言ってプロセスプログラミングを提唱したのはこの頃です。

プログラムをプロセスのメタファにする事で、新しい世界が広がりました。プロセスをモデリングして記述すれば、伝える、実行する、議論する、改良する、管理する、支援する、自動実行する、といった事が可能であるとされました。

プロセスモデリング

モデリングをするのであれば、記述言語が必要です。そこでソフトウェアプロセスモデリングの例題(井上ほか, ソフトウェアプロセス, 共立出版, P.209)が作られ、 多くの言語が研究されました。

例題では基本的なスケジューリング、工程とそのレビュー、監視、といった基本的なプロセスの入力、出力、責任、制限、が定められたほか、成果物やスケジュールの変更などが定められました。

その中には、実行中のダイナミックな変更も示されたので、リフレクション可能な高度な言語が提案されました。

このような言語は現場のソフトウェア開発には直接役に立っているとは言えないかもしれません。しかし、CSCW(Computer supported cooperative work)、エージェントシステム、ワークフローシステムなどにその概念が活かされていると思います。

CMM(Capability Maturity Model)

IWSPではハンフリー氏もCMMの段階モデルを提案されていました。その後、それまでのソフトウェア工学の成果をCMMの段階モデルに整理して「ソフトウェアプロセス成熟度の改善」を出版されたのは1989年のことでした。

その後1990年代になって、DoD(米国防総省)が発注先の選定にCMMのレベルを利用する事になり、CMMブームが訪れました。書籍の「ソフトウェアプロセス成熟度の改善」にはプロセスモデリング、スパイラルモデル、プロトタイピングなどが含まれていました。しかし、ブームになったCMMはもともとは政府のソフトウェア開発請負業者を評価するためのツールなので、プロセス監査を中心としたものでした。

日本では古くから各企業で開発標準が定められ、メトリクスの収集、改善活動が行われていました。ソフトウェア工学の成果をより多く体系的に取り入れることのできるCMMは、日本でも改善のベンチマークや参考としてブームになりました。

アジャイル開発

2000年頃になってCMMおよびその後継のCMMIのアンチテーゼとしてちゅうもくされたのがアジャイル開発です。アジャイル開発はアジャイルソフトウェア開発宣言にあるように、従来のプロセスや計画重視ではなく、コミュニケーションや変化への対応を重視し、動くソフトウェアを協調して開発するものです。

アジャイル開発をプロセスモデリングの観点で考えると、イテレーション毎に変更点を定期的に儲ける事で、難しいと言われたプロセスのダイナミックな変更を避けていると言えます。いわば、塗り壁の目立つところにひびが入らないように、目地を付けるようなものでしょう。

アジャイル開発は、CMMのようにプロセスを管理することで標準から外れないようにするものはなく、プロセスの混乱を避ける最低限のフレームワークを定めて、人を中心としてうまく実行できるように導くものと言えるでしょう。

TSP(Team Software Process)

このように書くとCMMはあまり良くない、アジャイル開発が良いと思われるでしょう。私もTSPを知るまではそうでした。組織プロセスを改善するCMMを提唱したハンフリー氏は、チームにはTSP、個人にはPSPという枠組みを作られました。

PSPでは開発者が自律的に定量的な管理を行い、TSPでは定義されたプロセスやフレームワークを提供してチームを構築します。しかし、そこには人を重視することが書かれています。

TSPガイドブック:リーダー編 (IT Architects'Archive) を読んだときは驚きました。サーバントリーダシップのようなリーダに求められる大切な事がたくさん書かれていたからです。

この本を読んでから、CMMの見方が変わりました。かつての日本の製造現場ではQC活動が盛んでしたが、CMMのブームに乗ってしまったことでその文化を失ってしまったのだと思いました。

おわりに

仕様の変わり易いソフトウェアで、小さく始められるなら、アジャイル開発はふさわしいでしょう。しかし、仕様が安定している、あるいは、安定していない部分が局所的で、最初にそれなりの規模が求められるなら、管理が必要になります。

しかし、チームの能力を引き出すには、小規模に分割して統治しておき、チームは自律的に動けるように導くと良いと思います。

ソフトウェアは人が協力して作るものです。問題に気付きながら「言わんこっちゃない」と思うチームより、進んで情報共有できるチームが良いでしょう。

いよいよ4本目のアドベントキャンドルに灯りました。街の中はクリスマスのかざり(注参照)でいっぱいですね。最後に聖書の言葉を紹介して終わりたいと思います。

「神の国はあなたがたの間にある」(ルカ17・20-21)

良いクリスマスをお迎えください。


:クリスマスのかざり

サンタクロースが聖人の名前である事は有名ですが、クリスマスツリーがカトリックでは正式な飾りでない事はあまり知られていないでしょう。 ツリーのトップにある星は当方の3人の博士を導いたベツレヘムの星にちなんだもので、Wikipediaによると元々はゲルマン民族のお祭りから来ている様です。この辺は1本目で紹介したクリスマスの起源と似て政治的ですね。

このエントリーをはてなブックマークに追加


トップダウンのWF、ボトムアップのスクラム、その成功の鍵 - アドベントキャンドル3本目 -

20141214_221245

左はアドベント(注参照)の日めくりであるアドベントカレンダーの写真ですが、この記事では週毎のアドベントキャンドルを灯しています。今回はプロセスプログラミングの視点でウォーターフォール開発とスクラム開発を考えてみます。

特徴

ウォーターフォール開発 (WF) ではトップダウンに管理され、スクラム開発ではボトムアップに自律的な管理をします。プロセスをプログラミングのメタファで考えると、特徴は以下のようになります。

トップダウン(WF)
全体の統率が取れ、一貫性が得易い。その反面、同じような機能が複数分散する事がある。

ボトムアップ(スクラム)
共通化が行い易く、無駄のない仕組みが作り易い。その反面、全体で一貫性のある仕組みが作りにくい。

より良くするには

トップダウンとボトムアップは古くから議論されています。どちらにも良いところがあるものの、一方だけでは良いプログラムはできません。主なアプローチがどちらであるにせよ、他方の要素を取り入れる事が求められます。

トップダウン(WF)
構造化設計においてもデータモデリングが重視されました。同じように、情報のモデリングを行い、処理の共通化と一元化を実現すればより良くなる可能性があります。

ボトムアップ(スクラム)
ボトムアップの方法ではトップダウンの要素を少し入れるだけで、全体の見通しが良くなります。実際、スクラムのスプリントとバックログの仕組みは、全体の見通しを良くし、開発者の行動はチームに任されています。

成功の鍵

以上から成功の鍵を考えると、WFにおいては情報のモデリングと情報の共有がポイントでしょう。チケット駆動開発はその解決策の候補の一つです。

スクラム開発に置いては、チームに任された改善活動が成功の鍵でしょう。それぞれのチームがプロセスを改善する中にも横断的な関心事(アスペクト)がありますので、無駄に再発明することが無いように社内に限らず情報共有の場を持つ事が求められるでしょう。

おわりに

今回はプロセスプログラミングの視点でウォーターフォール開発とスクラム開発を考えてみました。WFにはチケット駆動開発が、スクラムにはアスペクトを維持する活動が成功への鍵だと思います。

WFとスクラムの違いにはプロセスのプログラミング方法だけでなく、管理するか導くかという実践方法の違いもあります。WFはメトリクスで管理し、スクラムはファシリテーションで導きます。すでに長くなりましたので、このお話は次回に回します。


:アドベント(待降節)は年初め

クリスマスは日本ではお正月前のお祭りですが、キリスト教文化ではクリスマスの4回前の日曜から始まるアドベントが年初めで、お正月はあまり祝いません。

そのかわりに、クリスマスよりも大切なお祭りがイースター(復活祭)です。成人が入信する際に行われる洗礼式は、クリスマスよりもイースターで多く行われます。

ただ、イースター前の40日は四旬節といって肉食をやめたり断食をする期間なので、カトリックの多い国ではその前にカーニバル(謝肉祭)で騒ぐ様です。

このエントリーをはてなブックマークに追加


プロセスを分割してリリースポイントを作る - アドベントキャンドル2本目 -

20141207_213437_2

前回に続き、クリスマス(注参照)に向けてのアドベントキャンドル2本目です。

プロセスと言うと管理対象のように思われるかも知れませんが、戦略的に実行するものです。プロセスをどのように構成・再構成するかによってプロジェクトの成否が変わります。今回は納期にリリースが間に合わなくなった際に、戦略的にプロセスを分割してリリースポイントを作る方法を説明します。

納期とリリースを分けて考える

プロジェクトの制御要素には、品質・リソース・納期・スコープがあります。このうちの納期だけを固定的に考えず、リリースを分けて考えます。

いわゆるSystem of systemsとよばれる複数のシステムから構成されるシステムでは、システムの結合開始がボトルネックになリ易く、リリース時期を守る事が全体の効率を高めます。

また、会計や学校のシステムなど年度に関わる業務においてもリリースの遅れは許されません。業務が滞ってしまうからです。

そこで、納期、つまり開発の完了は遅れても、システム間の結合や業務の開始であるリリースだけは守らないといけなくなります。

プロセスの分割

ここでいうプロセスの分割はWBSを書く場合とは異なります。WBSでは上位のプロセスや成果物がもれなく計画・見積もりできるように詳細化しますが、リリース時期を守る場合は無理やり分割することでリリースポイントを作ります。

上にあげたプロジェクトの制御要素のうち、納期を除いた品質・リソース・スコープを基準にプロセスを分割できます。それぞれにメリットとデメリットがあります。

品質

方法:テストレベルを詳細化して分割する。

例:正常系テストの完了時点でリリースする。長期ランニングテストの前にリリースする。など。

メリット:システム間結合の実施が可能になる。

デメリット:障害対応によってリリース後のテストが進まなくなる可能性がある。

TIPS:既知の障害を伝えておくと対応の負担が減る。

リソース

方法:リソースそのものは増やさざるを得ないので、リソースを割り当てるタスクを分割します。

例:対象の業務知識を必要とするタスクとあまり必要としない作業に分割して増員を容易にします。

メリット:対外的な全体計画をあまり変更せずに実施できる。客先へのアピールになる。

デメリット:最も生産性が低くなる方法。単純作業がうまく切り出せなければ、増員によるコミュニケーションや管理の負担によって逆効果になる事も少なくありません。

TIPS:ファイル共有によるコミュニケーションは破綻し易いので、予めチケットシステム等を導入しておくと連絡、質疑応答、進捗管理、などの破綻を少しは押さえる事ができるでしょう。

スコープ

方法:リリースする機能や成果物を分割する。

例: リリース時点で実行できるものとできないものを分ける。成果物のうち、完成しているものと完成していないものを分ける。

メリット:リリース内容が明確。体制を大きく変えなくて良い現実的な解決法。

デメリット:必要なものを限定できなければ実施できない。

TIPS:全ての機能が必要な場合は、機能ごとに品質レベルを変えることで全体スケジュールに影響を与えずにすむ場合がある。

おわりに

プロセスの分割は新しい方法ではなく、多くの管理者が工夫しながら実践されているでしょう。しかし、毎回、再発明するのではなく、整理する事で、伝達可能になり、様々なノウハウが集まり、より良く改善できるようになると思います。

今回説明した方法のうち、リソースによる方法は増員を前提とした一般的な方法でしたが、必ずしも成功しません。これは品質や機能によりプロセスを分割した場合も同じです。プロジャクトの状況に応じて、分割方法を選択し組み合わせる必要があります。

また、プロセスを分割した場合は通常の管理だけではうまくいきません。他チームを含むステークホルダーとの調整が必要になるほか、開発者と意見が食い違わないように開発作業の理解が必要でしょう。

プロセスと言うと管理の対象の様に思われる方が多いかもしれません。しかし、ここに挙げたように実践方法を整理して支援をすれば、経験の少ない管理者でもピークの人数を減らして効率を向上できる可能性があります。それは、プロセスモデリングの効果です。

次回は、プロセスのガードとドライブについて説明する予定です。


参考:CCPM

CCPMではリソースを固定して時間軸(リリース)を変化させると言われます。しかしその意味は、全体のリソースではなく単位時間あたりのリソース、つまり、体制(人数)を変化させないという事です。

CCPMは各プロセスにある理想見積もりの工数とバッファの工数を切り分けて、バッファの利用を変化させますので、体制を固定してリソースの配分とリリースを変化させる方法と考える事ができます。これもリソースの分割と考える事ができるでしょう。


:クリスマスとクリスマスイブ

クリスマスというのは「Christ(キリスト)のmass(ミサ)」という意味で、キリストの誕生を祝う日の事です。誕生日ではありません(さすがにベツレヘムでも12月25日に馬小屋で生まれると命の危険があるでしょう)。

クリスマスイブというのは12月24日の夜の事ですが、教会歴では12月24日の日没からがクリスマスなので前日ではありません。祇園祭に宵々山はあっても、クリスマスイブイブは誤用です。

ちなみに、12月25日はキリスト教がローマ帝国の国教となり、ミトラ教の太陽神のお祭りができなくなったので、その日をクリスマスにあてはめたそうです。意外と政治的な背景があるものですね。

このエントリーをはてなブックマークに追加


« 2014年11月 | トップページ | 2015年1月 »