プログラマの思索

「成功する要求仕様 失敗する要求仕様」ではトリアージの概念が説明されている。
つまり、システムを実現する要求は、納期やコスト、リソースの観点から優先順位付けして、高い優先順位から要求をまとめていくというもの。

ヨードンの「デスマーチ」でも、デスマーチプロジェクトから脱出する唯一の方法はトリアージを行うことだ、と書かれていた。

そもそもトリアージとは、救急医療の用語。
災害医療等において、有限のリソース(医師や医薬品など)を最大限に活用して、より多くの傷病者を治療するために、治療の優先順位を決定することを意味する。

Wikipediaによると、下記4個の色のついた診断書を傷病者の右手首に取り付ける。
ここでは、治療の優先順位は、赤→黄→緑→黒　の順番になる。

【黒 (Black Tag)】
死亡、もしくは救命に現況以上の救命資機材・人員を必要とし救命不可能なもの。

【赤 (Red Tag) 】
生命に関わる重篤な状態で一刻も早い処置が必要で救命の可能性があるもの。

【黄 (Yellow Tag)】
今すぐに生命に関わる重篤な状態ではないが、早期に処置が必要なもの。

【緑 (Green Tag) 】
救急での搬送の必要がない軽症なもの。

日本では、実は、伊丹駅付近のJR西日本の脱線事故で、トリアージが初めて大規模に実施されたらしい。

Redmineでチケット管理を始めてから、トリアージについて色々思う所がある。
「ザ・ファシリテーター2」に出てくるFRCPの法則と絡めて、まとめてみる。

【1】機能(Function)

システム開発の要件定義では、まず、お客の業務をシステムがカバーできていることが最低条件。
これはまさに最低限の機能そのもの。
いわゆる正常系の業務フロー。

このカテゴリーでトリアージする目的は、不要な機能を捨てること。
直近のリリースに必要ない機能は、リソースが余っていない限り、作る必要は無い。
なのに、システム開発では、リリースに無関係な無駄な機能を作っている時が実は多い。
拡張性や保守性を重視しすぎて、逆に自分たちの仕事を無駄に増やしている。

【2】信頼性(Reliability)

最低限の機能を実現できると、お客は品質を求めだす。
このカテゴリーは、バグ修正や異常系の要求。

普通、バグ修正は機能追加や仕様変更よりも優先してやるべき。
理由は、品質が安定しないのに、機能追加や仕様変更で機能をどんどん増やしていくと、じきに品質をコントロールできなくなるから。

また、異常系の業務ロジック実装と、異常系に陥った業務のリカバリーロジックは、要求から漏れていることが多い。
理由は、お客も異常系の業務は殆ど使ったことがないから。

しかし、システムを構成するプログラムの8割は異常系業務の実装によるものといって差し支えない。
だからこそ、異常系業務の要件をあらかじめ根掘り葉掘り聞いておかねばならない。

異常系の中身は、プログラム内のException、DBのロールバックもあれば、ハード故障、フォールト・トレラントなどある。
例えば、小売系業務でクレジットカード決済が失敗した場合は、それなりの複雑な業務が発生する。

また、複数のWebサーバー、DBサーバーで本番系と待機系の二つを作り、ハードを冗長化する構成方法もある。
しかし、お金をかけずにハードの冗長化をせず、1台のサーバーで本番運用している所も多いだろう。すると、突然トラブルが起きてシステムが止まった時、それはお客の会社の業務が完全にストップすることを意味する。
そんな事態になったら、責任問題に発展する。

昨今はサーバーを含むハードウェアはとても安い。
信頼性を確保するために投資すべき。

【3】利便性(Convenience)

機能も信頼性も満足すると、お客は利便性を言い出す。
昨今の業務系Webシステムなら、もっと使い勝手を良くしてくれ、という要求が多いだろう。

最近は、業務系Webシステムもデスクトップアプリのように、リッチUIが普通になった。
良く使う技術は、Ajaxだろう。
他には、Flex/Air、Silverlight。

Ajaxを使えば、ブラウザ上の画面を常に最新情報で自動更新できる。
最新のWebブラウザは、JavaScriptエンジンの高速化に力を入れているから、Webシステムをうまく作ればデスクトップアプリと同じ感覚で使える。

しかし、Ajaxを使いこなすのは難しいと思う。
Ajaxのソースは、Javaのようなオブジェクト指向言語の発想ではなく関数型言語の発想。
クロージャや無名関数、リフレクションを多用しまくるので、敷居が高い。

更に、JavaScriptでサーバーに問い合わせずにクライアント内部でDOM生成できるので、画面の状態を保持するロジック、画面の状態を一つ前に復元するロジックが非常に難しくなる。
うまく設計しないと、すぐにスパゲッティコードになる。

また、使い勝手を重視した要件は大概、工数が結構かかる。
工数がかかる割には、期待するほどの使い心地にならないものだ。
だから、プロジェクトリーダーは、使い勝手向上の要望と工数を天秤にかけるのが普通。

【4】価格(Price)

機能、信頼性、利便性に満足したら、もっと安くしろ、とお客は言い出す。
システム開発が途方も無くお金がかかるのは、プログラマの単価が高いから。

大手SIerは、中国などに外注して、人月単価を安くする傾向にある。

最近思うのは、システム開発の現場は意外と手作業が多く、IT化されていない作業が実に多い。
システム開発の生産性が低いのは、システム開発のインフラがIT化されていないから。

ソース管理では、本番環境のモジュールはtrunk、裏で新規開発するモジュールはブランチのように、SVNリポジトリを分ける。
ソース管理は非常に重要なのに、ここでデグレが発生する時も実に多い。

継続的ビルド環境を作り、コマンド一発でモジュールをビルド＆デプロイできるようにしておく。
そうしなければ、バグ修正をすぐに検証できない。

要件を仕様に落とた実装は、全てRedmineのチケットで管理する。
そうすれば、チケットとソースが相互リンクされるし、全チケットの状態管理もRedmineならすごく簡単。
駄目なプロジェクトは、タスク管理が曖昧で、誰が何をしているのか、プロジェクトリーダーさえ知らない。

生産性を上げれば、価格にも対抗できる。