読者です 読者をやめる 読者になる 読者になる

アラタナエンジニアブログ

aratana Engineer's Blog

恐れと向き合う開発手法

アジャイル XP

こんばんは、4月にアラタナに入社しました、永遠の39歳、木目沢です。

私の部署では、ようやく保守のフェーズに入り、毎週定期的にお客様にリリースできるようになりました。

8月に大きなリリースがされるまでは所謂ウォーターフォール開発で進めており、リリース直前まで、私達はとても苦しい開発をしていたと思います。

8月以降は緊急でリリースされる案件も含め、毎週一回はリリースをしています。
タスクもBacklogで管理され、毎週リリース計画会議が開かれて次週リリース分を決めています。
その際には、延期される案件もあったり、前倒しでリリースされる案件もあります。

さて、こうして、大きなリリースした8月前後を振り返ってみると、気持ちに変化が生じていることに気が付きました。

今はとても落ち着いてリリースができている。誰も無理をしていない(かも)。開発に集中できている。
緊急度・優先度が決められ、それを基準に沿ったリリースできている。つまり、お客様のビジネス価値に直結するリリースができている。

それはなぜか?というのが今回のテーマです。

開発者の恐れ

すべての方法論は、恐れに基いています。
by Kent BeckXP エクストリーム・プログラミング入門 -ソフトウェア開発の究極の手法 」より


今回は、方法論の話ではないのですが、実際、8月前後で開発の仕方が変わっていますので、引用してみました。

それで、何を恐れているのかというと・・・

ソフトウェア開発における基本的な問題とはリスクである
by Kent BeckXP エクストリーム・プログラミング入門 -ソフトウェア開発の究極の手法 」より

そう、リスクに対する恐れなんですね。

例えば、

  • スケジュールの遅延
  • プロジェクトの打ち切り
  • システムの劣化
  • 欠陥率の高さ
  • ビジネスの誤解
  • ビジネスの変化
  • 必要のないフィーチャーばかり
  • 人材の流出

by Kent Beckエクストリーム プログラミング」より

こういったリスクから恐れが生まれます。

つまり、8月以降、これらのリスクとそこから生まれる恐れにきちんと向き合うことができるようになったと言えます。

その要因はなんだったのか・・・

ソフトウェア開発の不確実性

まず思いついたのが、「ソフトウェア開発の不確実性」

f:id:kimesawa:20160928084408g:plain
見積りを狂わすメカニズム − 「なぜ見積りは不正確なのか」より)

上の図は「不確実性コーン」と言われる図です。
X軸はウォーターフォールによるプロダクト製造過程、Y軸が計画と実績のブレ幅です。

この図から言えることは、プロジェクトの初期段階で立てた計画では、最大で4倍見積もりが足りず、最小では0.25倍多く見積もることがあるということです。大概見積もりは過小評価されることもわかります。
設計から実装にかけて見積もりは正確になっていきますが、それでも開きは生じます。


開発からリリースまで期間が長ければ長いほど不確実性が増します。
8月以降、毎週一度はリリースすることによって、この不確実性の度合いが少なくなっているのが大きいです。

しかも、見積もった期間よりもっと時間がかかると判断すればリリースを延期しますし、早くできると判断すれば早くリリースします。

このやり方によって、スケジュールの遅延というリスクと向き合え、さらに品質の向上(=欠陥率の高さというリスクと向き合う)にもつながっていると思っています。

また、頻繁にリリースすることで、緊急度・優先度が高い順に自然とリリースすることになり、ビジネスの変化というリスクにも向き合うことができています。

8月以降の気持ちの変化はこういうところから来ているのだと実感しています。

ソフトウェアは人間が作っている

最後に、私が強く思ったことを。

人間がソフトウェアを作っているからリスクが生まれ、そこから恐れが生じる。
恐れを克服するのではなく、きちんと向き合うことでよいソフトウェアは作られる。

そして、もっと人間に着目すればもっとよくなるかもしれない。。。
そのように思いました。
今回アジャイルという言葉を使いませんでしたが、アジャイルが重要視しているのもやはり同じことだと思います。

ソフトウェアが人間の手によって作られるということを忘れてしまっては何も役に立たない。結局、人間に焦点を当て、幸せで、向上心を刺激するものであれば、ソフトウェアを納品することができるだろう。

by Kent Beckエクストリーム プログラミング」より