nDiki : 適応型ソフトウェア開発

適応型ソフトウエア開発、ジム・ハイスミス、翔泳社

コンポーネント ソフトウェア プロジェクト立ち上げフェーズ メール プロジェクトマネジメント プロジェクトデータシート プロジェクト憲章 目標 ミッション ソフトウェア開発 ミッションプロファイル 開発ガイドライン 会議 すごい会議 コンピュータ書籍 リスク 納品 Wiki 開発 事後評価セッション コラボレーション コミットメント 製品 レビュー ピアレビュー ウォークスルー UML ゆとりの法則 ピープルウェア ガントチャート

■ 適応型ソフトウェア開発読了

昨日電車の中で適応型ソフトウェア開発を読了。 って 買ったのは8月21日か。電車の中で読める時に読んでいただけとはいえ随分かかったな。

しかし適応型ソフトウェア開発、しんどそう。 カオスの縁でやっていけるかなぁ。

全体的には読みごたえがあって買って損なし。 難を言えば

• 例え話にしては登山の話が多すぎ
• 全体的に漠然とした印象 (登山の話だけはすごく具体的なんだけれど)
• (ビジネス的には成功しているといっても)マイクロソフトを誉めすぎ
• 読んでいる途中で思考が脱線。気がつくと字面を追っているものの実際には読んでいないことがしばしば(これは自分の問題。つい現況に照しあわせていろいろと夢想してしまう)

といったところか。 参考にできるところをうまく取り入れてみたくはある。

• すごいKPT事後評価セッション (2005-10-07)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• ワイヤレスモバイルマウスが欲しくなった (2006-01-17)
• 効果的な複数人電話会議は? (2005-10-24)
• ワイヤレスマウス用にバスパワー方式 USB hub (2006-02-23)

■ 私的10大ニュース2003

今年の大事件、マイブームなど。

@ [web] WiKicker 公開

オリジナル WikiEngine 「WiKicker」を公開し、 www.naney.org での運用を開始。 機能追加、負荷軽減など定期的にメンテナンスを継続中。 今年も1年 Wiki の年だった。

12月からは WiKicker ベースの日記システム「DiKicker」の開発も開始。

@ [comp] cool programs

• bogofilter ... spam メールが苦にならなくなった & 楽しくなった。
• SpeedyCGI ... WiKicker の高速化にかなり効果
• Unison ... 双方向同期では rsync より便利。

@ [net] ADSLトラブル

春の数ヶ月間悩まされ続けた。 一度常時接続に慣れてしまうと、もう戻れない。 結局モデムの故障。 その間「@FreeD」も契約してみたが、ADSL復旧に合わせて解約。

@ [comp] 適応型ソフトウェア開発

仕事でのソフトウェアプロジェクトでの適用を開始しはじめてみた。

@ [comp] ThinkPad X31 2672-PHJ

3年ぶりのメインノート PC の買い換え。 Pentium M 1.6GHz + 1GBメモリ。 また3年は頑張ってもらわないと。

@ [camera] TC-1、GR1s修理

愛用のTC-1が故障したため修理。 修理費16,300円也。

妻の GR1s も 修理。

新規に購入したのは、Ai Nikkor 45mm F2.8P(10月12日)、 F3接眼補助レンズ 、 ドンケ F-2 ぐらい。 あまり散財しなかった。

今年は撮影枚数が伸びず。

近所のミニラボが閉店したのも痛い。

@ [misc] レザークラフト

昨年買ったままだったレザークラフトセットを使ってレザークラフトを始めた。 パスケース、LEDフラッシュライトケース x 2、ツールナイフケース x 2、露出計ケース などを製作。 最近は何も作ってないな。 また何か作りたい。

@ [misc] LEDフラッシュライト

LEDフラッシュライトに興味を持つ。 SureFire E1e + KL1 、 ARC-AAA 、 Arc LSL-P などを購入。

• [ WiKicker ] 日記機能開発開始 (2003-12-27)
• ケータイ用にプライベート Wiki を設置 (2008-01-07)
• 私的10大ニュース2004 [ web ] (2004-12-31)
• 社内 Blog 開設 (2006-05-16)
• Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)

■ [ お仕事 ] プロジェクトの事後評価セッション

本日、担当プロジェクトの納品物件の発送が完了したので、終業時刻前の30分間プロジェクトの事後評価セッションをしてみた。

「成功と問題の両方について議論する。(適応型ソフトウェア開発 p.167)」、 「人は事後評価に対して過度に批判的になる傾向がある。セッションが始まる前にプロジェクトについて3つの成功した点と3つの問題点のリストをを作成するように参加者に依頼することで、進行役は、否定的になりがちな傾向を緩和することができる。(適応型ソフトウェア開発 p.168)」

ということで、良い点もきちんと振り返ってみることにした。 たしかにそのおかげで、ぐっと建設的なセッションになった感じ。

@ postmortem session

postmortem は検死という意味もある。 今回ひとまず検死は避けられたようだ。

• すごいKPT事後評価セッション (2005-10-07)
• ストーリーカード・タスクカードを導入した開発の成果物を納品 (2005-11-30)
• コミットメント・リスト vs ガントチャート (2005-10-19)
• 有給休暇 - 納品前の忙しい時期ではありますが (2005-02-08)
• 納品作業 (2004-06-25)

■ ピープルウェア読了

ゆとりの法則より扱っているテーマが広く分量も多いので読み終わるまでちょっとかかった。

「ダメ」なケースがいろいろ書かれているのだが、こうすればヨイというのは逆にあまりない。 結局のところ王道なし。 自分で頭をつかって考えなければいけないということであり、本書もそういう意図で書かれているんだと思う。

ソフトウェアの「品質」についてはバランスが難しい。「適応型ソフトウェア開発」で書かれている品質とあわせて、落としどころどうするのかかがポイント。

ゆとりの法則とあわせて要再読。

[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]

• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• トム・デマルコ ピープルウェア 第2版 - ヤル気こそプロジェクト成功の鍵 (2004-05-13)
• Joel on Software - 必読書 (2008-08-14)
• 熊とワルツを読了 (2004-10-31)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)

■ 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク

• 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク - ソフトバンクパブリッシング

以前からちょっと探していた本。 会社帰りに有楽町の三省堂で発見。

ソフトバンクパブリッシングから出しているからてっきりコンピュータ関連のところにあると思っていたのだが見あたらず、端末で検索したら動物学・植物学関連のところにあるとでた。

創発というキーワードは「適応型ソフトウェア開発」でも何度も出てきているし、ちょっと押えておこう考えている。

それと自己組織化といえば大学時代、研究室に興味を示している友人がいたな。

[ コンピュータ書籍 ]

• 創発 蟻・脳・都市・ソフトウェアの自己組織化ネットワーク 読了 (2004-07-09)
• 第14回産業用バーチャル リアリティ展最終日 (2006-06-23)
• tkh夫妻を囲む会 (2004-01-11)
• 今日のさえずり - 「じゅうふく(重複)」はやはり気持ち悪い (2008-03-21)
• ピープルウェア読了 (2004-05-25)

■ すごいKPT事後評価セッション

先週納品を終えてほぼ完了したプロジェクトについて、冷めないうちに事後評価セッションを行う。 「適応型ソフトウェア開発」に触発されて去年から主に自分の担当プロジェクトで導入しているセッションであるが、今回はこれにすごい会議の手法と、@ITの記事*1で紹介されていたKPT法を組み入れて実施してみた。

@ 招待状

参加者には、以下の事前準備をメールでリクエストしておいた。

• 「あなたが、この会議で達成したい事を考えておいてください。」(すごい会議流)
• 各評価対象について「3つの成功点(良かった点)、3つの失敗点」を事前に考えてください。 (「適応型ソフトウェア開発流」)
  • スコープ、スケジュール、リソース、欠陥レベル
  • プロジェクト運営
  • コラボレーション (スタッフ間)
  • 個人・チームとして学習した点
  • その他 (開発手法など)
• 問題点については「どのようにすれば〜(だろうか)」のかたちに書き換えてください。(すごい会議流)
• 良かった点のうち Keep のものがあるかご検討ください (KPT法流)。
• 問題点は Problem です。(KPT法流)
• 問題点について「次にやってみたいもの(Try)」が思い浮かんだらメモしておいてください。(KPT法流)
• 問題点に関係なく Try してみたいものがあれば、メモしておいてください。(KPT法流)
• 注意点 (「適応型ソフトウェア開発流」)
  • 良かった点を必ず書いてください。(すごい会議にも通じる)
  • 成功点、失敗点については3つ以上でも構いません (その際は、成功点と失敗点が同数程度に)
  • 特定の個人を批評はいけません。
• 事前に考えたメモを K・P・T 別にA5〜A4用紙各1枚程度ずつにまとめてプリントアウトして持参してください (発表時間短縮のため)。

@ セッション

メンバは4人。 ホワイトボードをK(Keep)・P(Problem)・T(Try)の3領域に分割。

それぞれ用意してきたプリントをマグネットや、テープでホワイトボードに貼りつける。4人分ぐらいならホワイトボードに貼れたし、前に集って座れば字もだいたい読むことができた。

【Keep】まず最初に成功点について各自発表。「うまくいっている」ことから開始するのはすごい会議流で。 次のプロジェクトで Keep しておきたい点について確認しておく。

【Problem】どのようにすれば〜でそれぞれ発表(すごい会議流)。この形式で表現することで、アイデアが浮かびやすくなる。アイデアが出れば ホワイトボードの Try の領域に書き込んでいく。

【Try】あらかじめ考えてあった Try をそれぞれ発表。

KPTの発表が終わったら、今度は Try をコミットメント化していく。 「担当」と「期日」を明確に設定 (すごい会議流)。

@ 完了

合計90分。ほぼ予定時間とぴったり。 事前に書いてきた内容をホワイトボードに書き込まずに貼りつけるだけで済むようにしたためかなり時間が短縮できた。

今までの事後評価セッションに比べて次のアクションが明確になり、コミットメント化した事で実行する可能性が高まった。 成功点・問題点をそれぞれ発表して確認しあう段階までだった過去の事後評価セッションよりパワーアップ。

• すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
• すごい会議はじめての全手順(1/2) (2005-06-30)
• 「すごい会議」2度目 (2005-06-03)
• いまいちパッとしなかった「ふりかえり」 (2007-02-28)
• すごい会議の正しい手順 (2005-07-04)

■ コミットメント・リスト vs ガントチャート

会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。

 社内にはコミットメントをコアにした管理手法もあり、
 その優位性は十分に認めている。

 しかし、単純にガンチャートがすきなのである。
 特に見た目、がね。

 -- GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より

とのことだ。 コミットメント・リスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメント・リストとガントチャートについて整理しておこう。

ここで言うところのコミットメント・リストというのはすごい会議で紹介されているものである。

ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。

どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。

@ モデル

コミットメント・リストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。

• 作業時間がある程度精度よく見積もれる
• 作業時間と成果が比例的である

であるような場合はガントチャートで計画しやすい。

逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。

@ ガントチャートを利用したマネジメントの特徴

• マネージャからのトップダウン的なスケジュール向き
• リソースの多重度を把握しやすい (本来はかけもちさせない方がいいと思うが)
• 比較的多人数のチームでもいける
• リソースがタスクに時間を割く割合を設定できる (やろうと思えば)
• 人月計算/コスト積算できる
• プロジェクト外からの割り込みの発生によって狂いやすい
• 成果がみにくい
• チェックしにくい
  • 「進んでますか?」「はい作業中です」「どれぐらい?」「うーん、30%ぐらい」
• ぱっと見、計画できている気がする
• 期間が長いと、チャートが見にくくなる
• 1日単位で見積もりたくなる
• 休日が気になりだす

@ コミットメント・リストを利用したマネジメントの特徴

• 担当の裁量を尊重・重視
• コミットメントのクロスチェックがしやすい (コミットメント、メジャーメントの明文化)
• 期日前にせっぱつまりやすい
• 依存関係が複雑だと把握しにくい
• 専用のソフトウェアがなくても可能
• 他のプロジェクトと兼任しているリソースの稼働状況がわかりにくい
• 線表派からみると計画だと思ってくれないかも

@ 自分がガントチャートでうまくいかなかった点

ソフトウェア開発で線を引いてみたときの感想

• スケジュールの変更があった時に面倒
• 現状とあわなくなってくるとだんだん見なくなった
• 結局だんだんメンテナンスしなくなってしまう
• 進捗チェック時に、ガントチャートで○○%と入力しても適当で意味がなかった

@ コミットメント・リストでうまくいっている点

• 成果が達成できているか、そうでないかが明確
• 達成できていないコミットメントのチェック、フォローができている
• 担当自身が忘れていたコミットメントもクロスチェックで再認識できる
• コミットメント一つ達成するたびに「いい気分を味わえる」

@ まとめ

現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメント・リストベースがかなりイケているように思われる。

必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。

ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。

• ソフトウェア技術者御用達のプロジェクトマネジメントツール TaskJuggler (2007-04-23)
• Joel on Software - 必読書 (2008-08-14)
• ソフト契約と見積りの基本がよ～くわかる本 (2005-10-14)
• すごい会議の正しい手順 (2005-07-04)
• すごいKPT事後評価セッション (2005-10-07)

■ 効果的な複数人電話会議は?

年初あたりから社内で Skype が利用されはじめて、複数人による電話会議もよく行われるようになっているようである。 離れている拠点のスタッフ間での連絡が密になるなど、効果はあるようだ。

しかし自分は特に複数人における効果的な電話会議手法を見い出せていないので、積極的に利用していない。

@ 長所

• 物理的に離れているスタッフを含めた会議が可能
• 既存のインターネット接続上で Skype を使う分には通信コストが余計にかからない

@ 短所

• 顔が見えない
  • 聞いているのか、理解できているのわからない
• 通常の会議より時間がかかる / 同じ時間で決まることがすくない
• 回線断などがあると、しらける

@ 効果的に行うには?

アジェンダにしても参加者の下準備にしても、集合して行う時以上に周到に準備しておく必要があるであろう。 Skype だと気軽に召集できる感があるが、ミーティング中に伝達できる情報量は少ないのだからそれぞれ事前に資料を用意してメールなり、Wiki なりで情報を共有しておく必要がある。

たとえば、共同創造に必要な情報は顔を突き合わせてやり取りしたほうが効果的なのに対して、情報伝達に必要な情報は紙や電子ファイルの形態でも直接やり取りするのと同じぐらい効果的である。-- 適応型ソフトウェア開発 p.119

普通の会議と同様、情報伝達と共同創造の区別が重要である。

いわゆるミーティング、特にコラボレーションが、否定的に捉えられがちなのは、共同創造と情報伝達という2種類の基本的な相互作用が区別できていないためである。--- 適応型ソフトウェア開発 p.118

ほとんどの組織では情報伝達を濫用している。--- 適応型ソフトウェア開発 p.119

• すごいKPT事後評価セッション (2005-10-07)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• 「すごい会議」をしてみる (2005-05-27)
• 私的10大ニュース2005 [ comp ] (2005-12-31)
• すごい会議の正しい手順 (2005-07-04)