 |
|
|
| 前のページ 1 2 3 次のページ
|
|
| キックオフミーティング
|
8月某日。「今日も暑いですねぇ。」と、当たり障りの無いこの一言からプロジェクトが始まることになります。
プロジェクトを開始するに当たり、ユーザとプロジェクトメンバーとでキックオフミーティングを行うことになりました。キックオフミーティングではユーザと、ベンダーである筆者らとの間でプロジェクトの目的・プロジェクトの進め方を確認していきます。
今であれば、キックオフミーティングを行う意義や重要性はわかるのですが、何せこの時はキックオフミーティングを主体となって行うのが初めてで、資料は何を用意して、どのように進めていけばよいかも分かりませんでした。分からないながらも自分なりにミーティングの目的を考え、そのためにはどのような資料が必要かを考え、何とか資料をそろえた重たいかばんを抱えて、汗を流しながらユーザのオフィスに向かいました。
そして、ついにミーティングが始まりました。私は内心、キックオフってこういうものか、と思いながらもユーザを不安がらせてはならないと思い、「いつもこのようにしております。」などと、あたかも経験豊富なエンジニアのふりをするのに懸命でした。ユーザ側には経営者も参加しており、その方たちの前であの時流した冷や汗のことは今も鮮明に覚えています。
上司のサポートのもとなんとかキックオフミーティングを終えた頃には、喉がからからになっていました。
|
| うわべだけの要件定義
|
キックオフミーティングの翌日から早速要件定義が始まりました。要件定義ではユーザの要求をもとに、"AS IS"および"TO BE"の業務フロー、開発する機能の仕様を決めていきました。結論から述べてしまいますと、ここで筆者はいくつもの失敗を犯してしまっていました（表1）。
|
- ユーザの要求をそのまま受け入れた
- 「木を見て森を見ず」となり、全体としてちぐはぐなシステムにつながった。
- 機能の業務上の目的を明確にしなかった
- 業務を理解せずに仕様を作成したため、システムを実際に業務で使ってみると「使えない」。
- 運用を考慮していなかった
- 表面上動くように見えるが、動かすためには非常に手間がかかる作業をする必要がある。
- 実装を考慮していなかった
- 工数オーバー。
|
表1：失敗例
|
要件定義でも筆者は「経験豊富なエンジニア」のスタイルを貫きました。このこと自体は悪いこととは考えていません。ユーザを無闇に不安がらせても何も良いことはないためです。しかし、この時筆者には、知ったかぶりしたことを後で徹底的に調べ、考えてキャッチアップするということが欠けていました。そのため、この時には気づいていませんでしたが、不完全な仕様となっていたのでした。
|
前のページ 1 2 3 次のページ
|
|
|
|
|
著者プロフィール
株式会社ビーブレイクシステムズ 鹿取 裕樹
オープン系ITコンサルタント。SAPジャパン社にて、ERP導入コンサルティングを行い、そのユーザ企業の現場でJava及びオープンソースの躍動を感じ、それらに興味を持つ。その後、会社を設立。オープンソース及びJavaを用いたシステム提案活動を行い現在に至る。専門分野はSAP R/3と連携するWEBシステムのコンサルティング。
|
|
|
|
|
|
