「リーン開発の本質」を読みました

何か発想の転換になりそうなので、「リーンソフトウェア開発」はちゃんと突き詰めていきたいところ。というわけで、次はこれを読んでみました。

リーン開発の本質

リーン開発の本質

そもそもなのですが、リーンソフトウェア開発が全体の中でどういう位置づけかが曖昧だったので、そこから。「リーン」と「アジャイル」の関係とは?:書籍でたどる「リーン」の本質 (3/4) - @ITの以下の画像が、分かりやすかったです。

http://image.itmedia.co.jp/ait/articles/1311/15/hu_tt_aja01.jpg

第2章 原則

検証時の欠陥発見は、当然ではなく、例外であるべきだ。検証がいつも「テストをしては修正する」というサイクルを生むようなら、それは、開発プロセス自体に欠陥があるということである。

欠陥は早め早めに(理想的には作るそばから自動的に)発見・対処できるように、プロセスを作り込んでいくべきだってことですね。思い当たるふしがあったので、今後の参考に。

第3章 価値

トヨタでは、チーフエンジニアがその車種のビジネス上の成功責任を持つ。

(中略)

チーフエンジニアを立てるという手法には、多くの情報を、責任ある一個人の頭の中で統合できるというメリットがある。

「チーフエンジニア」について。以前は、どちらかというとこういうリーダー的なのは不要ではと考えてました。チームメンバーがチームが達成すべきことなどを適切に把握してたら、リーダーはいなくとも進むだろうと。ただ、この本で説明されてた下記の理由を読んで、やっぱりリーダー的な役割はあったほうがいいかなとも思ってきました。

  • 結果責任・説明責任を明確にできる
  • 一個人の頭の中で、多くの情報を統合できる

あと、知らずに何となく感じてたことですが。チーフエンジニアって、スクラムで言うところのプロダクトオーナーみたいな役割に似てるなーと思ってたら、やっぱり関連があったとのことです(参考:株式会社戦略スタッフサービス)。なるほどー。

第4章 ムダ

複雑さを自動化するな

複雑なプロセスや、乱雑なプロセスをただ単に自動化したところで、顧客の役には立たない。ソフトウェアのもつ複雑さというがちがちのよろいで、ムダだらけのプロセスをつつむようなものである。

う、頭が・・・>< CIやビルド周りに興味があるくらいなので、自動化は好きなのですが、これはそうだよねー。

続いては、ムダの話。これは有名な話ですよね、多分。リーン生産とリーンソフトウェア開発の対応表はこちら。

製造 ソフトウェア開発
在庫のムダ 未完成の作業のムダ
作りすぎのムダ 余分な機能のムダ
加工そのもののムダ 再学習のムダ
運搬のムダ 引き継ぎのムダ
動作のムダ タスク切り替えのムダ
手待ちのムダ 遅れのムダ
不良を作るムダ 欠陥の無駄

いくつか、対応付けがいまいち分かってないところもあります。「加工そのもののムダ」に相当するものが「再学習のムダ」だったり。ただ、「作りすぎのムダ」=「余分な機能のムダ」が一番タチが悪く他のムダを引き起こすことがあるというのと、(対応付けは分かってなくとも)ソフトウェア開発のムダに紹介されてるもの自体はその通りなので、ひとまずはそれらのムダを意識して見つけることができるようにというところからかな。あとは、カンバンにも表れてるけど、「在庫のムダ」=「未完成の作業のムダ」らへん。

あと、バリューストリームマップ。これは、カイゼンの基本 | Ryuzee.com (on Azure)で紹介されてたこの本を読んで、別途やってみようと思ってます。

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

トヨタ生産方式にもとづく「モノ」と「情報」の流れ図で現場の見方を変えよう!!

第5章 スピード

要望やタスクを管理する「待ち行列」について。

  1. 待ち行列は短くなくてはならない。おそらく、作業の2サイクル分あたりが適当だろう。その程度の長さであれば、開発プロセスの間中、要求の平均サイクルタイムを管理できる。
  2. マネジャーは、待ち行列にある項目をいつでも改定したり、変更したりできる。しかし、いったんチームがある項目に着手したら、マネジャーが日々の開発作業に干渉してはならない。
  3. チームは、待ち行列から作業をプルし、その作業が完了するまで、一定のリズムで作業を行う。プルシステムによって、作業を許容範囲に収めながら、常にチームに仕事を与えていられるのだ。
  4. 待ち行列ありさえすればチームに対応する時間がなくても、そのうち要求に対応してもらえる、という誤解を与えてはならない。

特に、1, 2が気になりました。1 は、無限待ち行列になってるのをよく見かけますよね。。。意識して制限しないとそうなりがちなのですが、無制限だと全体が見えづらく改善ポイントが分かりづらいとか、待ち行列を見るだけでいやになるとか、あとはリズムが出ないとかも結構大きいことかも。2 は、仕掛り始めたものをやっぱりやめたってなると、これまたリズム出ないしなかなか終わらない=価値の提供が遅れますしね。

とここまで書いてきて、これ見たことある、カンバンの原則だー!って気づきました。カンバンはリーンの考えから影響受けてるっていってましたしね。自分の読書感想ブログも含めて、本も改めて見直しておこう。

ikikko.hatenablog.com

第7章 知識

この章では、「顧客要求にもっと応えたい」というチームにおける例をふまえて、科学的方法の進め方が説明されています。科学的方法とは、こんな感じ。

  1. 問題を定義する
  2. 状況を分析する
  3. 仮説を立てる
  4. 実験を行う
  5. 結果を検証する
  6. フォローアップする / 標準化する

この中で、3 の「仮説を立てる」が「科学的方法の要でありながら、問題解決を急ぐチームが見落としてしまいがち」とされています。これ、すごい分かる。ちゃんと意識しておかないとだめですね。

ここの例、すごく参考になるので、多分今後何度も見直すんだろうなあ。

第9章 パートナー

オープンソースでのセキュリティフィックスをグローバルにまたがった複数のチームで対応した話と、トヨタ傘下のサプライヤの工場が火事になったときに別のサプライヤが協力して大本の発注を無事に納品した話。その中で、何がキーポイントだったのかというのが、↓な感じで説明されています。

よく、どうすれば世界規模のチームでのコミュニケーションを改善できるか、という質問を受ける。しかし、たいていの場合、根本的な問題はコミュニケーションではなく、約束を取り交わしたチームの不在なのだ。

なるほどね。約束を取り交わすことが第一で、その約束を果たすために必要ならばコミュニケーションの話になる、とのこと。多分その約束も、お互いがちゃんとやるべきことを把握できるレベルでの約束が大事な気がする。何となくとか、いい感じでお願いね♪みたいな曖昧なものだと、多分正しく機能しないんだろうな。

あと、コラムにあった「グローバルな作業グループから、グローバルなチームへ」っていうTIPSも、すごく参考になる。目次と簡単に一言で説明。

  1. 頻繁な統合:コードベースでの統合とか
  2. 人の交換:一方のチームメンバーを、もう一方のチームに送って一緒の時間を過ごす
  3. テストを交換する:要求を引き渡す際、実行可能なテストでやり取りする
  4. 窓口(Proxy):窓口となって、毎日コミュニケーション
  5. 動き回るチームリーダー:各地のチームを、チームリーダーが動き回る
  6. 差別の撤廃:言語や立場などの違いは、真のチームワークに欠かせない尊敬や信頼や約束を簡単に破壊する

第10章 旅立ち

どこからリーンソフトウェア開発を始めるかについて。「訓練」「思考」「計測」とありますが、計測が特に気になりました。

「開発作業が終了してからしばらくたたないと、効果的な計測は難しい -> たくさんの部分最適から着手してしまう」という流れが紹介されてましたが、これだと全体最適を阻害する可能性もあるのでだめだとのこと。代わりに、計測対象を減らして、(サブシステムではなく)システムレベルでの計測点を見つけるのがいいよと。具体的には、この辺。

サイクルタイムは、コンセプトがキャッシュになるまで。これを見るだけで、あらゆるムダが露呈するので、リーン手法の一番基本的な計測対象となる。

財務上の成果は、まあそのまま。開発(やもろもろの作業)がどう財務・ビジネスに紐づくか、当然意識して計測できるようにしておくべきだとは思ってるのですが、現実なかなか難しいなあと。ビジネスレベルまでいくと、開発者の作業以外の要素も絡んできそうなので。もちろん、最終的にはここに行き着くべきだけど、一歩目はもうちょいやりやすいところからかなーと。

顧客満足度は、こういう簡単な指標で出せるみたい。

「あなたの製品を、どれだけ薦められますか?」そして、顧客に0(薦めない)から10(絶対に薦める)までの点数をつけてもらう。その回答を、9~10点は「推奨者」、0~6点は「批判者」7~8点は「中立者」としてグループ分けする。

...

推奨者の正味比率を算出するには、推奨者の割合(パーセント)から批判者の割合を引く。すると、マイナス100パーセントから、プラス100パーセントまでの数字が出る。平均的な企業なら、点数は10パーセント」前後である。本当に優秀な企業であれば、50パーセントからそれ以上の点数が出る。マイナスになったら、深刻な問題につながると思った方がよい。

簡単なのはいいけど、実際にこのデータが手元にあった場合、どう活かせばいいのかはちょっとイメージできていない。傾向を継続的に見ていって、傾向が変わったタイミングで何かを検知するとか。もしくは、何かアクション起こす前に傾向がどう変わりそうかを仮説立てておいて、アクション後にその仮説を検証するとかかなあ。


一度通して読んだ後、この読書感想ブログを書くために再度読み直したのですが、この辺がいいなと感じたのかなと改めて。忘れがちなので、適宜また戻ってこようと思います。

  • スクラムなどの開発チーム・プロジェクトにフォーカスするだけでなく、(バリューストリーム(マップ)をはじめとして)より上位の全体システムを見据えた最適化をはかれそう
  • うっかりするとバッチサイズを大きくして一度に効率よく作業しようとなるところを、逆にバッチサイズを小さくしてサイクルタイムをよくすることを心がける

それにしても、いつにもまして長い・・・