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

適応型ソフトウェア開発 - Adaptive Software Development

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

2003年9月30日 (火)

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

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

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

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

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

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

スポンサード リンク
[ 9月30日全て ]

2003年12月31日 (水)

私的10大ニュース2003

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

[web] WiKicker 公開

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

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

[comp] cool programs

[net] ADSLトラブル

モデム

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

P-in Free 1P

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

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

[comp] ThinkPad X31 2672-PHJ

ThinkPad

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

[camera] TC-1GR1s修理

TC-1 GR1s

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

GR1s修理

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

接眼補助レンズ ドンケ F-2 Ai Nikkor 45mm F2.8P

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

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

[misc] レザークラフト

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

LEATHERMAN MICRA 革ケース ツインメイトカバー SureFire エクゼクティブ・エリート E1e + KL1 レザーケース マグライト ソリテールケース Leatherman juice S2 レザーケース Arc-LS 用レザーケース

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

LEDフラッシュライトに興味を持つ。 SureFire E1e + KL1ARC-AAAArc LSL-P などを購入。

SureFire E1E-HA Arc-AAA Arc LSL-P

[ 12月31日全て ]

2004年3月29日 (月)

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

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

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

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

postmortem session

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

[ 3月29日全て ]

2004年5月25日 (火)

ピープルウエア読了

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

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

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

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


[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

[ 5月25日全て ]

2004年6月11日 (金)

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

rimage:ISBN:4-7973-2107-5

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

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

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

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


[ コンピュータ書籍 ]

[ 6月11日全て ]

2005年10月7日 (金)

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

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

招待状

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

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

セッション

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

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

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

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

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

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

完了

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

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

[ 10月7日全て ]

2005年10月19日 (水)

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

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

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

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

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

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

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

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

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

モデル

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

[ 10月19日全て ]

2005年10月24日 (月)

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

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

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

長所

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

短所

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

効果的に行うには?

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

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

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

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

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

[ 10月24日全て ]

2014年9月29日 (月)

ふりかえり、あるいは検死

10年前に読んだ「適応型ソフトウェア開発」では事後評価セッション postmortem (検死) session と呼んでいて、なんとなくいつも検死というイメージを持っている。 今日はふりかえりの会があったので参加。プロジェクトのリーダーが冷静にふりかえりをまとめていたのは素晴しかった。

個人的にはコンセプトと倫理観の一致は重要だなと改めて思った。あと、「グループシンク」という用語は始めて学んだ。気をつけるようにしよう。

「人は事後評価に対して過度に批判的になる傾向がある。」(記事)

というのを思い出したのはふりかえりの会が終わった後で、よりニュートラルに聞くべきだったなというのは反省点。おつかれさまでした。

[ 9月29日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.116833s / load averages: 0.58, 0.64, 0.80
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker