とある.NETやさんのつぶやき

開発プロジェクトがうまくいかなくなり、どうにも進展しないが作業だけは山のように降りかかる暗闇プロジェクト、いわゆるデスマーチ。
暗闇プロジェクトに関する記事を読み、いろいろ思うところがありました。


【現場に行かずにマネジャーが危機の予兆をつかむ方法は存在する】
http://itpro.nikkeibp.co.jp/atcl/column/14/120500119/070600051/


暗闇プロジェクトの始まりにいかに気付くか、またそうならないようにどうしていけばよいか、いくつかの具体例が紹介されています。

私の感覚的な話になりますが、暗闇プロジェクトの始まりは、メンバーの異変から始まるケースが多いかなあ、と感じます。

今までと仕事ぶりが変わってきたとか、今までできていたことができなくなるとか、今までになかった何かに急に執着するようになるとか、逆に今までのこだわっていたことや当たり前のようにしていたことをしなくなる、など。

これは、プロジェクトの暗闇部分に気付いたメンバーが発するサインです。
プロジェクトのリーダー、マネージャーは、こういった異変に気づき、先手を打って行動することが重要です。

そのためには、日々のメンバーの様子を知っていないといけません。
責任者が、プロジェクトリーダーなどの上位層とだけコミュニケーションをとっていると、細かい現場の異変には気づけないかもしれませんね。

そんなことを思った記事だったので、こちらで紹介しました。

今回は「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」という点について書きます。

システム開発の現場では、発注者と受注者がいます。
発注者と受注者が異なる会社であることもあれば、同じ社内にいる別の人という場合もあるでしょう。
この違いを問わず、システム開発を依頼する側と、請け負う側とでやり取りする書面についてのお話です。


システム開発の現場では、様々な資料・書面が交わされます。
発注書、見積書、要件定義書、設計書、などなど。

これから開発していくシステムの内容を決めたりしていくうえで、これらの書面のやり取りはとても重要な意味を持ちます。
ただ、一度相手方に渡した書面の内容を変更する場合もあるでしょう。しかし、だまって書き換えるのはNGです。変更の理由を相手に伝えて、納得してもらう必要があります。


例えば、記述の内容が間違っていた場合。
書き換えた本人は間違いを訂正したつもりだったかもしれません。
でも相手方は、何も連絡なく勝手に別の内容にすり替えられた、と悪い印象を持つかもしれません。

相手にとって有利になるような書き換えの場合も、問題になる場合があります。
例えば受注側が見積額をあとで下げたり、開発期間を短縮する、などの場合。
受注側がどうしても受注したくて、意図的に値段を下げる場合もあるでしょう。
でも相手方に予告なく金額を下げてしまうと、発注側に「金額を書き間違えているようだが、金額を間違える会社ってそもそも大丈夫か？」「金額が下がるのはありがたいが、最初の見積もりはぼったくり料金なのか？」などと思われる場合もあります。


具体的な例を挙げましたが、これに限った話ではありません。
書面の勝手な書き換えは、相手に不信感を与えてしまうことがありますから、やはり丁寧に変更内容を説明するべきだと思います。

固すぎる発想かもしれませんが、一度出した書面を書き換える場合は、契約書を書き換える場合と同じくらい丁寧な手続きを取ったほうがよい、という考えを持ってもよいと思います。


「発注者に提示した資料の内容を、受注者が変更するなら、その理由を説明する必要がある」と書きましたが、発注者と受注者を入れえた場合でも同じことが言えます。やはり資料の変更においては、黙ってやるべきではなくて、相手方に理由を説明する必要があると考えるべきでしょう。

こちらのサイトが参考になりました。
http://www.724685.com/weekly/qa130327.htm

列全体の書式を変えたい場合は、このページの記述を参考に、絶対参照の参照方法を変更するとよいです。

プロジェクトマネジメント関連のドキュメントをExcelで作っている場合には、使える内容ではないでしょうか。
（プロマネ作業を、Excelなんかでするなよ〜、というツッコミはご遠慮ください・笑）

PMについて、思ったこと・・・。

PMが業務知識を持っている場合とそうでない場合とで、プロジェクトの進み具合に大きく差が出ます。
業務知識がないと、要件定義で難航しやすく、またプロジェクトメンバーに要件の伝え漏れも発生しやすくなります。
業務知識をしっかり身に着ける姿勢が重要です。業務知識が足りないと思ったら、積極的に学ぶ姿勢がPMには欠かせません。

先日話題になった、雑誌の記事の内容。
思わず、う〜ん納得、と思ってしまった。

↓

デスマーチは、技術やソフトウェア工学によって改善されるものではなく、よりよいプロジェクトマネジメントによって改善されるものです。
様々なソフトの見積もり技術により、開発期間や工数をかなり正確に予測することができるようになりました。しかし、そうして算出された期間や工数は、「競争が激しいから開発期間をもっと短くせよ」というような圧力により「改ざん」されてしまう。
結果、デスマーチになってしまう。

技術者上がりの経営者トップの中には、細かいことにこだわりすぎる者がいる。
会社のトップである以上、細かいことにこだわりすぎず、全体を見通してスピードある決断をしなければならない場面も多い。

経営トップは、物事を最初から100点満点の状態に持っていく必要はない。70点と判断できたら、それで物事を進める。それでうまくいけばより高得点を目指すなりすればよい。うまくいかなかったら、方向転換をすればよい。

つい先日、こんなことを思ったのでした。

納品に関するトラブルと、その対応方法について学ぶ機会があったのでメモ。


●成果物の品質が確保できず、納品するに値しない状態の場合
納期やカットオーバー日程を延期する。改めて納期を再設定し、それに向けてプロジェクトマネジメントを継続する。

●納品物の大部分の品質は確保できているが、一部に問題がある場合
当初の予定日にて、機能限定にてカットオーバーする。カットオーバーした部分飲みを納品し、残りはあとから納品するという、多段階納品で対応する。

●システムの機能はカットオーバーしたが、ドキュメントなどが間に合わないまたは品質が確保できず納品できない場合
ドキュメントなどは、後日納品する。システム機能を優先してカットオーバー日程に納品できると見込める場合は、ドキュメントなどの作成作業は後回しにすることも検討する。

欧米のアジャイル開発現場では、ドキュメントを全く作らない事例がある。
これは、ソースコードを読めばドキュメントの代わりになるようなコードを書ける、熟練したエンジニアが集まっている現場だからである。
一方で、管理の対象としてドキュメントの作成が必須の場合は、アジャイルといえどもドキュメントの作成は必要である。