97 things Every Project Manager Should Know を読んでみた(1)

表題のとおり、読んで、勝手に訳してみた。

今回はその最初のエッセイ『Get Users Involved As Early As Possible』。

ちなみに、オレの翻訳はかなり適当感満載なので、
各自Google先生に正しい訳を求めること。

オレが提供するのは英文が醸し出している雰囲気のみ。

PAST PATTERNS OF SOFTWARE DEVELOPMENT involved getting user requirements and then going off to do the coding and testing under a veil of great secrecy. After all, the users wouldn't understand what we were doing anyway, right? At the end of the project, our magician's magic cloth was whisked away and the user was expected to "ooh" and "ahh" at the brilliance of what we had produced. However, all too frequently the reaction was, "Well, I know you went to a lot of work, but what I really wanted was...".

旧来のやりかただと、まずユーザーの要求を集めて、その後、ユーザーにお楽しみにねなんて言って、コーディングしてテストしてっていうやり方でした。そして、ユーザーは私たちが何をやっているか理解なんかしていなかったんじゃない？プロジェクトの終わりに、私たちの魔法の種明かしの時がやってきて、きっとユーザーは私たちのプロダクトを一目見た瞬間に「オオオッ」とか「うほっ！」とかって言うんだろうな～なんて期待しているんですよね。でも、たいていのリアクションが「あぁ～、なるほど、よく働いてくれたよ。でもね、我々が望むのはね、云々」

Today, the secret to project success is to involve the users almost as soon as there is anything visible to show them. How much better it is to find out that there are problems with what we are developing early on, rather than after the project is complete!

最近ではプロジェクトを成功させる秘訣というのは、ユーザーをできるだけ早めに巻き込むことなの。ユーザーさんが触れるようになったらすぐ触らせてみて。早い段階で私たちが作っているものに何か問題があることを見つけてもらえるなんて、プロジェクトが終わってから見つかるよりも全然いい。

Costs for changes become increasingly high the further along we are on the project schedule timeline. The time to recode, retest, and rework the immediate software, as well as to test integration with all the peripheral code involved, can delay the project substantially. And both time and cost baselines are jeopardized if a change is so major that it has to go through a lengthy Change Control Board process for approval.

変更にかかるコストはどんどん高くなります。プロジェクトが進行していくとね。コードを修正して、テストを再実行して、そのたもろもろの作業をさささっとおこなって、もちろんすべての関連するコードも動くことを確認して、なんてやっているとプロジェクトが知らないうちに遅れ始めます。そして、時間とコストが危険を迎えるようになります。特に変更がでかいモノで変更管理委員会から承認が必要なものだったりすると、もう最悪。

Programming decisions over very minor issues, which make perfect sense to the software developer and the project manager, may create chaos back at the workstation when the software goes into use.

ちょっとしたプログラムに関する変更、それは開発者とプロジェクトマネージャーにとって非常に重要なものなのかもしれませんが、それを使っている人にとって混沌とした状態を作り出してしまいます。特にソフトウェアが使われ始めた後などではね。

以下、2011/06/04に追記

I know of a large training company that spent $5 million redesigning its ordering software. Previously, the item numbers matched the product being ordered in a logical way. For example, 4125 might be a student manual, 4225 was the accompanying student exercise disk, 4325 could represent the instructor manual, 4425 was the course outline for marketing purposes, and so on. You could order all the items in the 4X25 series on the same screen

私の知っている大規模な研修会社で行われた500万ドルの規模になるソフトウェア改修の例を取り上げてみます。以前は商品番号はうまい具合に発注する商品と関連付けられていました。例えば、「4125」という商品番号は学生用の研修資料、「4225」は学生の自習用ディスク、「4325」は講師用のテキスト、「4425」はマーケティング用のコース概要などと関連付けられているような感じです。ユーザーは「4X25」という値を同じ画面から入力することで、すべての商品を発注することができたわけです。

Each day, administrative coordinators in 140 locations around the world ordered the same kinds of materials over and over and soon memorized the item numbers. Once you knew the number for a student manual, you could immediately key in the numbers for the other items without looking them up, and ordering went quickly.

毎営業日、世界140箇所に点在するコーディネーターの責任者は同じ資料を発注していて、すぐに商品番号を覚えてしまいました。ひとたび商品番号を覚えてしまえば、画面を探し回ることなく、一発で目的の商品番号を入力でき、発注業務は非常に素早く行えるものでした。

In the redesign, somehow the project team forgot to consider the way the ordering process was used by the real people doing it. Under the new design, there was no logical relationship between items. Item 6358 might be the same student manual that once was 4125, the accompanying student exercise disk was now 8872, and the instructor manual for the same class was 3392.

ソフトウェアの再構築に当たって、プロジェクトチームはどうやら発注業務を、実際に人がやっているやっているということを失念してしまったみたいです。新しいソフトウェアの設計では、商品番号と商品とがうまく関連づかなくなってしまったようです。新しい番号6358が前は「4125」だった学生用の研修資料に、学生の自習用ディスクは今では8872に、講師用のテキストが3392になってしまったようです。

Not only did the user have to look up each item and try to "forget" the old numbers and system, but also each type of item was now on a separate page.

Administrative coordinators were furious. Ordering slowed to a crawl. The project far exceeded its time and cost baselines.

As a project manager, you should get the users talking to the software developers early and often.

その結果は、ユーザーは個々の商品について前の知識を捨てて、画面をくまなく探さなければいけなくなっただけではありません。個々の商品が別個の画面に表示されるようになってしまったのです。

コーディネーターの責任者は非常にぷんぷくり～ん＞＜したようです。結局プロジェクトは時間とコストが、計画をオーバーしました。

プロジェクトマネージャーとしては、早い段階、かつ頻繁にユーザーと開発者とが話をできるようにするべきです。