月別アーカイブ: 2009年6月

嬉しい言葉「また一緒に仕事をしたいですね」

「またこのチームの皆さんと一緒にプロジェクトをしたいですね!」

システムのカットオーバーを無事に迎えたプロジェクトの打ち上げで、クライアントからこんな言葉をもらえるとすごく嬉しいものです。
こういう言葉やクライアントの笑顔を見ることができるのはエンジニア冥利に尽きます。

一方で「二度とこの人達とは一緒に仕事をしたくない」と残念な言葉を持つことがあります。

クライアントだけでなく、所属会社に関係なく一緒にプロジェクトを遂行したチームメンバーや上司など関係者にも、同じように嬉しい言葉、残念な言葉の両方をもらい、自身も思うことがあります。

できるだけ嬉しい言葉をたくさんもらうため、そして自分が言えるように、役割を固定せず積極的に越境していき、最後には冒頭の言葉をもらえるようにやっていきたいものです。
10年くらいの経験ですが、自分は冒頭の言葉を思うことが多くありましたし、何度かはクライアントやチームメンバーから良い言葉をもらいました。
そういう体験を思い出すたびに「よし!今度のプロジェクトもそう思う、思われるように頑張ろう!」と思うわけです。

Photo credit: J. Star via Visual hunt / CC BY-NC-SA

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

【引継ぎ】タスクへの考え

 『トラックナンバー』について以前書きました。
そのトラックナンバーを意識して取り入れたプロジェクトの効果に『引継ぎタスクをスムーズにできた』というのがあります。

ほとんどのプロジェクトでは、後工程になるにつれてメンバーが減っていったりします。
また新規開発プロジェクトでは、その後の追加開発/保守開発プロジェクトを当時のプロジェクトリーダーは抜けて、その下のサブリーダーが担当することもあります。

そんな時に(引き継ぐ側と引き継がれる側双方の)「引継ぎ」タスクが発生します。

この「引継ぎ」タスク…プロジェクトの進捗に関わる成果物を生み出さないので見落としがちですが、やっかいなタスクです。
油断するとプロジェクトで構築したシステムのライフサイクルにも大きな影響が出るものだと思います。
 

1:引き継ぎ時期

プロジェクト終盤、もしくは終了後すぐに…というパターンが多いと思います。
(順調なら)この時期は忙しくないのですが、(残念ながら)バタバタしていることが多いと思います。
そんな状態では、引き継ぐ/引き継がれる双方とも十分な時間が取れません。

また終了後すぐのパターンでは、引き継ぐ側は(往々にして)新しいプロジェクトに参画していて(そして忙しい)、同じく時間が十分に取れません。

2:双方の気持ち

引き継ぐ側は(悪い言い方をすれば、自分が抜けた後はそのプロジェクトの当事者でないと思っているからか)、「苦労をするのは自分でない」とばかりにけっこう適当にやってしまいがちな気がします。

引き継がれる側も「(なんかあったら)後で聞けばいいわ」と思ってしまうのか、浅いレベルの理解で済ませてしまいがちです。

上記の理由などにより、システムの設計思想やその仕様に至った過程などの(保守開発などでポイントで重要になる)情報が不十分になったりします。

一方、トラックナンバーを意識してプロジェクトを進めると、そもそも『引継ぎ』タスクがほとんど無く、また引き継がれる側の理解度もトラックナンバーによって高く保たれていると思われます。

どうしても直近のタスクの処理や、納期をクリアすることを優先するのはもちろんですが、『トラックナンバー』など、こういうプロジェクト終了後のことも含めてトータルで考え、マネジメントしていきたいです。
#『トラックナンバー』と類似の取り組みで『ペアプロミング』もあります。

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

Štefan Štefančík

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rawpixel.com