#1年以上前に「優秀な技術者を追い出してしまう方法」を書いた。
それに対して、今の時点での私が思うことを書き足そうと思う。
この例の中で書かれているマネージャーとは違うタイプのマネージャーが最近登場してきている。
サーバントリーダーシップという考え方。
旧来の組織だと、「マネージャが偉く全てはマネジャの判断に従え」というタイプのマネジメントが多い。
最近の組織だと、サーヴァントリーダーシップという考え方での組織運営を心がけるところが出始めてきている。今チームの中で抱えている問題を解決するために、「信頼関係を重視しており、部下の話に耳を傾け、協力しながら目標を達成していきます。」
蓋然性が低い中での意思決定
合理的な意思決定をしようと思っても、必要な情報が集まってない時点で意思決定しないと、すでに負けているみたいなことっていうのはあって。
情報が全部集まったら、そりゃ数理的に統計的になんらかの方法で答えは出るけれども、蓋然性がかなり低い中で意思決定をしなきゃいけない。なにもわからないけど意思決定しなきゃいけないという、不可欠なものに対する耐性、耐える強さみたいところがどんどん問われるようになってきて。
組織運営はどう進化できるか
企業ごとに抱える課題は違います。抱える課題の経営へのインパクトの度合いも違います。
ですから、そのような中で、問題を解決するのに効果的な運営のしかたを考え続けなければなりません。
従来の組織運営の多くは、リーダーが判断を間違わないということを前提にしたものであり、特定のリーダーにそのチームの運営を一任するものです。
「完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。」(プロジェクト・マネジャーが知るべき97のこと から引用)とあるのであれば、「常に最適な判断をし続けるリーダー」というのも、実現することのない妄想と考えるべきなのでしょう。
アジャイル、 スクラム、 サーバントリーダーシップなどは、そのような従来型の組織運営に対する別の試みなのだと思います。
プレイングマネジャーとして技術的な判断も、組織運営のさまざまな要因も同時にすべて開発できる極めて優秀な人物の存在を仮定することをやめようとするものでもあるでしょう。
アジャイル・スクラムの手法が、ソフトウェア開発の分野だけに限るものなのか、それとも別の分野でも有効なものなのか興味深いところです。次のような事例が書かれていました。
一方で次のような指摘もあります。
[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia
１： すべてのものに階層を
2： 調和を維持しよう
3: 異なる教育システム、異なる思想
4: アウトーソシング - すべてはコスト削減のために
作業の進めた方をウォータフォール型ではなく、スクラム (ソフトウェア開発)をする組織も増えてきている。
「1年の目標を個人ごとに決めて管理する成果主義」が硬直化した組織運営に落ちいったりしている。１年間の目標設定のとおりに、目標やプランの修正なしに、１年間の業務が遂行できることを前提とした評価制度になっていたりする。しかも、解決すべき課題をチームで動的に分業協力して解決していくことに対して、成果主義が適切に機能するものだろうか。
その一方で、属人性を排除し誰でもが問題を解決できるようなやり方が推奨される組織もある。
「ミニマムな仮説検証を繰り返して精度を上げる」組織の例
このような事例がある。
クックパッドが新サービスのリリースまでに捨てた10のこと ミニマムな仮説検証を繰り返して精度を上げる
リリースまでに捨てた10のこと - Speaker Deck
「まとめ：
ミニマムな検証を繰り返し、仮説の角度をあげていくことでリリースしたサービスのかたちに至った
・筋の悪い仮説はさっさと捨てる
・実現スピードが落ちそうな理想は一旦捨てる
・検証を終えたプロトタイプは潔く捨てる」
フラットな組織と、face-to-faceのコミュニケーションを大事にする組織が増えてきている。
フラットな組織運営では、自発的に必要な人とコミュニケーションをとっていくことが大切。文字によるコミュニケーションでは、表情や音声のトーンがないため、face-to-faceの小ミューにケーションには及ばない。相手の様子を確かめつつ話していくこともできない。だからface-to-faceのコミュニケーションを大事にしよう。
大部屋でパーティションを切らないようにしたからといって、face-to-faceのコミュニケーションは発生しない。face-to-faceのコミュニケーションを生じさせるきっかけが必要だ。
リフレッシュエリアの配置ひとつでも、社員同士のコミュニケーションの頻度は変わる。
会社の中で知り合っただけの人間同士を、見つけた課題を自発的に協力して解決していく人間関係に育て上げる方策が必要なのです。
硬直した組織の場合、その人が話をしていいのは、どの範囲の人だけ、勝手にそれ以外の部署と話をしないようにとなっていることさえある。会社の中の部屋がさらにセキュリティシステムで分割されていると、人と人の交流は著しく低下する。そのことによって、アイディアが別な分野に波及する力をその組織は失ってしまうのです。
アイディアにあふれる人であっても、そのアイディアを実現するための時間は限られています。そのアイディアを、別な人が実現できるようにするためには、人と人との交流が重要なのです。
slackのようなコミュニケーションツールによる変化
ピンポイントの求人活動で高い給与を出す企業も増えつつある。
■学士卒：月給40.1万円（月45時間分、103,351円の固定残業代含。45時間を超える時間外労働は追加で支給。)
という好条件を出す企業も出てきている。
問題は、それが、一部の外資系企業だということだ。
修士の学生でもピンポイントに自分の得意分野を攻める求人活動をしている場合が増えつつある。
せっかくのその分野で伸びゆく若手の研究者・開発者が、大企業の採用活動の中では、なかなか希望の部署に配属にならず、その力を出せなくなってしまうというもったいない状況を生じることがあった。
その分野に詳しい若手に対して、十分に発言させることもなく、その見解を力で封じ込んでしまう運営がなされて、その人の力を発揮できないというリスクを持つことがある。しかも、賃金が抑制気味であったりするので、将来賃金が上昇することを期待できないという状況も生じている。
こういった中で、ほんとうに力のある学生は、その技術に秀でていて伸びている会社を見抜くようになってきている。今自分ややりたいことで、伸びていく技術分野で力をつける人が増えているきざしがある。
そういったこともあるから、その時代が求めているまさにその技術に習得している人には、特別枠を設ける企業が出つつある。
大学教員として30年以上の経験のなかで，この10年間に，学生の意識がずいぶん変わったと感じる．かつては
優秀な卒業生の多くが安定した大企業に就職していたが，最近はベンチャー志向も強くなってきている．大企業や
官庁などに就職して活躍している人が新分野にチャレンジするため転職するケースも増えてきた。（ 東京大学 五神真総長 https://www.u-tokyo.ac.jp/content/400103184.pdf)
私としては推奨したいこと：
伸びていく技術分野で、刺激的な組織に身をおくことを勧めたい。
産業構造が世界的な競争の中で変化し続けている時代において、大学卒業時に選択した職種で、その後数十年にわたって仕事をし続けることは難しいと思う。大企業に所属したってそうだと思う。あなた自身が変化し続けて世の中で役に立つ何かをし続けることが大切だと思う。
全力をつくしても、ある開発に成功しなかったということも起こるだろう。でも伸びていく技術分野で全力をつくすことは、次の挑戦への貴重な糧にすることができるはずだ。
優秀な結果を出し続ける人は、年齢に関係なく結果を出し続ける。
学び続ける人は年齢に関係なく学び続ける。
新しいツール、ライブラリ、言語、設計の考え方など、学び続ける人は年齢に関係なく学び続ける。
そうすることで、新しい価値を引き出し続ける。
どうやったら失敗し、どうやったら成功にたどりつけるのかを意識する。そういう人が活躍できる場所にできていれば、優秀な技術者を追い出してしまうことは減らせるだろう。
最新の技術を学び続ける組織運営をすること
深層学習やビッグデータを実務で活用にするには、業務知識が必要だ。
ソフトウェアを適切に疑うことができない人には、ソフトウェアシステムの管理ができない。
「AI開発ソフトを導入しても、業務で使いこなせなければ意味がない。例えば、外部に任せても、委託先を管理したり、システム構築をしたりするのにさえAIの知識は欠かせない。」などという意見は、AIを理解しない導入者側を問題点としているようにうつる。しかし、実際には「なにができると業務上うれしいのかを見抜くこと」と「今の時点の不完全な機械学習技術でできることの中で、価値のある結果をだせる範囲を見ぬくこと」、「そしてその不完全な状況から限られた予算の中で改善していくか」という業務知識の側の重要性が高い。
課題を解決するための柔軟な組織にし続けていれば、最新の技術を学び続けることができる。
コードの品質を見て採用につなげることが増えてきている。
プログラミングスキルチェックツール などのキーワードを検索してみれば、そのような現場が増えてきていることがわかるだろう。
進展を目に見える形で共有することが、組織の一人ひとりのモチベーション（熱意）を維持するのにつながる。
事業を成功させるための進展があったら、それを一緒に喜びましょう。「おおー、うちらの中では、これだけすごいことをやっているんだ！」という感動は、開発者だけのものではありません。総務部門の人にとっても感動するものがあったりします。そのような喜びを共有して、喜んでもらえることが開発者の力になっていきます。
提案：新しい開発手法を少しづつ導入していってみましょう。
SVNではなく、gitを少しづつ導入してみましょう。
あるいは、少しづつのgitの使用を許してみましょう。
- プロダクトの全体をSVNからgitに一度に移行するのは危険です。
- 独立性の高いプロトタイピングのコードや、モージュルなどをgitに移行して使い方をなれてみること始めましょう。
- gitの考え方になれる必要があります。
- 少しづつgitの考え方に慣れていくことで、同一のリポジトリに対して異なる変更の開発を同時に進めやすくなります。
- 「会社がgitを使ってくれない？」 ますは、プライベートの開発でGithub やBitBucketを使って見ましょう。
qiita 職人エンジニアのチームにGitを導入した時の工夫と反省
qiita 新入社員による新入社員のためのGit
ビルドと自動化テストは自動化できるサービスを利用することです。
- 開発者個人の負担を減らすことが、開発速度を維持することと、品質の確保につながります。
qiita CircleCIで出来るコト
古い言語でも、単体テストの自動化をすることは、可能だったりします。
アジャイル手法を一部の運営に導入してみる。
ハードウェアチーム、ソフトウェアチーム（全体）、ソフトウェアチーム（モジュールA)などといったときに、アジャイルな開発手法が試行できそうな一部のチームに、アジャイルな開発手法を導入してみてはどうだろうか。
アジャイルな開発手法についてのセミナーなどがあるから、それらを受講してみることだ。
試行してみるチームの範囲でアジャイルな開発手法がどのようなものかを経験していないと、アジャイルな開発手法を理解しないまま、「使えなんじゃない」という結論に達しやすいだろう。
アジャイルな開発スタイルも「銀の弾」ではない。アジャイルな開発手法を採用したからといって、すべてが解決するわけではないことを承知しよう。
注：アジャイルという表現よりは、スクラムという表現を用いた方がいいらしいことを最近知った。
「進捗どうですか？」より2015倍捗る「困ってますか？」
些細（ささい）なことだが、聞き方しだいで、その後の状況が変わってきます。
リーダーの仕事は問い詰めることではありません。困っていることを解決する力になることです。
優秀な人はまわりの人を優秀にすることができる
- 会社の中で勉強会をできるように組織的に応援することです。
- ペアプログラミングで、優秀な人のプログラムの書き方をまわりの人が学べるようにすることです。
- qiita などの技術情報サイトにノウハウを共有化することを活用するのがいい。
- 会社の制度でできないことがあっても、できる範囲から応援することです。
- 優秀な同僚から学べる人は成長していきます。
付記：
ありもしないことを仮定して、「あってほしくないことは起こらない」と夢想するのは、組織を自滅に陥れます。「あってほしくないことは起こらない」という希望的観測にすべてを委ねるということは、組織を構成する大多数の人の利害に反することです。アジャイル・スクラムの組織運営がなされていくと、そのようなリスクに対して目を見開いて取り組まれるのではないかと期待しています。
--
日本の組織は、「あってほしくないことは起こらない」という希望的観測にすべてを委ねることがありすぎる。
私たちも、記憶の新しい阪神・淡路大震災、東日本大震災を目の当たりにしていますが
「自分が生きているうちに地震はこないかもしれない」
「見たくないものは見ない」
「考えたくないものは考えない」
と人間の困った法則（「天災と国防」畑村洋太郎解説）により、
私たちは記憶の中から、心の中から忘れ去ろう、消し去ろうとしていませんか？
技術者を大切にしない日本企業
1０年先どころか３年先も見通せないほど、多くの製造業は変化の激しい時代に直面しているということだ。
となると、早期退職募集というのは逆に恐ろしい負の効果を発揮することになる。たとえば貴重な技術を持ち、中国や韓国の新興メーカーから高額オファーをもらいつつも転職をためらっている優秀なエンジニアに対し「２年分の年収を退職金に上乗せするから、頑張って転職してごらん」と背中を押してやるようなものだからだ。
技術職と一般事務職の給与を比べてみると 2007/12/10
技術職と営業職で求められる能力や平均年収の比較 2018年02月08日(木) 更新
「技術職の平均年収」を（2014年データ）を年代別にご紹介します。
20代 333万円、30代 440万円、40代 538万円、50代 570万円
技術職の全国平均年収は435万円となっています。
続いて「営業職の平均年収」を（2014年データ）を年代別にご紹介します。
20代 382万円、30代 489万円、40代 630万円、50代 755万円
営業職の全国平均年収は474万円となっています。
出典の独自データがどのようなものかはわかりませんが、技術職の軽視が今の日本社会で続いていることになります。
米国も日本と同様に加齢とともに給与は高くなるが, 若年技術者の給与が日本の 1.7 倍であるのに
対して 41 歳以上は 0.85 倍になることから, 年齢格差は日本より小さいといえよう｡ 本人への報酬
が給与として個人の収入という形で現れる米国に対して, 日本は研究費, 権限, 仕事の内容と業務
にかかわる厚遇という形で現れている。
追い出してしまった側の視点でみたらどうなのだろう。
- 問題の設定が悪くて失敗しているのか、担当者が無能で失敗しているのかの区別がつかない。
- 担当者が「自分が無能だから失敗している」ということはまずないから、人は担当者の発言を疑って話をしまいがちになる。
- 担当者は、自分の発言内容を疑ったような言動をされることで落胆する。実は一応聞いてみるだけであって、そこまで疑っていないのかもしれない。人によっては、一度目は必ずだめといって、それでもそうじゃないと言い返してくるのだけ採用するなどという変わった流儀を採用しているかもしれない。
- 今まで自分が開発してきた範囲と、今自分が開発のマネジメントを任されている部分の難しさの区別がつかない。
- 学び続けること、技術者としての勘を磨き続けることをしていない場合には、今任されている範囲の技術的な難しさと、それを回避する手法がわからない。
- 現象は桁が１桁変わると、やり方を変えなければならないことが増えてくる。にもかかわらず、そのことに気づかないマネジメントをしてしまう。ソースコードの同時開発も、５人で行う場合と、５０名で行う場合では状況が変わってくる。SVNでは同時開発する人数が増えてくると管理が困難になってくる。gitのbranchの場合には、まだ格段に扱いやすい（すくなくともSVNよりは)。
- 従来の製品と変更点が１割以下の設計での開発の場合と、新規の要素が７割以上の設計と開発では、同じ流儀では開発を管理できない。
- にもかかわらず、従来の製品と変更点が１割以下の設計での開発の経験で、その手法を無理やり、新規の要素が７割以上の設計と開発に当てはめてしまうしかない。
- そこに問題があることに気づかないままに開発を続けてしまう。
- 生意気なことを言っている個人よりは、組織として行動している人たちのことのほうがよっぽど信用がおける。
- 協調性があって評価されてチームのリーダーとして選ばれた人は、生意気なことをいう個人を理解できない。
- 新しい技術は、少数の人が明確な指導原理をもって開発することがある。その場合、その指導原理はときとして生意気である。
- 「やれと言っていることをできない言ってくる根性なしよりも、頑張ってみますと言ってくるヤツのほうがよほど期待できる。」
- 一部の根性主義は、物事の解決を遅らせる方向に働いてしまうことが多い。
- 知恵や工夫のない流儀であってはならない。
- 組織の上の人物の主張していることを否定する人間は、人間的にできていない。そんな人物の言うことなど当てになるわけがない。
- 従来型の組織の秩序を重んじる立場だと、メンツを潰されるやり方は、中身がどんなに正しくても受け入れることはできない。
- メンツをつぶしにくいかたちで伝えることも考えたほうがいい。
- その組織の中で誰に伝えるのであれば、誰ならばわかってもらいやすいのか、組織を分析して当たらねば成功の確率は低くなってしまう。
- 次の記事にあるように、「その組織の健康状態が、内部に渦巻く悪いエネルギーに注意を喚起した人物が追い出されるほどまでに悪化していた」という兆候があるかどうか、自分の属する組織を冷静に観察してみよう。
追い出したわけでなくても出て行く場合
優秀な人が出て行く場合としては、追い出されたわけじゃなくても出て行く場合があると述べておかなくては、公平性が保たれません。
そこで、追い出したわけでなくても、新しい場所に向けて活躍の場を変える人がいます。
- 新しいことを作り出す経験をしてしまった人は、その延長の中で仕事をすることよりも、また別のもので新しいものを作り出さずにはいられないということもあるようだ。
- この場合には、在籍していた企業に問題はない。