【翻訳】ソフトウェア見積もりのパラドックス
はじめに
このエントリーは、Chris Lucianさんの Software Estimation Paradoxを許可を得て翻訳したものです。また、 Recruit Engineers Advent Calendar 2018 の20日目のエントリーでした。盛大に遅れましたごめんなさい。 誤訳等の指摘歓迎です。
ソフトウェア見積もりのパラドックス
人は以前に何度も完了したものの見積もりは上手にできる。
ソフトウェア開発者は、繰り返せるものや、時間のかかることは自動化する。
上手に見積れるものは、以前になんども繰り返して、自動化していないものである。
なぜソフトウェア開発者は、以前になんども繰り返したことを自動化しなかったのだろうか?
見積もりはムダだろうか?
ソフトウェア見積もりのパラドックスからすると、簡単に自動化できたソフトウェアは自動化できたかもしれない、といえます。また、見積もりが締め切りになってしまう環境下では、作りこまれるムダの量が増加するとも言えるでしょう。これはリーンソフトウェア開発の中核的なコンセプトに本質的に反しています。
どうやってムダを減らす?
ムダを減らすには、インセンティブの構造を変える必要があります。良い設計、継続的デリバリー、継続的インテグレーション、垂直的な区切り、遅延コストに基づく小さな機能の優先順位づけを組み込むことで、価値を素早く実現し、劇的にムダを減らすことができるようになり始めます。
次に何をすべきか?
※元記事からそのまま転載しています。そのうち訳します。
もし、次にやるべき機能を全てやろうとしていたら、継続的デリバリーと、垂直的なスライスを利用することで、その機能の遅延コストに基づいて機能を選ぶことが可能になります。機能を選んだ後は、今までに利用したことがない技術を含んでいたり、未知の設計を選択した機能を検証します。我々はこれを「既知の未知(known unknowns)」と呼びます。従来の見積もりのプロセスでは、これらの見積もりをするための調査期間を設けていただろうということに注意してください。もし、既知の未知が見つかった場合は、もし、既知の未知が見つかった場合は、コンセプトの証明のために時間をとるか、現状の我々の知識ではその機能の作成は不可能だと結論づけます。ひとたび、全ての既知の道がなくなったら、新たな未知の未知が見つかるまで機能のデプロイを進めます。もし何か未知の未知が見つかった場合は、再びその未知が消えるまでコンセプトの証明を行います。この時点で、デプロイし、次の機能に取り掛かります。このプロセスを、基本となる開発プロセスに組み込みむことで、コードはより高品質であることを維持し、途中でも効果を出し続けられるようになるでしょう。
※元記事からそのまま転載しています。そのうち訳します。
どうやって安全にムダを削減する?
この方向性をサポートするプロセスや技術はたくさんあります。下記のプロセスをゆっくりと組み込めば、徐々に変化していくことに気づき始めるでしょう。
- アジャイルなふりかえり
- ラーニングセッション
- カンバン
- WIP制限1
- ユニットテスト
- 超最小のMVP
- 継続的インテグレーション
- Zaroboogz1
- 自動化された受入テスト
- 継続的デリバリー
- 遅延コストに基づいたイテレーション
フィードバックがありますか? コメントでディスカッションに参加してください! そしてtwitterの #NoEstimates ハッシュタグもチェックしてください。
-
[訳注]すいませんこれ何かわかっておらず質問中です。わかる人いらしたら教えてください。↩