ソフトウェアのリーン思考入門

作者 Jacky Li, 翻訳者 大田 緑 - (株)チェンジビジョン 投稿日 2008年9月4日 午前12時59分

コミュニティ

Agile

トピック

Delivering Value,

方法論

タグ

継続的な改善,

Lean

ScrumやXPからアジャイルにやって来た開発者やリーダーにとって、リーンに関するこの話はすべて少しばかり不可解であるかもしれません。これは、InfoQ Chinaのアジャイル編集者、Jacky Li氏によるリーン思考とリーン思考をどのようにソフトウェア開発に適用するかについての入門です。ここにはThoughtWorks ChinaのNing Lu氏の話がまとめられています。彼は、リーンやアジャイルのもっとも大きな障害を力説しています。その障害とは大規模生産の期間に起因する考え方です。

今年既に、InfoQ Chinaは、Matrix(リンク)、ThoughtWorks China(リンク)、Beijing Java User Group(リンク)、AgileChina Google Group(リンク)、Beijing Python User Group(リンク)などとオープンパーティ(リンク)を開きました。OpenSpaceアンカンファレンス(リンク)に沿って行われるオープンパーティがThoughtWorks Chinaのオフィスで開催され、約30人が参加しました。Ning Lu氏は、ThoughtWorksのコンサルタントで、リーン思考とその例についてすばらしいスピーチを行いました。彼は、リーンやアジャイルの採用についてもっとも大きな障害を分析し、無駄を認識し省いていく方法について述べました。この記事では、アジャイル開発者の視点からその話を要約します。

アクティビティは、簡単なスタンドアップミーティングで始まり、すべてのトピックへの投票が続きました。その日、数多くのすばらしいトピックがありました。「オープンソースコミュニティの成長」、「GPE」、「Mingle」、「Erlang」などです。トピックは3つのトラックに分けられ、Ning Lu氏は1つのトラックで話しました。彼は、トヨタ生産方式とリーン生産方式の歴史からはじめ、リーンやアジャイルを採用する際のもっとも大きな障害に立ち向かいました。その障害とは大規模生産の期間に起因する考え方でした。Ning Lu氏は、また、どのようにトヨタが自分たちの生産システムを検討したかについて話しました。

リーンは、無駄を認識して省くことができる技術です。その無駄とは、付加価値を生み出さないアクティビティのことです。

彼は、例を挙げてリーンの5つの原則で無駄を認識して省く方法を説明しました。そして、いつも無駄に伴って起こるいくつかの典型的な現象をリストアップしました。

• 在庫 - 在庫によって非効率的な供給を避けることができますが、一方でコストがかかり、会社は市場に追従できなくなっていきます。市場の要求が変化して、会社は過剰在庫に直面するかもしれません。在庫は至るところにあります。本棚、冷蔵庫、そして、結果を出せずに終わる作業について考えてみましょう。
• バッチ処理と待ち行列 - いつも込んでいる交差点のようなものです。ほとんどのドライバは、そこで「待つ」ことを経験しなければなりません。
• アンバランス - 例えば、季節的なセールスと閑散期のセールス期間です
• 複雑さ - 予想していたよりも物事がずっと複雑になる場合、なにか無駄なことがあるはずです。例えば、複雑なドキュメントやプロセスなどです。
• 「規則に従うこと」に集中する - すべてのルールや規則が道理に適っているわけではありません。例えそうであっても、顧客にとっては価値がないかもしれません。

Ning Lu氏は次のように強調しました。

未完了の作業は、一種の無駄です。リーンやアジャイルは、未完了の作業を最小限にすることができます。

あぁ、それって書かれたコードもすべて無駄だってことのようです。それはおかしい!私たちが上述の言葉に従って無駄を最小限にしようとする場合、コーディングをやめるべきであるらしい!それでは、どうやって顧客に何かを納品することができるのでしょうか?そして、その価値はどこからくるのでしょうか?

オーケー、ちょっと別の方向から見てみましょう。もしかしたらあなたは「プレファクタリング」から次の言葉に見覚えがあるかもしれません。

あなたはすべてを予想することができますか?いいえ。今日、あなたがした決断は最後の決断ですか?いいえ。プロジェクトの始めにすべてを考えたり、すべてを知ったりすることは、実際のところ不可能です。

実は、顧客でさえ、その機能がまさしく彼らがほしいものであるかどうか確かではないでしょう。それが、彼らにとって価値があるものだということはまだ証明されていないのす。未完了の作業を一種の無駄と考える場合、コードを動くソフトウェアにすることに専念し、それをできる限り早く製品環境にデプロイするでしょう。その後、顧客からフィードバックともっと詳細な要求を聞けば、コミットした機能が完了でよいか (修正が必要か)を調べることができます。未完了の作業が多ければ多いほど、ますますリスクは大きくなるでしょう。

このアイデアに賛成する場合は、未完了の作業のような無駄を省くために解決策を見つける必要があるでしょう。では、何をするのでしょうか?

5つのリーンの原則は、明確で段階的な方向性を示します。ソフトウェア開発に関して言えば、数多くのアジャイルプラクティスから成るとても有用なツールキットです。それらのアジャイルプラクティスはすべての具体的な問題を解決する役に立つのです。コードが完成し、それをテストして統合する時間を減らすために、小さな段階を踏んで進む必要があります。そのためには、頻繁にチェックインして、継続的統合を行います。機能が完成し顧客に価値を提供するまでの時間を減らすために、頻繁に納品する必要があります。これから分かるように、この点でリーンとアジャイル開発は完全に統合されているのです!

4ヶ月前（元記事掲載時）、Amr Elssamadisy氏がニュース「オピニオン: リファクタリングは必要な無駄」(参考記事・英語)で提案しました。

リーンには2つのタイプの無駄(リンク)があります。純粋な無駄と必要な無駄です。純粋な無駄は、ソフトウェアを構築するチームにもそのソフトウェアを使う顧客にも価値がないものです。必要な無駄は、一方で顧客にとって価値がなくても、今のところ知っている仕事のやり方でもっともよい方法です

Ning Lu氏はまた、リーンで定義された無駄の種類についても述べています。特に、「必要な無駄」と呼ばれる2番めのタイプについてです。彼の意見では、テスト、統合、リファクタリング、マネジメントはすべてこのタイプの無駄に属します。無駄についてのそれらの形式を減らすためによく使われるいくつかの興味深いパターンをまとめてみました。

• 肯定的に扱う : チームメンバの数を減らし、採用条件を上げる。
• 個人のタスクを「チームタスク」に変える : チーム全体で一緒になって設計、テスト、統合の一部の作業に取り組む。チームを自己組織化する。コードの所有権はチームで共有する。
• 人とマシンの間で責任を分ける : 可能な限りすべての作業を自動化する。
• 作業を早めに、そして頻繁に行う : テスト駆動開発を導入し、頻繁にユニットテストを実施し、初期段階でリファクタリングと統合を行う。皆が前もってプロジェクトの目的地をはっきりと理解し、プロジェクトの状態がいつも目に見えているようにする。

このトピックに関してもっと読みたい人には、Mary氏とTom Poppendieck氏がウェブサイト(リンク)で記事を提供しています。また、ThoughtWorks Chinaのコンサルタント、Jeff Xiong氏とYe Zheng氏がリーン、アジャイルと無駄の関係について役に立つ記事を書いています。(参考記事・中国語) このトークの中国語のスライドがダウロードできます(PDF)。

こちらでオリジナルの中国語のInfoQの記事を見ることができます：路宁谈精益思想——2008北京Open Party摘录 (参考記事・中国語)、そして、いくつかのビデオ(リンク)とこのイベントのストーリー(リンク)があります。
 

 

---

 

---

著者について

Jacky Li氏は、InfoQ China/Agile Communityのリード編集者で、Javaとアジャイルソフトウェア開発を専門にしています。中国でのアジャイルの普及に貢献しています。中国語版のInfoQミニブック、Struts2を始める(参考記事・中国語)と前線からのスクラムとXP(参考記事・中国語)を英語から翻訳しました。

 

 

原文はこちらです：http://www.infoq.com/articles/lean-thinking-software 
（このArticleは2008年6月23日に原文が掲載されました）

• 次へ >