リーンソフトウェア開発(LSD)の読書メモ(1)
|
を読んだ。読んで、思ったことをメモしておく。
ムダを排除する
リーンソフトウェア開発では、第一にムダをなくす事に注力する。リーンの名前、思想の由来は、リーン生産方式から来ている。このリーン生産方式の元を辿ると、トヨタ生産方式に行き着く。昨日のblogを読むきっかけになったのは、この本である。以降で、ソフトウェアでのムダについて、本の内容について、「
」の内容と比較しながら感じた事を書いていく。
ムダを認識する。
『リーンソフトウェア開発』では、製造でのムダとソフトウェア開発でのムダを比較して、以下のようにまとめている。
| 製造でのムダ | ソフトウェア開発でのムダ |
|---|---|
| 在庫のムダ | 未完成の作業 |
| 加工そのもののムダ | 余分なプロセス |
| 作りすぎのムダ | 余分な機能 |
| 運搬のムダ | タスク切り替え |
| 手待ちのムダ | 待ち |
| 動作のムダ | 移動 |
| 不良を作るムダ | 欠陥 |
でも、本当はこっちではないかと思う。
| 製造でのムダ | ソフトウェア開発でのムダ |
|---|---|
| 在庫のムダ | 未出荷のコードのムダ |
| 加工そのもののムダ | 記述のムダ |
| 作りすぎのムダ | 余分な機能のムダ |
| 運搬のムダ | 引継ぎ・統合のムダ |
| 手待ちのムダ | 待ちのムダ |
| 動作のムダ | 単純作業のムダ |
| 不良を作るムダ | バグを作るムダ |
| - | 車輪の再発明のムダ |
一つ増えてしまっているが、ソフトウェアと工業製品の決定的な違いだと思う。ネットの世界とリアルの世界では条件が違うように、ソフトウェアの開発と製造とでは違うのは当り前だ。
以下に、ムダについての書いていく。
未出荷のコードのムダ
未出荷のコードは、利益を上げていないので、キャッシュフローが悪くなる。
それに、未出荷のまま放置しておくと時代遅れの機能となるので、出荷の時には機能追加が必要となり、利益をあげていないのに追加費用が必要になる。
また、他社が既に出しているのと同等の機能か、遅れた機能になるので高く売れなくなる。
対策としては、とにかく出荷して検収を上げて
- 利益を確保する。
- 顧客のフィードバックを得る。
- 市場で最初の製品になり、シェアをとる。
記述のムダ
同じ内容の記述を計画書、仕様書、ソース、テスト項目表に記述して、時間をムダにする。
重複があると、文書作成以外に、文書間の整合性を取る時間が必要になる。そのためのレビューなどは愚の骨頂である。
同じような内容を色々な文書に記述すると、その文書独自の用語を使うようになる。(特に作成の担当者が異なる場合。そのように一部の担当者間でしか分からない用語を連発して部外者よりも自分は賢い、特別な人間なんだと勘違いする馬鹿なプログラマーはよく見かける)。そうなると文書間の用語の対応関係の把握に時間がかかり、後任者が文書を理解するのに時間がかかるようになる。
対策としては、
- One fact one placeを心がける。
- 参照で済むものは、コピーせず、リンクを張る。
- 文書間で用語の一貫性を持たせる。(検索をかけて、文書間の依存性の調査を可能にする。)
- 新たに用語を作る時は、is-a、part-ofの関係になるようにする。
- ツールを使って、他のドキュメントをなくす。
仕様書からソースの概略を作るツールがあるが、ソースに手を入れるとメンテできない事が多い。
逆転の発想で、ソースのコメント等から、その他の文書を生成できないか?
ソフトウェア開発者の基本は「ソースを読め」である。事実はソースコード、したいことはコ
メントでというのが本筋ではないだろうか。それ以外のドキュメントは解説書となるのではないだろうか? Linuxの関連ドキュメントはそんな状態である。
余分な機能のムダ
余分な機能を作ってしまうと
- 出荷が遅くなる。
- バグが増える。(デグレードしやすくなる。)
- マニュアルが分厚くなる。(顧客が使い方を覚えるのに時間がかかる。)
対策としては、基本的な機能のみを実装してしまう。(あったら便利という機能は、全てVer.2で実装する。)
基本的な機能と、そうでない機能の違いを見分けないと不具合やバグと認識されてしまうので注意が必要である。その見分け方は、
- この機能がないと、絶対に出来ない事がある。
- 複数の事をしていない。(関数を作成する要領で考えればよい)
- 別の機能と組み合わせたらできるものは、基本的な機能ではない。
- 使わない運用方法が考えられる。(Change the ruleで済むならいらない)
- ユーザーを馬鹿にしない。(フールプルーフはほどほどに。フールプルーフを考えすぎてガチガチのソフトウェアを見た事がある。)
- GUIで対話的に真夜中に作業をする。
- 微妙に違う操作を100回繰り返しする。
- 文書の誤解により、バグが実装される。
- 分割したものの間での不整合が発生して統合時にバグとなる。
- 作業担当者の割振り、作業の順序を変える。
- 事実を伝える為だけのミーティングはムダ。
- 改善のための議論をする時間を増やす。
- 一般的に後工程となっている部門からの指摘は要改善項目である。
→ならば、何故早めに声を聞かない? - 分割を減らす、分割した部分間での結合性を弱める。
- する事がなくても、人を雇うには費用がかかる。
酷いときには、不必要な費用が発生しないように仕事をでっちあげる事が行われる。それだけなら良いのだが、でっちあげの仕事よって本来の仕事に取り掛かれなくなる事もある。 - 開発結果に対するフィードバックが遅れ、改善が進まない。
- ソフトウエアに完成はなく、リリースがあるのみとの考えを持つ。
(完成するのは仕事がなくなる時) - 部分毎にフィードバックが得られるようにする。
(部分を追加した時のテストを自動化する事) - 部分毎の機能で顧客満足を得られるようにする。
- バグを作り出す。
- 時間をムダにしている。
- 自動化する方法を考える。
- 自動化しやすい、良いツールを使う。自動化するのに手作業の何倍もかけるはめになるツールは絶対に悪い道具だ。特にMicr○s○ftのツールはよくない。
- 品質がよいものを利用する。
良い物がないというのは開発の十分な動機である。ただし、何故既存品が悪いのか、自分達がどのようにするから良くなるかを十分に見極めてから開発する事。一つや二つ機能が少ないからと言って開発するのはよくない。それはまた新たにキーボードの配置を考案するような愚かな行為である。 - 機能/品質をコントロール出来るものを利用する。
少なくとも改良に携われるものを利用する。市場のシェアがあるからといって使うとそれのバージョンアップに振り回される事になる。 - テストしてから利用する(テストは自動化する事)。バージョンアップによるバグに振り回されないためにも。
-
である。
ただし、必ず作らなければならないのは、自動化するため(してもらう)のインタフェースを用意する事である。ユーザが
引継ぎ・分割のムダ
工程毎の作業担当者間で引継ぎの資料作成・ミーティングによって時間をムダにしている。
必要以上に担当者を分ける事により、
-
という弊害の方が多くなっているような気がする。
対策は、
待ちのムダ
待ちが発生すると
このように待ちが発生するのは、完璧を期すぎるから(余計な機能をいっぱい付けすぎてから)出荷しよう(次工程へ送ろう)とするからだと思う。そうならないためには、
単純作業のムダ
単純作業を繰り返しているというのは、何かおかしな事をしている証拠である。コンピュータとは自動化のための道具なのだから。ただ、ディスプレイの前で、ひたすら同じような作業を繰り返している人を見かける事が多いのは何故だろう。
ソフトウェア開発で単純作業を繰り返している場合は、必ず、対策としては、
バグを作るムダ
バグを作ってしまうと、修正/確認/適用が必要になり工数が発生する。(場合によっては説明資料が必要になる)
車輪の再発明のムダ
既に存在しているものを再作成するので時間を消費する。作っても付加価値がないので存在意義がない。また、再発明されたものは動作実績がないのでバグの量が既に存在するものよりも多くなってしまう。
対策としては、既にあるものを積極的に利用する。利用する時の注意点としては、
「トヨタ生産方式」のムダの排除の何がすごいかというと、在庫のムダが諸悪の根源であると結論づけている所である。在庫を無くすために、一個流しを実施する事になって、段取り替えの時間は増えても、それはムダとは考えていない所が世間一般とは違う。
リーンソフトウェア開発でも、何が本当にムダなのかを見極めないと無意味な開発方式になるだろう。
