サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

仕事のやり方 旧館より

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

投稿日:2009年6月7日 更新日:


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

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

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

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

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

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

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

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

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

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

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

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

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

rawpixel.com

-仕事のやり方, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

「Q&Aビンゴ」アクティビティ

(時期を逃した感がありますが)、新しくできたグループなど、あまり知らない人同士が集まった宴会で使えるアクティビティです。 「Q&Aビンゴ」 ビンゴの数字を(「くじ」ではなく)「質問に該当する人 …

仕事が10倍速くなる最強の図解術[読書感想]

仕事が10倍速くなる最強の図解術 報告書やプレゼン資料を作成する際に、図解化することで抜けや漏れが無いか(MECE)、また説得力のある論理構成になっているか?を確認し、質の良いものを造り出しましょうと …

「お世話になりました」エントリを見るのはツライものです

所属している組織はそれなりの規模なこともあり、毎月何人かが去っていきます。 社内SNSを使っている人は(人事異動の連絡が出る前に)自分で「お世話になりました。」エントリを書いていく方がちょくちょくいる …

こんなPMOはいらない

私のキャリアの中に、数年ですがPMO(Project Management Office)的な経験があります。 #PMOの役割や定義も組織においてまちまちなのですが…。 当時はそういう組織がなかったの …

UltimateAgileStories1で書いた内容

最近、UltimateAgileStories Iteration2(UAS2)のエントリ([雑多]UltimateAgileStories Iteration2が届きました)を書きましたが、その1冊 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。