あるプロジェクトで工夫したこと

仕事のやり方

(QCD的に)成功したあるプロジェクトで工夫したことを備忘録のために書いておきます。

そのプロジェクトの特徴は以下の通りです。
【納期】サービスインの時期は確定しており、それまで約3.5ヶ月。
【要素技術】RubyOnRails
【メンバー】お客様、SI側もこのプロジェクトの前のプロジェクトと一緒(なので気心が知れていた)。
【自分の立場】プロジェクトリーダー

【1】マイルストーンの認識合わせ

まず最初にお客様と具体的なマイルストーンの認識合わせを行いました。短納期だったため、ちょっとした遅れが大きなダメージを与えるものでした。

その為、その共通認識を高め、お互いのタスクの優先度や期限日を調整、合意しました。
タスクの期限日を2つ…「できればこの日までに欲しい(努力日)」と「絶対この日までに欲しい(必達日)」…設けて、お互いにバッファを設定し、それを有効利用できました。
#この辺はお客様、メンバー双方とも気心が知れていたので、こういう交渉や調整がかなりスムーズにできました。

【2】実物…デモ版の早期リリース

かなり早い段階…それこそだいたいの外部設計が固まった段階…で、お客様に実際に動くデモ版※を見せ、そのフィードバックを早めにもらったことです。
そこそこDBとの連携もできているものでした。

イメージや仕様書で見せるよりも実際に動くものをさわってもらった方が、ユーザもその操作感も含めて、より具体的なフィードバックをもらえます。
この辺りは、RubyOnRailsの技術特性があってのことかなぁと思います。
この点でもお客様と「検討すべき重要な項目」と「(後で軽いコストで対応できるので)検討は後回しにすべき項目」をうまく切り分けて進めることができたのもポイントでした。

【3】ソースコードの理解

(PLとしてですが)ほぼ全てのソースコードを理解しました。
お客様から要望や仕様変更の話が出ても(ソースコードが入っているので)「だいたいあの箇所をああ修正すれば行けるかな」とか、ソースコード視点からの検討ができたので、精度が上がりました。

ソースコードの構造や内容の理解が浅い場合、「仕様面ではすぐにできる」と思われることでも「ソースコードの修正には思いの外、コストがかかる」ことになり、よけいな調整が必要になったります。

このプロジェクトはQCD的にももちろんのこと、お客様から相応の労いの言葉をいただいた思い出深いものです。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

rawpixel.com

コメント

タイトルとURLをコピーしました