思考できないエンジニアの作り方

プロジェクトチームを編成すると、当たり前だけどプロジェクトを推進するうえで必要な役割(ロール)を定義して、メンバをアサインします。一番わかりやすいロールはプロジェクトをキャリーするリーダのプロジェクトマネージャですね。プロジェクトの推進と一言で表現するとなんとなくわかったような気がするんだけれど、実は、何をやるか具体的な作業を言えるのは経験者に限られるほど様々なタスクがあるのはあまり知られていないものです。知る人ぞ知るというかやったことがない人にはわからない、と。で、また、どのプロジェクトでも共通のタスクもあるし、それぞれのプロジェクトごとにしかない独特のタスクもあったりするのでさらにわからなくなるという一面もあったり。

ロールの善し悪し
作業を専門化するということは、作業の種類を制限するということです。それは、専門化することと言うことで、作業の単純化による効率化の向上を期待しているということです。いや、そうは言っても、生産工場のように単純化はできませんけど。それでも、担当領域が狭まるので集中して作業をすることができます。これはイメージとして組織を縦で見た場合でも、横で見た場合のどちらでも一緒です。縦横だと専門化で担う内容が違いますけどね。

で、良い面は効率化、専門化するところです。一方、悪いところがあって、縦横の面夫々であるものです。縦であれば、責任範囲に線引きするようになるので所謂縦割り意識が出てくるし、それを根にする意思疎通の分断があります。横の面ではロールによる責任範囲を分担することになるので、担当するロールより上に依存するという関係が作られてしまいます。

エンジニアが依存すること何がいけないのか
プロジェクトチームのどのロールでも負う責務はあるわけですが、横の面での役割の分担では、横断的なバーチャルタスクチームの様なものは除いて責任範囲が制限されるので、自分の責任範囲以外は「そこはよろしく！」と考えてしまいがちです。

自分の責務を果たすために自分の頭脳をリソースとして割り当てる。これ自体おかしいところはないのですが、この範囲は「わたしの担当ではないからよろしくね。」と思う瞬間に、それについて思考を止めてしまうということが起きています。こういった<思考の癖がついてしまうことがいけない>と思っています。

例えば打ち合わせでも、自分の担当でないテーマになれば、誰も真剣に聴いていないようなイメージになるわけです。上の空だったり、ブラウズしていたり。

いや、何から何まで自分の担当ではないことまで自分の担当として考えないといけない、と言っているわけではありません。自分の担当範囲でさえ、思考を止めて上のロールを担うエンジニアからの指示を待つような癖を付けてはいけない、と言いたいのです。

逆に言えば、都合よくエンジニアを使い捨てしたければ、リーダなどのロールを担うエンジニアがあれこれ考えて箸の上げ下げまで指示するようにすれば、配下のエンジニアは思考する場面が限定することができます。それは結果的にプログラムを組む、パラメータを設定する、試験を起こす、試験を実施する、だけにしか思考する場をなくせることができる、と表現することもできるのです。
＃いやこれ、自分で書いていても恐ろしい。

実際の現場で
偶々かもしれしれませんが、所謂、リーダを担えるエンジニアは課題を解決しようと行動することができるのですが、そうでない、担当のエンジニアに課題解決のテーマを与えるとそのエンジニアが10年程度の経験を持っている人であっても課題を解決するために考えることが不得手な人が少なくないことに驚かされます。

それは、プロジェクトマネージャにとってとても怖いことです。なぜか。それは、プロジェクトチームとしての思考が偏ってしまうからです。例えば、作業手順を組み立てるとき、この作業は順番を間違えると危険だ、と気づくためには、一人より複数の目線で見た方がよいのは同意してもらえるでしょう。その複数の観点が単焦点になるということですから、リスクの識別が劣ることになります。その点がコワイのです。

思考させるために
兎に角、メンバが考えるようなタスクの与え方をすることです。例えば、

システムのポンチ絵を作らせる　→　全体感を養う
タスクの作業内容(仕様)を定義させる　→　タスクの要件確認、完了条件を聞き取りさせ調整させる
理想時間で作業を見積もらせる。　→　実力を推し量り、段取りの訓練をさせる
メンバ同士で事前レビューをやってもらう　→　相互に気づく場を与える

プロジェクトチームのエンジニアを思考させるか、思考させないか、どちらのエンジニアでもプロジェクトの中で訓練し、躾けることができます。