アジャイルにするとなぜ開発期間が短くなるか

従来型からリリース改善型アジャイルに変えるメリットのひとつは納期短縮である。しかし、何故それが可能なのかを理解している人は少ない。今回はこれを考察してみよう。

次の画面は簡単な社員管理システムを構成する。

ログイン画面
ユーザ登録画面
社員情報照会画面
社員情報明細画面
社員情報登録画面
社員情報修正画面

画面とは機能であり機能とは優先順位をつける対象である。そこで上の画面に優先順位をつけてみよう。

優先順位の付け方は、その画面がなくても他の画面を開発できるか、である。どういう意味か。
上の画面でいえば、社員照会画面はログイン画面から遷移され、照会明細画面は社員照会画面から遷移される。社員照会画面はログイン画面がなければ動かないし、社員明細画面は社員照会画面がなければ動かない。これらん踏まえた優先順位にリリース日を付与すると次の様になる。

ログイン画面：4/6リリース
ユーザ登録画面：4/13リリース
社員情報照会画面：4/20リリース
社員情報明細画面：4/27リリース
社員情報登録画面：5/11リリース
社員情報修正画面：5/11リリース

このように、アジャイルであれば1ヶ月半で全機能がリリースされるが、従来型のプロセスなら2ヶ月以上かかってしまう。では、何故アジャイルだと早くリリースできるのか。

理由はふたつある。ひとつはフィードバックによる設計またはプログラミングの学習効果である。社員修正画面は社員登録画面や社員明細画面のフィードバックにより開発工数は半分以下になる。
もうひとつは開発環境配布の容易さである。第1イテレーションで開発された画面は直ぐに配布され開発者全員が次のイテレーションの準備に入る事ができる。

ここでログイン画面がない状態を想像して欲しい。ログイン画面がなければ社員照会画面をどうやって起動するのだろう。
もちろん最終的にはその様な画面はリリースされないが、開発途中ではそのような状態にはなり得る。そして現場ではこの様なケースはしばしば起きる。社員照会画面の担当者はログイン画面なしで開発をしなければならない。つまりログイン画面の社員照会画面を起動する機能とユーザ情報を作成しセッションにセットする機能を、ログイン画面担当者でもない社員照会画面担当者が作らなければならない。これはログイン画面が先に開発されていれば全く不要な作業だ。要するにその無駄な作業工数が増大するだけなのである。

プロジェクト管理の実践

アジャイル開発の方法論は大きく２分される。ひとつはXPに代表されるプログラミング改善を主に置くもの。もうひとつはFDDに代表されるリリース改善に主を置くもの。
FDDの特徴は機能毎にリリース計画をたてることである。システムを6ヶ月後にデリバリーしなければならないなら、通常の開発であれば、最初の1ヶ月目で基本計画と要件定義、2ヶ月目で基本設計、3ヶ月目で詳細設計、4ヶ月目でプログラミングと単体テスト、5ヶ月目で結合テストとシステムテスト、6ヶ月目で受け入れテストとデータ移行、リリースという感じであろう。しかし、これでは受け入れテストでクライアントがNGを出した場合にリリース遅延が発生してしまうリスクがある。
そこでFDDでは重要な機能を先行リリースする。これによりクライアントが重要な機能でNGをだしても対応が容易い。

例えば買い物サイトを考えてみよう。ざっと考えても次のような機能があげられる。

ログイン機能
メニュー機能
商品照会機能
商品明細機能
買い物カゴ照会機能
会計機能
ユーザ登録機能
ユーザ管理機能
商品管理機能
取引管理機能

さて、FDDで開発するならこれらの機能に優先順位をつけなければならない。
まず、リリース日に最悪間に合わなくてもいい機能を洗い出そう。それは管理機能、つまりユーザ管理機能、商品管理機能、取引管理機能である。これらは最悪リリースに間に合わなくても運用でなんとかなる。一般ユーザが使う機能ではないからだ。これらは最後にリリースする。
次に画面遷移順に優先順位を考える。これなら優先順位の高いのはログイン機能でありメニュー機能である。
さて、いまの段階で優先順位は3段階に分けられている。

<優先順位1>
ログイン機能
メニュー機能
<優先順位2>
商品照会機能
商品明細機能
買い物カゴ照会機能
会計機能
<優先順位3>
ユーザ管理機能
商品管理機能
取引管理機能

これでイテレーションは3回だが、もう少し分割してイテレーションを7回にしてみよう。

<優先順位1>
ログイン機能
メニュー機能
<優先順位2>
商品照会機能
<優先順位3>
商品明細機能
<優先順位4>
買い物カゴ照会機能
<優先順位5>
会計機能
<優先順位6>
ユーザ管理機能
<優先順位7>
商品管理機能
取引管理機能

優先順位が決まったら次にリリース日を計画する。最初のリリースはログインとメニューしかない所謂ブランクシステムである。といっても、ログイン機能にはログイン画面の他にユーザ登録画面が必要だし、セッションにユーザ情報をセットしなければならない。ユーザ情報を管理するテーブルも必要だ。メニューにしてもトップ画面としての画面デザインも重要である。また、最初のリリースであれば開発者も環境に「慣れ」ていない。つまりこのリリースは簡単ではない。そこでイテレーションは4週間に設定し、優先順位2移行を2週間単位でリリース計画をたてる。

イテレーション型は従来型のやり方を何度かに分けているにすぎないのでリリース日は早まるわけではない。だが従来型に比べ、フィードバックによる学習効果がある。これにより開発者の勘違いが減り、単体レビューによる手戻りは激減する。またノウハウをシェアできるので開発効率や品質は向上し、遅延による損害リスクも最小限に抑える事ができる。

nullを返却しない

前回、NullPointerExceptionの原因を解析するには１行にメソッドを２つ以上記述すべきではないと書いた。だが、そもそもnullが入っている変数のメソッドを呼ばなければNullPointerExceptionは発生しない。つまりメソッド呼び出しの前に常にnullチェックをすればいい。だが、やり過ぎるとコードは冗長となり読みにくい。そこで今回はNullPointerExceptionを発生させない方法について考えよう。

ボブマーチンは著書クリーンコードで「nullを返さないことで無用なnullチェックを避けられる」と書いている。

List employees = getEmployees();
for(Emploee emp : employees) {
totalPay+=emp.getPay();
}

これは従業員の給与合計を算出するコードだが3行目でNullPointerExceptionが発生する可能性を秘めている。これを回避するためにnullチェック行を追加しなければならない。

List employees = getEmployees();
if(employees != null) {
for(Emploee emp : employees) {
totalPay+=emp.getPay();
}
}

なんてセンスのないコードだ！インデントが２段階ある！
この様な冗長なコードを書いてはいけない。

センスのないnullチェックをせずに尚且つNullPointerExceptionを回避するにはgetEmployeesの返却値がnullでないようにすれば良いのだ。

/**
*全従業員を取得する。
*@return 全従業員( != null )
*/
Employee getEmployees() {
.....
if( もしも従業員がひとりもいなかったら ) {
return new ArrayList();
}
}

従業員が一人もいない時にnullを返せば、呼び出し側はnullチェックをしなければならない。だが、空のListならチェックは不要だ。nullでないと分かっているならnullチェックなんて必要ないのだ。

良いコードの条件

最初に例外について。

Javaの例外といえばNullPointerException、NullPointerExceptionといえばJavaの例外と言われるほどNullPointerExceptionはJava開発でよく発生するが、この例外をつぶすのは初心者には意外と難しい。何がnullなのか分からないからだ。だがコツをつかめば簡単に分かる。

NullPointerExceptionが発生する箇所はnullが格納された変数のメソッドである。これ以外にない。

str=str.substring(2,3);

エラーログがNullPointerExceptionが発生したのはこの行だと示していたとしよう。この行に変数はメソッドはsubstringしかない。とすればstrにnullが混入しているとすぐにわかる。
では次の行でなNullPointerExceptionが発生していたならどうか。

v1.m1(v2).m2();

このコードにはメソッドが2つある。このままではNullPointerExceptionがどちらで発生しているか分からない。そこで次のようにリファクタリングする必要がある。

v3=v1.m1(v2);
v3.m2();

これならメソッドが１行にある１つとなるため、どちらでNullPointerExceptionが起きたかがわかる。

良いコードとは読みやすいだけでなく解析しやすいコードなのである。

ダメダメ君にならないために勉強しなさい！

こんにちは、ちゅんと申します。

この間、ある会社の社員教育を支援したんですが、そこの社員がダメダメで、まぁ、かわいそうなくらいでした。

そのダメダメ君がなぜダメダメなのかを一言で表現するなら勉強しないからです。

むろん、闇雲に勉強してもだめで、初心者にはやはりメンター（導師）が必要です。

ダメダメ君にはメンターがいなかった。それが彼にとっての不幸です。

このブログがもしもあなたのメンターの代わりを務められるなら幸いです。