 |
|
|
前のページ 1 2 3
|
|
| 押し寄せる変更要求
|
開発が完了した機能からユーザに確認を取っていきました。筆者は開発作業をおこなっているため、確認会は松井氏に任せていました。そんなある日、確認会からプロジェクトルームに戻ってきた松井氏に「鹿取さん、ちょっと来てくれへん？」と呼ばれました。
できあがったシステムを見たほとんどのユーザから、やはりこうしたい、イメージと違っていた、という声があがります。開発者の立場からすると「要件定義の承認をしたではないか」という思いですが、それはなかなか通りません。ユーザが望むもの、必要なものを明らかにできなかったのは開発者の責任でもあります。
松井氏から見せられたノートにはびっしりとユーザの要望が書かれていました。残りの機能の開発があるため、とてもではありませんが全てに対応することができません。そのためユーザに優先順位をつけてもらい、優先順位が高いものの対応を検討することになりました。
確認会をおこなうたびにこのように変更要求があがり、最終的には結構な数にのぼりました。それまで開発してきたプログラムの中身は、動かすことで精一杯であり、読みやすさ、変更のしやすさなどは全く考慮されていませんでした。
そのため、いざ変更になると非常に苦労することになりました。プログラム間の依存度が高いために、1つの変更をおこなうと色々なところに影響がでてしまいます。また、同じ処理をおこなうためのコードが複数のプログラムに書かれており、1つの変更のために複数のコードをチェックしなおさなければなりませんでした。
|
| 今後を考えた上で
|
工数に余裕はありませんでしたが今後の機能拡張の可能性も考え、できる範囲でリファクタリングをおこなうことにしました。他に影響がでないように一部分ではデザインパターンも適用しました。その結果、変更にかかる工数が減り、変更によって新たなバグが埋め込まれることが少なくなりました。
これまで書いていたプログラムは言語こそJavaでしたが、お世辞にもオブジェクト指向とはいえないものでした。この経験により、設計の重要性やオブジェクト指向のメリットを実感することができました。
|
| カットオーバー
|
テストを終えてユーザからの変更要求も収束し、いよいよカットオーバーを迎えることになりました。この時点でA社の松井氏と坂井氏はプロジェクトを離れ、筆者がシステム全体のサポートをおこなうことになりました。
稼動してみるとすんなりとはいかず、障害が続発しました。しかしこの時点では筆者1人しかおらず、障害解決の責任は全て自分にのしかかってきます。最終的には、Webで調査したり、自社のメンバーの助けを借りたりして障害を解決することができました。
稼動から1ヵ月すると障害は収束してサポートが不要になり、プロジェクトチーム（最終的には筆者1人でしたが）は解散しました。このプロジェクトで様々なトラブルを経験したことで、システム開発における問題点を実感することができました。表3にあげる点が主に考え直した点です。
|
- システムのレベル
- 規模がある程度大きく複雑な処理があり、当時の自分の能力を少し上回る
- システムに対する責任
- カットオーバー後のシステムの責任を自分1人で負う
- 担当範囲の広さ
- 縦（要件定義〜稼動後サポート）に長く、横（システムの機能）に広い。プロジェクト全体・システム全体を見る
- 変更の多さ
- 要件変更時にいかに簡単・安全にプログラムを変更できるかを工夫する
|
表3：筆者の転機となった点
|
筆者は表3の問題点をなくすにはどうしたら良いかを考え、再度情報収集をしてプロジェクトに反映させていくようになりました。このことが今回紹介したプロジェクトで1番学んだことです。
|
前のページ 1 2 3
|
|
|
|
|
著者プロフィール
株式会社ビーブレイクシステムズ 鹿取 裕樹
オープン系ITコンサルタント。SAPジャパン社にて、ERP導入コンサルティングを行い、そのユーザ企業の現場でJava及びオープンソースの躍動を感じ、それらに興味を持つ。その後、会社を設立。オープンソース及びJavaを用いたシステム提案活動を行い現在に至る。専門分野はSAP R/3と連携するWEBシステムのコンサルティング。
|
|
|
|
|
|
