荒ぶる四天王がたちはだかったらスコープを倒せ

アジャイルサムライに出てくるプロジェクトの前に立ちはだかる強敵たちだ。

  • 時間
  • 予算
  • 品質
  • スコープ

プロジェクト成功のカギを握っているのは、荒ぶる四天王とどう付き合うかが重要になってくると思う。

アジャイルサムライによると、全ての四天王を最優先に倒しながらプロジェクトとを進めるのは非現実てきだと述べられている。

では、どのように付き合っていくのが良いのだろうか。

計画が現実にそぐわなくなっているのであれば、アジャイルサムライは計画を変える。

アジャイルサムライ――達人開発者への道より

計画が崩れ始めるとアジャイルサムライは計画を変えるようだ。となると、次の問はどのように計画を変えるかだ。

時間は、有限と考えられており、伸ばすことで顧客の信頼を失う可能性があり、それに加え何も提供できなくなる状況に陥る可能性があるため、変えることが難しいと考えられている。

予算は、資金調達の難しさや、人的リソースが有限であることから、変えることが難しいと考えられている。

では、品質とスコープはどうだろうか。

品質は、落とすことで期間内にソフトウェアをリリースすることは可能だと考えられている。

しかしながら、この考えはアンチパターンとなりそうだ。

品質には大きく外部品質と内部品質のふたつに分かれる。まずは外部品質から見ていこう。

外部品質は顧客が要望した機能がちゃんと実装されたかどうかをはかる品質だ。外部品質を下げることは、顧客の要望に沿わない機能ができてしまう可能性があるので論外だ。

では、内部品質についてはどうだろうか。結論を言うとこの考えもアンチパターンになりそうだ。

内部品質は細分化するといくつかの項目に分けられるが、ここではプログラマからみたコードの品質としたいので内部品質の中でも保守性に充填をおくことにする。

内部品質を下げるということは、今後の開発のスピードを下げることとイコールになると考えられている。

内部品質を下げて開発をすすめることに関しては、マーチン・ファウラーのブログがとても参考になる。

開発者は、質の悪いコードは数週間以内に著しく遅くなることに気づいています。つまり、内部品質とコストのトレードオフが適用される期間はほとんど無いのです。

品質の高いソフトウェアはそのコストに見合うのか?より

内部品質を下げる行為は、数週間後にその代償を払うことになりそうだ。

半年以降に代償を払うことになるとすれば許容できそうな気がするが、数週間となれば内部品質を下げてまでゴールに向かう意味はないように思える。

顧客そして開発者にとっても幸せな結果をうまないことは容易に想像できる。

時間・予算・品質が削れないとなれば、残りはスコープを削ることになりそうだ。

スコープを削ると、リリースできる機能は少なくなるが良いこともありそうだ。具体的には次の良いことがあると思われる。

  • 時間を犠牲にせずにすむので期間内にソフトウェアがリリースできる
  • 内部品質を犠牲にせずすむのでソフトウェアの保守性が高まる

もし価値を継続的に俊敏に提供したいならスコープを削ったほうが良いのかもしれない。

参考文献

ソフトウェア開発における見積もりはあくまで予測

TODO: 時折言葉が強い部分が強く攻撃的に感じられる表現があるので改善したい

主語を大きく「ソフトウェア開発」としてしまったが、厳密にはアジャイルを採用しているソフトウェア開発の見積もりについての言及である。

見積もりをどうしても間違うことが問題なんじゃない(まあ実際、間違えてしまうわけだし)。問題は、見積もりは本来そこにありもしないものを読み取ってしまうことーーつまり、見積もりを本来の正確な予測と思い込んでしまうことにあるんだ。

アジャイルサムライ――達人開発者への道より

私はこの言葉に強く共感する。ソフトウェアエンジニアであれば、この内容に頷ける人も一定数いるのではないだろうか。

私個人としては、アジャイルを採用しているソフトウェア開発に限らず、ウォーターフォール開発においてもこの認識は重要だと考えている。

ここで言う「見積もり」とは、予算や納期のことである。

見積もりを未来の正確な予測と捉えてしまう人は、ビジネスサイド1の人に多いように感じる。

私はビジネスサイドの人と対立して主張を通したいわけではない。実装の見積もりは本当に難しいということを理解してほしいのだ。

私が見積もりが難しいと感じる理由は、主に以下の2点である。

  • ソフトウェアのプログラムをすべて把握するのは不可能に近い
  • 実装してはじめて分かることや、壁にぶち当たることがある

また、ウォーターフォール開発の場合、納期に向かって開発を進めるため、見積もりを誤ると内部品質(特に保守性)を犠牲にして開発を進めざるを得なくなる。

この状況は、あまり良いとは思えない。

なぜなら、内部品質を犠牲にしてソフトウェアを構築すると、後々の機能追加に時間がかかったり、バグの発見が遅れたりして、結果的にコストが大きくかかってしまうからだ。

私の実体験からも、納期が逼迫した現場では、保守性を犠牲にする具体例として、コードレビューを疎かにしてしまうことがよくある。

見積もりを未来の正確な予測と捉えてしまうと、良いソフトウェアを継続的に開発するのは難しいのかもしれない。


  1. ここでビジネスサイドという表現で対立するような表現になってしまったが、揶揄しているのではなく他の言葉が思い浮かばなかったので、プログラマとではない人として、このような表現になっていることを了承してもらいたい。