マネジャーは自分の強みを何におくのか。
自分で適切に判断できるはずのことは何か？
自分の力だけではどうにもならないことは何か？
どういう手助けを必要かを知らなくてはならない。
以下の考察は、少ない経験の範囲で書いたものです。
極めて典型的と思われる傾向を書いたもので、あなたの知っている個々のマネジャーに当てはまるものではないことにご注意ください。
技術を知るマネジャーの場合
- 技術者としての直感をもとに、同じような専門的な技術者とともに少ない手順でアプローチすることができる。
- マネジャーが技術的に能力があることをメンバーは理解しており、そのアプローチにしたがって開発していけばうまくいくことを信じられる場合が多い。
- マネジャーの考えと担当者の意見とが違った場合でも、担当者が技術に基づいてマネジャーに説明すれば、たいていの場合議論が成立する。
- 技術を知るマネジャーの場合、それを実現するのに平均的な技術者でどれくらいかかるのかを推測できるから、無理なスケジュールは自分からは組まない。
- 自分の得意とする分野では、**「どうあらねばならないか」**を厳しく持っている場合があり、時として過度にメンバーへの要求水準が高くなる場合がある。
-
上級のマネジャーが理屈よりも感情で考える人であることについての理解が不足する場合がある。
- そのため、本来行使できるべき権限が行使できない状況に最悪おくりこまれてしまう。
- ときとして起こること：
- メンバーに対する要求水準が高くなりすぎて、平均的な技術者がついていけなくなって脱落する。
- メンバーの担当者に任せればいいことを、マネジャーが直接手を加えてしまう。それによって担当者の成長が阻害される。
- 政治的な配慮をせずに、技術の視点だけで話してしまうので、何気ない言葉が敵を作ってしまうことがある。そのようなときに、いくら正しいことを言っても、あるいは正しいことが分かるように言っても、「あいつが言っていることなんて聞いてやるか」となる人が存在することに対しての対策が不足している。
- 優秀であり続けた技術者のマネジャーが、ある時点で間違った技術的な判断を開発チームの押し付けてしまうこともある。例：空冷エンジンを自動車に使用した例
異分野の新製品・新技術の開発を成功させたことがマネジャーの場合
- 新しいものを作るうえでのすべきこと、してはならないことが分かる。
- しかし異分野であることの怖さを知っている。
- どういう失敗の可能性があるのかを推測することができる。
- 異分野の技術を理解するために、今までの技術のアナロジーなどを使って推測することができる。
- 異分野を理解するために必要な差分情報を探し出して、異分野を自分の分野に取り込んでいくことができる。
- 成功させるためには、その分野の技術者によるアドバイスが有効であることを知っている。
- その分野で既に仕事をしてきた人たちへの尊敬を忘れない。
- ２つの技術分野で共通していること、違っていることは何であるのかを知っている。
- そのことを元に、何をどうしなければならないのか、設計の指針を判断することができる。
- このタイプのマネジャーとしては新幹線開発・宇宙開発を成し遂げた島秀雄 氏の例を挙げることができる。
異分野であることに気づいていない場合：
- 異分野の怖さを十分に自覚しないと、間違った判断をしかねない。
- 例：医療系の機械学習では、学習データ、テストデータで良好な判別結果をもつでは不十分。その判断が正しいとする十分な根拠が必要
- 相関関係ではなく、因果関係を知ること。
- そのような視点と分析力がなければ、ビッグデータたくさんの間違った判断を導くだろう。
- 例：医療系の機械学習では、正しくラベリングされたデータを得ること自体が簡単ではない。ラベリングなしの医療データを得ること自体が、パートナーなしに行なえない。しかもある画像は、乳がんの例であって、別の画像は乳がんではないというラベリング作業をしてくださる医療機関の専門家の協力を必要とします。その問題に対して対策を打たないまま、少ないデータの範囲で機械学習がうまくいったと言っても、実用になる機械学習にはならないのです
- 例：車載系の安全に関わる分野では、人検出に求められるものが監視カメラとは決定的に違う。
- 異分野での怖さは、その分野で仕事をしてみて始めて気づくこともあるだろう。
プロセス重視のマネジャーの場合
- 技術的に新規な部分少なく、要件自体に曖昧さが少ない案件の場合だとうまくいく。
- 新しい開発要素の多すぎるプロジェクトの場合にも、がちがちに管理しようとしてしまう。
- そうすると、技術者の直感に基づく選択などは受け入れられず、技術者とマネジャーとの間で対立が生じやすい。
- 何もその技術者は、技術者の直感をごり押ししたいのではなく、PDCAを繰り返して改良していくための初期値を直感にもとづいて選択しようとしている場合が多い。
- ある程度の性能が出てからの改善・確認は、初期値の選択とは状況が異なってくる。
- 担当者と意見の違いが生じたときに、過度に職権で従わせようとすることがある。
- 職権で従わせた作業の結果が、マネジャーの期待する結果ではなく、担当者が予め予測結果であったとしても、そのことでプロセス重視のマネジメントが変わることはない。
- 担当の技術者がいたずらに疲れきっていってしまう。
- 自分が職権を持っていることが大事である。少ない手順で正解を嗅ぎわけて成功に導くことは邪道だと考えている。
- 「この人になら、この範囲はまかせて大丈夫だから、あまり細かいことを言わなくても大丈夫。」などとすることができない。
- 混沌とした状況からアイディアを作り上げていって、検証していくような部分についてまで、細かくチェックを入れたがる。
- 担当者の方が疲れきることが生じやすい。
誰がどれくらい信用できるかで任せるタイプのマネジャーの場合
- 個々の担当者の能力と行動がどの程度を任せても大丈夫なタイプかを見極めて、作業をゆだねるマネジャー。
- 開発全体の中で、どういった作業の意味の塊があって、それを自立的に任せても大丈夫なメンバーがいるのかどうかを見極めて、任せつつ品質をチェックするという作業になる。
- そのためには、任せてもいい○○屋の場合には、どういう能力を持っていなければならないのか、どういう具合に品質をチェックしなければならないかを、任せる判断をするマネジャーの側が持っていなければならない。
- その分野の技術者として期待される能力を習得させようと試みる場合がある。（例：テスト駆動開発のしかた、アジャイルな開発スタイル。エラーを予防するコーディングスタイル。処理速度の改善のためのノウハウの共有。）
時として起こること：
- 任せて大丈夫だと思っていたメンバーが、実は致命的なエラーを見過ごしていて、これならばもっと細かく管理しておけばよかったということ。
- マネジャーの側が適切なフィードバックを返していないと、開発者が**「私が開発している内容に関心がないのですね」**となってしまって、開発者のモチベーションを下げてしまうこと。
- 本人が何をやりたいのか、その技術的な成長への期待に対してこたえていく必要がみたされないと、有能なエンジニアを失うことがある。
- マネジメントではなく、単なるほったらかしになってしまう危険がある。
伝言者の立場に安住してしまうマネジャー
- いつのまにかスケジュール調整役・トラブルシューティングの対策の調整役などの立場に安住してしまうマネジャー。
- 開発プロジェクトのマネジャーの場合、トラブルシューティングよりもトラブルを発生させない開発スタイルの構築に注力すべきである。しかし、日常の忙しさのために、そのことに思いが及ばない。
- 上層部と現場の技術者との間にあって、自分の見解を表明することができないままになってしまう。
- メールでの連絡の調整で忙しくしている。課題管理システムRedmineなどはあることは知っていても、メールを愛用する。
課題管理システムRedmine を利用しているメンバーから見たとき：
- 発生した不具合をRedmineできちんと管理するように他のメンバーにも指導すれば、伝言者になってしまっているマネジャーは楽になるはずだ。
- Redmine を使うようにメンバーの側から推奨しても、その価値を気づかないほどの見識ならば、そのほかのソフトウェアでの開発のアイディアを考えるほどの技術的な力量に乏しいのではないかとメンバーの側は疑う人も出てくるだろう。
責任回避型のマネジャーの場合
- ものごとをあるべき姿にもっていく際に生じる細々としたことに対して、「後でなんと言われたらどうしよう」と考えるばかりで、前に進むことができない。そのため、メンバーの提案に対してブレーキをかけるばかりで、課題の解決に対して何の役もたたない。
- 物を作るうえで必要なあらねばならない姿というものを理解していないままにマネジャーという立場にたってしまったことによって生じている。
- とりえわけ責任回避型のマネージャーは、技術を新規に開発する現場を経験しないままに、技術開発の分野のマネジャーになってしまった人に生じやすそうだ。
- それなりの検討で予測していても、技術開発の場合にはその予測がはずれることはあるものだ。そういったことを理解していないので、過剰に責任回避に働いてしまう。「よくわからないけど、こういう条件がよさそうだ。実際にためしてみよう」（開発者）、「よく分からない部分があるんだったら、とにかく止めておこう。」(責任回避型のマネジャー）。そのため、開発時点での必要な試行をしないことで、時間を無駄に失ってしまう。
- 物を作るうえで必要なあらねばならない姿とはなんだろうかを自分で勉強することがなさそうに傍目には見えている。
このような人が上司になってしまった場合
あまりこのような人に相談をしない方がよい。実務でとにかく進められることを進めるのがよい。
発生しない心配事まで心配している場合には、実務者レベルの責任で思い切って進めてしまうという手もあるだろう。それを明確にやめなさいと断言できるまでの確信をもっていない場合もあるからだ。実務者レベルの他のメンバーとも妥当性を確認しておいたうえで進めることも、自分自身が独りよがりな「改良」をしてしまわないように注意しながら、進めていこう。
仲間内重視のマネジャーの場合
- マネジャーたちが、自分たちは現場の技術者よりも優れていると信じており(注)、とにかく自分たちが決定するのだという強い信念で行動する場合があるようだ。
- 仲間内重視のマネジャーの場合は、マネジャー層の仲間内で対立を嫌う。
- 上層部が何を希望しているかに対しては敏感であり、実現可能性を無視してでも上層部によい返事をしたがる傾向がある。
- それが現場の担当者たちの不評をかう。
- 技術者の「できる」、「できるけどやっかいだ。」、「できそうに見えない」、「できないとは断言はできない」、「できない」のうち、「できないとは断言はできない」までは、「なんとか実現できるだろう」（マネジャー）と極めて楽観的に考えてしまうバイアスが働くようだ。
- 開発中の技術であるから不具合があるのは自然なことなのに、仲間内の外にある道具としての技術者が無能だからうまくいかないのだと考える場合がある。
- 担当の技術者たちが離脱していく原因となる。
- 技術的内容を理論に基づいて説明するのは、このタイプのマネジャーに適さない。
- 「小学生でも分かるような説明がよい」
- うまくいったときには、「自分たちのマネジメントがよかったから」、そうでないときは、「現場の担当者が無能だったから」となりやすい。
- 技術的な内容を含む基本的な方針を決める際でも、技術的に一番詳しい現場の声を無視できる。
- このタイプのマネジャーと技術者との間では、議論が成立しないことがある。
- 自分がマネジャーとして有能であり続けることができる範囲についての自覚がない。
- 担当している開発案件の技術には興味がない。
- 無理なスケジュールや無理な開発内容でも「やります。」という元気のいい返事を返すメンバーの方を評価する。
（そのような体育会系ののりと、伝えるべき見識を持ち合わせていない「コミュ力」の方を評価する風潮が日本の社会の広い範囲にあるのだろう）
このような人たちが上司になってしまった場合
- 問題を切りくずす対象を１つに定めること。
- 分かりやすく単純化すること。
- 感情論を含めないこと。
結果を出やすくすること。
「自分たちは現場の技術者よりも優れていると信じており」、「道具としての技術者が無能だから**うまくいかないのだと考える」場合、議論は成立しない場合が多い。
そのような場合には、それらの上司よりももっと上に対して働きかけるという決断をしなければならないときがある。
ただ問題は、その後のそれらの上司たちとの人間関係だ。ただでさえ厄介な人間関係がさらに険悪になる場合もあるだろう。
私の知っている事例では、自分が別な場所でも生きていけるという自信に満ちている人がそのように行動した。
付記：
陸軍大学校の優等生である卒業生が、「上司に命じられたことにはただ従えば良いとする発想」でその部下は「無理難題を幾度も押し付けられて泣かされたことがある」。失敗後は「あれは私のせいではなく、部下の無能さのせいで失敗した」と述べたという。そのような事例との共通性を感じる。
注：そのように信じている根拠は、現場の技術者には理解できないことが多い。
それぞれのタイプのマネジャーに対して、どのような取り組み方をすれば、開発がうまく進むようにできるのか？
それが知りたい。
- メンバーを信頼する。
- メンバー間のチームワークがうまくいくようにしていく。
- 互いにノウハウを教えあって、互いを尊敬する状況を作る。
- （チーム内の相対評価なんてしないほうがいい。）
- メンバーの側は、マネジャーが判断をしやすくするように、必要な情報をあげていくこと。
参考になりそうな本
この本では開発の組織運営での人的な要素について着目している。あるアイディアを提案してもなかなか採用されないことに嘆いている人に、相手の立場にたって物事を考えるようにアドバイスしている。
相手は、自分とは違う経験をしてきている。そのため、物事を判断する際に何に重みをおくのかが、自分とは違っている。
