プログラマーでも、弟子入りとか師事とかあっていいんじゃない?

プライベートアプレンティス

つい最近、
友人がプライベート運営してるサービスの開発に、
勉強のために若い方がお手伝い参加すると聞いて、
とっても良いことだなぁと思いまして。

色々な現場でよく言ってたんです。

「サービスを作りたい!」

って方は多いですが、
なかなか実力もきっかけもないときは、
開発環境の準備からいきなり手間取ったり、
そもそもの企画や画面設計やDB設計もあったり、
アーキテクチャ構築やプログラミングも
試行錯誤しながら...なんて感じで、
なかなか先に進みません。

その過程もすべて含めて楽しめるならいいですが、
あまりに期間が長いと人間だんだんモチベーションも減り、
しばらく止まってしまって挫折しちゃったり。

まだやり切る実力がないときに突っ込んでも、
なかなか効率も良くないから...

身の回りでそういうことをやっている先輩がいるなら、
一画面でも二画面でもいいから手伝ってみたら?

って。
その中で、学べることたくさんあって、
本当に自分がやるときの大きな糧になるはずです。
何か差し迫ったきっかけがないのであれば、
そういうことで充電してもいいんじゃないかと。

その先輩にとってもありがたいことです。
プライベートでやっているのだから、
手が足りなくて手が足りなくてしょうがない。
ノウハウを提供することで、
自分の手が少しでも楽になるのであれば良い話です。

これ「サービス開発」だけの話じゃないです。
周りにオープンソースコミッターがいれば、
「オープンソース活動を手伝う」でもいいし、
勉強会に参加したり運営してりしてる人がいれば、
「コミュニティ活動を手伝う」でもいいし。

別に自分のやりたいことと完全に一致しなくてもいい。
学べることは様々なところにあります。

そして、なんといっても、
「人同士がもっとい密接につながること」で、
プラスアルファな相乗効果があるとも思っています。

なぜかプログラミングでは聞かない

jfluteは、ドリフが大好きなのですが、
しむらさんがいかりやさんに弟子入りを懇願した
っていうエピソードが好きです(^^。
(まあ月並みのことくらいしか知りませんが...
その後も色々とあったみたいですけどw)

演奏家フィギュアスケートの選手などの
プロフィールでもよく「...を師事」とか見ます。

知り合いのダンスの先生も、
自身が先生という立場になっても、
「...先生のダンスを学びたいので習ってくる」
というのをよく聞きます。

また、こんなところでも、伝承があるなぁとふと思いました。
「優れたスポーツ選手がコーチを雇い、
トレーニングを欠かさないのと似ている!」(38ページ)
 => シリコンバレーの「何が」凄いのか | SlideShare

こういうの、プログラミングの世界では、
ほとんど聞かないことだなぁと。
まあ、あまり言わないだけであるかもしれませんが、
多くはない印象です。

もちろん、そういうプロの世界では、
ちゃんと金銭が発生してのことだったりするわけで、
一概に比較できるものじゃありませんが、
仕事の中の先輩後輩関係でさえも、
そういうことは少ないと感じます。

プログラミングの世界では、
「伝承」というのがとても弱い

それで総合的にロスしてることが
たくさんあるんじゃないかと考えるのです。

...

先ほどのサービス開発の例は、
「付き人になる」ってのが近いかもしれませんね。
プログラミングだと若くても貢献できることが
いくらでもありますから、
もっともっとGive&Takeがやりやすんじゃないかと。
いまやチャットとかでリモートやり取りもできるし。
別にずっとじゃなくて、三ヶ月だけ、半年だけ、
って期間を決めてもいいでしょうし。

属人性こそ伝承したい?

プログラミングの世界では、
「誰からも教わらず自分ひとりで成長するもんだ」
的な話をよく耳にします。

jfluteは、これに対して、
局所的な場面では正しいこともあるでしょうが、
大きな視野で見ると、ちょっと乱暴だと感じます。
というか、もしそうなのであれば、
「プログラミングって、そんなに簡単で浅いもんなんだ」
って思ってしまいます。

...

A + B = C

これてどの場面でもどの場所でも確定するようであれば、
それはもはや単なる定理で、
本やネットに書いてさえあればいいだけ。
調べるコツだけわかればいい。
そして、その定理を使って問題を解決していくのであれば、
そこの属人性は何もなく、ひとりで極められます。

もしかしたら、
プログラミングはそういうイメージがあって、
あまり人から学ぶ必要がないって感覚があるのかもしれません。
でも、そういう部分はどんどんツールが進化して、
人間がやらなくてもいいようになっています。

...

少なくとも昨今のプログラミングでは...

o Cであれば、...なメリットがあるが、ちょい不安
o Dであれば、...なデメリットがあるが、安定はしている
o Eであれば、...そもそも良いのか悪いのか論証に時間がかかる

というように、答えは固定ではなく、選ぶものになります。
つまり状況に応じた判断が必要になるのです。
厳密にはどれが良いとも証明できない、でも選ばないといけない。
これらの選択肢を洗い出して特徴を捉えること自体も難しい。

例えば、とあることを優先して C を選んだとしましょう。
別のところで...

S + T = U or V or W

似たような選択肢があって U がいいと思ったとします。
ただ、その場面においては U が良さそうに見えるかもですが、
先ほど A + B のところで C を選んでいます。
「そこが C なのに、ここは U なの?」って、
局所的な論理性では良さそうに見えることが、
全体のバランスを加味した論理性のを考えた時には、
必ずしもそうならないこともあります。
さらに M + N もあるかもしれません。
様々な論理がごちゃごちゃに入って、
まったく証明できない判断を繰り返します。

これはもはや論理性のデザインです

判断の連続を積み重ねてできあがる、
他に存在しない唯一の属人的な作品です。

プログラミングは、判断の連続です。
パズルを解いておしまいではありません。
パズルの解き方も重要かもしれませんし、
パズルを解くべきかどうかも疑わないといけません。
アーキテクチャデザインは、まさしくその最たるもの。

// プログラマーに求められるデザイン脳
http://d.hatena.ne.jp/jflute/20170623/desigraming

それは...

「先人からの伝承」と「孤独の実践」の
コラボでようやく乗り越えられるくらい

の難易度のものだと思います。

人に教えてもらってばかり...
ひとりでひたすら勉強してばかり...
どちらか片方だけ、なんて言ってる場合じゃないと。

// 両方だいじなんです
http://d.hatena.ne.jp/jflute/20150426/bothdaiji

「バランス感覚」というスキルこそ伝承したい。

...

【追記】
Facebookのコメント頂いたのですが、
そういえばこんな本ありました!
 => ソフトウェア職人気質 | Amazon

大昔、師匠に見せてもらったことあります。
あまり覚えてないので...改めてちゃんと読もうかな^^。
「メディア掲載レビューほか」のところに書いてある、

自分の「作品」に責任を持つソフトウエア職人

そういう心意気のプログラマー増えて欲しいですね(^^。

焦ることはない

すぐに自分の城を持ちたくなるのは、気持ちわかります。
本当に自分のやりたいことをすぐにやりたくなるのも、
よくわかります。

ただ、それは...
やりたいことを最終的に成就させたいのであれば、
「そのためにいま必要なことはなに?」
その選択肢の一つを、本日話題にしてみました。

ちょっと遠回りしたくらいで、
モチベーションが続かないのであれば、
そこまでやりたいことじゃないよ、きっと。
成功してる人たちは、
みな地味なことを続けてきた人たちばかり。

...

先輩は、あなたの成長のリソースです。

// こうはい extends せんぱい
http://d.hatena.ne.jp/jflute/20131124/extendsmaster

// お世話になってる先輩が登壇する勉強会くらい行ってみたら?
http://d.hatena.ne.jp/jflute/20161201/gotomeeting

「...さんのプログラミングの考え方や判断力を学びたいです!
色々と手伝わせてください」

って、フランクに盗みに行ってもいいと思うよ。