BP Study #18でプレゼンしたリーンソフトhウェアの資料です。問題のある表記、図は省かれています。

1. リーンソフトウェア開発
MOONGIFT 中津川篤司
2009年2月16日月曜日

2. みなさん！
2009年2月16日月曜日

3. 不況です！！
2009年2月16日月曜日

4. プロジェクトが火を噴いて
いる場合ではありません！
2009年2月16日月曜日

5. リーンソフトウェアを
学んで乗り切ろう！
2009年2月16日月曜日

6. リーン（Lean）とは？
無駄のないこと
無駄を知り、無駄をしない
2009年2月16日月曜日

7. 元々の由来
むかしむかし、あるところにおじいさ
んとおばあさんがいました…（中略）
（中略）…そしてカンバン方式がうまれ
ましたとさ、めでたしめでたし
2009年2月16日月曜日

8. カンバン方式は生産業向け
システム開発って生産業？人力集
約型？
人++って火を噴くよね？
人→人であるべき
2009年2月16日月曜日

9. リーンはソフトウェア化
開発向けカンバン方式
ソフトウェア開発は労働集約ではなく、料理
で言う所のレシピの作成
研究ともリサーチとも違う
2009年2月16日月曜日

10. 第一人者
Mary Poppendieck
元3M
Tom Poppendieck
夫婦
2009年2月16日月曜日

11. リーンとはなんぞ？
2009年2月16日月曜日

12. ルール (1)
ムダをなくす
品質を作り込む
知識を作り出す
決定を遅らせる
2009年2月16日月曜日

13. ルール (2)
速く提供する
人を尊重しろ
全体を最適化する
2009年2月16日月曜日

14. ムダをなくす
2009年2月16日月曜日

15. システム開発のムダ
後で使うかも的な機能
見返すことのないドキュメント
よく変更されるタスク管理
複雑さ
2009年2月16日月曜日

16. 7つのムダ
未完成の作業のムダ
余分な機能のムダ
再学習のムダ
引き継ぎのムダ
タスク切り替えのムダ
遅れのムダ
欠陥のムダ
2009年2月16日月曜日

17. 未完成の作業のムダ
コード化されていないドキュメント
同期されていないコード
テストされていないコード
ドキュメントのないコード
導入されていないコード
2009年2月16日月曜日

18. 余分な機能のムダ
大野耐一曰く、作り過ぎが製造における7つの
ムダの内、最悪のムダであると強調
経済的必要性、常識的に判断して不要な機能
は削ってしまう方が良い。
2009年2月16日月曜日

19. 再学習のムダ
忘れの防止
既知の情報を適切に組織内で共有化する
2009年2月16日月曜日

20. 引き継ぎのムダ
暗黙知が欠落する
社員が辞める→引き継ぎ→また辞める…
コミュニケーションを増やす（すべてドキュ
メントで対応しようとしない）
2009年2月16日月曜日

21. タスク切り替えのムダ
マルチタスクで動くのは非常に難易度が高い
大抵どれも中途半端
短い周期でのバッチ処理を行う（週ごとに担
当を決めるなど）
2009年2月16日月曜日

22. 遅れのムダ
週末みんなが集まってのミーティング
メールの返事がこない
現場で何も決められない
2009年2月16日月曜日

23. 欠陥のムダ
テストファースト！
エラーは人にあらず、開発プロセスに問題が
ある。
2009年2月16日月曜日

24. 品質を作り込む
2009年2月16日月曜日

25. バグのないシステム
コードを書かない
最初から正しく書く
→ 一度書いたコードを修正しないという意味
ではない
バグを作らないような開発プロセス、
早期のテストを行うシステムを構築する
2009年2月16日月曜日

26. 知識を作り出す
2009年2月16日月曜日

27. 要求定義で終わり？
最初から全てが分かっている人はいない
実際のシステムをみて、そこから徐々に要求
が出始める。
小さく作って早期にリリース
評価とフィードバックを得る
2009年2月16日月曜日

28. 毎日ビルド&テスト
結合テストから素早いフィードバックを得る
ようにする。
2009年2月16日月曜日

29. 決定を遅らせる
2009年2月16日月曜日

30. 状況の変化
オプションを用意する
→ 各オプションの特性を予め把握する
計画は変わるもの。
どこで判断すべきかは経験則
2009年2月16日月曜日

31. 速く提供する
2009年2月16日月曜日

32. 気が変わる
人は気が変わりやすい
ビジネスの変化もある
初期段階で固めた要求が覆ることはよくある
そこも踏まえつつ組んでいくのがプロ
2009年2月16日月曜日

33. LL Beanの場合
青いシャツを注文する
次の日、気が変わったので電話する
「もしもし」「はい、LL Beanです！」
「青いシャツやめて黄色いシャツにするよ」
2009年2月16日月曜日

34. あたし青いシャツさん、
あなたの家の前いるの
2009年2月16日月曜日

35. 人を尊重する
人員のマイクロ管理はやる気をそこない、創
造性をなくしていく
現場に権限を委譲する。
エキスパートエンジニアを育てる
2009年2月16日月曜日

36. 全体最適化
自分の作業だけではなく、チームさらには部
署、さらには会社全体、さらに顧客のビジネ
スまで含んで最適化する
時には利益相反する最適化も
→ 別途交渉する
2009年2月16日月曜日

37. 実際のプロジェクト例
2009年2月16日月曜日

38. 某社プロジェクト
社内ポータルの開発
ドキュメント管理
スケジュール管理
2009年2月16日月曜日

39. 段階的開発
第一回（約2週間）
第二回（約1週間半） → プレリリース
第三回（約2週間） → ベータリリース
第四回（約2週間） → v1.0リリース
2009年2月16日月曜日

40. コーディング量の軽減
フレームワークの利用（Rails）
プラグインの活用
オープンソースの利用
2009年2月16日月曜日

41. オプション
スケジュール機能
Googleカレンダー？
オープンソース？
スクラッチ開発？
認証システム
独自？
OpenLDAP？
シングルサインオン？
2009年2月16日月曜日

42. テストファースト
ユニットテスト中心
RSpecとかユニットテストとか。
コントローラのテストが半端…
モデルにロジックを入れるべき？
2009年2月16日月曜日

43. 気になる料金体系
リリースまでは最低限
リリース＆検収後に残りをもらう（成果報酬
形式）
直取引でもそうしていくべき
2009年2月16日月曜日

44. 感想
変化を自然として受け入れると気持ちがいい
契約よりも信頼
ヘッジをたてるとお互いの信頼を損ねること
になる。
手早く組み立てるくせができる。
DB再構築＆テストデータ再投入の繰り返し
2009年2月16日月曜日

45. 私とリーン
2009年2月16日月曜日

46. MOONGIFTでは受託開発
はほとんどしていない
2009年2月16日月曜日

47. きっかけ
http://www.itmedia.co.jp/enterprise/articles/0812/10/news066.html
目的に見合ったツールとプラットフォームを利用する
リーンおよびアジャイル開発プロセスを導入する
ツールやアプリケーションに対してコンポーネントをプ
ラグ接続できるようにするため、各種の標準に準拠する
スキルを持った開発者を雇う
オープンソースを活用する
配備を最適化する
コンテキストはレンタルまたはアウトソースし、コアア
プリケーションは所有する
2009年2月16日月曜日

48. リーンとオープンソース
オープンソースはオプションとして最適
また会話の元としても有効（それっぽいものを見
せられる）
PHPは採用できるのにそれを使ったオープンソー
スが採用できない？（バグがあるかも？）
2009年2月16日月曜日

49. リーンとエンジニア
金型工
顧客のアバウトなニーズを具現化し、さらに変化に
強くある職人
様々な類似技術を知り、それぞれの特性を把握する
技術要素を知り、数字データを元に採用すべき技術
を提案できる
いかに素早く顧客のニーズに応えられるかを日々研
究
システムありき/言語ありきで話をしない
2009年2月16日月曜日

50. リーンって何なの？
リーンはムダを省くこと
「ムダ」は会社や個人によって変わる
日々継続的な最適化、生産性
を高める継続的な活動
2009年2月16日月曜日

51. まとめ
今更ウォーターフォール型はないっしょ！？
2009年2月16日月曜日

52. まとめ
1冊2,520円！2冊まとめて買えばなんと5,5405040円！
2009年2月16日月曜日

53. 終わり
2009年2月16日月曜日