ソフトウェア開発の基本的な問題〜 18年前からXPが提示するリスクの紹介

Takeshi Kakeda

·

Follow

Published in

kkd’s-remarks

·

3 min read

·

Oct 22, 2017

--

Share

自分が、ここ数年アジャイルのトレーニングの際に必ず示している図がある。それが「エクストリームプログラミング」の第一版から第一章で提示されている、ソフトウェア開発に関するリスクについての図だ。

先日、Agile459のオンライン読書会で紹介したら好評だったので図を貼って置くことにする。

念のため、エクストリームプログラミングを読んだことのない人向けに説明しておくと、これらの元ネタは書籍（初版では１章まるごと、第二版・新訳版では１章で部分的に）では列挙されているが、本文に列挙されているだけなので、自分なりに整理してこのような図にしている。

実現できない

スケジュールが遅れたり、度重なる遅延で実現の前に資金がなくなりプロジェクトが終わってしまうというリスクがまず最初にある。

動かない

なんとか実現しても、欠陥が多くまともに動かなかったり、その結果としてシステムが劣化（＝メンテナンス不能に）になり、作り直しせざるを得ない状況になる。今で言うところの技術的負債が蓄積した結果だ。

役に立たない

なんとか技術的負債を返済して、動くシステムが出来上がったとしても、そもそもビジネスを誤解していたり、ビジネスの変化に対応できないと、システムはビジネスにとって役に立たない存在となる。

続けられない

ビジネスを正しく理解し、変化に対応できる仕組みが整っていたとしても、追加していく機能がビジネス的に価値がない、あるいは、技術的に面白いという理由だけのフィーチャをつけ加えていくと、ビジネス価値に繋がらず結果として儲からず、続けられないシステムになっていく。

すべてに関わる離職

そして、システムやビジネスに価値がなく、利用者に愛されず、質の悪いシステムのままだと、仕事にやりがいを感じなくなり、たとえ周囲の環境を変えようとしても、孤独な戦いに疲れてしまった優秀な開発者は職場を離れていくだろう。

これらのリスクは段階的に書いてはいるが、それらが有機的に関連している。

自分は、これらのリスクを「プロダクト開発リスク」と「ビジネス開発リスク」と整理し、チーム全員でこれらのリスクに対応していくことをまず第一に伝えている。開発者だけではビジネス開発リスクには対応が難しい、同じように、プロダクトオーナーだけではプロダクト開発リスクには対応できない。システムの全体性とはこれらすべてなので、部分的に対応していても、いずれ問題として顕在化してくるだろう。

古くても新しいXP本

これらのリスクに具体的にどうやって対応するか？というのが第一版から第二版へと継承されているブレないXPの価値・原則・実践のテーマの１つだ。

もし、XPのことを、「10年以上前の昔の本だ」と思って読んだことのない方がいたら、是非新訳版を手にとって読んでほしい。

きっと、あなたの現在課題に感じている箇所について、ヒントとなる、あるいは、勇気づけられる言葉がきっとあるだろう。