リーンソフトウェアについて1「無駄について」

MOONGIFT.dev @moongift_dev

今回は「リーン・ソフトウェア開発」の紹介。MOONGIFTではリーン・ソフトウェア開発の社内教育やプロジェクト管理を承っております。ご用命は @moongift までお願いします。 #twicus

MOONGIFT.dev @moongift_dev

「リーン」とは無駄のない、という意味。つまりリーン・ソフトウェア開発とは無駄なことはしないプロジェクト管理手法のこと。 #twicus

MOONGIFT.dev @moongift_dev

その根底にあるものとしてトヨタのカンバン方式が挙げられている。後工程で必要なものをだけを提供することによって、無駄な開発や作業を防ごうとする。逆に言えば後工程で必要なものは素早く用意する必要がある。 #twicus

MOONGIFT.dev @moongift_dev

基本は10個あるので、それぞれを説明していく。とりあえず今回は「1.無駄の認識」のみ。無駄には7つの無駄が定義されている。未完成作業、余分な機能、再学習、引き継ぎ、タスク切り替え、遅れ、欠陥となっている。 #twicus

MOONGIFT.dev @moongift_dev

「未完成作業」とは顧客に納品されていないもののこと。単なるコーディングからはじまって、単体テスト、連結テストなど様々なテストを経て最終的に納品、運用までいく。この途中工程にあるものは無駄。 #twicus

MOONGIFT.dev @moongift_dev

作るものは顧客のためになるものであり、それはすぐに納品されなければならないというのがリーンの考え方。一気に10開発して納品ではなく、段階的な納品を勧めている。 #twicus

MOONGIFT.dev @moongift_dev

ウォーターフォールで失敗する場合、この段階的納品を経ないために完成してから「思っていたものと違う」とか「既にフローが変わっている」なんて事態に陥る。これを細かく確認しながら見ていくことで防ぐ。 #twicus

MOONGIFT.dev @moongift_dev

「余分な機能」自体も無駄と考えている。システム開発において、2割の機能で8割のニーズを満たせるとはよく言われる。イテレーションの中で余分な機能を見極め、実装しないのが無駄を防ぐ方法。 #twicus

MOONGIFT.dev @moongift_dev

顧客の妄想を全て実装するのがSIerのすべきことではない。システムの専門家として適切なレベルでのニーズを満たす方が重要。なのに仕様が膨らめばお金になるからとどんどん膨らませる輩が多い。 #twicus

Wizard @gameeffect

@moongift 契約段階で、仕様書までとかの区切りを設けてますけど、お客はそんな事忘れて後工程で文句言ってきますよ。特に金融、官公庁のお役所人間たちはｗ

MOONGIFT.dev @moongift_dev

「再学習」の無駄とは、既に一度答えの出ていることを繰り返すこと。個人レベル、チームレベル、部署レベル、会社レベルでのナレッジ共有ができていないと何度も同じことを繰り返す。 #twicus

MOONGIFT.dev @moongift_dev

縦割り、チーム体制を厳しくするとこの再学習コストがどんどん膨らんでいく。社内勉強会であったり、ナレッジマネジメントシステムの導入、部署を越えての情報共有などで防げるようになる。 #twicus

MOONGIFT.dev @moongift_dev

「引き継ぎ」の無駄とは、そのまんま。引き継ぎを行うとどうしても暗黙知がこぼれ落ちてしまう。作業の縦割りもその問題に陥りやすい。例えばテスターや運用チームにも仕様、開発時点から加わってもらうようにする。 #twicus

MOONGIFT.dev @moongift_dev

@SekaiDeSaisin ？仕様書までの作成という契約ではなくですか？

MOONGIFT.dev @moongift_dev

早い段階から加わってもらうことで文書化されない暗黙知を含めて知ってもらう必要がある。ドキュメント化で克服するというのは、これまでの経験上ではまず不可能。 #twicus

MOONGIFT.dev @moongift_dev

「タスク切り替え」の無駄。なぜか出来る人に限ってマルチタスクでも動けると考えている。実際にはそんなことはない。シングルタスクで集中して片付ける方が効率的。切り替えコストは意外と大きい。 #twicus

h12o @h12o

ドラッカーの『プロフェッショナル』にも同じことが書いてあったような…耳が痛いです。反省。 RT @moongift:...

れいな@底なし沼の魔女 @MegaBlackLabel

@moongift 企業の社長さんがマルチタスク信奉者だったりすと、大抵どっか破綻しますね　 #twicus

MOONGIFT.dev @moongift_dev

@h12o 非公式RTだと元のツイートが分からないので何も言えませんw

MOONGIFT.dev @moongift_dev

@MegaBlackLabel 1つの作業が1週間かかるとして、3つの作業を3週間平行で終わらせるのは困難ですね。大抵どれも60%止まり。むしろ一つずつこなして2つ完了、一つは40%のがマシです。

Wizard @gameeffect

@moongift 仕様書までって契約なんですけど、その後もやる事はほぼ決まってて、結局ただお金貰える機会を増やしてるだけって感じです。払いたくないって後でごねられないために。だから、仕様は結局、土壇場で変えられてしまってたりします。しかも顧客のミスとか用件でｗ

たけだっちぃ（ちっちぃ） @yasutkd

@moongift そうですね、ドキュメント化作業で破綻してしまうｗできる限りドキュメントを残したいのは山々だけど。

まっきゅ @maqmakmac

@moongift お金になるから膨らませる…ちゃんと戦略持ってコレをやって儲けてるなら「まだ」良いんですが、ただ言いなりで膨らませるのが多いです＞＜。で、泥沼へｗ

れいな@底なし沼の魔女 @MegaBlackLabel

@moongift このムダと判断した機能について、どうやって顧客を説得するかのノウハウが有るならば、ご教授して欲しいところです。実はその作業が一番骨が折れる、というか心が折れるので、、、orz

Wizard @gameeffect

@moongift もっというなら仕様書が出来る途中から開発始めちゃってるんで（それぐらいスケジュールがバカ）結局、形だけ契約があるといった状態でしたよ。今はそこ離れましたけどね。リソースもまともに無い状態でかつかつで開発するという死にたくなるような環境でしたよ