若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編

若手エンジニアを不幸にしないための開発の「べからず」集が
長くなりすぎたので、組織運営に関する部分を別項目として独立させました。

ここに書いてあることを、組織運営を行っているリーダー以上の方は冷静に読んで欲しい。
組織運営に失敗すると、
優秀なエンジニアがいてもどうしようもないほどに開発速度の低下を引きおこす。
資金を投入して外部に開発を委託したものが、まったく使い物にならないことになる。
対外的な信頼をぶち壊しにすることができる。
優秀なエンジニアの心を、組織の開発目標から引き離してしまうことができる。

リーダーでない人もリーダーではないなりに組織運営に関わっている。
組織の運営に失敗して、成果の達成ができなければ不幸である。
1人1人のエンジニアの成長を実現できなければ不幸である。

不幸にしないための「べからず」を書いてみました。

###自分たちの強みを何におくかを考えない。

仕事として開発をする場合には、自分たちの強みを何におくのかを考えなければならない。
仕事とは、給料をもらってする通常の勤務の場合もあるし、大学院での開発の場合もあるだろう。
その場合、自分たちの強みを何におくのかを考えなくてはならない。
　
　自分たちの強みがない場合、ビジネスとして成功しないし、大学院の研究生の場合、
研究が論文として通用しないものになってしまう。
　　だからこそ、自分たちの強みを何におくのは、知恵の限りを使って考え抜く必要がある。

　自分たちの強みを何におくのかを考えない組織の場合、せっかくの強みを強みと気づかないまま
簡単に捨ててしまう。

画像認識の場合も、強みのおき方は組織によって異なっています。

• 高フレームrateの画像処理に強いところ
  • フレームrate が高いことは、制御の仕組みを単純化します。追跡trackingをさせるのにしても、移動範囲が狭くなるだけ物事が単純になって、単純なロジックでうまくいく場合が増えます。
• FPGAやLSIへの回路化に強いところ
  • カメラ信号処理の回路設計の分野では、画像認識を回路化する場合があります。その場合、画像認識のロジックを固定小数点化した上で、回路規模を小さくするアイディアを多数入れ込んでいきます。
• 携帯電話など組み込みに強いところ
  • 消費電力の限られたターゲットなので、いかにバランスのよい開発をするのかが重要なポイントとなります。
• サーバー用の画像認識に強いところ
  • GPUを使うライブラリCudaなどを利用した複数のサーバーを構築して、機械学習のハイエンドの技術の実装を得意とするところ
• 大規模データセットを持っていることによる強みを持っているところ
  • 人物認証について、データセットを大規模に利用しているとこでは、そのことによる製品の性能の検証があることが、営業における優位性を確保しています。

　自分たちの組織の特徴と、その強みを必要とするユーザーの状況とを組み合わせて考えて強みとして何を作るのかを経営視点で考える必要があります。利益を上げることができるのか、優位性を維持し続けることができるサービスか。優位性を作るのは人です。　

自分たちの強みと思っていたことが、外部のライバルが作り出す状況によっては、弱みに変わることがあります。
　例：国内向けの携帯電話のハードウェアとソフトウェアとを両方、携帯電話メーカーが開発していた（実際は下請けに出す）のが、ソフトウェアを共通化させるGoogleという存在が出現したことによって状況は変わってしまいました。どのハードウェアメーカーに対しても同じ環境を提供するということで、特定のハードウェアメーカーでは実現できない中立性も担保しつつ、勝負の土台を変えてしまったのです。

###組織の強みとは組織を構成している人の強みであることを理解しない

• 的確な判断をすることができるのは、その分野に対して経験に基づく勘が働く人。
  • 闇雲に、論理的にはありうる全ての可能性を考えると、答にたどり着くのに時間を無駄にしてしまう。
    • 直感のきく技術者になろう
    • 可能性の枝切りができない開発は必ず失敗する。
    • うまくいきそうにない技術
• 必要な作業と省略しても大丈夫な作業とを区別して、チームワークを推進できるのは、良好な関係のたまもの。
  • 「それは自分のせいじゃない」とチームがぎすぎすしてくると、しなくていい仕事が増えてしまう。
• 今からみれば不十分なものでも、ある時期までは使い物になった技術を開発した人を軽んじてしまう。
  • 技術は簡単に進歩するものではありません。古い技術があったらからこそ、新しい技術が作り出されるのです。
• 技術を売りにする会社ならば、その技術を作り出す人こそが会社の資産・強みだということを理解しなくてはならない。
  • 経営状況のために給与水準を高くできないことはあるだろう。でもかぎりの部分で人を大切にしよう。
• 根幹をなす技術分野で技術者が辞めてしまうのが続く場合には、組織運営に問題があると言わねばなりません。
  • そのような組織を個人で内部から変えれるとは思わないことが得策です。
  • 変えれるのは、権限のある人で、しかも問題に気づいていて、方策を考えて実行できる人の場合だけです。

技術者を失えば技術の優位性も失われる

　ある時点で市場で優位に立った技術が、開発が終了したからといって技術者を社外に放出してしまっている例がある。その会社が意図した結果なのかどうかはわからないが、技術が更新されていないままになっている。その結果、ここ数年の技術の変化の中で優位性を次第に失ってきている。「その場にとどまるためには、全力で走り続けなければならない」

###誰が何に責任を持つのかを明確にしよう
プロジェクト・マネジャーが知るべき97のこと
「すべての成果物にはその完成に責任をもつ人が一人いるべきです。各アイテムの完成にだれが責任をもっているのか、プロジェクトに取り組んでいる全員が明確に理解するべきです」

技術的な内容を適切に判断できるのはだれだ？

　開発は技術的な内容を判断して先に進んでいなくてはなりません。
　どういう指導原理に基づいて、設計していくのか考え抜かねばなりません。
　全ての項目を実験で検証することはできません。
　実験をせずに明確にできることは明確にして先に進まねばなりません。
　技術的な内容を直接に判断できるのはだれか
　それを見極めて、その人を信頼して先に進まねばなりません。

###組織運営にコストモデルがない。

• 特に会議のコストがどれだけ高いかを意識しない。
  　会議でなくて代用できる方式がある(後述のRedmineなど)。
  　　会議のコスト＝会議に参加する人の時間あたりの給料＊人数＊時間＊一定の倍率
  　　それだけの価値のある成果をだしている会議なのかを常に会議の主催者は意識しなくてはいけない。

• 一方で必要なものの購入を渋る。
  　いくらオープンソースのライブラリが充実しているからといって、ソフトウェア開発が全てただのツールでできるわけではありません。しかるべきツールを使ったほうが開発効率が上がります。開発者が効率よく開発するには、マシンの性能やネットワークの性能、必要なツール類の充実が大切です。そのれらをケチった状態では、優秀なエンジニアも力の出しようがありません。

• Excelでタスク管理・進捗管理をする

  • Redmineなどのツールを使いましょう。生きているタスク管理と古くなっているタスク管理
  • Redmineのようなタスク管理ツールを使うと状況の整理や把握がうまくいきやすい。プロジェクトリーダーの状況の把握の作業が減るようになります。
  • メールでは、新規に加わったメンバーに対して十分な情報がとどきません。Redmineでタスク管理・進捗管理をするならば、新規に加わったメンバーでも今までの経緯がきちんと把握することができます。
    • メールが届いている場合でも、メールは検索し、添付ファイルの暗号化を外してようやく内容を見ることができます。しかもメールの添付のExcelは、Aさんからのメールの添付と、Bさんから添付されたメールの添付ファイルが同じファイル名であったときに、それが同じ内容なのか改訂されたものかを知ることは、手間を考えたらほぼ不可能です。

成果物にならないドキュメンテーションのコスト

　「この件についてはレビューをしましょう。」といつの間にか、会議が増えていって、そのための準備の資料が増えていく。しかも、それは成果物にならないドキュメントだったりする。計算結果のファイルを直接みても分かることを、「PowerPointの資料にまとめてくれ」となるし、本来の作業の時間が奪われていく。
　PowerPointなど余計なソフトウェアができて、直接的な作業の時間が低下してしまっているように思う。
　

答は既に出ているのに、それに気づかないまま(あるいは気づかないふりをして)会議を繰り返す。

　その分野の理屈がわかっていれば、既に答が出ているのに、（その分野の技術者も何人もが指摘しているのに）、それを無視した議論を重ねる。それがどれほどの損失を生じているのかを理解しようとしない。そのため、本来行わなければならない対策が、未対策のために放置される。そのことによって、本来対策を講じて改善できることが改善できないままに症状を悪化させてしまう。
開発は時間との勝負です。所定の期日と予算の範囲の中で開発が完了しないという形でプロジェクトは失敗します。

有用なアイディアが陳腐化してから採用される。

　どんなに有用なアイディアでも陳腐化してしまってから、競争力を持つことはできません。そのアイディアが有用なものかどうかは、自力で考えるしかないのです。そのアイディアが有用なものであったことを、他社が実現してから気づいてもらってもどうしようもないのです。
　有用なアイディアを、自分の頭で有用であると判断できない組織が増えていることが、衰退を招いているように私には見えるのです。今からそのアイディアに着手したところで、外部に対していかなる優位性をもつこともできません。優位性を持ち得ない開発は、資金だけ投入しただけの無駄に終わります。

###プログラマ・エンジニアの能力は同じではないことを理解しない

• ある方式について方式を選択してコーディングできるような人物は組織の中に何人もいるわけではありません。
  　　人月という考え方は、1人のエンジニアの能力は共通という前提にたっていますが
  　ある方式を構築して検証して実装できるエンジニアを、別の人員に簡単に置き換えられるものではありません。
  　そのことを理解して行動することです。
  熟練と並の開発者の生産性
• 特定の人員に負荷を集中させる。
• 有能なエンジニアを動作検証のオペレータとして浪費してしまうことは避けなくてはなりません。
• 実務を解決できる有能な人を道具として扱ってしまってしまう。
  • ソフトウェアを書ける人の中で、OpenCVを使える人は少ない。OpenCVのcontribを使いこなせる人はさらに少ない。どれが支配的な要因であって、適切な方式の選択できるのはさらに経験と勘が要る。画像計測上の実機で生じるさまざまな問題を適切な解決策を選択できる人間はさらに少ない。
  • 専門的な技術者に成果を上げさせるためにリーダーができること

###新しい技術の開発をできる資質のある人は限られていることを理解しない

• 新しい技術を作っていく際には、「この手順をふめば必ず誰でもうまくできる」などというものはない。
• 新しい技術を作っていく際には、なぜそうするのかについて、論理的な飛躍あるいは、開発者の思い入れが存在する。10年、20年たって状況が詳しくわかってくれば、それがあるべき選択だったことが判明することもあるだろうが、開発者の開発中にはそれらの情報はわからない。新しい技術の開発に苦闘した経験がない人が、新しい技術の開発をマネジメントしようとする場合の間違いは、そのあたりにあるのだろう。
  • 例：真空管の時代に、固体の中を流れる電流を直接変えてしまうことを夢想するのは、相当な飛躍です。
  • 例：大多数の開発者・開発企業がAという材料を選択しているときに、1人だけでBという材料を選択することは相当な思い入れが必要です。その材料でうまくいくなんてことが証明されていることは絶対ないからこそ「新しい技術」なのですから。このような開発を行う人たちがどのような点を開発を行うための指針としているのかは、それらの人の著作などを読むことで知ることができます。　

###ひとあたりのよさは、適切なマネジメント能力を意味しない。

• 開発にあたって何をすべきであって、何をしてはならないかというのを、その開発案件に対して適切な理解をしているのかが重要です。

• 解決すべき課題が多数あるときに、どのように、どの順序で解決していくのか、適切な理解を作り上げていかなくてはなりません。適切な理解を自力で作る必要はありません。チームのメンバーの詳しい人に聞いて何が本質なのかを理解することです。

• 「すべきこと」、「してはならないこと」を知っている人は、明確な言い方でそれはいけないと断言してしまいます。そのために、オブラートに包んだような表現をしないために、ひとあたりのよさとはならなくなってしまいがちです。

• 開発のマネジメントをするには、失敗しない・させないためには何をどうすればよいのかを、知ろうとする習慣をこころがけてほしい。

誤りを認められないマネジメントは、まるでインパール作戦のよう p.66

引用「高学歴社員はお互いを庇い合う『ぬるま湯』を好みます。相手のミスを指摘したり、誤りを正したりするより、狭いコミュニティの平和を優先するわけです」

実務もできない、他人の意見を聞くこともできない人をリーダーにしてはならない(新技術の開発ならば)

何をすべきであって、何をしてはいけないのかが、その担当すべき分野ごとにあります。どのようなアプローチをすべきかはその分野ごとに様々な定石があります。新しいものを作り出すためにはどうしなければならないのかは、そのような経験をして感覚を研ぎ澄ます必要があります。カンナがけも出来ない人を大工の棟梁にはしないでしょう。しかし、会社や組織によってはそのような人事がなされることがあります。
　他人の意見を聞くことができて学んでいける人の場合には、状況が変わってきます。他人の意見を聞いて取捨選択ができる人の場合には、他の人の能力を自分の能力にしてしまえるのですから、実務のできる人になっていきます。その場合でも、まったく実務が出来ない人よりは、何らかの実務ができて、その勘を活かしながら他人の意見を聞ける人の方が望ましいと思います。

実務担当者にまかせきって、マネジメントなどしないほうがいいこともある。

上記のような状況では、問題と対処案とを理解している実務担当者を信じて、マネジメントなどしないほうがいい結果になることもありえます。
　余計なブレーキが入らないので、さっさとアイディアを試してみることができます。
　実務担当者は、どうなったらおかしいかに自分で気づきえますから、
　間違ったまま暴走を続ける心配はなかったりします。

###問い詰めて怒鳴るだけなら誰でもできる

問い詰めて怒鳴ることよりも大事なことは、何が問題を生じさせているのかを、一緒に考えることです。しかりつけることよりも、どうやったらうまくやり方ができるのかを示すことです。あなたが、その開発のマネジャーとして力を発揮するためには、欠点だらけのメンバーを好きになってください。いっしょに仕事をしていくのが楽しいと思ってください。

世の中は欠点だらけの人でできている。組織も同じ。
メンバーのもつ欠点を目立たないようにチームを運営すること。
　怒鳴る人のところにには、必要な情報が前もって上がって来なくなります。

問題を指摘することより、問題の解決策を提示することは難しい。解決策を成し遂げるのはもっと難しい。

　問題の解決にあたっている貴重な人材を組織の中で浪費してしまっていませんか。設定が正しくできているか確認しましたか。動作ログはきちんととってますか。そのようは作業をしないままに、担当モジュールの開発者に「なんかおかしいんだけど、最優先で対応してくれ。」と、新規開発の作業を止めさせてまで対応させるのは、組織運営上問題です。分野によっては、解決策を作るのがとても難しいことがあります。けれども、設定が正しくできているか、動作ログをとることは、そこまで難しいことではないのです。開発の一番の課題を解決している人材を浪費しているのを見るにつけて、大丈夫なのだろうかと不安になります。

###上司・経営幹部だけをみた開発の進め方をしてしまって、最終ユーザーへの視点が欠けた開発を組織運営で行ってしまう。

上司や経営幹部の言うことも聞かなくてならないのは、サラリーマンエンジニアである以上避けえない。しかし、最終ユーザーへの視点がなくなった開発は、時として不幸な結末に至る。
ものごとの本筋を考慮したときにはしなければならないことが、上司・経営幹部だけをみた開発の進め方をすると、欠け落ちてしまいがちだ。何をしなくてはならないか、何をしてはならないかを知っている現場のプログラマ・エンジニアは、リーダーがものごとの本筋を見失って、上司・経営幹部だけをみた開発の進め方をしているとさめた視点で物事をみるようになってしまう。

• 開発している仕事が最終ユーザーに対して何を約束しているものなのかを若手が考えないままにしてしまうこと。
  • 業務として開発している場合、最終ユーザーに対する約束すべき機能や品質がある。そのことを理解しないままになってしまうと、最終ユーザーの期待を裏切ることになってしまう。最終ユーザーに受け入れられないものを作っていると、利益を確保できず仕事を失うことになる。大企業の人事の場合、人事しか経験していない人事の比率が高くなっていて、どのように開発エンジニアを教育するのか、どのような開発エンジニアを責任ある立場につけていいのか悪いのか、どのような人員が本当に仕事をできる人員で採用していいのか悪いのか、それらを判断するための経験がないままひたすら人事の仕事をしている場合が多い。

間違った判断のもたらす不幸な状況についての想像力がない

　上司や経営幹部は、判断を遂行する力を持っている。経営幹部が間違った判断をするとどれだけの不幸な状況を作り出すのかは、最近のニュースが伝えている通りです。間違った判断は、多額の損害を発生させます。ソフトウェアなんだから後でバージョンアップすれば大丈夫などと安易に考えたりはしてはいけません。バグのあるソフトウェアが作り出した損害に対して賠償請求がなされることもあります。ソフトウェアを含むシステムのバグは、ソフトウェアだけで解決できるとは限りません。それなのに、安易に「ソフトウェアをバージョンアップすればなんとかなる」と決め付けることは、不幸を招き寄せる可能性があります。「ゴミが入れば、ゴミが出る」のですから、最初の入力データが悪い時点でどうしようもなくなります。年が下2桁だけしか与えられていないときに、「25年開通予定」と書かれた道路が、平成25年なのか(開通が遅れたまま表示がそのままなのか)、2025年の意味で書かれているのかは、知りようがありません。入力の時点で既に手の打ちようがなくなっていれば、ソフトウェアのバージョンアップで何とかなる可能性はありません。計測の場合もそうです。既にノイズだらけのデータになっていれば、どうしようもありません。ノイズの少ない測定をしておかない限り無理です。そのようなことを無視して、ソフトウェアをバージョンアップすればなんとかなる」と考えることは、無謀な行為です。

間違った判断は、一緒に仕事している人たちを路頭に迷わせる可能性さえあります。
　間違った判断がもたらす不幸な状況について想像力を働かせれば、何をしてはいけないのか、何をしなければならないかについて、おのずと分かるようになっていくはずです。

リーダーがメンバーの意見を聞けない

• リーダーの立場にある人が、最新の開発手法の実務経験のある若手の意見を聞けないという場合に、開発に大きな問題を生じる。開発効率があがらないやり方を組織のリーダーが選んでしまったら、開発効率は簡単に低下する。10倍開発速度を上げることは難しいが、開発速度を0.1倍にすることは簡単だ。

• 実務能力に秀でたリーダーであっても、メンバーから学ぶことは多いはずだ。実務能力に秀でたリーダーの持つ手法が、他のメンバーにとっても有用な手法であるのかどうか、手法を共有してみると分かってくる。うまくいけばOKだし、うまくいかなければ、なぜその手法が有効でないと感じるのか他のメンバーの意見は有効だ。

• 私は常に同僚から学ぶように心がけている。時が変わると最適な手法やツールも変わってくる。新しいツールを自力で全て調べて習得するのは大変です。同僚と学びあうことでよい開発を行うことができます。ぜひ、リーダーの方は、メンバーから学んで、よりよい開発のマネジメントを見つけてください。

###　リーダーがプライドが高すぎて、自分が間違えている可能性を考えない
　そしてメンバーが危惧していたとおりの現象がおきても、その問題を生じさせてしまったことから何かを学んでいるようには見えない。

　

リーダーがプライドが高すぎて、自分の前の発言を修正できない

　正しい判断をすることは難しい。前提条件が変わると、結論も変わる。それなのに、表面的な発言の一貫性にこだわって、今の時点での適切な行動をするのが後回しになってしまう。

もしリーダーにこういう傾向が高ければやばいかもしれない。

• 他者に冷淡で共感しない
• 行動に対する責任が全く取れない
• 自尊心が過大で自己中心的
• 口が達者で表面は魅力的

日本の企業のマネジメントでは、その分野に対して適切な勘が働いて実務ができることを軽視しているから、「口が達者で表面は魅力的」なのを選んでしまう可能性はある。

こういう傾向もやばいようだ

• 「格上」の人間にはおもねり、身内に甘い
• 「格下」の人間には極めて冷淡
  「高学歴社員が組織を滅ぼす」

「責任感の強いことは、昇進を妨げる可能性が高い」

次の記事は、組織運営に問題を生じやすくなる理由の可能性を提示するものです。もしそうであるとすると、どのように克服したらよいのか。組織の末端に位置する人間にはどうしようもないことです。
東芝など大手6社の調査で判明した「昇進の条件」が恐ろしい

マネジャーは自分の強みを何におくのか？

###全ての情報について完璧に情報がそろっていて、誰が見ても自明になるまで、判断を保留し続けるマネジメント。

• どのような方式を選択すべきかという問題に対しては、迷うことはあるだろう。しかし、いつまでたっても決断できないことは担当者の力をそいでしまう。目的に対して十分であれば、ベストを求めるのはやめにしよう。機械学習のように100％の精度が実現できないものもある。迷い続けて、どれもしっかりしたものにならないよりは、この方式ならいけると開発者が信じる方式を力いっぱい開発してみてはどうだろうか。開発しきる前から、絶対うまくいくなんてわからないのだから。
  　「全ての情報について完璧に情報がそろっていて、誰が見ても自明になるまで、判断を保留し続けるマネジメント」をすると、行動することではなくて、調査と書類書きに労力を使い尽くしてしまう。

###メンバーが発する危険信号を受け止めない

開発にあたっているメンバーは、開発がうまくいかなくてやばそうだと感じるとそれなりの意見を職場で口にするようになる。しかしながら、リーダーや経営幹部がそれらの危険信号を受け止めないことは、開発を不幸な状況に導きやすくなる。満たすべき機能が実装を完了しないことの要因や、開発速度が低下する要因に対して、早めに手をうっておくことが必要なのに、メンバーが発する危険信号を受け止めないことで、対策を打つために必要な時間を失ってしまう。

　最悪なのは、何も対策を打たないという結論をリーダーが出すことだ。

###品質が確保できない状況で思いとどまることをしない

チャレンジャー号爆発事故

大きなプロジェクトでは組織が分断され、そこで情報も途切れてしまう。また一度できあがった組織は、それ自体が生き延びようとして尋常でない判断がなされ、事故につながる場合が多い。

###組織運営で人事評価で成果主義を金科玉条とする。

• 競うべきは他社とであるのに、同僚と競うようになって、同僚の力を高めることを毛嫌いする人を生み出してしまう。
• 年間での目標設定と達成度の評価になるため、そのエンジニアへの仕事の内容が年度の初めに立てた計画に対して縛られる硬直化した状況になりやすくなる。そうでない場合には、年度の初めに立てた計画と一致しない結果になるので、達成度の評価で不利な状況になる。
• 「これはだれだれさんの今年のテーマ」という枠組みを固定してしまうことで、その人へのアドバイスが、「テーマの横取り」ととらえられるようになってしまう。

###年度での業務の計画がきっちりと決まっている度合いが高い場合

• 次年度の開発業務の獲得が年間の作業の中で占める比率が高くなりやすい。
• 巨大な組織の場合だと、開発のアイディアを出して、そのアイディアを実現するための部署を、複数の部署で競争させるという状況が生じてしまうことがある。

###改善すべき方向性がすぐには伝わらないからといって、リーダーへの説得をあきらめてしまう。

• リーダーがその分野の技術についての適切な理解をもっているとは限りません。
  すぐには理解してくれないからといって、あきらめてはいけません。
  1週間かもしれませんし、1ヶ月かもしれませんし、半年かかるかもしれません。
  それでも、説得をあきらめてはいけません。

• 以下の記事にあるように、ゆっくりと辛抱強く説得していけば、きっとわかってくれるはずと信じましょう。
  同僚にも同じ言語を使ってほしいと思ったら

###ときとしてある理不尽な状況に対して自己防衛をしておかない。

ソフトウェア開発の現場では、ときとして理不尽な状況が発生することがあります。そのようなときに、自分の責任外の部分に問題があるのに、自分の開発しているモジュールに問題があるように言われてしまうことがあります。そのようなことを避けるために自己防衛をソフトウェア開発の中に入れておきましょう。

• 自分の責任のライブラリは、単体テストしておく。他がどうであっても。
• 自分の責任のライブラリは、他の人の作成するモジュールに極力依存しないようにつくる。
• やむなく依存性がある場合には、単体テストをして動作検証して使う。

###何が開発速度を落としているのかを考えないまま、スケジュールの再設定をする

スケジュールが当初の計画通りすすまなかったのは、何らかの理由があるはずです。そのような理由を考量して、現場が進みやすくしないかぎり、スケジュールを再設定しても解決しない可能性があります。そのようなときに上から問い詰める流儀で原因の発見と対策を講じようとしてはなりません。現場の担当者に課題を自由に発言させて、現場の担当者が困っていることを取り除くようにしてください。　

###努力の方向性を発散させてしまう目標設定
　一つのことを十分にやりとげることでさえ、新規の開発要素があるものでは、それなりの手間がかかるものです。それが、あれもこれも実現して欲しいと一度に複数のものを開発要求されても、一人の工数には限りがあります。努力の方向性を発散させてしまうと、出来ることさえできなくなってしまいます。マネジャーの責任は、開発の本質にかかわる部分に開発速度を向上させるために何ができるかを考えることにあると私は思っています。つまり、チームのメンバーが楽しく仕事ができるようにする「ことだと考えています。

###変化することを恐れすぎて、問題解決を先送りにしてしまう。
そのために、本当に変化を受け入れなければならなくなったときには、時間の猶予が失われてしまう。
めんどうなことはしなくて済むならば、しないのがうれしい。誰だってそう思うだろう。どうしてもその変化を受けいけなければいけないのかを誰にとっても自明になるだけの十分な証拠がでそろはないうちは、その変化を受け入れることを拒否する。そのために、時間という貴重なリソースを取り返しのつかないまでに失ってしまう。
　そのような結果にいたった企業の名前は、いったいいくつ挙がることができるだろう。

###ドキュメントに関する理不尽

• 不具合を回避するために守らなければならない手順を、ドキュメントとして共有しない。またドキュメントが実際の状況と異なってもほったらかしにしてしまう。
• 最初のドキュメントを書いた人の労力を省みずに、コードの改変によって生じてしまった違いのために、保守されていないドキュメントの悪口を言ってしまう。
• 全ての項目に対して完成度の高い、誰にでも分かりやすいドキュメントを要求する。
• バージョン管理や差分表示が困難な形式でドキュメントを作成してしまうことで、最新版に自動に置き換えたり、変更が生じたときに変更点の確認がしにくいという状況を生じる。
• 将来、問題を生じうるかもしれないことに気づいたときに、その情報を共有せず、「問題が生じたときに考えればいいさ」としてしまう。

###その分野のベテランエンジニアに関連することなど

• その問題に対して一番知見をもっている人物の言うことを無視する。

• 理解する側には基礎知識が不足していることを考慮して、少しでもわかりやすい実例をかみ砕くことをおろそかにする。

• ある問題について一番知見をもっているからといって、そのことを鼻にかけていると思われかねない行動をしてしまう。

• 組織としての判断や行動では、すぐさま対応できないことを理解せずに、組織内で対立を生じてしまうこと。

• 理解する側の基礎知識のなさを「あいつは、コミュりょくがないから」、説明している側の責任にする。

• おそらく、多数の理系大学生・大学院生の就職活動で生じているのだろうな。 >「誰にでも分かりやすく」するアプローチを求めてはいけない理由の追加

• 現状のアプローチにある問題点が見えてしまっているので、それを指摘する人がいたとしよう。得てして、マネージャーにとっては、その人は面倒な人という位置づけになってしまって、その人が問題を事前に扱いやすくしてくれる人でもあることを見落としてしまう。

• マネージャーとはどういう人種なのかを理解しない。

  • 組織を運営しているマネジャーがどれほど心配しているかを理解しない。
  • マネージャーは、どの要因がどんな具合に支配的なのか、重要さの順序が分からないものであるということを理解しないまま、マネージャーがいう作業の優先順位に盲目的に従うこと。
  • 担当者がどれだけ厄介なことを扱いやすい問題に変えていって解決してきているのかを理解せずに、未解決のことだけに着目して担当者を責めてしまう。
  • スケジュールの見積もりの精度を上げようとするあまり、過度に作業への介入を行うことで実作業の時間を半日単位で失わせる。別工程の部分で数日不具合に苦しんで実作業の遅延を生じたさせられたことなど、考慮に入れてもらえない。見積もり精度の「不確定性原理」
  • コードを書ける人よりもコードを書けない人がスケジュール管理をするようになりがちである。しかも、いつの間にか責任者として出世している。
    • 事業部の製品に対して、本質的な付加価値を新規に作り上げた人物よりも、たまたま出世した人と仲がよかった人がつられて出世しやすいものである。
  • 「問題を解決できる力量のある人には権限がなく、権限がある人には適切な判断をする力がない。」ということが起こりがちである。

• 動くようにする、正しくする、速くする（、安くする）。この三つを実現するときに、速くする（安くする）ことを、過度に優先順序を高くしてしまうこと。>動くようにする、正しくする、速くする。

###解決中の問題に関する不満は、問題を解決している人に集中する。
ある技術的な問題を解決できる能力のある人はとても限られています。その問題を解決するために全力を尽くしているのですが、「解決中の問題に関する不満は、問題を解決している人に集中する。」という不幸な状況が発生することがあります。
　 従来からの問題を解決するときには、少しずつ問題を解決していくしかない。一瞬に全ての問題が解決できるわけではない。そのため、問題を解決中でも不満は残る。その不満の向かう先が、問題を解決中の開発者に向けられてしまう。
コードを書かない人がバグを埋め込むこともない。そのため、コードを書かない人の方が、「間違ったことをしていない人」として、自信げに発言して行動することになることがある。
スケジュールに対して少しでも追いつくようにしている当人を、スケジュールに対して遅れている問題人物とみなすようになってしまう。別の要因（例えば、バグが頻発する別のライブラリ）が、担当者の作業をどれほど困難にしていても、それらが着目されることはない。ソフトウェアを含む製品の開発遅延は、常にソフトウェアの遅延としてとらえられてしまう。

• 専門的な技術者に成果を上げさせるためにリーダーができること

###新しいもの・先見性に関連した理不尽

• 　本質的に新しいものを作るだけの人間の場合、「歯に絹を着せぬ」直接的な言い方をしがちになるから、本人が自覚しないうちに敵を作ってしまうこともある。

• 「空気を読む」なんてことはできない。

• 世の中の新しいやり方を紹介している人は、いわば「その他の人を不勉強な人」と決め付けている「不穏な輩（やから)」もしくは「独善的なやつ」と受け取られることは、日本の企業社会の中では珍しくないようだ。

• デジタル回路を専用の言語で設計する手法を留学先で学んだ人が、社内で紹介しようとしたら、「留学は留学、実務とは別とわきまえろ」という旨のことを言われたということをその人の著書の中に書かれていた。

• 新しい言語の有用性を組織が理解するようになるのは、どうしても数年以上の遅れを持っているし、ひょっとすると将来にわたっても理解されないことがある。

• いったん「新しいもの」に対して間違った判断をすると、間違った判断をした自分を認めることを拒絶し、未来永劫判断を変えない人が存在する。

• 問題を予見するだけの実務経験があるからこそ、事前に課題を指摘する。それを聞くがわが、「例の不平屋が騒ぎ出した」くらいにしか思わない。後でギリギリのタイミングになってから、その問題点に気づいても、早い段階で指摘した人物を尊重することがない。

###多忙を理由に若手を十分に教育しないままになってしまう。

• ソフトウェアエンジニアの場合、単にコードが書ける以上の強みのある分野を複数もたせないと、この厄介な時代を乗り切れないのに、強みを持たせてあげられないままになってしまう。
• すぐに実装できてアイディアの正しさを検証できる言語とC/C++言語との両方が有用なのに、一方だけの開発の仕方しか認めない。
• 今いる会社の今の仕事が30年後も存続していることは（ソフトウェアエンジニアであれば）考えにくいのに、別の組織でも生きていけるだけの力を与えないままになってしまう。
• 自分の周りの有能な人の力にたよることに慣れすぎてしまって、自力でも解決できるだけのノウハウの習得をおろそかにしてしまう。
• ソースコードの品質を保つために必要なやり方があります。それを満たしていないコードを書いている人にはより適切なコードを書くためのやり方を伝えなければなりません。不適切なデータ構造を使うことで生産性を1/10や1/100に下げることはとても簡単です。若手エンジニアを不幸にしないためのC++コーディングべからず集
• その分野で仕事をしていくために必要な感覚をもっていない事例を見かけたことは、ソフトウェアの分野に限りません。
  • 例：機器の組み立てをしている部署でカッターナイフの刃を出したまま、昼休み休憩をしてしまう。
    このような不穏な傾向が多数みられる組織の場合には、組織が落ち込みをなるほどと思えることがあります。

###理不尽な人事制度のために、報われるべき人たちが心を砕かれてしまう。
　若手に対して理不尽なことをしないこと。理不尽なことをすれば、確実に心は離れていく。何が何でも成功に結び付けようとする意欲をそぐことにつながる。
1人1人への尊敬を忘れないことが、1人1人の力を引き出す上で大切なことです。

　あるモジュールの性能がでないのは、そのアルゴリズムの原理的な限界なのに、そのモジュールの開発をした人のせいにするかのごとき扱いを組織の中で受けてしまう。

　コードの改良と実装の追加を一番行っている人ほど、「最近、プログラムの実行速度が遅くなったのは、お前のせいなんじゃねえ？」と不用意に疑われて、本来の開発業務をストップさせられて、原因解析にあたらせられてしまう。」

• 立場の違い・意見の違いを、個人攻撃に変えてしまう。
  • それぞれの人の仕事上の立場、それぞれの人が持つ判断材料の違い、嗜好性の違いなど理由から、仕事上意見の違いは必ず生じる。そのような違いを個人攻撃に変えてしまわないようにすること。個人攻撃になってしまう表現を使ってしまうと、人間関係を破壊して修復不可能な状況になってしまう。

###優秀な技術者を追い出してしまう方法
別記事として独立させました。
　優秀な技術者を追い出してしまう方法

個人攻撃は絶対するな

　
　考え方の違いはあるだろう。理不尽な言い方をされることもあるかもしれない。しかし、いずれ分かってくれることもある。

改良の余地がたくさんある状況の中で

　うまくいっていない状況は、改良の余地がたくさんある状況です。改良の余地のどれか一つでも、改良をさせてみましょう。改良が１つでもいい結果につながると、それと同じように別の改良を期待する組織の雰囲気を作っていきたいものです。その中で、一人ひとりの仕事のしかたが改善されていくことを期待したいものです。

###未整理のことなど

• 使われる関数は使う側の条件がわからないと、品質が確保できない種類のものがあることを理解しない。
• その技術の開発者が、「こういう条件で使わなければいけないよ」と言っているのを無視して使って、「うまく動かないじゃないか」という。
• うまくいかないのを誰のせいとする雰囲気をつくってしまう。
• 自分の努力で困難を乗り越えるというプレッシャーに耐え切れず、「あいつが悪いから、○○できなかったんだ」という結論に達して、自分が楽になりたがってしまう。

会社をダメにする物事を決められない「横パス上司」
納得！会議で「声の大きい人」に押し切られない方法

###上司とは

• 上司とは、「自分の発言中に妨げられることは断固拒否しつつ、相手の発言中に妨げるのとは当然と思っている」人物のことである。
• 上司とは、「自分が期待している回答と同じ順番で同じ内容が出てこないと、相手の言っていることは聞かなくてよい」と当然のように振舞うことのできる人物である。
• 上司とは、「自分が期待している回答と同じ順番で同じ内容が出てこないと、相手の言っていることは間違っている」と当然のように振舞うことのできる人物である。
• 厄介な状況の場合、相手の判断ミスもあったなどということを指摘しようものなら、その数倍の厄介さを背負い込むことになる。相手の判断ミスを指摘して、謙虚になってくれる上司など存在しないことを心得なければならない。
• 個人的な人の好き嫌いと、その人が言っていることが正しいかどうかを区別して考え行動できる上司はいない。

　ここに書いている内容は、極めて極端な事例です。
そうでない上司の方が圧倒的に多いでしょう。でも時としてそのような上司にめぐりあうことがあります。そのようなときにどう対処できるのかが、その後の仕事の成否を決めてしまうことがあります。

###若手の育成のためにすべきこと

• 得意な技術分野を深く広くできるような仕事の配分をすること。

  • そのように仕事を分配できなければ、仕事への魅力を失ってしまって、優秀な人物であればあるほど、別の場所に移動してしまう可能性が高くなる。

• 必要な技術を使いこなせるメンバーを2重化しよう。

  • その技術を使いこなせるのは、その部署の中で○○さんだけという状況はなくそう。それは仕事の進め方ではない。

• 実際のアプリケーションの開発のなかで生じるトラブルを解決するための力を与えること。

  • 効果的なデバッグの手法を共有して、トラブルから早めに抜けられるようにすること
  • 自分の担当外の部分についても、問題の切り分けがしやすくなるようなノウハウやツールの情報を共有すること。例えばネットワークのアプリケーションだったら、wiresharkを使って問題を切り分けることは役立つことが多い。
  • テストをしやすいコードにリファクタリングすることの大切さを伝える。
  • 単一責務の原理を満たすコードにしていくことで品質を確保しやすくなっていくことを、実務の中で経験させていくこと。
  • 実行速度を改善するためのよく使われる手段(定石）を共有すること。
    • ペアプログラミングで相手のコードを見るとそのような改善を相互にできる。

• 実装するアイディアに対してすばやくプロトタイピングをすることで、開発の方向性を早めに見定めることの大切さを伝えること。

  • 例えば、OpenCVでの開発でも、Pythonでのimport cv2として、python上で開発することのメリットを実際に開発の中で経験させること。
  • このようなプロトタイピングのしやすさが、機械学習の分野でもPythonがフロントエンド用に言語として使われている理由がであることがわかってもらえるでしょう。

• それぞれの若手に対して、自分の強みを持てるようにすること。

• 自分は何をしたいのか考え、より充実した仕事を将来できるための下地を作ること。

• 上司やマネジャー層に対して、どのように若手からの影響力を行使して、仕事が成功しやすいようにもっていくのか、いい手法とよくない手法とは何かを伝えていくこと。

• 組織につぶされないための強さをもてるように見守ること。

###組織のリーダーが心がけるべきこと

• 技術の先見性もあって、リーダーシップもあって、メンバーへの配慮もよくて、プレイングマネジャーとして、実務担当者としても1番優秀で、なんてことは無理です。
  　ですから、必ずチームのメンバーの中には、ある点については自分よりも優秀な人が必ずいます。そのような人のよい点を学ぶことです。技術の先見性を持ち合わせていなければ、それを持っているメンバーの知恵を借りることです。

###組織の運営者に働きかけるべきこと

• 「なぜ開発に失敗しているのか、どうすれば失敗を減らせるのか」一番本質的なことをピンポイントで分かりやすく伝えること。　それ以上のこまごましたことは、こちらからは言わない。

• 優秀な技術者がどれだけ得にくいものであるのかを理解してもらうこと。

  • 求人を転職紹介業者を通じて確保するコストを考えたら、今いる優秀な技術者になっとくのいく水準の賃金を支払うのが、会社としての出費を抑えるだろう。

• それぞれの技術者が、それぞれの優秀さを持ちあわせていることを理解して、尊敬をもって接すべきことを運営者に理解してもらうこと。

  • それぞれの技術者の優秀さは、優秀な分野が異なる。その人の得意とする分野の力を引き出すことがマネジャーの責任であって、誰がどの分野にどういう優秀さを持つのか、いい点だけを見るように心がけるべきだと考える。

• 「どのような組織運営をしてはならない。どのような組織運営をすべき。」なのかを知ることができるようにしていくこと。

• 上司に働きかけてもしかたがないのであれば、その上に働きかけること。

適切な影響力を持てるようになろう

自分の判断力が適切であると信じられるなら、適切な影響力を持てるようになろう。
「自分はあのときそう言っていたのに。」とか言うのはいやだ。
技術者として成功しなければ意味がない。
「○○という言語はいい。○○というライブラリはいい」という内容の技術資料を登録するよりも、
実際にその言語やライブラリのユーザーを増やすことの方がいい。
技術者が技術者として結果をだせるチャンスはそんなに多くない。
中途半端な結果で終わってしまってはもったいない。
適切な影響力を持てるようになれば、まわりのエンジニアも能力を発揮しやすくなるようにもっていけるのではないか。

以下のページにはあるアニメの中で効果的な人への頼み方を述べているものです。

• 「人への頼み方を教えてください！！」

『相手には自分から動いてもらうように 仕向けること』
『相手に 精神的な満足感を与えること』
『問題は あまり大きく見せないこと』

このようでありたい。

引用元の記事 金出武雄 自動運転の実現は、わたしに言わせれば 30年「も」かかってしまった

秘訣というほどのものではないですが、先ほど述べた魅力的な「ストーリー」を、一方的に押し付けるのではなく、さも説得される相手側が考えたように思わせる、ということですね。面白い「アイデア」に基づいた研究開発の「ストーリー」を伝えるとき、「なるほど、だとしたらこんなことができるかな」とか、「本当だろうか、話のこの部分に問題がある気がするが、こうしたらもっと良くなるんではないだろうか」といったふうに、相手に発想や提案をわき起こさせる。その時点で、わたしの「ストーリー」はわたしのものではなく、相手の「ストーリー」になります。こうなれば、ほぼ勝ちのようなものですよ（笑）

---

プロジェクトマネジャーが知るべき97のこと プロジェクトの失敗は組織の失敗

---

上司・経営幹部だけをみた開発の進め方をしてしまって、最終ユーザーへの視点が欠けた開発を組織運営で行ってしまう。
への対案

• プロダクト・オーナー（PO)という立場の人物を設定することです。そのことによって、最終ユーザーの視点が失われることを防止します。

**組織運営にコストモデルがない。**への対案

• すべての発言者の時間を制限しよう。
• 全ての参加者がポストイットにメモを書くことで、それぞれの参加者が何らかの意思表明をする。このことで、ある人が話している間、他の人がまったく意思表明ができなくなることを予防できる。
• ポストイットを一箇所に貼る前に、すべてのメンバーにまとまった時間を与えて、ポストイットを書ききるようにする。こうすることで、各人の考えの独立性が保たれる。

**成果物にならないドキュメンテーションのコスト。**への対案
-チームの内部でだけ使う資料で、その時だけしか使わないものを、Excelなどにまとめることはやめよう。

• ホワイトボードの写真をとれば十分だったりする。
• ポストイットを並べて貼って、写真をとるのもある。

**もしリーダーにこういう傾向が高ければやばいかもしれない。**への対策

マネジャーへ何を求めるのかという組織の考えを変えていければ良いのだが。
開発事例の中では、チームの構成メンバーがフラットな立場にあっても開発は機能していることがある。チームメンバーが互いに尊敬しあっている状況で、目的を理解し、透明性の高い状況では、従来型のリーダーというものは必ずしも必要ではないようだ。

---

追記：
Redmine と書いているところは今ならJIRAのサービスを使うという選択肢がある。