- 作者: エンジニアマインド編集部
- 出版社/メーカー: 技術評論社
- 発売日: 2007/03/14
- メディア: 大型本
- 購入: 1人 クリック: 7回
- この商品を含むブログ (14件) を見る
この本（雑誌）、すげぇ。珠玉の記事が多数ありますよ。幾つか纏めてみたくなった。とりあえず特集1のエンタープライズアジャイル化計画。
アジャイルプロセスとアジャイル化計画
eXtreme Programmingをはじめとするアジャイル開発プロセスは、通常、ソフトウェア開発プロジェクトを対象とした「プロセス」である。その手法はPDCAサイクルをベースとした、絶え間ない細かな改善活動が中心である。
一方、アジャイル化計画とは、プロジェクトレベルのプロセス改善を起点として、組織全体/組織間の「システム改革」を目指すものである。その手法はPDCAサイクルを拡張した戦略的学習サイクルである。
戦略的学習サイクル
通常のPDCAサイクルは、目の前の問題をスタートにして改善活動を行う。この場合、局所最適化になりやすい。全体としてみたときの大きな最適化を逃してしまう可能性がある。戦略的学習サイクルは
あるべき状態（ビジョン）を大目標として設定し、それに従う価値観とポリシーのみを制約として、個々の局面での戦術はリアルタイムに、自律的に決定するためのサイクルです。
とのこと。PDCAよりも柔軟で広範囲な最適化が可能らしい。
アジャイル化計画における品質
品質を表層品質と深層品質に分けて考えるらしい。
- 表層品質
- 利用時の品質: 有効性、生産性、安全性、満足性
- 外部品質・内部品質: 機能性、信頼性、使用性、効率性、保守性、移植性
- 深層品質
- 利用時の品質: 手触り感、安心感
- 外部品質: 統一性、整合性
- 内部品質: 優秀なアーキテクチャ
アジャイルプロセスは
ユーザーが必要とするだけの表層品質を適切なコストで提供することを目指しています。
かつ
ユーザーをリアルタイムでプロジェクトに巻き込むことによって、深層品質にも手をつけようとしています。
だ。アジャイル化計画では、アジャイルプロセスより更に深層品質を重視する。
＃手触り感って、きっとMacBookをつかっている時に私が感じてるようなヤツだらうなぁ。
アジャイル化計画で重視するもの
アジャイルプロセスで重視するものは
- 人間
- コミュニケーション
- 実際に動くソフトウェア
- 変化への対応
であり、一方、アジャイル化計画で重視するものは
- ビジョン
- 何のために何を目指しているのか
- 局所最適化に陥らない高い位置の視点を得るために
- 文化
- 流れ
- 成果物だけをみてはダメ
- 成果物がどう使われるか？次の価値の流れにどう繋がっているのか？その流れはスムーズか？スピードは？
- 知識
- ソフトウェア自身は実行可能な知識
- つまりソフトウェア開発プロセスとは知識から知識への変換過程
である。
道筋
組織変化の2つのやり方。
- 理想に向かって計画を立て、それに従って全体を一気に変えてしまうやり方
- 悪いところをす少しずつ変えては様子を見て繰り返していくやり方
アジャイル化計画は後者のやり方。なぜならば
- 組織という規模や影響力の大きな実態の変革には前者はリスクが大きすぎる
- （現代的な）組織という複雑なシステムに対処する計画を最初から完全に立てることはできない
- どんな組織も変革すべき点だけでなく、捨ててはならない良い点、良い文化を持っている
からだそうだ。
エンタープライズアジャイルの始め方
全てのプロジェクトで一斉に始めるのではなく、パイロットプロジェクトを1つ選ぶ。
ビジョンを持つ
我々が持つべき3つのビジョンのレベル。
- 個々人がこのプロジェクトに関して持つビジョン: 自分はどうなりたいか
- プロジェクトが共有するビジョン: われわれはどうなりたいか
- 組織のビジョン: 全体として何を目指すのか
プロジェクトの開始時に、これらのビジョンについて話し合い、共有する。
戦略的学習サイクルを回す
PDCAサイクルは局所的な最適化を目指すときには向いている。ただし、大きな方向性は示されている必要があるし、大きな飛躍は苦手。
PDCAの対象が「何をするか（doing）」だとしたら、戦略的学習サイクルの対象は「何になるか（being）」
ビジョンからアジェンダへ
ビジョンを起点にして行動計画へ落とす。ビジョン＝ゴールなので、ゴールから辿って現時点に行き着くまで、行動を洗い出していく。ビジョンを実現するには
- その直前の段階として、何をしなければならないのか（アクション）
- このビジョンを1段階分解するとどのようなサブゴールになるか
- その直前の段階として、どうなっていなければならないか（必要条件）
- ビジョンの実現を妨げているものは何か（阻害要因）
を繰り返し考える。で、注意すべきなのは
- 途中を飛ばさないこと
- 途中で排他的な複数の道が現れてしまった場合にはシミュレーションするか、それが大変ならば適当に「見切る」こと
- 阻害要因はその本質的な原因まで遡ること（一般的には5段階とも言われる）
- アクションにはそのアクションの結果、満たされるべき評価基準を付加すること
- 道ができあがったら、それが可能かどうか逆に遡って検証してみること
である。
＃ここが個人的には一番ぐっときた。素晴らしい。ゴールからタスクを洗い出していくのは結構やるんだけど、これは大変参考になります。
ミーティングの種類
- 確認ミーティング
- 事実の確認だけ
- 収束型ミーティング
- 問題・課題の解決
- 発散型ミーティング
- アイデア出しのミーティング
問題は成長のチャンス
問題が起きたり、失敗するのは良い知らせ。乗り越えれば成長する。
- 問題があったら、それにすぐ気づくことができるようにすること
- 問題に気づいたら、それを明確にして、解決のスケジューリングをし、全員で解決に当たること
- その過程がみんなの記憶に残り、次の機会に活きること
すべてがよく見えるように
- 見えちゃった化: 気づき。
- 見たい化: ああ、あれがもう一度みたい。そのためにはどうすればいいか。
- 見える化: いろんなモノが自然に見える。
- 見ない化: 不要な情報は削ぎ落とす。取捨選択。
- 見えない化: もう見なくてもいい、というか、最初からみんな見えている。
＃見える化、見える化とはいうけれど、こんなにバリエーションが出てくると面白い。
エンタープライズアジャイルを広げよう！
何から始めるか
以下のことをやろう。
- パイロットプロジェクトでやったことを、他のプロジェクトへ
- パイロットプロジェクトでやったことを、組織全体に対して
- 上記2つには整合性がなければならない
- 最終的には組織全体の成果（ビジョンの達成）が必要
プロジェクトを流れで考える
ソフトウェアを開発するというのは、一連の長い流れ。何らかのユーザーニーズから始まり、営業が案件を取ってきて、開発が終了したらユーザーの現場で使えるようにし、そしてユーザーがそれを使い続ける。それを意識すること。プロジェクトだけを最適化するのではなく、全体の流れの最適化を考えよう。そのために、営業担当者や経理担当者にプロジェクトに入ってもらったり、営業や経理を自分達でやってみることで、様々な異なる見方を得ることが大事。
価値の流れを作る
せっかく苦労して作ったのだから、このソフトウェアには何らかの価値がある、と思いたいですよね。しかし、1つの孤立したモノには何の価値もありません。それを誰かが使って、その誰かがまた新たな価値を生みだして（再帰的になっていますね）、初めて価値が生じるのです。
我々は価値の流れのまっただ中にいるのである。流れが淀んだり、止まったりすると、我々の価値もまたなくなってしまう。
- どこで必要以上の時間がかかっているか
- どこで必要以上の資源がかかっているか
- 価値が付加されないのに行われている作業はどれか
- 誤差を生じさせている作業はどれか
これらに焦点を当てることで、プロジェクト内部を価値がスムーズに流れるようになる。
また、組織においては、価値の流れが組織の入り口で複数のプロジェクトに分かれ、組織の出口で合流する。プロジェクト間は、基本的に並列性が高いが、有限のリソース等を巡って競合が起きることも。ここでは、次のようなポイントに注意する。
- 入り口の分岐点
- 出口の合流点
- プロジェクト間の競合
- ポリシーの衝突
- 資源（人、知識）の競合
組織間にも同じような価値の流れがある。主に、顧客の組織とデベロッパーの組織の価値の流れ。
コミュニティを作る
コミュニティは「ミーム」という「文化の遺伝子」のようなものをばらまく手段の一つ。ここで重要なのは、
- 組織横断的。場合によっては、組織すら超える
- オープン
- 熱意を持った人を活かす
である。
