Help us understand the problem. What is going on with this article?

仮説・検証(38)プログラマで「飛び抜けた人が少ない」という仮説

ソースコードはしゃべるように書け
https://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4

に触発された記事です。

20代の頃から、約45年

Programming like a poem

プログラムを詩のように書くを信条にして、プログラミング、プログラミング教育、プログラム試験をしてきました。

プログラマの、プログラミングの量と質の差は、
小説家の小説の量と質の差と似ているというのが経験則です。

仮説1 量を多く書く人は質がわるい

量を多く書いて来た人の品質の分布と、量を少ししか書けない人の品質の分布は、
量を多く書いて来た人の方が、品質のよい方に偏っているというのが経験則です。

根拠としては、多く書くと、多くの不具合に遭遇し、その治し方も習得するため、
すこししか書いてない人とは品質が段違い。

量が多くなるように書く人の品質の分布と、量が少くなるように書く人の品質の分布は、
量が少なくなるように書く人の方が、品質のよい方に偏っているというのが経験則です。

根拠としては、量が多ければ、誤りも混入しやすく、量が少なく書く人の方が品質がよい。

「量を多く書く人は質が悪い」という誤解は、「量が多くしか書けない人は品質が悪い」という理解とが混ざったのかも。

量が少しで品質のいい人と、量がそこそこで品質の悪い人を見て、経験則に取り入れているのかもしれません。いろいろな人の確率、分布を調べてみてはどうでしょう。

仮説2 飛び抜けた人はそんなにいない

ある年に面白い道具(tool)を1本書いた大学4年生がいました。
その次も期待していました。
担当教授が、方向性を振り回し、その後、大学院の2年かかっても4年時のほどの成果はでませんでした。

なぜ、書きたいものを書かせればいいものが書けるのに、
不必要な制約や、方向性に対する批判をするのかうんざりしました。

企業の中では、金になるかならないかで、3年かければ金になるものも、1年で回収しなきゃといって、飛び抜けた人をつぶしていくのを、遠くから眺めることがあります。

飛び抜けた人はそんなにいないと言う人が、ひょっとしたら潰している人かもしれません。

経験則では、学生で10人に1人は、最初にあったときに、自分よりプログラミング能力が上でした。やりたいようにやってもらうと、その一人と、もう一人が、飛び抜けた状態になってくれます。

小説家になろうと思って文学部に入った学生で、プロになれる確率より、
プログラマになろうと思ってプログラムを書き始めた人の方が、
飛び抜けたプログラマになる確実に高いと思います。

文学は最初の障壁は人です。
プログラミングの最初の障壁はプログラミング言語です。
プログラミング言語に、そうとう駄目出しされ、よいものしか通らないようになって、世の中に出る。
小説家よりもプログラマで飛び抜けた人が多い理由は、障壁の違いだと思っています。

仮説3 飛び抜けた人に依存していてはいけない

いかにももっともらしく聞こえます。
GCC, Linux、今、世の中でものすごい量で使われているソフトウェアは、ほとんどが、飛び抜けた人が書いたものに依存したソフトウェアです。

これらのソフトウェアのうち、オープンソースであれば、飛び抜けた人以外の人も、よくすることに協力できる仕事の仕方を組織できるため、使う危険性はありません。

飛び抜けた人を支える組織、作業の仕方(process)が大事であることは歴史的な経験則ではないでしょうか。

数学、物理の法則と同様、誰かが発見してくれれば、あとの人はそれを利用する仕組みを作ればいいのですから。

飛び抜けた人に依存する仕組みと、飛び抜けた人を潰さない仕組みの均衡が大事。
どちらかだけに力をいれているとまずい。

仮説4 若いうちしかプログラムは書けない。

10代で燃え尽きる人はいます。
20代が全盛期の人もいます。
30代からプログラムを組み始め、仕事にされる方々がおみえになります。

当方で、言語処理100本ノックを一番最初に、最後まで実行された方は30代です。
言語処理100本ノックをdockerで。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4

40代で、管理職はプログラム組んじゃだめだと言われ、転職してプログラム書かれている人がいます。
20年前、50代でアセンブラでプログラム組まれている方がおみえでした。

今、60代でのプログラムをお勧めしています。

65歳からのプログラミング入門
https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f

どういう問題を解決したいか、プログラムが解決に役立つか、その点に関するやる気が鍵です。

昨年、3人の30代で初めてプログラミングする技術者の方の教育を担当させていただきました。
3人とも音楽が趣味または仕事でした。
3週間で、pythonで音楽のプログラムが組めるようになられました。

下記は、3人の方に音楽用の題材をさがしてもらうために書いた記事。

プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8

仮説5 飛び抜けているかどうか分からない

普段仕事をしていると制約条件が多すぎて、飛び抜けた仕事がしづらい環境が多いかもしれません。

良いのは、自分の仕事の道具を作ることです。
自分が利用者ですから、内容や出来について文句を言われることはありません。

短時間で、自分が便利になる道具が作れることが、飛び抜ける一つの段階かもしれません。

国立研究開発法人宇宙航空研究開発機構(JAXA)と独立行政法人情報処理推進機構(IPA)共催、第14回クリティカルソフトウェアワークショップ(WOCS2: Workshop on Critical Software System)
https://www.ipa.go.jp/sec/events/20161212.html

データセンターにおけるITオペレーションの業務品質向上を達成した改善事例
NSSLCサービス株式会社 鈴木 貴広
https://www.ipa.go.jp/files/000055796.pdf

自分の道具が整備されているときには、外部のコンテスト、ハッカソンに参加するのも手かも。

TOPPERSまとめ #名古屋のIoTは名古屋のOSで
https://qiita.com/kaizen_nagoya/items/9026c049cb0309b9d451

TOPPERS活用アイデア・アプリケーション開発コンテスト受賞作品紹介(1) 第一回(2011)アプリケーション開発部門銀賞『Natural Tiny Shell Task』中村晋一郎
https://qiita.com/kaizen_nagoya/items/763209c213e3c0daee10

第四回(2014)アプリケーション開発部門 金賞Toppers_ASPカーネルとScilab による組込みメカトロニクス制御シミュレーション 塩出武 (個人)
https://qiita.com/kaizen_nagoya/items/fe398eb623889f587bba

第四回(2014)アプリケーション開発部門 銅賞 組込みソフトウェア学習用教材ボードNCES TRAINING BOARDと教材テキスト,サンプルプログラム一式 松浦 光洋(個人) / 本田晋也(名古屋大学)
https://qiita.com/kaizen_nagoya/items/aa318576dffb857893eb

第五回(2015)アプリケーション開発部門 銅賞シュリンク版TOPPERS/SSPとそれを利用した タミヤラジコン改造RaspberryPiスマホリモコンカー アライブビジョンソフトウェア株式会社(代表:髙橋和浩)
https://qiita.com/kaizen_nagoya/items/c79a812ee6163e16342a

第八回(2018)アプリケーション開発部門金賞 TOPPERS/ATK2 カーネル向け実機レス開発環境(athrill2) 森崇((株)永和システムマネジメント)
https://qiita.com/kaizen_nagoya/items/92faa2220d63588afa9d

仮説6 飛び抜けた人を育てるのは難しい

飛び抜けた人を育てるのは難しいって、本当でしょうか。
仕事で道具を作ったり、仕事時間でコンテスト・ハッカソンに出るのもよいでしょう。

仕事の1割の時間でも、将来や教育のために使う制度があれば容易です。
そうでないと、仕事時間以外に、仕事のための勉強を強いるブラック企業になってしまうかもしれません。

お客さんにプログラムを収めるのに、その分野の世界一のプログラマであるとよい。
お客さんにしてみれば、世界一でもない人に、なぜお金を払わなければいけないのだろうと思っているかもしれません。
飛び抜けた人じゃない人に、仕事をしてもらってもお客さんを喜ばせるのは難しいと思ったことはありませんか?

飛び抜けるためには、次の3項目がうまく均衡しているとよい。本人の意思が一番大事。邪魔をする人がいてもその分助けてくださる人がいれば、なんとかなる。

1 本人の意思(will)

何か解決したい、何か作りたい、何か人と違うことがしたいという意思。

2 邪魔をしない環境(environment)

足をひっぱる人のいない空間、
自分がやりたいと思ったことを実行する1日1時間、
やりたいことをやれる空間(例えばgithub, dockerhub)

3 もう一歩先に行ってもいいよという助言(advice)

やったことをいいよと行ってくれる先生、先輩、知人
代替案候補を提案してくれる顧客
参考にするとよい資料をしめしてくれる専門家

ぼくの先生 プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4

顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818

まとめ(summary)

小説家の仕事の仕方は、パッケージソフトウェアのプログラマのような場合が多い。
どのお客さん向けに書くかは、書く側の選択で、当たるところを狙わないといけない。

それに対して、お客さんから頼まれてプログラムを書く仕事は、
ソフトウェアのマニュアルを書いたり、その会社の規則を作ったりする仕事に似ているかもしれない。

飛び抜けた人でなければ、前者の仕事で成功しないかもしれないし、
5年後、10年後しか売れないかもしれない。

日銭をかせぐには、言われたものを書く、単価の安い仕事をこなすしかないかも。
飛び抜けていかなければ、長期的には仕事を競争で取られてしまうかもしれない。

とんなに小さな領域でも、飛び抜けているのでなければ、仕事でプログラムを書く価値はない。
飛び抜けた人が、自動生成してしまうかもしれない。

飛び抜けることができるためには、才能と努力と環境の3つのうちのなんらかの組み合わせがいいかも。

小説家が65歳を超えても書き続けるように、プログラマも65歳を過ぎても書き続けてもいいというのをまとめにしてみます。

仕事上、設計が3割、試験が3割、教育が3割、その他1割です。
一緒に仕事をしている方は、設計が8割、試験が1割、その他1割という感じの方が多い感じです。
立場の違いによって、見えていることが違うため、ここに書いていることがピンとこないこともあると思います。

飛び抜けた人が、自動生成作っても、お金にならないからと捨てられたのを目撃したことがあります。
実情としては、飛び抜けた人の半分くらいは、傷心して業界を去っている感じです。
官庁の飛び抜けたプログラマも半分くらいは、官庁を辞めています。

IT企業、製造業、官庁から去る、飛び抜けたプログラマの比率は同じくらいというのが経験則です。
逆に、伸びている企業は、飛び抜けた人の仕事をうまく生かしているように感じています。

DataRobotという機械学習のシステムに、ソフトウェアを追加して業績をあげているある会社は、
マスコミへの情報開示を禁じていて、詳しく書けないのが残念です。

マスメディアの情報に振り回されないことも、飛び抜けた人を育てる土壌の一つかもしれません。

参考資料(reference)

ぼくのかんがえた さいきょうの新人研修
https://qiita.com/aosho235/items/23625cdb340eaaeb5b94

新人教育の際に気をつけたこと
https://qiita.com/yu-croco/items/c41aa79a87fdbcf418fb

自己参照(self reference)

Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる5つの道
https://qiita.com/kaizen_nagoya/items/c72fa39e3191ea0290df

プログラミング言語教育のXYZ
https://qiita.com/kaizen_nagoya/items/1950c5810fb5c0b07be4

プログラミング言語の勉強の仕方と水準
https://qiita.com/kaizen_nagoya/items/ba2651035339ef45b3aa

プログラム初心者が知らなくてもいいこと
https://qiita.com/kaizen_nagoya/items/3eaeb88e583898b8aae7

disること仮説・補題・例題
https://qiita.com/kaizen_nagoya/items/e4f486edf00598945598

機敏(agile)

公開算譜は機敏だ<完全版>(open source is agile &名古屋のIoTは名古屋のOSで
https://qiita.com/kaizen_nagoya/items/5dd49a046b5991af3a5e
顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818

分析(analyze)

効率的なHAZOPの進め方
https://qiita.com/kaizen_nagoya/items/2b8eae196945b7976446
安全分析(HAZOP)の際の声かけ
https://qiita.com/kaizen_nagoya/items/381649a6ea025ecba173

確率・統計(probability and statistics)

計画者(programmer)のための横顔(profile)入門 (1)「お金のセンスを測ってみる」on「確率論及統計論」輪講演習
https://qiita.com/kaizen_nagoya/items/c77cafd3fe47a558bfe5
確率論及統計論
https://qiita.com/kaizen_nagoya/items/cc3730e4494e7d37ea4d
科学四分類と算譜(program)
https://qiita.com/kaizen_nagoya/items/a2f2b9cc3a51b6af7603
言語論と確率論
https://qiita.com/kaizen_nagoya/items/cc3730e4494e7d37ea4d

事業計画確率(project plan with probability)
https://qiita.com/kaizen_nagoya/items/f2dc5d216e57df844f50

課題(issue)

open な issue がどんどん溜まる現象を解決するために
https://qiita.com/kaizen_nagoya/items/efe22d9a23ad2e9934d6
プログラマが英語で報告・質問する時のいくつかの事例・方法
https://qiita.com/kaizen_nagoya/items/9cf2ba858e52e9795b67

見直し(review)

Reviewerの数
https://qiita.com/kaizen_nagoya/items/36aefeea21fb190bf873
プログラマの「日報、週報、月報、年報」考
https://qiita.com/kaizen_nagoya/items/97ad8ac9217c12c3bb69

作業改善(process improvement)

プロセス改善が改悪へと突き進む
https://qiita.com/kaizen_nagoya/items/0f3a1174f81935bb6d85
ペアプロの3つの種類
https://qiita.com/kaizen_nagoya/items/5c80663799d99b807870
ITシステムの見積もりの見積もり
https://qiita.com/kaizen_nagoya/items/93a7d3ba13da0a7a9c15
作業診断(process assessment)を成功させる5つの鍵。失敗する5つの罠
https://qiita.com/kaizen_nagoya/items/bcdc60db20e8d7081fab

仮説・検証(110) プログラムは詩のように描こう
https://qiita.com/kaizen_nagoya/items/dd2a912f23b18e0f8893

ソフトウエアプロセスの改善に向けて ~SPIへの今後の取組み~ (ソフトウエア開発・調達プロセス改善協議会報告書の公表)
http://warp.da.ndl.go.jp/info:ndljp/pid/1368617/www.meti.go.jp/kohosys/press/0002639/0/020419spi.pdf

読書(reading)

amazon殿堂入りNo1レビュアー(2011)
https://www.amazon.co.jp/review/hall-of-fame
https://www.amazon.co.jp/gp/profile/amzn1.account.AEZYBP27E36GZCMSST2PPBAVS3LQ/ref=cm_cr_tr_tbl_hof_name

booklog 改善本棚
https://booklog.jp/users/kaizen

読書メーター kaizen
https://bookmeter.com/users/121023

文書履歴(document history)

ver. 0.01 初稿 20190222 午後3時
ver. 0.02 仮説4若いうちしかプログラムは書けない。追記 20190222 午後4時
ver. 0.03 参考文献追記 20190222 午後9時
ver. 0.04 プログラムは音楽だ 追記 20190223 午前
ver. 0.05 まとめ 追記 20190223 昼
ver. 0.06 表現補足 20190223 夕方
ver. 0.07 まとめに小説家を追記 20190223 夜
ver. 0.08 誤記、表現調整 20190323 深夜
ver. 0.09 仮説5 飛び抜けているかどうか分からない 追記 20190223 真夜中
ver. 0.10 第八回(2018)アプリケーション開発部門金賞 TOPPERS/ATK2 カーネル向け実機レス開発環境(athrill2) 森崇((株)永和システムマネジメント)追記 20190223 23:55
ver. 0.11 参考資料追記 20190224 朝
ver. 0.12 邪魔と助けの均衡 追記 20190224 昼
ver. 0.13 表題に「」追加 20190224 午後4時
ver. 0.14 仮説6 飛び抜けた人を育てるのは難しい 追記 20190224 夕食前
ver. 0.15 マスメディアに振り回されない 20190224 夕食中
ver. 0.16 読書、官庁 追記 20190224 夕食後
ver. 0.17 表現訂正、URL追記 20190225 午前3時
ver. 0.18 Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる5つの道 20190225 朝
ver. 0.19 編集リクエストに基づき「量を多く書いて来た人」と「量が多くなるように書く人」を区分 20190225 午前
ver. 0.20 参考資料編集 20190225 もうすぐ昼
ver. 0.21 表現加筆 20190225 昼
ver. 0.22 見出し追記 20190419
ver. 0.23 見出し変更 20190512
ver. 0.24 URL追記 20201226

このエントリーをはてなブックマークに追加
https://b.hatena.ne.jp/guide/bbutton

kaizen_nagoya
I'm a network designer.I work on TOPPERS SmallestSetProfile Kernel,MISRA-C, STARC RTL Design StyleGuide (Verilog-HDL),HAZOP,ISO/IEC15504(AutomotiveSPICE),ISO26262. I was an editor on ISO/IEC 15504.
https://researchmap.jp/blogs/blog_entries/view/81777/f691323917cc4ea12caf0b03b34c8ea0?frame_id=442673
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away