ご褒美の先取り
顧客はできたものを見たら「違う」としか言えない
パワポでいくら画面設計をしても、画面遷移を見せても、画面を実際に作るのはエンジニアであり続ける限り画面の最終形態をイメージできるのはエンジニアだけしかできないのです。だから、いくら画面設計をしてもダメ出しや微調整が繰り返されるのです。
石器時代の画面設計
工程はエンジニアサイドの不具合でなければ原則戻ることはしない固定化された管理が強く要求される手法を採用しており、要件、機能仕様、実現仕様と詳細化、具体化されるともに画面設計も具体化されるのです。
ですから、詳細化された画面をみてイメージと違う場合は工程を遡ってやり直しが発生することになります。
ベンダーはこれをやられると手戻りが大きいので不具合以外は対応したくないテーマです。
顧客にとっては、受入試験や業務総合試験などで初めて動く画面を見ることになるので、その場面でこれまで決めてきたことと実際に使ってみて「違う」というのです。特に、色合いについては印刷や投影される色味と差異が出るのです。
近代の画面設計
ベンダは試験工程まで進んでからの画面設計の変更に懲りて、画面設計工程を上流に持ち込むことで、画面設計の変更に伴う手戻りリスクを低減することを図るように知恵を出しました。
残念ながら、顧客が実際に動くものに触れるのはシステムができてからであり、顧客が現物を見てから初めて顧客の要件を確認するプロセスは、実は変わっていないのでした。
ベンダがいくら仕様凍結と言っても、使われなければただのゴミプログラムで価値がありません。
現代の画面設計
発想が柔軟なベンダは現物を見ないとそれでいいのか違うのかを顧客が言えないのなら、現物をさっさと作って動くプログラムを作り、顧客からフィードバックをもらうことで手戻りを減らす手法を採用するようになりました。
その古典的な手法はプロトタイプであり、今ならアジャイル開発です。どちらも短期間で動くプログラムを顧客が確認することができますが、前者は捨てることを前提としており、後者はそのままリリースすることを前提としています。
旧世代の画面設計は、顧客からの「違う」というフィードバックを柔軟に取り込めないところまで進んでからしか現物を見せることができないのです。
どっちにしても人は現物を見てから「考える」生き物なので、フィードバックを手戻りが少ないうちにもらう工程デザインをするのがプロジェクトのリスクをコントロールしやすいのです。
積み本
プロマネを育てる三要素
プロジェクトマネージャはなかなか育たない。そういう声を聴く機会は多いですし相談を受けることもままあります。よくよく聴いてみるとプロマネが育たないと嘆くマネージャはプロジェクトマネージャ候補自身を育たないと批判していることの方が多いのです。
では批判をするマネージャに対してどのような育成をしているかと投げかけると自分は誰かに育ててもらったことはないというのです。自分自身の実力でプロジェクトマネージャになった、と。それをプロマネの実力というなら、マネージャが実力のあるプロジェクトマネージャ候補を選抜すれば良いのです。そうしたら、候補が育たないと不満を言い触らす必要も無くなるでしょう。
プロジェクトマネージャを育成する必要に迫られているのは、プロマネを必要とするビジネスサイドの要求に起因します。ビジネスを広げるためにプロマネが必要という構造である限り、プロマネ育成のニーズはなくならないでしょう。
でもそのプロジェクトマネージャを育成するマネージャが育成方法を知らないのであれば、プロマネを得るのは偶然に頼る方法しかありません。
プロマネを育てる３要素
プロジェクトマネージャを育てるには３つの要素が必要です。１つ目は、プロジェクトマネージャ候補自身がプロジェクトマネージャになろうとする意思を持っていることです。２つ目はマネージャがプロジェクトマネージャ候補のサポートです。そして３つ目は、実践の場です。
これらの３つの要素が揃わない限りビジネスサイドがいくらプロジェクトマネージャを欲しいと思ってもそれで得られるプロマネは自然発生的に、偶然でしか得られることはできません。エンジニアリングの延長線上でのプロジェクトマネージャを育成しようとするのであれば、プロマネを育てるためにはこの３要素が揃わなければなりません。
プロマネ候補の意志
少なくとも本人がプロジェクトマネージャの候補になっていることは認識していなければなりません。人は意識することで視界に入る情報が変わってきます。プロマネの候補であるという認識は、プロマネに関連する情報を自然と見える風景や情報の中から無意識に選別をすることを促すからです。
マネージャのサポート
困るのがマネージャが俺が育てるという自己の経験を押し付けることです。それはマネージャが試行錯誤して得た暗黙の知であって体系化された形式知ではありません。暗黙知の場合、拠り所はマネージャしか知りませんから、プロマネ候補が自ら学習しようとしたいときにリファーできませんし、マネージャしか知らない知識を共有することができないのでマネージャの指示は理不尽にしか感じられません。
マネージャはあくまでもプロマネ候補をサポーツする黒子に徹するのです。
実践の場
いくら本人がプロマネになる意志を持っていても、マネージャのサポートがあるとしても、経験する場がなければ身に付けることはできません。素振りをしなければ、実践で振り回すこともできませんし、実践で振り回さなければ、どれだけ振り回す実力を身につけているか検証することもできません。
マネージャは、プロマネ候補が実践するべきスキルとレベルに合わせたプロジェクトにアサインする必要があるのです。
エンジニアは伝わる日本語を学び直してほしい
30年くらい前から変わらず、技術文書やマニュアルはソフトウェアやハードウェアが海外製品が多いので、情報を手に入れるには日本語にローカライズされるのを待っているよりは英語で読むほうが段違いで早く手に入れられます。
日本発のソフトウェアやハードウェアならそんなこともないのですが西高邦低（書きながら作った造語です）なので仕方がない。
というわけで、嫌々ながらも英語と戯れなければならないわけです。まあ、英語であってもマニュアルがあるだけマシだったりしますけど。
ずいぶん前のプロジェクトでは新バージョンのソフトェアを使うことになったのでマニュアルがどれだけ揃っているかを調べてもらったら、同じブランドの他の製品と比べてからっきし揃っていないという驚愕の事態に巻き込まれ、ずいぶんと苦労したものです。もう、途中から英語でいいからマニュアルよこせ状態でしたから。
PMIのPMPの問題の日本語訳も誤訳が10％くらいあるよと教えてもらったので、当時は英語版で覚えましたねぇ。テスト自体は日本語と英語を切り替えて表示できるのでまずは日本語で回答して、設問を読んで？？？となったら英語に切り替えてみると！！！と英語で回答を選ぶ感じでした。今はどうなんだろう。
読み物は英語で読めればそれでいいとして、実際には日本語をプロトコルとする顧客と意思伝達し、文書で合意するのだから日本語が堪能でなければそれはそれで困るわけです。
一番困るのは意思伝達でしょうね。何せ会話を面倒くさがるエンジニアが多すぎますね。じゃあ、伝えなければならないことを十分伝えているかといえばそんなことはなく、伝えられたことを受け止めているかといえば思慮も解釈も不十分で伝えられたことの50％も受け止められていないという。
思考していることを文字に起こせば誤字脱字はもちろん、てにをはに始まり、おかしな二重否定のメッセージを書いてみたり。必要最小限で良いから暗黙は止めていただき、伝えなければ伝わらないことを全て辞書に載っている意味で伝えてほしいものです。
不均衡な意見をエンジニアは取り込んではいけない
自分で仕様検討のたたき台を作って会議を開き、その場で発言されたコメントを全部対応しなければならないと思っている節のあるエンジニアってよく見かけます。こうした行動をとるエンジニアはエンジニアとしてやっていけないです。
例えば、５−６人の関係者を召集して仕様検討会議を開催して、たたき台を広げるのはそのたたき台で同意を取りたいという目的があるからです。その目的を達成したいのであれば、たたき台を多少の不備の修正はあったとしても決定稿として同意しなければなりません。
もし、関係者が好き勝手に発言する内容を全部反映しようとするならば、それはたたき台を決定稿として同意するという目的を達成すること放棄して、合意したとする事実だけを得るために会議を開いたという目的と手段がすり替わっていることを地でやっている他なりません。
エンジニアがしなければならないことは、要件を実現することでその要件は顧客が実現したいことです。決して、会議で発言されたコメントを取り組むことではありません。
第一、会議で発言するのは限られた人だけです。それは発言していない出席者の意見は反映されていないのです。
そういった発言の不均衡をバカ真面目に全部取り込もうと考えること自体、バカらしいことです。エンジニアがやらなければならないことは、たたき台として考えた仕様で顧客が実現したいことが実現できることを仕様検証することです。
