あなたは、自分のお金で買ったソフトウェア、きちんと使いこなせていますか?

よく分からなくて使っていない機能とかありませんか?

ソフトウェアの機能が100あるとしたら、私は10ほどしか使いこなせていないと思っています。

個人レベルだけでなく、会社レベルで導入したシステムも同様に、結構使われていない機能があるのではないかと推測できます。

リーンソフトウェア開発とは

システムを開発するプロジェクトでは、プロジェクトマネージャーをはじめ、システムエンジニアやプログラマーが日夜、奮闘し続けてくれています。

しかし、ほとんどのプロジェクトでは、無駄な作業が発生していると思われます。

なぜなら、ユーザーの立場からすると、誰も使っていない機能がたくさんあり、それは開発するだけ無駄になっているからです。

そこで、これから紹介する「リーンソフトウェア開発」の考え方がでてきます。

「リーンソフトウェア開発」とは、主に製造業で採用されているリーン生産方式(トヨタの生産管理手法をアメリカで体系化したもの)の考え方をソフトウェア製品に適用した開発手法のことをいいます。

リーン生産方式は製造工程において、無駄を徹底的に排除する方法です。

ソフトウェア開発のプロジェクトで無駄な作業を減らしたい場合、このリーンソフトウェア開発の考え方が活かされることになります。

リーンソフトウェア開発では、7つの原則が提唱されていますので、ひとつひとつ見ていきたいと思います。

原則①:ムダをなくす

ソフトウェア開発のムダとは、ユーザーやクライアントに対して、価値がないものを提供することをいいます。

冒頭の話のような、使われない機能などが典型的な例となっています。

どうして、このような使われない機能が提供されることになるのでしょうか?

それは、開発側もユーザー側も、どのような機能が欲しいのか、きちんと定義できていないことによります。

プロジェクト的に言えば、「要件定義」の甘さだと言い換えることができます。

ムダな機能を作らないように、開発側とユーザー側では、十分なコミュニケーションをとり、少しずつ開発を進めていくことが重要です。

原則②:品質を作り込む

システムの不具合は、発見が遅れるほど、修正するコストが増大していきます。

場合によっては、手遅れになるケースもあるでしょう。

早急に不具合を見つけることが、時間のムダを避ける秘訣になります。

テストの品質を上げ、開発側とユーザー側のコミュニケーションを密にし、品質を高めていきましょう。

原則③:知識を作り出す

通常、システム開発は、ウォーターフォール型で進められ、予定通りに進むことが前提になっています。

しかし、現実はうまくはいきません。

どれだけ精緻な計画を立てていたとしても、問題は発生するでしょう。

このため、プロジェクトの中で、その都度、知恵を生み出していくことが必要になってきます。

知恵の例としては、例えば、ユーザーからのフィードバックや、開発のノウハウ、代替案などを挙げることができます。

これらの知恵は、どこかの教科書には載っているものではありません。

個々のプロジェクトに合わせて、考えていく必要があるので難しいのです。

原則④:決定を遅らせる

システム開発プロジェクトでは、さまざまな意思決定の場に出くわします。

意思決定をするのに、十分な情報・根拠が揃っている場合はいいですが、ほとんどのケースでは、十分な情報がなく、トレードオフを考慮しながら、妥協案を選択していく…

ことになります。

不確実な情報を元に意思決定をしないといけない場合、手戻りになるリスクもあります。

できることなら、情報が十分に揃ってから意思決定をしたほうが、不確実性は減ります。

このためにも、システムは、できるだけ、後からでも変更できるような仕組みにしておくことが重要です。

原則⑤:早く提供する

原則①で挙げているムダをなくすためには、開発側とユーザー側のコミュニケーションが重要です。

開発側は、ユーザーが本当に必要とする機能を、正確に聞き出さなければなりません。

システムを構築してから、ユーザーに仕様の確認をお願いしていたのでは、手戻りコストが大きくなってしまいます。

このため、できるだけ、早い段階で、ユーザーのフィードバックを受けることが、ムダを減らす秘訣です。

原則⑥:人を尊重する

システム開発プロジェクトにおいて、システムを実際に構築しているのはプログラマーです。

しかし、ユーザーと要件を詰めているのは、上級のシステムエンジニアであることが多いです。

ユーザーと詰めた要件を上級のシステムエンジニアが、プログラマーに仕様書という形で伝達しています。

ということは、プログラマーは、上級のシステムエンジニアもしくは仕様書の枠内で仕事をこなすことになります。

完璧にコミュニケーションがとれているのであればいいですが、実際はそうはいきません。

実際に開発しているのはプログラマーなので、ある程度の裁量・権限をプログラマーに与えておき、お互いに尊重し合うことが、仕事の質を上げることにつながります。

最終的に、品質を決めていくのは人間なのです。

原則⑦:全体を最適化する

システム開発プロジェクトのゴールは、システムを完成させることではありません。

完成されたシステムを使って、ユーザーが価値を見出していくことがゴールです。

このため、システム機能の細かな議論だけでなく、ユーザーのビジネス環境を踏まえた上で、検討を進めなければなりません。

システム開発プロジェクトでは、不足しがちな、「全体的な効果」を、常に意識しておくことが重要なのです。