リーンソフトウェアのリーンとは「無駄のない」を意味する英単語で、無駄を省き、満足なシステム開発を行うという概念になります。ここではこれまでに私が覚えた重要なキーワードとそれぞれの説明をしたいと思います。
via spectra rss viewr | recomendado on Flickr – Photo Sharing!
1) 無駄の認識
開発における無駄とは何でしょうか。例えばソースコードの重複、これは無駄です。さらにドキュメント。私がこれまでに携わってきたプロジェクトで過去のドキュメントが活用されたというケースは皆無です。また、二次開発、三次開発を行う中で既存のドキュメントを修正せずに別途ドキュメントを用意する場合があります。これはマージする手間を省いているだけで、全体の網羅性は失われドキュメントとしての価値は殆どなくなります。はっきり言って無駄です。
さらに開発者の管理体制にも無駄が多くあります。詳細なプロジェクト管理を作ったとして、その通りに進むことはありますでしょうか…まずありません。ということは詳細なプロジェクト設計は無駄です。必要十分な分だけ作れば良いのです。
他に機能の無駄もあります。今後必要になるだろうから…という予測の元に作られる機能は数多いのですが、これはテストの工数を増やし、バグを含む可能性を高めるため無駄になります。現在必要な機能だけを絞り込んで作るのが重要です。さらにミーティングなど無駄と思われるものを認識し、それを排除していく継続的な努力が重要です。
2) ぎりぎりまで決定を遅らせる
これはオプションとも重ねて考えられるキーワードです。オプションとは、取り得る選択肢のことです。例えばスクラッチで開発するのか、既存のシステムを利用するとしたら、オープンソースなのかパッケージなのか、オープンソースだとしたらどれを使うのか…などなど可能な選択肢をぎりぎりまで見極め、残しておくことを意味します。
初期の段階でこうした事柄を決めることが多々ありますが、後から湧いた要件によって全てがひっくり返る可能性があります。決定はできるだけ遅らせて、逆に決めたらすぐに取りかかれる仕組みを構築することが重要ということです。
3) 先んじて作る
とは言え納期の問題であったり、顧客がイメージが浮かばずに悩んでしまうなどという問題もあります。そこでラフになるモックを作ることが選択肢になります。このモックは使い回さない前提で作ることが重要です。そのため簡単なもので良くなりますし、スクラッチアンドビルドがしやすくなります。後でベースに…などと考えると余計なエラー判定を入れたりして工数を増やしてしまいます。
また、先んじて作る場合は要求が変わりそうな部分を予め予見し、それに対応できるようにしておく工夫が必要です。そこをどう見極めるかは、経験による部分が大きいとのことです。逆に言えばコーディングをされる方はそのような内情も把握した上で、経験値を活かして素晴らしいシステムを構築することが求められる訳です。
4) 契約より連携
現在のシステム開発の現場では契約書やメールなどでヘッジを立てることに躍起になっています。そのため顧客との距離感ができ、相互に納得できるものになりません。リーンソフトウェア開発では顧客との密なつながりを基本とし、契約での縛りではなくお互いの信頼をベースにした連携によって「このシステムをよりよい状態でリリースする」という目的に向かって突き進むことで目的を一致させます。
5) 細かなイテレーションを繰り返す
イテレーションとはXPなどで代表される開発手法の反復型開発プロセスにおける一回の繰り返しのことです。ウォーターフォール型開発では設計を完了しなければ開発に入れないのですが、反復型の場合は基礎的な機能、基本的な機能、オプションといった具合に段階的に開発を進めていきます。このため、要件が変わることを前提に開発を進められるようになります。
例えば2週間程度で実装できるものを決め、その間に別な機能の要件を固めていきます。そして次の二週間の間に顧客はテストを行って、デバッグしながら開発を進めていくと言った具合です。短く区切ることで検収を段階的に終わらせることができ、顧客としてはシステムが組み上がっていることが実感でき満足度を高めることができます。
6) シングルタスクで進める
平行して様々なタスクを行うと頭の切り替えに時間がかかってしまい、生産性が著しく低下します。できるだけ同じ作業をできるようにし、あまり長時間かかる作業についてはサブタスク化し、短期的に集中した作業を繰り返せるようにします。
7) 仕掛品を増やさない
ソフトウェア開発における仕掛品とは、テストされていないコードや、顧客テストを通っていないコードです。これがあまり増えるとプロジェクトに何らかの問題が発生してぽしゃった時のリスクが高まることになります。テストされていないコードはバグを含んでいる可能性があり、そのバグが発覚した時に与える影響は大きくなります。できるだけ仕掛品を減らす努力が必要です。
チームに権限を与える
トップダウンの開発ではなくボトムアップの開発に切り替えます。開発者同士の話し合いを増やし、そこから生まれたアイディアをできるだけ取り入れていきます。顧客とのミーティングに開発者自身が参加し、納得感のある会議につとめます。
9) 作り直しは当たり前
よく一度書いたコードは触れないという人がいますが、それは無駄です。必要に応じてどんどん手を入れていくべきです。手を入れた時には必ずテストを行い、既存のシステムへの影響がないことを確認します。そのため、テストの自動化は必須です。
10) 部分最適化をしない
これはコーディングに限った話ではありません。企業としても営業部が営業だけを考えない、個人が自分の利益だけを考えない、経営層が自分たちの会社だけを守ることを考えないといったことも含みます。部分的な最適化は全体からみた場合、最善であるとは限りません。あくまでも全体の利益を考えた上で、最適な答えを見つける必要があります。
まとめ
リーンソフトウェアはトヨタに代表される日本の自動車業界をベースに生み出されています。そのため、カンバン方式などにも注目しています。が、ソフトウェア開発を工場などの製造業として捉えているのではなく、開発業として見ているのが特徴です。研究でもなく、あくまでも開発です。そのため、既知の技術や自分たちのもっている技術を使っていかに良いものを製品化できるかを常に考えるのが重要と説いています。
まだまだ足りない部分があると思いますので、ご指摘、ご質問はコメントにどうぞ。