81
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

「プロの初心者」の罠:永遠に抜け出せない二流の道

Last updated at Posted at 2023-04-18

ハイサイ!オースティンやいびーん!

概要

我々開発者は職人でいくら腕を磨いても完全にプログラミングを習得することは不可能です。

それでも、その終わりのない成長には段階があり、「達人」領域まで技術を極めたいものです。

しかし、我々開発者の中には、プロの初心者がいます。ただの初心者ではなく、初心者であることそれ自体の達人になっている人がいます。

多くの場合、「プロの初心者」は自分のことを天才と思い上がったり、他のエンジニアより優れておりプログラミングの達人だと勘違いしています。また、自己主張が激しいおかげか、技能を見極められない人に自分が専門家であるかのように騙しているケースも多いです。

特にエンジニアの人手不足が蔓延しており海外からのエンジニアが少ない日本の市場では、競争が極端に少なく、エンジニアが自身の能力を見誤る閉鎖的な空間が出来上がりやすいとも言えるでしょう。

我々エンジニアはみんな「プロの初心者」になりかねないのです。

「プロの初心者」は、成長が止まってしまったエンジニアのことです。

今回の記事は職人全般の成長の段階について紹介し、「プロの初心者」の罠と抜け出せない愚者について解説した上、その罠にハマらないように日頃からできることを提案していきます。

職人の知的熟練度モデル

上記にも触れたように我々職人は永遠に我が技能を高めるべく日々からの努力で腕を磨いて終わりのない学習を続ける道を歩んでいます。

その道の終着点は、永遠に見えてこないのかもしれませんが、それでも出発点からどれくらいの距離を走ってきたのかは測れるのではないでしょうか?

その道の進み具合を測ろうとするのは、「知的熟練度モデル」です。

知的熟練度には二つの能力が含まれていると言われています。

  • 問題に対処する能力
  • 変化に対処する能力

熟練度が高いと、問題を解決するための武器を既にたくさん持っているし、道具が足りなかったら、どのようなものが適切でどうやって入手できるかの能力も十分に身につけているはずです。

知的熟練度の段階はDreyfusモデルによって5つに分かれて定義されています。

  1. 初心者
  2. 見習い
  3. 一人前
  4. 中堅者
  5. 塾達者(達人)

以下の段階をかいつまんで解説します。


初心者

経験がないし、知識はあれば文脈通りの理解しかないため、現実問題と知識の乖離があります。能力も低く、スピードも遅いです。

見習い

ある程度経験があるので同様にある程度の成果を出すことができます。ただ、全容が掴めていないので知らないことを知らないし、指導がないと伸び悩む段階

一人前

経験に基づいて計画や目標を設けることができるようになります。主体的に行動ができて尚且つ自分の置かれている状況に対する理解もある程度得ています。

この段階から、合理的な判断と意思決定ができるようになると言われています。自分の能力の限度、知らないこと、わからないことを把握できるのです。

中堅者

一人前より更に知見を培っており典型的なパターンも理解できることに加えて状況を包括的に分析できるようにもなります。

塾達者

経験と知識を十分に重ねているので、直観的に適切な判断ができるようになります。

引用:知的熟練と学習論、松尾 睦

Drefus氏は塾達者に達するのに最低でも10年間かかると主張していますが、筆者はどうかなぁと思います。若いからそう思うでしょうか?:fist::joy:

プロの初心者

さて、上記のモデルに「プロの初心者」はどの位置付けにあるのでしょうか?

「見習い」では、ある程度のことができるようになるのです。Web開発に例えると、PHPでWebサイトを作ってコメントができるように自作のサーバーを作ることが案にできるようなイメージです。たいていのことができるということです。

「見習い」レベルに達すると、一気に可能性が広がります。読者にもそのような経験を覚えていませんでしょうか?

しかし、上記の自作アプリケーションの例だと、Botに無駄な投稿やコメントを大量に書かれるようになったらどうしますか?大量のアクセスに耐えられるようにスケーリングをどう設計しますか?保守性を高めるためにアプリケーションの設計ができるのでしょうか?

「見習い」なら、上記のような課題にそもそも気が付かないはずです。しかし、「一人前」の段階なら、課題が存在すること自体は把握できるのかもしれません。

無知の知と言いますが、自分が何かを知らないかもしれんと自身を疑う能力は「見習い」と「一人前」の大きな違いだと思います。

上記の質問に答えると、プロの初心者は、自分の無知を知ろうとしないから、永遠に「見習い」と「一人前」の狭間を彷徨っているのです

自分の知識と経験に穴がぽかんと開いていることに永遠に気づかないで仕事を続けるのです。

なぜ気づかないかというと、アプリケーションを作ってそれが失敗であることをすぐに知るよしがないからです

テーゲーにそれらしいアプリケーションを作って機能の要件を満たしていたら最初は「OK」でリリースされますが、一年以上立つと、設計ミス、セキュリティの弱点、保守性の悪さ、拡張性のなさが見えてくるのです。最初はぐんと新規機能開発できていたのが、徐々に効率が悪化して何も締め切りに間に合わず、延期多発のバグりまくりのアプリケーションにどんどんなっていきます。

筆者はこういうアプリケーションを作った経験があります...:sweat:

残念ながら、たいていの場合は「これぐらいでいい」で済んでしまいますが、世の中はこのような品質の悪いアプリケーションで溢れかえっています。スタートアップだと、これが大体致命傷になりますし、多くの会社が今げんに抱えている問題です。

こういう痛い経験を経ると、自分の無知に気づいて更に勉強を重ね、「一人前」になります。

しかし、自分が携わって作ったアプリケーションの問題点を経験するところまで付き合わず、もしくは問題になった時に他人のせいにしたりすると、自分の無知に気づけないで終わってしまいます。

これがまさに、プロの初心者の罠なのです。二流確定です。

プロの初心者がもたらすダメージ

プロの初心者は、本人が意図していないのかもしれませんが、最高の怠け者と言っても過言ではありません。問題になるようなコードを永遠に書き続けてしまうからです。

コードレビューの指摘があっても、研修を受けても、自分の無知を知らないから、学習の必要性を感じず、同じやり方でやり通すのです。さまざまな言い訳で自分の「スタイル」を正当化し変化を拒むのです。

これだけでも十分なダメージをもたらすのですが、より最悪なパターンがあります。次のパターンの人はプログラミング業界は本当によく当たるなと感じています。

自分の無知を知らないだけでなく、自分が誰よりも才能に溢れた天才だと思い上がっている毒プログラマーがいます

このタイプのエンジニアは毒でしかなく会社の雰囲気を北極圏で行う葬儀の如く冷え込んだものにしていくのです。批判と指摘に耳を傾けない、助言と提案を真っ向から否定して自分の言い分を押し通す、わかりにくい説明を問われても「なんでわからないのか?」というように相手を貶しながら答えなかったりする、そういうエンジニアと付き合わされたことはありませんでしょうか?

相手にするのも最悪です。

だから、徐々に相手にしないように仕事を工夫してコミュニケーションを避けたりします。これもスタートアップにとって命どりになりかねない現象ですが、悪いのは毒プログラマーと対応しない人事です。

毒プログラマーは「プロの初心者」でもあるのです。間違っていることが多々あるのに、自分の失敗は認めないので改善しない上、同僚が常にトカゲの尻尾になるので組織も成長しません。自分の失敗は部下のもので部下の成果は自分のもの、まるで半沢直樹みたい

多くの場合、毒プログラマーに進化したプロの初心者は、実際に問題を解決するより、自分がいかにも賢くて組織にとって必要不可欠であることを訴える能力に長けているのです。そのせいで技能を見極めることができない人事、マネジメントは本人のナマケと技能のなさを「本当に不可能だ」と勘違いしてしまい、そのまま野放しにします。

いいことはないです

まともなエンジニアもすぐ辞めるし、辞めない人はそれ以上に伸びなくなります。

プロの初心者も、レベルアップした毒プログラマーも同様に組織が抱えている問題を解決することは少なく、問題を作ることが多いです。例え一時的に解決できているように見えても、塩害で錆びきっていていくら絆創膏で水漏れを塞いでも漏れてくる配管のごとく、問題を増やすのです。

プロの初心者にならないように日頃からできること

成長が止まっている人は、小さな池にいる魚のように海に出てみないと自分の小ささに気づけません。井の中の蛙は大海を知らずというように、自分の無知を知ることが大切です。

地元で最高に強い高校野球チームでも、甲子園に出てみると自分らの力が足りないことに気づきますが、我々開発者の場合は、オープンソース開発が甲子園に近いでしょう。甲子園というより、英語だからメージャーリーグに近いのかもしれません。

オープンソース開発に挑戦すると、いやでも自分の足りなさを思い知らされます:sweat_smile:。筆者は何度も試しにPRを出してみてはクローズしています。未だにマージできたことはないのですが、毎回学びはあるし謙虚になります。

なので、筆者のおすすめは、時々好きなプロジェクトのIssueをみて自分が解決できそうなやつにPRを出してみることです。とんでもない失敗でもいいし、勘違いでもいいです。筆者は勘違いでPRを出すことがほとんどです:joy:

もう一つのアドバイスは、普段やっていないような領域に手を出すことです。フロントエンドが得意だったら、バックエンドのフレームワークを新しくやってみる。Pythonが得意だったらGoを試す。AWSが強いなら、GCPで同じことをやってみる。意外と、謙虚になれば、自分の知らないことがいくらでもあるということにすぐに気づけると思いますが怖くならなくてもいいし、遊び心でどんどん学習して知識の幅を広げていけばいい、そう思いませんか?

まとめ

我々職人には知的熟練度があり、職人の道を極めるにつれてどんどん高くしていけます。しかし、気をつけないと、自分の無知に気づかずに停滞してしまいます。停滞に慣れ、それに満足すると、永遠に一人前にならない「プロの初心者」になります。停滞は人を腐らせるので、最悪の場合、他人を貶すまでしてその停滞を維持しようとする「毒プログラマー」にもなりかねません。

プロの初心者の落とし穴にはまらないように、日頃から謙虚な気持ちで無知の知を心掛けて慣れないことにも挑戦する努力をしましょう。

達人になるまでの道のりは長く、険しいのです。筆者ももしかしてプロの初心者になっているのかもしれませんが、止まらずに常に高みを目指していきたいと思います。なぜなら、その方が楽しそうだから

職人はやはり好きだから職人になると思うのでみんなで楽しくやっていきましょう。

参考文献

本記事を書きたくなったのは、以下の記事を読んだ後です。英語ですが、とても参考になるのでおすすめです。

81
46
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
81
46

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?