若手エンジニアを不幸にしないための開発の「べからず」集 組織運営編から記事を独立させました。
優秀な技術者ほど辞めてしまいやすいのは、多くの会社に共通していることです。
この文章では、どうして優秀な技術者が辞めていってしまうのか、その理由を探るとともに、そうならないようにするための対処方法を少しずつ書き足していきたいと思っています。
マネジャーのみなさんへの前書き
会社の資産であるソースコードはきちんと管理されてますか？
「きちんと金庫にしまってある」ではありません。
開発が進みやすく、今のソースコードはどのように品質が保たれているのかがわかるようになって
管理されてますか。
ソフトウェアの開発などで生じている課題は、どのように管理されていますか。
「去年の△月ごろに問題になっていたあの件は、結局どうなったのかい。」
「担当していた○○さんがだったら知っているんですけれども、もうやめちゃいましたのでちょっとわかりませんね。」
そのような状況を打破していくためには、ソースコードやドキュメントのバージョン管理・仕事の課題管理が必要です。
Git:ソースコード・ドキュメントのバージョン管理と関連する課題管理ができる。
Redmine:課題管理用のソフトウェア
SVN:ソースコード・ドキュメントのバージョン管理ソフトウェア
そうすれば、上の会話は
「Redmineであの件を調べてみました。○○さんが、△月△日の***のrevisionで解決していてくれてますね。そのときのテストでの検証結果は、××に残していてくれてますね。」と変わります。
このようにGit, Redmine、SVNなどを上手に使って、課題管理をうまくいくようにすることです。
開発すべき内容についての上流工程での要件定義を、開発できるレベルに落としこんで、現場のエンジニアに無理のないよう、ソフトウェアの開発手法を改善すれば、状況を緩和することができます。
今、プロジェクトを成功させようとするならば、あるいはシステムを持続していこうとするならば、優秀な技術者を追い出してしまう愚かな事態を避けなければなりません。
物事が深刻化する前に組織の課題を解決することです。
優秀な技術者を追い出してしまう方法
-
理不尽な待遇をする。
- 事例：優秀なエンジニアがロールチェンジを望まず、かといって行き止まりのキャリアパスを見ると、その組織に長くいる理由がなくなる。従って優秀な人で技術キャリアを追求したい人ほど組織から流出する
- 「企業側の人事部門が硬直化している。これから何をやりたいかを決めて、それに必要な人材は何か、そういう発想ではなく、年齢できってリストラする。これは一番簡単な方法。サボっている。」
- 例：3年かかる開発に対する評価。最初の１，２年はまだ３年目で達成する予定のことが達成できそうかわからないので、未達成扱い。３年目にその目的が達成できたときだけ、１００%の達成。そうすると３年間の平均の評価は未達成を含む評価になる。→ 割があわない。
- 例：あるときは「本社研の研究者といえども、その研究がグループのビジネスに寄与することが大切である。」、別なときは「ビジネスに直結するほど明確になった研究は事業部の研究開発部門に任せるべきである。」などとして振り回される研究者。
- 下記のコメントにあるような女性軽視。
-
技術者を尊重しない。
- 専門的な技術者に解析を頼む前に、きちんとしたバグレポートも上げずに解析を依頼する。専門的な技術者に成果を上げさせるためにリーダーができること
- 事例「君は優秀なんだから、プログラミングみたいな低俗なことは早く辞めて人を動かせるようになれ。私が引っぱりあげてやる」
- 事例 エンジニアを商品や物のように捉えている人がいる
- 日本独特のSE／PGの分業体制のもたらす不幸
- 事例 今までソフトウェアを軽視してゼネコン・スタイルで開発をして来たために、社内にはソフトウェアが自分で書けるエンジニアはほとんどおらず、自分でソフトウェアも書けないくせに、給料だけは高い「自称エンジニア」が仕様書だけ書いて下請けに丸投げしているのが現状だ。
- ライブラリを間違った使い方で不具合を生じたのに、△△さんの実装したライブラリに問題があるように周囲を誤解させたままにしておく。△△さんは、不名誉な誤解を受けたままにほっておかれる。
-
無理難題を押しつける。
- 正しくするよりも、速くするを優先することで無駄となる作業を作り出す。動くようにする、正しくする、速くする。
- 「こういう条件ではうまく動作しませんよ」とあらかじめ言ってあることを無視して、（必要性のない）無理な使い方をしてバグと責められる。
- 技術的な理解を深めようとしない。技術的な説明も拒否する。 ある人の言うこと：「幼稚園児にもわかるような説明をしなくてはいけません。絵で説明すること。式を使ってはいけません」
- ソフトウェアだけで改善できる部分には限界があることを理解しない。
- 例：ソフトウェアだけで計測装置の精度を上げる、音声認識の性能を上げる。
- 「ソフトウェア屋さんは何でもソフトウェア書けるんだろう」という無茶振り（下記のコメントにそれらしいのがある。）
-
不便な開発環境で作業させる。
- ネットワーク環境が不便。
- 開発者のPCが、事務作業者のPCと同じ。
- 例：モニタの数が足らない。開発作業マシンとメールの読み書きにはリブートして切り替える。
- 移植対象が貧弱すぎる。
-
マネジメントが劣っていて、技術者としての成長が見込めないと技術者に思わせてしまう。
- 適切なマネジメントができていない現場では、仕事の結果を出すことも、技術者として成長することもできません。
- 例「YRP 軍曹が携帯電話開発の現状を語る」の状況で、「私ならうまくやれる」という人はいるでしょうか。
- 適切なマネジメントができていない現場では、仕事の結果を出すことも、技術者として成長することもできません。
-
マネジメントが劣っていて、そのプロジェクトは成功しないと思わせてしまう。
- アルゴリズムを考えコードが書ける人が必要なときに、実務のできない管理者を増やす。
- その分野のその技術の製品をどう作るかについて勘の働かない人を、管理者にしてしまう。
- まとまった製品開発全体を経験していない人(しかも何を学ぶ必要があるのかを知ろうとしない人)を、開発の要職につける。
-
マネジメントが劣っていて、その設計・その開発のアプローチはないだろうと思わせてしまう。
- 開発内容に対する適切な要件定義ができていない。
- 品質に対する部門の意識が低下している。
- 事前に手順をふんでチェックすることが前工程で守られていない。
- 単体テストを軽視する。
- ソフトウェアの品質を確保するための設計の原則（例えばSOLID原則）を無視している開発を続けている。 (品質を確保するためには、ソースコードの設計のしかたが大事になってきているということです。そういった原則に従わないとちょっとの改変のたびに動かないプログラムになってしまいやすいということです。同じ処理をしているコードの断片が複数の関数の中に入っていると、一方だけ修正して、他方を修正し忘れることがあります。項目を１つ追加するとその変更が数箇所にわたって発生するようなコードよりは、１つの項目を追加しても、その変更は1箇所だけであり、他の処理の部分が壊れることがないような設計方法が求められています。)
-
優秀なマネージャーでも、分野が異なると適切なマネジメントは難しい。その分野のマネジメントには何が必要なのかを学ばなくてはなりません。
-
時代遅れの開発手法
- 事例：レガシーな開発手法がまかり通っていた マネジャーのみなさんは、その分野での最新の開発手法を知らないことがあるかと思います。若手に学んで最新の開発手法を取り入れていきましょう。
-
専門性の高い開発内容に対して、その分野の技術を理解していない人が過度に口出しして、せっかくの改良の計画を反映できなくしてしまう。
- 「もう私には面倒みきれない！」 専門性が高い開発分野で、一番詳しい人の見解を無視した開発を続けていると、その担当者はこういうしかありません。
山ほどの雑用で本来の開発時間が奪われる。
既に解決してある項目があるのに、それを本流のコードに反映させてもらえない。
道具として扱われているという印象を技術者に与えてしまう。
例：アルゴリズムの開発を外部に委託を出して、社内の技術者には、データの準備だけにさせてしまう。元々アルゴリズムの開発ができるだけの力量のある技術者を、アルゴリズムの開発から切り離してしまうことで、不満をつのらせてしまう。
例：開発の方向性を失敗しにくい方向に導くことのできる力量のある技術者を、開発の末端だけの仕事をさせて、それ以上のことをさせない。
例：とにかくクローズドな組織 いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない
例：このまま(何が言語の名前)erを続けていたら、いつか腐ってしまう外部委託ばかりで自社開発能力の低下をよぎなくされるシステム部門
システム開発を協力会社に外注している比率が高すぎると、ここでも技術者の不満がたまりやすくなります。ソフトウェア技術者としてのスキルの向上が実現できる仕組みを組織の運営として心がけておいてください。特にCOBOLのように過去のシステムと見られがちなシステムでは、技術者としての成長が実感できにくいという不満がたまりやすいと聞いています。-
基幹システム分野での取り残された開発スタイル
- 基幹システム分野（ときとしてレガシーシステム）と呼ばれる分野では、ソースコード・ドキュメントの管理、課題管理の分野で、20年以上も前のスタイルをとっていることがある。言語それ自体の特性よりも、コード・ドキュメントの管理、課題管理の分野のツールが不十分な職場もあり、そのことが技術者の不満をつのらせることがある。
-
古くからのシステムのメンテナンスよりは、まっさらなキャンバスに絵を描きたい。
- 基幹システム分野（ときとしてレガシーシステム）と呼ばれる分野では、新しい言語も新しいライブラリも、新しい手法も無関係になることが多いようです。そのためストレスを感じる人も少なからずいます。管理者にとっては、「優秀な技術者」と思っていない技術者でも、「新しい絵を描けない」ストレスのために、別な場所に異動を希望する人も出てきます。
-
技術的誠実さよりも「空気を読む」ことを要求する。
理不尽な扱いをされているときに、同僚が弁護しない。
不十分なバグレポートのまま、不具合解決を要望する。
ソフトウェアの開発では、バグも生じるだろう。
バグを報告する際のバージョン情報・どの条件で発生したのかを
きちんと確かめてから担当者に報告して欲しい。
「△△の関係で動作おかしいんだけど」と多数の人数の前で言っておきながら、
実際には、△△以前の処理で不具合を発生していたということがある。
しかし、「△△以前の処理で不具合を発生していた」という報告はえてしてされないから、
「△△の関係で問題がある」という間違った認識が部署内に残る。
そういったことを続けて過ぎていると、担当者の心に強く影響する。
「はたして、ここにいていいのだろうか」と。
うまくいくようにする方法を繰り返し伝えているのに無視され続ける
「この人たちは、本当に成功させようとする気がないんだ。
開発ごっこをしているだけなんだ。」そう思わせる行動を見せ続けられると
どうしようもなくなってしまう。「近いうちにメンテナンスが不能になるのでは」という心配を引き起こさせないこと。
-
「うまくいって当然、何かあれば減給」のような待遇にしないこと。
経営戦略の中での技術の軽視 日本の技術は負けていないという思考停止
会社を変えていくのは難しい。会社を換えるのはそれよりは簡単だ。
誰だって仕事で成功したい。
だから、その人なりのやり方で状況を改善しようとする。
しかし会社は変わらない。
1人の意識を変えるのでさえ簡単ではなく
ましてや、大勢の人の意識を変えるのは簡単ではない。
あなたの言葉で気づいてくれるような人ならば、
自分自身で気づいてくるような人だろう。
とにかく、理不尽なやり方をすれば、優秀な技術者は、その組織に見切りをつけて、別の場所で働くようになってしまいます。優秀な技術者を追い出したいなら、上に書いた仕組みを採用することです。
最初に逃げ出すのは優秀なプログラマかもしれない スライドの8ページ目
- 優秀な技術者が嫌うこと
- 技術的に無意味なことを押し付けられて作業し続けること。
- 職場の同僚に
技術者を追い出すツケ
- 優秀な技術者が抜けることで、開発効率・開発品質は低下します。
- 技術者が辞めた根本原因をそのままにしているのを見た別の技術者は、組織に幻滅します。
- 負担が集中することで、別の技術者も辞めたくなります。
- 組織運営がうまくいっていないときは、「優秀な方の技術者」が辞めるようになり、さらに加速することが起こります。 引用 > 今問題になっている連鎖退職というのは、プロジェクトチームがゴソッと一体で辞めるというよりも、ハイパフォーマーや中核的人物が辞めたとき、その社員に対し会社は何のフォローもしなかった、自分も頑張ったところで結局その程度の扱いなのか、と負の空気感が周囲に蔓延してしまうこと。
負の連鎖が大きくなっていき、やがて組織が崩壊することも起こりえます。
対処方法
マネジャー層がエンジニアから学べば改善できること
- Git, Redmine, SVN などツールの導入を認めてあげてください。 そうすれば、現場のエンジニアがどう導入すればよいのか工夫を進めていきます。
-
不便な開発環境を改善する。
- 開発環境を改善すれば、それにかかった費用以上の成果を出してくれることが多いものです。(例：モニタをケチらない）
- 常に暗号化したUSBメモリ・USBハードディスクを使えば十分なのに、USBメモリ・USBハードディスク自体の使用を禁止することをなくしてください。
- ネットワークストレージに遅すぎる・不便すぎる業者のサービスを利用するのではなく、開発者の扱うデータ量にふさわしいサービスを選んでください。
新しい開発手法のチーム内の勉強会などを許可してやってください。
マネジャー自体が直接判断する必要性はあまりないかもしれません。
その部署のチーム内で複数のメンバーがそれをどう評価するかです。
マネジャー自体が判断するのは、そのあとで十分でしょう。-
論理的に考えれば自明なことに、過度のテスト作業を要求しない。
「（○○社では）SEではなくプログラマが技術を重視して仕事をしており、理系のエース級も集まってきつつありますので、世界に通用する勝負ができる会社なのです。」
ベンチャー企業の経営危機データベース ～83社に学ぶつまずきの教訓～
ビジネスを成功させるとは、どういう失敗をしやすくて、それらの失敗をどう回避したらいいのかを考えることです。-
マネージャーもエンジニアも、今の課題を解決するためには学び考え抜く必要がある。
- 「エンジニアがどう考えていようが、私にはその開発を成功させる力がある。」と思っていたら、それは傲慢な考えです。
-
「エージェントを使って求人をかければ補充できるから」という考えは捨てるべきです。
- 新入のベテラン技術者もすぐに辞めたくなる。
- 優秀なベテラン技術者は、開発を成功させるためには、チームとしての協力が必要であることを知っています。また仕事の進め方についての職場のルールなどが重要であることも知っています。リーダーがどのような考え方をしているのかによって成果のあげやすさが大切であることも知っています。優秀なベテランであればあるほど、組織の問題点に気づきやすいのです。１周間も立たないうちにその組織の問題点に気づいてしまい、「しまった。ここに入るべきではなかった。」となります。そうすると、職場の課題を解決しないまま放置しておくと、辞めてしまうの時間の問題となりかねません。
- 「会社で活躍する人が辞めないしくみ」
- 新入のベテラン技術者もすぐに辞めたくなる。
優秀な技術者がやめそうなときの傾向
- このやり方は間違っていると遠慮もなしに大きな声で話している。それを聞いているはずのリーダーや、担当の技術の人は、プライドの高さのためか、その声を無視しつけてしまう。リーダーや該当の担当者がどうしたら間違っているやり方を変えられるのか、担当者が苦労している部分を伝えることをすれば、その優秀な技術者が辞めることは減るだろう。
- 提案をしているのにもかかわらず、リーダーがその提案を放置し続けている。
- もう何も言わなくなる。そのプロジェクトを改善しようとすることを断念してしまった可能性が高い。リーダーの方針を受け入れたのではないことに注意してください。リーダーの方針を受けいれたのであれば、実際作業を生じる中でさらにやり取りを生じていているはずです。
- 急に退社時間が早くなる。相当事態は進展してしまっている可能性があります。
- その技術者が指摘している課題について解決する方向に進展しているときは、少しでも早くそのことを伝えるべきです。そのことによって、思いとどまる可能性があります。
自分をダメにするやり方を続けるわけにはいかない
- 適切じゃないやり方を他のメンバーがしていることを我慢できたとしても、自分自身が間違ったやり方を強制させ続けられることには耐えられない。
- 自分自身をダメにするやり方を排除してきたからこそ優秀な技術者になりえている。
- 一時的な金銭的な損得以上のもので判断する傾向がある。（もちろん、一時的な金銭的な損得を重視してもよいのだが。）
開発対象の課題を成功するものに変えるための視点
-
この文章の作者は、課題分析の際の取り組むときの視点の置き方で、解決がしやすくなると主張します。
マネジャー層がエンジニアから話を聞くべきこと
- 優秀なエンジニアが続けざまに辞めていく職場でありがちなことは、エンジニアの話をマネジャーが聞こうとしないことです。
- 相手の話を理解しようとしているのか、聞いたふりでほったらかしにしているのかで、エンジニアにとっての受けとめ方も代わります。
- プロジェクトが成功するために必要な項目が、その分野に詳しい人を抜きで決めることをしすぎていると、面倒みきれない。
マネジメントが劣っているとは、マネジャーの方々には認めたくないことだと思います。
「20年間の上司はこういうやり方をしてうまくやっていたんだ。」というのはそうかもしれません。
しかし、それは、Open Sourceやインターネットが世界のやり方を変える前の時代のものです。
ですから、今の現場の開発を経てきた人たちの意見をまずは聞いてみてください。
プロジェクトの目標設定や進め方を見直してみよう
以下の文章は、ものごとを成功しやすい状況にしていくためにできることを書いてみました。ヒントになるものがあれば幸いです。
技術者としての自分は、いったい何がしたいのか？
舛岡富士雄・東北大学名誉教授 最初に外国が評価して 後から日本人が気づくようでは遅い
日本の技術者が中国に行くという話も聞きますが、日本に残って技術を評価してもらえず、技術を生かす場所がないなら、中国に行って精一杯やればいいんです。技術者も食べなければいけない。中国で技術を評価してもらえれば技術者は嬉しいし、それでご飯を食べればいいんですよ。残念ながら、その根っこにあるのは、日本で技術を評価できないことです。
水野博之 氏企業はビークル（乗り物）だ
会社というのはビークル（乗り物）だと思う。自分は、会社に奉仕するためにあるのじゃなく、自分を磨くために会社はある。
大企業に入って、自分の好きな、一生の仕事とするに足るものが見つかればよい。会社も自分もそれで成長する。
しかし、見つからず、気に入らないなら乗り換えるしかない。
実情に合った有効なアイデアは、いつも現場から出てくるもの。そして、優秀な人材ほど結果で返してきます。そのためにも、自分で決断できる自由度がなければ、なかなか「いい仕事」はできません。
社員の意見に耳を貸さない企業は、従業員にとってすぐに分かる。上司が自分の意見に興味がないと直感的に感じれば、他の仕事を探す以外の選択肢はないだろう。社員の存在や考えを評価しない組織で働くことはできないし、そんな組織で働くべきではない。
「若手の優秀なエンジニアが、この一年で3人辞めてしまいました。来月もまた一人やめる予定です。いったい、どこに問題があるのでしょうか。」
あるSIerの経営者からこんな話を聞いた。僭越ながら、私は次のように答えた。
「楽しくないからじゃないですか？」
注意：この文章の目的は、転職を推奨するものではありません。ご自分の人生をどのように歩まれるかは、ご本人が自分の判断でなさってください。予想外に「いいね」の数が伸びたため不安になり、この注意を書きました。