またプロジェクト管理自体を承ることも可能です。ぜひご検討ください。

お問い合わせはinfo@leansoftware.jpまでお気軽にどうぞ。

• 未完成の作業のムダ
• 余分な機能のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ

になります。個々の項目について簡単に説明をしていきます。

未完成の作業のムダ

未完成とは、システム開発における

　仕様決定 → コーディング → 統合 → テスト → ドキュメント化（必要に応じて）→ 導入

までの途中に存在する仕掛品を意味します。例えば、

コーディング前の作業

仕様だけ決定し、コーディングが行われていないドキュメント。これは保存期間が長ければ長いほど、変更が発生する可能性が高くなっていきます。要求の変更はビジネスや市場の変化に応じて必ず発生するものであり、それがコーディングされていないのであれば要求を定義するのが早すぎたということになります。

同期されていないコード

リポジトリへのコミット作業はマージが付き物であり、コミットしない時間が伸びれば伸びるほどマージ作業時間も長くなります。できるだけ早めにコミットしていくべきです。

テストされていないコード

テストされていないコードはバグをはらんでいる可能性があり、それをそのまま利用していると連鎖的に問題が起こる可能性が高まります。テストはできるだけ早期に、継続的に行うべきです。

ドキュメントのないコード

ドキュメントを後でまとめて書く場合もありますが、結局の所ヘルプレベルの文書がなければ顧客や関係者のテストは難しくなります。できるだけコードと一緒に提出できるべきです。

導入されていないコード

導入されていないコードがたまると変化を一気に起こすことになります。できるだけ小出しに導入し、変化の波を低く抑えるのが理想です。

といった類のものです。

余分な機能のムダ

余分な機能は使われることもなく、品質管理上のムダにもなり、そもそも邪魔なものになりかねない。顧客の80%のニーズは20%の機能で満たされるとさえ言われているので、できるだけ少ない機能で顧客のニーズを満たすことが重要です。顧客にとっての本来のニーズは要望が満たされることであり、混乱することでも、ただ多機能なことでもないのです。

再学習のムダ

再学習とは、既に経験していることを再度繰り返してしまうことになります。それは個人レベルであっても、組織レベルであっても同様です。そのようなナレッジを蓄積し、同じ問題に対して効率的に取り組めるようにする必要があります。

引き継ぎのムダ

開発チームから運用チームや、担当者から別な担当者に引き継ぎを行った場合、相当数の暗黙知が取りこぼされる。また、その引き継ぎにかかるコストも相当になる。なるだけ引き継ぎが発生しないような体制を作り上げることや、常に少数のグループ単位で取り組むことで数名でフォローし合える体制にするといった工夫が必要です。

タスク切り替えのムダ

複数のプロジェクトに参加したり、やるべきことを複数持ち、それを同時にこなすのは無理があります。マルチタスクにこなす人もいますが、実際には作業レベルは別な方が行っている場合が殆どです。実務を伴うマルチタスクは非常に困難であり、開発作業者はできるだけ集中して一つのタスクを行っていく必要があります。

過去のプロジェクトの保守作業がある場合は、複数人でチームを組み、週間の交代制で保守を全て引き受けるようにしたり、毎日の決められた時間（午前中の2時間など）を保守作業の時間と決めてしまうといった集中型への切り替えが重要です。

遅れのムダ

意思決定や問題解決に際して、遠隔地にいる人に対して都度問い合わせていたりすると時間が余計にかかってしまう。開発者、プロジェクトマネージャ、顧客とリスクテイカーができるだけ一同に集まって素早く決定を下せるようにすべきです。少なくとも全員に配信されるメーリングリストなどを介して、素早く情報共有と決定がなされる体制を作っていく必要があります。また、そのためにはお互いに権限委譲を推進し、責任者を明確にする必要があります。

欠陥のムダ

欠陥を作り込まないようにするには、テストが最重要です。自動的にテストを行う仕組みを早期に導入し、継続的にテストを行うことで欠陥の入り込む余地を減らしていきます。アジャイル開発ではテストしやすいコードを書くことが原則になっています。

テストを自動化するメリットとして、リファクタリングが容易であるということがあります。インタフェースが決まっているのであれば、中身を分かりやすく、使いやすく作り直しても動作が保証されます。それによってコードの変更が怖くなくなり、より良い設計に基づいたコーディングが可能になります。

まとめ

トヨタのカンバン方式などに代表されるムダの排除は「顧客が注文を出し、現金を改修するまでの時間軸において価値を付与すると思われないものは全て排除する」という考えに基づいています。そこには社内の体制や考え方、全体最適化など多岐にわたって考えていく必要があると書かれています。各自が自己や自社、部署の満足感のために行動するのではなく、顧客へ価値を提供するという一点に対して何をすべきなのか、その原点に立ち戻って考えると色々なムダが見えてくるかも知れません。

火を噴くプロジェクトの特徴

開発プロジェクトにおいて納期ぎりぎりになってきて火を噴くということは多々あります。原因は色々と考えられますのが、主に以下のような要因が挙げられます。

• 要求定義の漏れやビジネス環境の変化
• 見積もり精度の甘さ
• 情報伝達ミス
• バグフィックスのコスト増
• マネジメントの甘さ

これらの項目について、開発モデルの違いを見ていきます。

要求定義の漏れやビジネス環境の変化

要求定義時にはなかった事柄や、状況の変化によって開発工数が増減する（主に増）ことは多々あります。これを防ぐために、システム開発会社では「契約」「仕様の確定」などを前段階できっちりと行うことが求められています。が、半年や一年後においてビジネスが変化していないと誰が言えるのでしょうか。また、もし状況が変化しているにも関わらずシステムが元のままであった場合、いわゆる使われないシステムができあがることになり、顧客満足度は著しく低いものになります。

ウォーターフォール型の場合、この問題はとても大きいものになります。特にWebシステムの場合は短期間での開発が求められる上に、状況の変化も激しいマーケットです。この場合にウォーターフォール型のような階段を上がっていくような開発手法は問題の火種を常に抱えているようなものです。

さらに契約というのは主に自分たちの身を守る事柄について明記されていることが多く、顧客と自分たちとの間に壁を作る結果につながります。そのため、本来であれば顧客の要望しているビジネスを一緒に成功させるための存在であるシステム開発会社が敵と見なされる場合もあります。この辺りは別途記したいと思います。

見積もり精度の甘さ

見積もり精度があまく、工数が膨らんでしまったというケースもあります。これは実際の見積もりを行う人が現場感がなかったり、必要と思われる機能を予知できなかったりする場合に起こります。そのため、工数の算出は現場と一緒になって行う必要があります。その結果を顧客とすりあわせるのがマネージャの役目と言えます。そして無駄と思われる機能を削ったり、代替え手段を用意することによって、双方の満足いく予算および納期に仕上げていくことが重要です。

また、もう一つのコツとして全てを見積もらないということがあります。状況の変化の件も重なりますが、初期の段階で全てを見積もるのは非常に困難です。で、あればリリースの段階を複数回にわけ（リーンソフトウェアではイテレーションと呼びます）、その段階ごとに見積もりを行っていくという方法です。

情報伝達ミス

メールや電話での言った言わないや伝え漏れなどによって勘違いがおき、開発に戻しや遅延が発生することがあります。リーンソフトウェアでは顧客、開発現場の距離を縮めることを推奨しています。遠隔地でのプロジェクト推進も増えていますが、それでも同じ部屋にいて暗黙知を共有するのには敵わないと書かれています。実際、距離は温度差につながりやすく、お互いのヘッジにつながります。開発をさらにアウトソースする場合においても顧客との打ち合わせに同席したり、密にコミュニケーションをとれる状態にしておくことで仕様には書かれていない情報を知り、品質を高めることができます。

また、開発のマイルストーンをできるだけ小さく、コミットやテストの回数を増やすことで、間違った方向に進んでしまうのを前もって防ぐことができます。できれば毎日状況の確認と現段階でできているシステムのテストを行うといったことが望ましい状態です。

バグフィックスのコスト増

バグを出さないコツは、テストの自動化とコーディング量を減らすことにあります。成果物の規模を極力小さくすることで、1行あたりに含まれるバグの可能性を減らしていくことが可能です。これはフレームワークの活用や、オープンソースの活用で実践することが可能です。

テストの自動化についてはできるだけ初期段階から取り組んでいく必要があります。都度人力でテストを行っているのでは時間も工数もかかってしまいます。できるだけ速い段階でテストの自動化を仕組みづくってしまい、テストされていないコード部分を極力減らすようにしましょう。

マネジメントの甘さ

マネジメントは予想以上にコストのかかる作業です。元来、プロジェクトマネジメントは作業における無駄を省き、作業量を最大化する目的で作られているそうです。その目的から言うと、プロジェクトを円滑に進めるために行うものではないということが分かります。実際、プロジェクト管理を行っている工数があるなら顧客との信頼性を築く、テスト自動化の仕組みを考える、リリース契約を立てるなどの生産性のある仕事に取り組んだ方が良いと考えられます。

ガントチャートをいくら奇麗に仕上げたところで思い通りに運ぶ訳もなく、各人のタスクは一人がトップダウンで進めるのではなく、各人からの申告制に任せる方がスムーズです。ちょっとした状況変化にも対応できないマネジメント手法であれば、元々取り入れない方が良いと言えます。

ウォーターフォール型の問題点

最大の問題点は「前行程に間違いはない」という前提で進んでいる点です。人が行っていることですから、間違いがある可能性はあります。また、間違っていなくとも状況の変化によって前行程の前提条件が変わってきたということも良くあるケースです。

その意味でリーンソフトウェアは、間違いや変化に強くなる開発手法と言えます。もちろん、手法だけで成り立つものではないため、同じ工数をかけるにしても役に立たないもの（無駄なもの）に工数をかけるのではなく、役立つものに工数をかけ、無駄なものは排除して変更する箇所を減らしていく努力が必要になります。

実際に開発の中に取り入れていくには

重要なのは顧客との意識の擦り合わせです。相手がウォーターフォール型で、こちらがリーンソフトウェアでは最初は良いとしても後になってから必ずほころびが生じます。まず相手に理解してもらうことによって、開発プロジェクトを双方にとって良いものにしていこうという意識を共有することが重要です。

まとめ

人月型に代表されるように、ソフトウェア開発の現場は30年以上前からそれほど進化していません。根底に流れるソフトウェアに対する意識や人月の扱い、建設業界のような孫請け/ひ孫請けなどのつながりが解消しない限り、なかなか難しい問題もあります。が、顧客がこれまでに感じてきた問題点（特に前に火を噴いた経験がある企業等）とリーンソフトウェアの利点とがマッチすれば、この新しい開発スタイルはきっと受け入れられるのではないでしょうか。

via spectra rss viewr | recomendado on Flickr – Photo Sharing!

1) 無駄の認識

開発における無駄とは何でしょうか。例えばソースコードの重複、これは無駄です。さらにドキュメント。私がこれまでに携わってきたプロジェクトで過去のドキュメントが活用されたというケースは皆無です。また、二次開発、三次開発を行う中で既存のドキュメントを修正せずに別途ドキュメントを用意する場合があります。これはマージする手間を省いているだけで、全体の網羅性は失われドキュメントとしての価値は殆どなくなります。はっきり言って無駄です。

さらに開発者の管理体制にも無駄が多くあります。詳細なプロジェクト管理を作ったとして、その通りに進むことはありますでしょうか…まずありません。ということは詳細なプロジェクト設計は無駄です。必要十分な分だけ作れば良いのです。

他に機能の無駄もあります。今後必要になるだろうから…という予測の元に作られる機能は数多いのですが、これはテストの工数を増やし、バグを含む可能性を高めるため無駄になります。現在必要な機能だけを絞り込んで作るのが重要です。さらにミーティングなど無駄と思われるものを認識し、それを排除していく継続的な努力が重要です。

2) ぎりぎりまで決定を遅らせる

これはオプションとも重ねて考えられるキーワードです。オプションとは、取り得る選択肢のことです。例えばスクラッチで開発するのか、既存のシステムを利用するとしたら、オープンソースなのかパッケージなのか、オープンソースだとしたらどれを使うのか…などなど可能な選択肢をぎりぎりまで見極め、残しておくことを意味します。

初期の段階でこうした事柄を決めることが多々ありますが、後から湧いた要件によって全てがひっくり返る可能性があります。決定はできるだけ遅らせて、逆に決めたらすぐに取りかかれる仕組みを構築することが重要ということです。

3) 先んじて作る

とは言え納期の問題であったり、顧客がイメージが浮かばずに悩んでしまうなどという問題もあります。そこでラフになるモックを作ることが選択肢になります。このモックは使い回さない前提で作ることが重要です。そのため簡単なもので良くなりますし、スクラッチアンドビルドがしやすくなります。後でベースに…などと考えると余計なエラー判定を入れたりして工数を増やしてしまいます。

また、先んじて作る場合は要求が変わりそうな部分を予め予見し、それに対応できるようにしておく工夫が必要です。そこをどう見極めるかは、経験による部分が大きいとのことです。逆に言えばコーディングをされる方はそのような内情も把握した上で、経験値を活かして素晴らしいシステムを構築することが求められる訳です。

4) 契約より連携

現在のシステム開発の現場では契約書やメールなどでヘッジを立てることに躍起になっています。そのため顧客との距離感ができ、相互に納得できるものになりません。リーンソフトウェア開発では顧客との密なつながりを基本とし、契約での縛りではなくお互いの信頼をベースにした連携によって「このシステムをよりよい状態でリリースする」という目的に向かって突き進むことで目的を一致させます。

5) 細かなイテレーションを繰り返す

イテレーションとはXPなどで代表される開発手法の反復型開発プロセスにおける一回の繰り返しのことです。ウォーターフォール型開発では設計を完了しなければ開発に入れないのですが、反復型の場合は基礎的な機能、基本的な機能、オプションといった具合に段階的に開発を進めていきます。このため、要件が変わることを前提に開発を進められるようになります。

例えば2週間程度で実装できるものを決め、その間に別な機能の要件を固めていきます。そして次の二週間の間に顧客はテストを行って、デバッグしながら開発を進めていくと言った具合です。短く区切ることで検収を段階的に終わらせることができ、顧客としてはシステムが組み上がっていることが実感でき満足度を高めることができます。

6) シングルタスクで進める

平行して様々なタスクを行うと頭の切り替えに時間がかかってしまい、生産性が著しく低下します。できるだけ同じ作業をできるようにし、あまり長時間かかる作業についてはサブタスク化し、短期的に集中した作業を繰り返せるようにします。

7) 仕掛品を増やさない

ソフトウェア開発における仕掛品とは、テストされていないコードや、顧客テストを通っていないコードです。これがあまり増えるとプロジェクトに何らかの問題が発生してぽしゃった時のリスクが高まることになります。テストされていないコードはバグを含んでいる可能性があり、そのバグが発覚した時に与える影響は大きくなります。できるだけ仕掛品を減らす努力が必要です。

チームに権限を与える

トップダウンの開発ではなくボトムアップの開発に切り替えます。開発者同士の話し合いを増やし、そこから生まれたアイディアをできるだけ取り入れていきます。顧客とのミーティングに開発者自身が参加し、納得感のある会議につとめます。

9) 作り直しは当たり前

よく一度書いたコードは触れないという人がいますが、それは無駄です。必要に応じてどんどん手を入れていくべきです。手を入れた時には必ずテストを行い、既存のシステムへの影響がないことを確認します。そのため、テストの自動化は必須です。

10) 部分最適化をしない

これはコーディングに限った話ではありません。企業としても営業部が営業だけを考えない、個人が自分の利益だけを考えない、経営層が自分たちの会社だけを守ることを考えないといったことも含みます。部分的な最適化は全体からみた場合、最善であるとは限りません。あくまでも全体の利益を考えた上で、最適な答えを見つける必要があります。

まとめ

リーンソフトウェアはトヨタに代表される日本の自動車業界をベースに生み出されています。そのため、カンバン方式などにも注目しています。が、ソフトウェア開発を工場などの製造業として捉えているのではなく、開発業として見ているのが特徴です。研究でもなく、あくまでも開発です。そのため、既知の技術や自分たちのもっている技術を使っていかに良いものを製品化できるかを常に考えるのが重要と説いています。

まだまだ足りない部分があると思いますので、ご指摘、ご質問はコメントにどうぞ。

リーンソフトウェア（Lean Software）のLeanとは「無駄のない」を意味しています。つまりソフトウェア開発における無駄のない手法、失敗を未然に防ぐ方法になります。このブログではリーンソフトウェアに注目し、その方法論を日本式に展開し、情報提供するものになります。