Home‎ > ‎Etc‎ > ‎

リーンソフトウェア開発

リーンソフトウエア開発~アジャイル開発を実践する22の方法~
メアリー・ポッペンディーク トム・ポッペンディーク 平鍋 健児 高嶋 優子 佐野 建樹
日経BP社 (2004/07/23)
売り上げランキング: 125202
おすすめ度の平均: 3.5
3 ムダを排除する
3 自分で考えるための本です
3 原典をおすすめします


この本を読もうと思ったのは、ウェブサイト構築においてアジャイル的な手法が使えないか?と考えたから。
結論としては、使えると思っている。
そこで、何処にフォーカスしたらいいかと考えたわけだが、「どうやったら、今より短期間で作れる」というところにフォーカスすべきではないか?というのが今の自分の中の仮説だったり。

TOCもそうだが、リーン生産方式というのも、製造の方にまず適用されて成功し、ソフトウェア開発などのプロジェクトにも取り入れられている考え方である。

リーンソフトウェア開発の骨子

  • 無駄を排除する
  • 学習しながらつくる
  • 決定はできるだけ遅らせる
  • できるだけ早く提供する
  • チームに権限を与える
  • 統一性を作り込む
  • 全体を見る
コレを支えるために、言い換えでもあるけど
  • シンプルに保つ
  • インクリメンタルな開発

無駄を排除する

「顧客の役に立っていないモノは、すべて無駄」

ツール1:無駄を認識する

では、ソフトウェアの無駄とは
  • 未完成の作業の無駄
    • できあがっていないものは価値を生まない
    • リスクの管理でもある
  • 余分なプロセスの無駄
    • 主に、誰も見ない分厚い仕様書・変更が反映されない仕様書、作るときだけ必要な書類とか無駄なペーパーワークで忙殺されてないか?
  • 余分な機能の無駄
    • お客さんからの要望だけど、実際には使われない
    • 高く売りつけるために付けた付加機能
    • あったら便利かも?という誘惑
  • タスク切り替えの無駄
    • タスクを切り替えるには時間がかかる
    • 二つの作業を同時並行させると、リードタイムも長くなる。(どちらも、待たされる時間が長くなる)
  • 待ちの無駄
    • イレテーション()が長いほど、関わる人が多いほど、することが多いほど、発生しやすい
  • 移動の無駄
    • 理想は、お客さんを隣に置いてやることだ。XPみたいに。
  • 欠陥の無駄
    • 欠陥の無駄は、欠陥の影響×発見されずに過ぎた時間
  • 管理
    • 管理は少ない方が良い。管理そのものは価値を生み出さない。
無駄と思われるモノについての問い
  • これは本当に「無駄」だと思うか?なぜか?あるいは無駄と思わないならばなぜか?
  • いったい平均的な週でそれにどれくらい時間を割いているか?
  • その時間を短縮するにはどうしたらいいか?どうすべきか?

ツール:2バリューストリームマップ


価値の付加されていく流れを、プロセスと共に図示する手法

従来手法とアジャイル手法での対比が行われている。

後で、ウェブサイト構築のバリューストリームマップ作ってみる。


学習効果を高める

ソフトウェア開発は、製造プロセスではなく、開発プロセス。
ウェブサイトの設計や立ち上げも、開発プロセスに近い気がする。
運用は、どちらかといえば、製造プロセスに近い部分が多いかもしれない。

ソフトウェア開発での品質とは?「認知統一性」と「コンセプト統一性」

「悪構造問題」=唯一の正しい回答がない問題や、解法にいたる最善の方法のない問題
ウェブサイトをビジネス解決の手段と考えるなら、当然、ウェブサイトも「悪構造問題」の一種だろう。

こういう問題を解決しようとする場合、設計者は高レベルの設計と詳細な解法の間を行ったり来たりする。
トップダウンで 要求>設計>開発>テスト と流れるわけではない。
そもそも、最初に正解を得ている、という仮定が間違っているからだ。(本当は誰もがわかっているはずだ)

ツール:3フィードバック

1年間のプロジェクトをタームを区切らず行った場合、学習機会は要求の段階のみの1回になる。
テストの時に、何かまずいことに気がついても、もう間に合わない。
では、どうするか?

これを、例えば1ヶ月毎にタームに区切って、その度にレビューを行う。
ターム毎に、結果に対するフィードバックを得ることができれば、軌道修正の機会が12回に増えるということになる。
つまり、作りつつ、試してより良い方向に修正していくという、柔軟な対応が求められる、ということになる。
これが、ここでいう学習。

ツール:4イテレーション

製造プロセスで必ず成功するのが、「ジャストインタイムの在庫フローを採用する」こと。
コレに対応する、ソフトウェア開発での手法が「イテレーション」。

従来より短い時間で、ソフトウェアを設計しプログラムし、テストし、統合する。
イテレーションが、プロトタイプと異なるのは、実際の最終成果物の一部を、キチンと動作するように作っているというところ。

イテレーションの手法として、1回のイテレーションの時間を固定するタイムボックス方式と、任意の長さのイテレーションに組み替える方式とどちらがよいかは意見の分かれるところらしい。
まぁ、いずれにしても 1ヶ月とか2週間とか、今までの感覚より短い時間で考える。

最初に、プランニングセッション
  • 機能の難易度、コストと機能の重要性から、最優先のものから開発する。コレにはリスク回避の意味もある。
  • 要求を詰め込みたいという欲求を抑える。あくまでチームメンバーがコミットする範囲とする。
  • イテレーションの途中で、新たな要求はいれない。次のイテレーションまで待つ。
  • 何かが遅れる場合には、スケジュールを延ばすのではなく、間に合う機能だけでリリースする。
  • 要求・スコープは途中で変更される可能性が高い。少なくとも、詳細については詰めすぎない。

結果、うまくいくと

  • クライアントは、システムができつつあることに信用を深める
  • クライアントから、正しいフィードバックを得られる
  • 開発者も達成感を得られる。
  • スコープの交渉がしやすくなる。なぜなら、必要な機能は先に実装されているから。
うまくプロジェクトが収束に向かっているか見る指標としては、
  • バーンダウンチャート 完成していない機能についての、残り人月見積もり
  • 受け入れテストの作成数と成功数

ツール:5同期

これは、複数作業者でひとつのモノを作る際に、避けては通れない話し。
スモークテストとか、デイリービルドとか、本当にやっていくには自動化されたテストツールが必須。

ウェブ構築の場合、何をテストするか問題だけど。

スパニング・アプリケーションということばがでてきたけど、イマイチぴんとこない。
モックアップみたいなモノ?テストツールにも聞こえる。
よくわからん。

マトリクス手法は、各サブシステムのインタフェースとスタブをつくってから、各サブシステムをつくることで、互いの進捗影響などを最小限に抑える方法。
この部分が、遅れやコミュニケーションの問題となりやすい部分でもあるため、リスク回避にもなっている。

















Comments