開発プロセス
アンチパターン
ソフトウェア開発

「優秀な技術者を追い出してしまう方法」再考

1年以上前に「優秀な技術者を追い出してしまう方法」を書いた。

それに対して、今の時点での私が思うことを書き足そうと思う。

この例の中で書かれているマネージャーとは違うタイプのマネージャーが最近登場してきている。

サーバントリーダーシップという考え方。

旧来の組織だと、「マネージャが偉く全てはマネジャの判断に従え」というタイプのマネジメントが多い。
最近の組織だと、サーヴァントリーダーシップという考え方での組織運営を心がけるところが出始めてきている。今チームの中で抱えている問題を解決するために、「信頼関係を重視しており、部下の話に耳を傾け、協力しながら目標を達成していきます。」

組織運営はどう進化できるか

企業ごとに抱える課題は違います。抱える課題の経営へのインパクトの度合いも違います。
ですから、そのような中で、問題を解決するのに効果的な運営のしかたを考え続けなければなりません。

従来の組織運営の多くは、リーダーが判断を間違わないということを前提にしたものであり、特定のリーダーにそのチームの運営を一任するものです。
「完全な知識という誤った考えは、ソフトウェアプロジェクトのための完全で矛盾のない要求が獲得できるという妄想のことです。」(プロジェクト・マネジャーが知るべき97のこと から引用)とあるのであれば、「常に最適な判断をし続けるリーダー」というのも、実現することのない妄想と考えるべきなのでしょう。

アジャイル、 スクラム、 サーバントリーダーシップなどは、そのような従来型の組織運営に対する別の試みなのだと思います。

プレイングマネジャーとして技術的な判断も、組織運営のさまざまな要因も同時にすべて開発できる極めて優秀な人物の存在を仮定することをやめようとするものでもあるでしょう。

アジャイル・スクラムの手法が、ソフトウェア開発の分野だけに限るものなのか、それとも別の分野でも有効なものなのか興味深いところです。次のような事例が書かれていました。

アジャイル・スクラムで公共施設の運営を立て直す

一方で次のような指摘もあります。
[翻訳] スクラムがアジア圏でうまくいかない4つの理由 - Scrum does not work here in Asia

作業の進めた方をウォータフォール型ではなく、スクラム (ソフトウェア開発)をする組織も増えてきている。

「1年の目標を個人ごとに決めて管理する成果主義」が硬直化した組織運営に落ちいったりしている。1年間の目標設定のとおりに、目標やプランの修正なしに、1年間の業務が遂行できることを前提とした評価制度になっていたりする。しかも、解決すべき課題をチームで動的に分業協力して解決していくことに対して、成果主義が適切に機能するものだろうか。

その一方で、属人性を排除し誰でもが問題を解決できるようなやり方が推奨される組織もある。

フラットな組織と、face-to-faceのコミュニケーションを大事にする組織が増えてきている。

フラットな組織運営では、自発的に必要な人とコミュニケーションをとっていくことが大切。文字によるコミュニケーションでは、表情や音声のトーンがないため、face-to-faceの小ミューにケーションには及ばない。相手の様子を確かめつつ話していくこともできない。だからface-to-faceのコミュニケーションを大事にしよう。

 大部屋でパーティションを切らないようにしたからといって、face-to-faceのコミュニケーションは発生しない。face-to-faceのコミュニケーションを生じさせるきっかけが必要だ。

 リフレッシュエリアの配置ひとつでも、社員同士のコミュニケーションの頻度は変わる。

 会社の中で知り合っただけの人間同士を、見つけた課題を自発的に協力して解決していく人間関係に育て上げる方策が必要なのです。

硬直した組織の場合、その人が話をしていいのは、どの範囲の人だけ、勝手にそれ以外の部署と話をしないようにとなっていることさえある。会社の中の部屋がさらにセキュリティシステムで分割されていると、人と人の交流は著しく低下する。そのことによって、アイディアが別な分野に波及する力をその組織は失ってしまうのです。

slackのようなコミュニケーションツールによる変化

50人規模の部門にSlackを導入してみた結果

ピンポイントの求人活動で高い給与を出す企業も増えつつある。

■学士卒:月給40.1万円(月45時間分、103,351円の固定残業代含。45時間を超える時間外労働は追加で支給。)

という好条件を出す企業も出てきている。
問題は、それが、一部の外資系企業だということだ。

修士の学生でもピンポイントに自分の得意分野を攻める求人活動をしている場合が増えつつある。

せっかくのその分野で伸びゆく若手の研究者・開発者が、大企業の採用活動の中では、なかなか希望の部署に配属にならず、その力を出せなくなってしまうというもったいない状況を生じることがあった。
その分野に詳しい若手に対して、十分に発言させることもなく、その見解を力で封じ込んでしまう運営がなされて、その人の力を発揮できないというリスクを持つことがある。しかも、賃金が抑制気味であったりするので、将来賃金が上昇することを期待できないという状況も生じている。
こういった中で、ほんとうに力のある学生は、その技術に秀でていて伸びている会社を見抜くようになってきている。今自分ややりたいことで、伸びていく技術分野で力をつける人が増えているきざしがある。

そういったこともあるから、その時代が求めているまさにその技術に習得している人には、特別枠を設ける企業が出つつある。

優秀な結果を出し続ける人は、年齢に関係なく結果を出し続ける。

学び続ける人は年齢に関係なく学び続ける。

新しいツール、ライブラリ、言語、設計の考え方など、学び続ける人は年齢に関係なく学び続ける。
そうすることで、新しい価値を引き出し続ける。

どうやったら失敗し、どうやったら成功にたどりつけるのかを意識する。そういう人が活躍できる場所にできていれば、優秀な技術者を追い出してしまうことは減らせるだろう。

最新の技術を学び続ける組織運営をすること

深層学習やビッグデータを実務で活用にするには、業務知識が必要だ。

「AI開発ソフトを導入しても、業務で使いこなせなければ意味がない。例えば、外部に任せても、委託先を管理したり、システム構築をしたりするのにさえAIの知識は欠かせない。」などという意見は、AIを理解しない導入者側を問題点としているようにうつる。しかし、実際には「なにができると業務上うれしいのかを見抜くこと」と「今の時点の不完全な機械学習技術でできることの中で、価値のある結果をだせる範囲を見ぬくこと」、「そしてその不完全な状況から限られた予算の中で改善していくか」という業務知識の側の重要性が高い。

課題を解決するための柔軟な組織にし続けていれば、最新の技術を学び続けることができる。

コードの品質を見て採用につなげることが増えてきている。

プログラミングスキルチェックツール などのキーワードを検索してみれば、そのような現場が増えてきていることがわかるだろう。

進展を目に見える形で共有することが、組織の一人ひとりのモチベーション(熱意)を維持するのにつながる。

事業を成功させるための進展があったら、それを一緒に喜びましょう。「おおー、うちらの中では、これだけすごいことをやっているんだ!」という感動は、開発者だけのものではありません。総務部門の人にとっても感動するものがあったりします。そのような喜びを共有して、喜んでもらえることが開発者の力になっていきます。


提案:新しい開発手法を少しづつ導入していってみましょう。

SVNではなく、gitを少しづつ導入してみましょう。

あるいは、少しづつのgitの使用を許してみましょう。

  • プロダクトの全体をSVNからgitに一度に移行するのは危険です。
  • 独立性の高いプロトタイピングのコードや、モージュルなどをgitに移行して使い方をなれてみること始めましょう。
  • gitの考え方になれる必要があります。
  • 少しづつgitの考え方に慣れていくことで、同一のリポジトリに対して異なる変更の開発を同時に進めやすくなります。

qiita 職人エンジニアのチームにGitを導入した時の工夫と反省
qiita 新入社員による新入社員のためのGit

書籍わかばちゃんと学ぶ Git使い方入門

ビルドと自動化テストは自動化できるサービスを利用することです。

  • 開発者個人の負担を減らすことが、開発速度を維持することと、品質の確保につながります。

qiita CircleCIで出来るコト

古い言語でも、単体テストの自動化をすることは、可能だったりします。

アジャイル手法を一部の運営に導入してみる。

ハードウェアチーム、ソフトウェアチーム(全体)、ソフトウェアチーム(モジュールA)などといったときに、アジャイルな開発手法が試行できそうな一部のチームに、アジャイルな開発手法を導入してみてはどうだろうか。
 アジャイルな開発手法についてのセミナーなどがあるから、それらを受講してみることだ。
 試行してみるチームの範囲でアジャイルな開発手法がどのようなものかを経験していないと、アジャイルな開発手法を理解しないまま、「使えなんじゃない」という結論に達しやすいだろう。

アジャイルな開発スタイルも「銀の弾」ではない。アジャイルな開発手法を採用したからといって、すべてが解決するわけではないことを承知しよう。

注:アジャイルという表現よりは、スクラムという表現を用いた方がいいらしいことを最近知った。

「進捗どうですか?」より2015倍捗る「困ってますか?」

些細(ささい)なことだが、聞き方しだいで、その後の状況が変わってきます。

リーダーの仕事は問い詰めることではありません。困っていることを解決する力になることです。


付記:

ありもしないことを仮定して、「あってほしくないことは起こらない」と夢想するのは、組織を自滅に陥れます。「あってほしくないことは起こらない」という希望的観測にすべてを委ねるということは、組織を構成する大多数の人の利害に反することです。アジャイル・スクラムの組織運営がなされていくと、そのようなリスクに対して目を見開いて取り組まれるのではないかと期待しています。

--
日本の組織は、「あってほしくないことは起こらない」という希望的観測にすべてを委ねることがありすぎる。

http://www.pita.co.jp/woodpita/blog/672.html

私たちも、記憶の新しい阪神・淡路大震災、東日本大震災を目の当たりにしていますが
「自分が生きているうちに地震はこないかもしれない」
「見たくないものは見ない」
「考えたくないものは考えない」
と人間の困った法則(「天災と国防」畑村洋太郎解説)により、
私たちは記憶の中から、心の中から忘れ去ろう、消し去ろうとしていませんか?