チーム作り

若手技術者とBPの成長を阻害する雑魚濃縮という現象

概要

  • 若手やBPが成長しづらい現象について解説
  • どうすれば成長を促進できるかの提案

「手順書ありますか?」「参考はありますか?」が口癖になってない?

手順書やマニュアルの必要性を否定するわけではないのです。
手順書自体は「作業を誰でもできるようにする」「品質を一定化する」などの多くの価値を提供してくれるものです。

しかし、これがシステム開発の現場になると意味が変わってきます。

若手のエンジニアや、協力会社(BP)という人売りビジネスの沼にハマった人たちは「開発」という本来クリエイティブな現場でこんなことは言ってきます。

若手技術者とBPの成長を阻害する雑魚濃縮という現象
若手男性

この作業、手順書はありますか?

若手技術者とBPの成長を阻害する雑魚濃縮という現象
若手男性

このドキュメント、参考はありますか?

この発言の重大な問題は「自分は何も考えない、貰った型の穴埋めしかできません」と言っているのと同義という点です。
開発環境を構築するための手順書や、開発標準的なものはマニュアルが必要だと思います。
しかしこの発言は「開発工程の中で」繰り出される点です。

穴埋め作業員は不要

特に多いのが「参考はありますか?」です。

ある機能の製造~試験をお願いした時に「参考はありますか?」なんて聞いてきます。

で、参考となる類似機能のコードをや類似案件の試験仕様書を渡すと、彼・彼女らは参考に渡したものをそのまま使おうとします。

要は「参考」じゃなくて「答えをもらって、クリエイティブなシステム開発を穴埋め問題化しようとしている」のです。
そこには「考え」なんてなくて、前にもらったものをそのまま使って、なんとなくちょっと変えるだけで乗り切ろうとしています。

つまり、「自分にはクリエイティブな力はないので、前に作った人の成果物を猿真似します」ということです。

ぶっちゃけた話、この程度のスキルの技術者は現場に全く不要です。
品質を下げ、コストを上げるだけの邪魔な存在です。

ただ、今回は今そのような状況の人を貶める記事ではなくて、なぜそれが起こるのか、どうすればその低スキル状態から脱出できるか

を広めるのが目的です!

生物濃縮をしっていますか?

まずは事前知識として。

公害とかの領域で登場しやすい言葉なのですが、生物濃縮という現象があります。

簡単にいうと、「元々は悪影響のないほど微量だったものが、食物連鎖の中で蓄積していって、最終的に有害な量が溜まってしまう」という現象です。

画像を用意しました。

若手技術者とBPの成長を阻害する雑魚濃縮という現象

どうでしょうか。有害物質が蓄積されていって、最終的に人間が影響を受けてしまいました。

これが生物濃縮です。

今回取り上げている、成長を阻害する要因の中心にはこれに近い現象があるのではないかと考えています。

その名も。。。。

雑魚濃縮

恐ろしい怪奇現象「雑魚濃縮」

この言葉、簡単にいうと「マニュアルとか(本来の意味でない)参考には深い洞察がなので、上辺のスキルしか得られない。だからそんなことばかり言っている人は、結果として全く成長しない」ということです。

マニュアルがないと作業ができない人たちをここでは「雑魚」と表現しているのであり、そうした人たちが生み出す成果物も圧倒的低品質の「雑魚」になります。
さらにそれを参考に、別の雑魚が新たな雑魚を生み出す。
こういった負のサイクルを「雑魚濃縮」と表現しています。

イメージは以下の通りです。

若手技術者とBPの成長を阻害する雑魚濃縮という現象

マニュアルとか手順書・参考というのは、本来多くの試行錯誤があった末に「最も効率的だと思われる方式」を明文化して保存したものでしかありません。

つまり、上の図では上二段の人たちは「ビジネスを作り上げていくすごい人たち」です。
その人たちが事業のスケールアップのために人員を追加しようとする際に、「誰でも簡単に」「一定の品質」が出せるようにマニュアルかされるわけです。

で、今回問題にしている人たちは「マニュアルに従って作業をする」ということになります。

この問題の本質は、「どれだけその業務を続けても、結局マニュアル上のことしかできないためスキルの価値が低い人材になる」という1点です。

例えばあるシステムの運用保守をずっとやっていた人に、新しいシステム開発をやらせようとすると全く何もできないでしょう。
さらに、運用観点のオブザーバーとして参加させたとしても「僕はこういう使い方してます」程度の意見しか出てきません。
「なぜそのような手順になっていて、他の手順ではなぜダメなのか」などの話は全くできず「今こうなってます」しか言えません。

つまり技術力が伸びないままで、ただ決まった作業をするしかできないということです。

「参考」くださいも同様

例えばソースコードや試験仕様書を作るときに、別案件の参考をくださいとか言っちゃう人も同じような現象にぶち当たります。

つまり、「なぜソースコードがそのような構成になっているのか」「なぜ試験仕様書の観点がソレなのか、試験項目が決まっているのか」などがわからず、「今もらったものが情報の全て」ということになります。

そうなると、元々あったはずの「試行錯誤や多くの失敗から導き出した洞察」は失われていき、表層の部分のみが残ります。

そして今度は、雑魚が作った雑魚い成果物を参考として、新たな雑魚が、より雑魚い成果物を生み出していくことになるのです。

クリエイティブを取り戻すには

では、この「雑魚濃縮」の輪から脱出するにはどうすればいいのでしょうか?
すごくシンプルです。

「なぜそうなっているのか」を把握するように努めましょう。

今ある手順書やマニュアルは、どんな背景・議論があって今の流れになっているのか。
どうしたらより効果的な流れを作れるのか。

参考にもらったコードや仕様書は、なぜそのような記述レベルなのか。
よりよくするにはどうすればいい。

これを追求することでしか脱出できません。

「なぜ」を把握したとき、「いや、でもこれこうしたほうがいいんじゃないか?」のような話ができるようになり、「今あるものを一歩前に進める」というクリエイティブを取り戻すことができるのです。

表層だけをさらってこの話をしてしまうと「その話は前にした」とか「こういう前提があるのに、わかっていない」などの反応を喰らっているわけです。

先輩の雑魚度も一緒に計っちゃおう

ではより具体的にどうしたらいいのか。

それは、同じ業務をしている身近な先輩に「なんでこうなっているんですか」と聞いてみてください。

これで簡単に「なぜ」を知ることができます。

このとき、先輩がちゃんと説明してくれればいいのですが、例えば「うーんわからない」とか「そういうもんだから」みたいな明確な回答がもらえなかった場合は、その先輩も濃縮された雑魚を喰らった雑魚です。

より上の先輩にもう一度聞いてみると同時に、その先輩は「雑魚」として処理しましょう。

###############お知らせ################
ブログランキングのITカテゴリに参加してみました。
この記事が役に立ったなどお力になれたら、 このバナーを押していただけると嬉しいです。

#####################################

-チーム作り