Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
「XPマンセーッ！」
毎度、XPオタクのますくです。
リスク．．．このキーワードも、前回の記事で挙げた”テスト”のように、100人いたら100通りの解釈がある、危険なキーワードだ。
だがXPにおいて、「ソフトウェア開発のリスク」は、ある程度定義されている（白本P3〜P4より）。
- スケジュールの遅延
- 度重なるスケジュール遅延によるプロジェクトのキャンセル
- システムの陳腐化によるコストや欠陥率の上昇
- 高い欠陥率
- ビジネスの誤解
- ビジネスの変化
- 誤った機能強化
- スタッフの退職
まず、これらが「ソフトウェア開発のリスクなの？」と頭を傾げる方がたくさんいるかも知れない。
何かにつけ「それは仕様変更なので、追加料金をいただきます」と脊髄反射する開発側にとって、「ビジネスの変化」は一体何がリスクなのかピンとこないかも知れない。
この典型的な反応は、ビジネス側の都合なんて一切考えていない開発側の対応そのものだからだ。
きっと、過去にビジネス側にいじめられたか、被害妄想が原因で、自分たちの開発プロセスのまずさや変更発生時のコミュニケーションの取り方のまずさに気付くことなく、ひたすら態度を硬化させた結果ではなかろうか？
ビジネス側でもこういった後ろ向きな反応はある。
「リファクタリングや最適化なんて、工数積むための開発側のエゴだろ」と言い張るビジネス側は「システムの陳腐化によるコストや欠陥率の上昇」なんてリスクは一切考えていない。
将来のコスト発生や欠陥発生なんて眼中にない、実に近視眼的というか、ケチなデイトレーダー的発想でしかソフトウェア開発を考えていない。
きっと、過去に開発側にだまされたり、裏切られたことを根に持って、自分たちの投資ビジョンのまずさや開発側をのせてこき使うやり方に気付くことなく、ただ少ない金でやらせればいいと割り切ってしまった結果ではなかろうか？
いずれにせよ、こういった後ろ向きな態度は、リスクを前向きに負って、他を出し抜くための競争力を持った者たちのやる行動ではない。
だから、結果的に稼ぐ量もたかが知れている。
いわゆる「リスクを負えないいくじなし」だ。
その生態は、大企業のSIerやサラリーマンエンジニアにたくさん見られる。
自分で決断をしない。
その代わり、リスクも負わない。
大勢が嫌がるリスクを負って、ローリスクに処理することで、大きな利益が獲得できるというのがビジネスおよび経営の基本だが、そんな考えとは無縁だ。
XPがベストで、XP以外のアジャイル開発プロセスや重量級開発プロセスがダメだと私が主張するのも、実はこの点に多くある。
ようするに、ビジネス側の利益を最大化するために、リスクを前向きにとらえて、きちんとローリスク化していくことがビジネスでは重要なのだ。
また、ソフトウェア開発におけるオプション的コンセプト（廃止、切り替え、遅延、成長）が、XP以外の開発プロセスでは、ほとんど考慮されていないことに大きな疑問を感じる。
ただの開発者のエゴとしての開発プロセスなら、経済的理由はいらないし、リスクへの対処もたいして重要ではないかも知れない。
しかし、純粋なオープンソース開発とは違い、お金をもらってソフトウェア開発をする以上、経済的な裏付けは必要だし、リスクへの対処はお互いの身を守るために必須だ。
そういう意味で、XPは単純な開発プロセスではない。
だが、他の開発プロセスが牧歌的過ぎるのではないだろうか？
少しは、XPのコンセプトから学んで欲しい。
たとえばXPは、「ソフトウェア開発のリスク」にこう対処している。
- スケジュールの遅延
- 短期リリースにより、遅れの範囲を限定しつつ、早期に遅れの検出を行う。
- 最重要の機能を先に実装するため、重要な箇所のスケジュールは厳守される。
- 度重なるスケジュール遅延によるプロジェクトのキャンセル
- ビジネス上で最も価値のある機能からリリースされるため、キャンセルされても最も価値のある機能は確実に残る（それを元に最低限の運用ができる可能性も残る）。
- システムの陳腐化によるコストや欠陥率の上昇
- 自動テストのおかげで品質は優れた状態に保たれるため、変更のコストや欠陥率の上昇は抑制される。
- 高い欠陥率
- 開発側のユニットテスト、ビジネス側の受入テストの両面でテストが行われるため、欠陥の発生やデグレードは大幅に抑制される。
- ビジネスの誤解
- ビジネス側とのワンチームを築くことで、コミュニケーションミスは少なくできる。
- 短期リリースにより、実際に動くシステムでコミュニケーションを取れるため、認識の違いから来る誤解も抑制される。
- コミュニケーションミスが発生しても、受入テストによる仕様伝達やフィードバックにより、早期に発見され、対処が可能となる。
- ビジネスの変化
- 短期リリースのたびに仕様変更を受け入れるタイミングができるため、柔軟な変化への対応が可能となる。
- シンプルな設計をしているため、プログラムは変化に強い。
- テスティングにより、変更を行った場合の影響範囲を把握できる。
- テスティングとリファクタリングの組み合わせで安全に変更を施すことができる。
- 誤った機能強化
- ビジネス上の最も価値が高い機能を優先しているため、余計な機能強化が入ってくることはなくなる。
- スタッフの退職
- 計画ゲームで作業ボリュームと見積もりはガラス張りになるので、無茶なスケジュールになることは少なくなり、スタッフの不満はたまりにくい。
- 更に計画ゲームに支えられた週40時間労働を実現することで、とんでもない残業やデスマーチに陥ることはなくなり、スタッフは快適に仕事ができる。
- 問題が起きても、仲間との頻繁なコミュニケーションやペアプロによって、問題を１人で抱えて自滅することを防御できる。
そして、これらXPのコンセプトは、どちらかと言えば、エンジニアよりも、SIerや経営層、投資家にこそ知ってもらいたい。
エンジニアが経済的にコントロールできることは、ほとんどないからだ。
それよりもお金を持っている「根っこ」のSIerや経営層、投資家たちが、ソフトウェア開発の経済的選択として、XPを選んで欲しい。
そして、開発側にXPを強要して欲しい。
根っこが腐っていれば、枝葉は自然と腐る。
根っこがしっかりしていれば、枝葉は自然としっかり実る。
There is no comment.