@chooyan_eng ソースコードはしゃべるように書け
https://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4
に触発された記事です。
NOP(NIT(Nagoya Institute of Technology) of Programmers)
https://qiita.com/kaizen_nagoya/items/fb5630980839aa9a6519
日本のプログラマが世界で戦える16分野・事例。仮説（53）統計と確率(25)
https://qiita.com/kaizen_nagoya/items/a7e634a996cdd02bc53b
に記載した支援経験に基づいているかもしれません。
しゃべるように
<この項は書きかけです。順次追記します。>
20代の頃から、約45 50年
Programming like a poem
プログラムを詩のように書くを信条にして、プログラミング、プログラミング教育、プログラム試験をしてきました。
プログラマの、プログラミングの量と質の差は、
小説家の小説の量と質の差と似ているというのが経験則です。
「風をあつめて」を計画書として事業展開してみる
https://qiita.com/kaizen_nagoya/items/92365c542714f27e5658
仮説(110) プログラムは詩のように描こう
https://qiita.com/kaizen_nagoya/items/dd2a912f23b18e0f8893
仮説１ 量を多く書く人は質がわるい
量を多く書いて来た人の品質の分布と、量を少ししか書けない人の品質の分布は、
量を多く書いて来た人の方が、品質のよい方に偏っているというのが経験則です。
根拠としては、多く書くと、多くの不具合に遭遇し、その治し方も習得するため、
すこししか書いてない人とは品質が段違い。
量が多くなるように書く人の品質の分布と、量が少くなるように書く人の品質の分布は、
量が少なくなるように書く人の方が、品質のよい方に偏っているというのが経験則です。
根拠としては、量が多ければ、誤りも混入しやすく、量が少なく書く人の方が品質がよい。
「量を多く書く人は質が悪い」という誤解は、「量が多くしか書けない人は品質が悪い」という理解とが混ざったのかも。
量が少しで品質のいい人と、量がそこそこで品質の悪い人を見て、経験則に取り入れているのかもしれません。いろいろな人の確率、分布を調べてみてはどうでしょう。
仮説２ 飛び抜けた人はそんなにいない
ある年に面白い道具(tool)を１本書いた大学４年生がいました。
その次も期待していました。
担当教授が、方向性を振り回し、その後、大学院の２年かかっても４年時のほどの成果はでませんでした。
なぜ、書きたいものを書かせればいいものが書けるのに、
不必要な制約や、方向性に対する批判をするのかうんざりしました。
企業の中では、金になるかならないかで、３年かければ金になるものも、１年で回収しなきゃといって、飛び抜けた人をつぶしていくのを、遠くから眺めることがあります。
飛び抜けた人はそんなにいないと言う人が、ひょっとしたら潰している人かもしれません。
経験則では、学生で10人に１人は、最初にあったときに、自分よりプログラミング能力が上でした。やりたいようにやってもらうと、その一人と、もう一人が、飛び抜けた状態になってくれます。
小説家になろうと思って文学部に入った学生で、プロになれる確率より、
プログラマになろうと思ってプログラムを書き始めた人の方が、
飛び抜けたプログラマになる確実に高いと思います。
文学は最初の障壁は人です。
プログラミングの最初の障壁はプログラミング言語です。
プログラミング言語に、そうとう駄目出しされ、よいものしか通らないようになって、世の中に出る。
小説家よりもプログラマで飛び抜けた人が多い理由は、障壁の違いだと思っています。
仮説３ 飛び抜けた人に依存していてはいけない
いかにももっともらしく聞こえます。
GCC, Linux、今、世の中でものすごい量で使われているソフトウェアは、ほとんどが、飛び抜けた人が書いたものに依存したソフトウェアです。
これらのソフトウェアのうち、オープンソースであれば、飛び抜けた人以外の人も、よくすることに協力できる仕事の仕方を組織できるため、使う危険性はありません。
飛び抜けた人を支える組織、作業の仕方(process)が大事であることは歴史的な経験則ではないでしょうか。
数学、物理の法則と同様、誰かが発見してくれれば、あとの人はそれを利用する仕組みを作ればいいのですから。
飛び抜けた人に依存する仕組みと、飛び抜けた人を潰さない仕組みの均衡が大事。
どちらかだけに力をいれているとまずい。
仮説4 若いうちしかプログラムは書けない。
10代で燃え尽きる人はいます。
20代が全盛期の人もいます。
30代からプログラムを組み始め、仕事にされる方々がおみえになります。
当方で、言語処理100本ノックを一番最初に、最後まで実行された方は30代です。
言語処理100本ノックをdockerで。
https://qiita.com/kaizen_nagoya/items/7e7eb7c543e0c18438c4
40代で、管理職はプログラム組んじゃだめだと言われ、転職してプログラム書かれている人がいます。
20年前、50代でアセンブラでプログラム組まれている方がおみえでした。
今、60代でのプログラムをお勧めしています。
６５歳からのプログラミング入門
https://qiita.com/kaizen_nagoya/items/1561f910c275b22d7c9f
どういう問題を解決したいか、プログラムが解決に役立つか、その点に関するやる気が鍵です。
昨年、３人の３０代で初めてプログラミングする技術者の方の教育を担当させていただきました。
３人とも音楽が趣味または仕事でした。
３週間で、pythonで音楽のプログラムが組めるようになられました。
下記は、３人の方に音楽用の題材をさがしてもらうために書いた記事。
プログラムは音楽だ (A program is a music.)
https://qiita.com/kaizen_nagoya/items/33c9f33581e6886f8ad8
仮説5 飛び抜けているかどうか分からない
普段仕事をしていると制約条件が多すぎて、飛び抜けた仕事がしづらい環境が多いかもしれません。
良いのは、自分の仕事の道具を作ることです。
自分が利用者ですから、内容や出来について文句を言われることはありません。
短時間で、自分が便利になる道具が作れることが、飛び抜ける一つの段階かもしれません。
国立研究開発法人宇宙航空研究開発機構（JAXA）と独立行政法人情報処理推進機構（IPA）共催、第１４回クリティカルソフトウェアワークショップ（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
仮説６ 飛び抜けた人を育てるのは難しい
飛び抜けた人を育てるのは難しいって、本当でしょうか。
仕事で道具を作ったり、仕事時間でコンテスト・ハッカソンに出るのもよいでしょう。
仕事の１割の時間でも、将来や教育のために使う制度があれば容易です。
そうでないと、仕事時間以外に、仕事のための勉強を強いるブラック企業になってしまうかもしれません。
お客さんにプログラムを収めるのに、その分野の世界一のプログラマであるとよい。
お客さんにしてみれば、世界一でもない人に、なぜお金を払わなければいけないのだろうと思っているかもしれません。
飛び抜けた人じゃない人に、仕事をしてもらってもお客さんを喜ばせるのは難しいと思ったことはありませんか？
飛び抜けるためには、次の３項目がうまく均衡しているとよい。本人の意思が一番大事。邪魔をする人がいてもその分助けてくださる人がいれば、なんとかなる。
1 本人の意思(will)
何か解決したい、何か作りたい、何か人と違うことがしたいという意思。
2 邪魔をしない環境(environment)
足をひっぱる人のいない空間、
自分がやりたいと思ったことを実行する１日１時間、
やりたいことをやれる空間（例えばgithub, dockerhub）
3 もう一歩先に行ってもいいよという助言(advice)
やったことをいいよと行ってくれる先生、先輩、知人
代替案候補を提案してくれる顧客
参考にするとよい資料をしめしてくれる専門家
ぼくの先生 プログラマになるまで
https://qiita.com/kaizen_nagoya/items/53e4bded9fe5f724b3c4
顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818
まとめ(summary)
小説家の仕事の仕方は、パッケージソフトウェアのプログラマのような場合が多い。
どのお客さん向けに書くかは、書く側の選択で、当たるところを狙わないといけない。
それに対して、お客さんから頼まれてプログラムを書く仕事は、
ソフトウェアのマニュアルを書いたり、その会社の規則を作ったりする仕事に似ているかもしれない。
飛び抜けた人でなければ、前者の仕事で成功しないかもしれないし、
５年後、１０年後しか売れないかもしれない。
日銭をかせぐには、言われたものを書く、単価の安い仕事をこなすしかないかも。
飛び抜けていかなければ、長期的には仕事を競争で取られてしまうかもしれない。
とんなに小さな領域でも、飛び抜けているのでなければ、仕事でプログラムを書く価値はない。
飛び抜けた人が、自動生成してしまうかもしれない。
飛び抜けることができるためには、才能と努力と環境の３つのうちのなんらかの組み合わせがいいかも。
小説家が６５歳を超えても書き続けるように、プログラマも６５歳を過ぎても書き続けてもいいというのをまとめにしてみます。
仕事上、設計が３割、試験が３割、教育が３割、その他１割です。
一緒に仕事をしている方は、設計が８割、試験が１割、その他１割という感じの方が多い感じです。
立場の違いによって、見えていることが違うため、ここに書いていることがピンとこないこともあると思います。
飛び抜けた人が、自動生成作っても、お金にならないからと捨てられたのを目撃したことがあります。
実情としては、飛び抜けた人の半分くらいは、傷心して業界を去っている感じです。
官庁の飛び抜けたプログラマも半分くらいは、官庁を辞めています。
IT企業、製造業、官庁から去る、飛び抜けたプログラマの比率は同じくらいというのが経験則です。
逆に、伸びている企業は、飛び抜けた人の仕事をうまく生かしているように感じています。
DataRobotという機械学習のシステムに、ソフトウェアを追加して業績をあげているある会社は、
マスコミへの情報開示を禁じていて、詳しく書けないのが残念です。
マスメディアの情報に振り回されないことも、飛び抜けた人を育てる土壌の一つかもしれません。
参考資料(reference)
ぼくのかんがえた さいきょうの新人研修
https://qiita.com/aosho235/items/23625cdb340eaaeb5b94
新人教育の際に気をつけたこと
https://qiita.com/yu-croco/items/c41aa79a87fdbcf418fb
自己参照(self reference)
Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道
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
データサイエンティストの気づき!「勉強だけして仕事に役立てない人。大嫌い!!」『それ自分かも?』ってなった!!!
https://qiita.com/kaizen_nagoya/items/d85830d58d8dd7f71d07
作業改善(process improvement)
プロセス改善が改悪へと突き進む
https://qiita.com/kaizen_nagoya/items/0f3a1174f81935bb6d85
ペアプロの３つの種類
https://qiita.com/kaizen_nagoya/items/5c80663799d99b807870
ITシステムの見積もりの見積もり
https://qiita.com/kaizen_nagoya/items/93a7d3ba13da0a7a9c15
作業診断(process assessment)を成功させる５つの鍵。失敗する５つの罠
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 午後３時
ver. 0.02 仮説４若いうちしかプログラムは書けない。追記 20190222 午後４時
ver. 0.03 参考文献追記 20190222 午後９時
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 午後４時
ver. 0.14 仮説６ 飛び抜けた人を育てるのは難しい 追記 20190224 夕食前
ver. 0.15 マスメディアに振り回されない 20190224 夕食中
ver. 0.16 読書、官庁 追記 20190224 夕食後
ver. 0.17 表現訂正、URL追記 20190225 午前3時
ver. 0.18 Fラン文系によるFラン文系のためのFラン文系プログラマ /「Fラン文系」でも就職(プログラマ)できる５つの道 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
ver. 0.25 風をあつめて 追記 20210503
ver. 0.26 表記補正 20220421
https://b.hatena.ne.jp/guide/bbutton
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.