ソフトウェア開発で何が良いか判断基準
前回も書いたが、他にも色々ある。
http://d.hatena.ne.jp/haru01/20100417/1271516548
Web企画屋の目
- ユーザ数の伸び率の傾きを維持しているか
- ページビューが十分あるか
起業家の目
- 継続的に儲けて、事業が続けられるか
- ユーザ、プロジェクトメンバーが集まってくる魅力的な場を提供できているか
開発者の目（自分に近いポジションなのでもう一度、別表現で）
- クリーンなコードを保っているか
- DSLsやデザインパターンが示すような、良いとされるcodeが形成されているか
- テストの不吉な臭いが発生していないか。xUnit Patternsが示す、良いとされる test、testingを 行っているか
- TDDらしい、有機的秩序の原理、診断の原理を満たしているか
- Customer Testing らしい、顧客参加の原理、有機的秩序の原理、診断の原理を満たしているか。
デザイナーの目
- ユーザにとって、わかりやすく 魅力的な インタフェースか
- ビューの裏側にある、情報構造やストラテジーと整合性はあるか
- ユーザの利用のコンテキストが想像できているか
複数の目を混ぜ合わせ、全体で何が良いかと判断する難しさ
例えば、顧客やユーザ目線だと、Codeのクリーンさなんて、プログラマ目線に比べれば、関心が薄い。
文字通り見ている要素が違うから。
ただし、Codeのクリーンさ は間接的に 顧客やユーザに影響を与える。バグ発生から修正にかかる時間や 今後の新機能追加にかかる時間などなど。
なんだけど、一定の共通の判断基準がないと、合意が難しい。技術的負債は、codeのダーティな度合いをお金に変換して説明している。顧客やマネージャが意思決定判断できるように。
「技術的負債」の言葉の利用で、開発者が、Codeの状態を時間・金として関心を払い、顧客やマネージャにきちんと状況を説明し、Codeの状態をクリーンに保つ、修復の時間を確保し、返済できれば、よしよしとなる。
この試みは、複数の異なる目があるなかで，ある一定の共通の判断する基準づくりの示唆を与える。
