「人は激務を経なければ大きな成長をしない」に対する意見。もしくは不連続な成長をする方法。

はじめに

よく目にしたり耳にすることに「成長するために激務をこなす」とか「追い込まれなければ成長しない」というようなことがありますが、私はこれに関して異なる意見を持っています。このエントリではそれを整理しようと思った次第です。様々意見ありそうですが「私の経験を振り返るとこういう意見にたどり着いているよ」という話です。そして私が人を育てる時の方針はこの考えに立脚しています。

言いたいこと

分類	成長度合い	きっかけ	備考
習熟	低い	同じやり方で同じことを繰り返して結果を出す	要領が良くなって短時間でこなせることを成長と感じている
概念獲得	高い	今までとは違うやり方でより効果的な結果を得る	新しい概念を獲得することで成果の質が大きく変わる

言いたいことはほとんどこの表の通りです。私は大きな成長は新たな概念を獲得することによって起こると思っています。だから、新しい概念を獲得できるような余裕ときっかけを上手に配することで、不連続な成長を生めると信じています*1。

激務の時の多くの人の思考

激務になって追い詰められた時、今までやったことのない方法に手を出せる人は稀です。それができる人はある意味博打打ちでもあるし、強い精神力か鈍感力、もしくは勇気を持っているのかもしれません。多くの人は「知っている確実な方法で成果を出そう」とすると思います。そのため激務が続くと、同じやり方の反復をしようとする傾向が強くなります。

結果、あるやり方に習熟していきます。人間は慣れるとはやくできるようになったり、正確にできるようになったり、ミスが減ります。これももちろん成長したと言えるでしょう。ただし「その程度は成長としては緩やかなものだ」と言うのが私の意見です。

高い成長のために必要な事

より高い成長を求めるには、ある程度の余裕が必要だと考えています。自身が塾考するための時間はもちろんですが、先輩に教えを乞う事（先輩にも余裕がなければもちろんアドバイスをもらう事が出来ませんね）や、書籍を読むなどすることにも余裕が必要です。ごく一部の優れた人は外部からの刺激無しに新しい方法を編み出すでしょう。しかし多くの人は他人や書籍など何がしかの「外部からの刺激」をきっかけに新しいことに気づくのではないでしょうか*2。

私も含めて多くの人は激務に追い詰められると上記のようなことができなくなってしまうようです。つまり何の助けもなく激務に放り込まれるだけでは多くの人は成長できないと考えています。

例

何がしか例示しないと伝わりにくい話をしていると思うので、もう少し具体化を試みます。

プログラミングでポリモーフィズムをうまく使えるようになる話

プログラマの人にしか通じないかもしれないので申し訳ないのですが*3、プログラミングの例がパッと浮かんだのでまずはこれで。Rubyでサンプル書いてしまいますが、他言語の方にも伝わるようにある程度 Rails じゃない感じにしています。また、作業を行っている人はオブジェクト指向について勉強中なものとします。

前提

クラウドソーシングを行うようなアプリを作っていることを想像してください。User、Projectというモデルがあります。

# Userのテーブル（users）に対応したモデル
# すべての人が受注できる能力を持っているが、is_employer が真の人だけは発注もできるとする
class User
  attr_accessor :name  # ユーザの名前が user.name で取得できる
  attr_accessor :is_employer # 真を返す人は発注もできるよう申請をした人
end

# Projectのテーブル（projects）に対応したモデル
class Project   
  def owner
    # projects.owner_id の値からSQLを発行してUserのインスタンスを得るコードがあると思いねぇ。
    # user.is_emplyer が真のユーザが必ず返ってくるはず。
  end
end

そして上記のクラスを表示するような、下記のようなコードが100か所くらい（作為的でごめんなさい。とにかくたくさん使われていると思ってくだされ）。

<div>プロジェクトの発注者: <%=project.owner.name %></div>

仕様の追加

今回新たに「発注者であった人が、発注者の権利を放棄することができる」機能をつけるとします。その際今まで発注者として表示されていた名前の後には全て「（休止中）」と付けます。ただし、受注者のアカウント機能は今までと変わらず残っているので、users テーブルの name カラムを直接書き換えてしまうことはできません。

Userモデルは下記のように変わりました。

# Userのテーブル（users）に対応したモデル
# すべての人が受注できる能力を持っているが、is_employer が真の人だけは発注もできるとする
class User
  attr_accessor :name  # ユーザの名前が user.name で取得できる
  attr_accessor :is_employer # 真を返す人は発注もできる
  attr_accessor :is_retired # is_employerが真の場合にだけ有効。真を返すとこの人は元発注者で、休止中の扱いにする。
end

激務に曝されている人が陥る考え方

先輩に相談しに行って簡単なアドバイスを受けるも、よく分からない概念を調査したり知ったりするコストが大きく思えて、期日に間に合うようには思えず、放棄します。 結果「if文、100個入れる」と判断をします。下記のようなコードのように100か所の変更をする判断です。

<div>プロジェクトの発注者: <%=project.owner.name %><% if project.owner.is_retired %>（休止中）<% end %></div>

1. 影響範囲もかなり広いので、テストも含めて何日かかかると考えて、見積もる。
2. Pull Request を送ると、レビュアーの先輩が時間をかけてレビューする。先輩はこの実装が微妙だとは思うが既に時間をかけて書かれてしまったコードを突き返すわけにもいかず、いくつかの抜け漏れを発見した後「とりあえず大丈夫じゃない？」とマージする。
3. デプロイ後、抜けに何点か対応して安定。
4. 上記のようなことを何回か繰り返して、影響範囲の考え方や、このシステムでの 落とし穴には詳しくなり、なんとなく成長したと思う。

余裕のある人にできそうな方法

先輩に相談しに行って簡単なアドバイスを受けます。ポリモーフィズムという言葉やデコレーターのような言葉を教わり、調査を始めました。書籍なども調べてデザインパターンを確認してみます。 どうやらそれらを使えば根っこの一箇所でうまくやるだけで全てを修正できるとわかりました。

class ReiredEmployer
  def initialize(user) 
    @user = user
  end

  def name
    @user.name + '（休止中）'
  end
end

# Projectのテーブル（projects）に対応したモデル
class Project 
  def owner
    # projects.owner_id の値からSQLを発行してUserのインスタンスを得るコードがあると思いねぇ。
    # user.is_emplyer が真のユーザが必ず返ってくるはず。
    if user.is_retired 
      # is_retired が真なら userをデコレートした`ReiredEmployer`を返す
      RetiredEmployer.new(user)
    else
      user # 通常はuserを返す
    end
  end
end

Viewの変更はありません。

1. 画面の簡単な確認で終わると判断し短期間で達成できると見積もる。
2. Pull Request を送ると、レビュアーがごく少ない変更コードを確認して、素早くマージする（この仕組みなら一箇所のView確認でうまく動くならほとんどがうまくいく想定ができるため）。
3. デプロイ後、抜けなどなく、安定。
4. 以後は同様の変更なら誤り少なく対応できる方法があると知る。以前に比べて確実な対応ができる能力の向上を成長と感じる。

ここでのポイント

前者は「抜け漏れがそもそも存在する可能性を残す方法」を、習熟によって正確さを増すように 頑張る アプローチ。後者は「抜け漏れがそもそも存在しない方法」を新しい概念として獲得するアプローチ。後者の方がはやく正確に作れる概念を身につけられました。 ある程度の余裕があったから、調査したり理解をして今回の仕事に導入もできました。先輩にも余裕があったため、アドバイスも適切に受けられたことでしょう。

言い訳

User#name に Viewの情報である （休止中） を教えてしまうことが気になってしまう人は、何か良さげな例を教えてくだされ。ただ、大事なのはそこじゃないことはわかっていただけるはず。ごめんなさい。

おしまいに

もうちょっと良い例もありそうなんですが、ちょっと力尽きてきたので、これくらいで。 新しい概念を獲得するために、よく考えたり試したりすることこそが大きな成長の鍵だと思います。それは激務だからできることではないと思うのです。なので、成長と激務を並列に並べて表現することには違和感を覚えてしまいます。もちろん、ある種の責任感によって成長が促進されることはあり、それが仕事の中によくあるというのは当然同意しています。

ちなみに今回出したコードの例は、内容を変えてはいますが似たようなものが実際に最近弊社の中でもあった事です。

*1:私が上手に配せるかどうかはまた別問題です。今も試行錯誤を続けています

*2:この気づきは無限の時間があれば、その人も辿り着ける感覚のはずですが、それを大きく短縮させるのに外部の刺激が役に立っていると考えるのが正確な表現だと思います

*3:私のブログをプログラマではない人が読むのは稀なので良いでしょう

量産型の話から思った老齢世代がやってこなかったことのツケ

medium.com

「『（コード）量産型』プログラマを撲滅したい」ですよね？「『量産型プログラマ（ジムみたいな）』を撲滅したい」ではなく。まぁ、いっか。 こちらを拝見して思ったことを書いてみます。

コピペプログラマって現場にそんなにいるんですか？

というのが最初の感想です。今の現場って「コピペはしないほうがいい」と知っている人の方が大多数だと思っていました。私の観測範囲が狭いからかもしれませんが、ガンガン積極的にコピペする人そんなにいない気がするんですよね。なのでこれが問題だという意識は私にはあまりありません。

※ 逆に初学者の人なら、私はコピペでも何でもまず動かして知ることが沢山あると思っています（どんなに綺麗に書かれていても、動かないシステムはダメだと私は思っています）。現場ではこれをやらせませんが、勉強している人はまずやってみるのも大事です。

今の課題って「一定以上の実力を持っている人が少ない」ではないでしょうか

現場の課題はこれだと私は思っています。「良い人いない？」とよく聞かれますし（そしてその要望に合致するような人はなかなかいない）、「Railsのスクールで勉強しました」だけではうまくいっていないのは言わずもがなでしょう。もちろんこの人たちの中に、数年後立派なプログラマーになる人がいる可能性はあります。今の要求には答えられないのかもしれませんが。

どうしてこうなった？

私たち老齢なプログラマ*1がやれなかったことのツケが今の時代に残り続けているのだと思っています。

現場目線では下記のような感じですかね。

1. 「職人だから」のような都合のいい理由をつけて適切な教育を行なってこなかった。
2. 上記のために、人が育つ文化を作ることも、仕組み化をすることもできなかった。
3. 育てるためのマインドやノウハウを持っていないチームばかりになった。

経営者目線ではこうかなぁ。

1. 普通に仕事をするだけで一杯一杯で、社員に余裕を作ることができない。
2. 新規に人を雇うにしても、育てる人材をアサインすることができない。
3. 結果、新人が来ても放置するので育たない。
4. ヘッドハンティングでしか有能な人材を獲得することができない。

ちょっと違う切り口だと、スタートアップのようなビジネスの考え方は「経営者より優秀な人をこそ雇え」なので、既に優秀である人にしか興味はなく、これから優秀になる人に成長時間をジックリ与えるようなことは難しいんですよね。それは事業のスタイルが「短期決戦で総力戦を常に展開する」からです。私が若い頃にはあまりなかった経営方針なのですが、こういう世の中の流れも影響しているでしょう。

もちろん上記は私の経験からの推察なので別の考え方もきっとあると思います。

過去、個人としては現場レベルでどうにかしようとしていて、自分の周りでは人が育つようにしたかったです。下記の話のイメージです。

ms2sato.circlearound.co.jp

ですが、世代としては負っていたはずの義務を怠ってきていたのだろうと感じています。特に今は経営者であって開発者でもあるので、どっち目線で考えても耳が痛いです。

じゃぁ、何をするべきなの？

文化を作ることじゃないでしょうかね。チームで仕事しながらメンバーが育っていくことが素晴らしいと思える文化。経営者ならそれを推進して社員に育てる余裕、育つ余裕を作ってあげることでしょうし、現場なら、まだ育っていない人のモチベーションを下げずに成長してもらえるようなフォローアップの環境とか。

さらっと書いていますがそんなに簡単ではないと思います。育てることは投資なので、短期的利益を目指したらできません。投資の回収見込みが立たなくてもできません。このケースだと、毎年の売上を至上命題にしていたらできないですし、入社した方が3年で辞めてしまうような会社でもできないんですよね。

つまり経営者としては長く居ついてもらえる会社を目指すことが最初のアクションになるはずです。それと「人を育てられる人」への評価を高くする必要があります。これでお給金を高くしようとか残業せずに帰れるようにしようとか考え出すと、もはや針に糸を通すような感じの話になるんじゃないでしょうか。私もまだまだ挑戦中で、十分なところまではたどり着いていないです。育てる時間に低下する売上をカバーするのに助成金探してみたりとか、ホント泥臭いことやっていると思います*2。

あとは育てるのを外注するのも短期目線では良いかもしれません。ただし、あまり外に依存してしまうと社内の文化やメンバーに馴染めない形ができてしまうので、特効薬として使うようなイメージでしょうか。チームビルディングと教育は繋がっていると私は思う為、異質すぎるものを導入するとかえってうまくいかないこともありそうです。

弊社だとトレーニングの事業をやっている都合上、人を育てるノウハウは持っていますし、先輩が後輩をトレーニングすることは本業の修行にもなるので、やるべきことだと位置付けることができます。あとはもう少し効率良くできたらいいなぁなどと悩む日々です。

おしまいに

ダメだダメだという前に、やれることをやっていきましょうよ。

*1:35超えたら定年と言われますからね（笑）40の私なんてもう定年退職なのに嘱託社員で働くお爺さんみたいなものです

*2:注意：助成金も売上にはカウントされないので、やはり短期的な成績としては下がってしまうことを受け入れないといけません。少なくとも会社が潰れたり、余裕が無くなる事を回避する手段としては有効だと思っています

確からしい内容を共有したいのです。できれば喧嘩せずに。

qiita.com 年明け早々こちらの記事がかなりバズっていました。記事の内容自体が「前提を共有せずに理由なしに斬って捨てる」だったのと、タイトルが「初級者のため」と付けながら内容が「中級者になろうとしている、もしくはそれ以上向け」であった為に、読んだ方の期待値との落差がかなり激しいものでした。

qiita.com

その後、私が上記の記事を書いたのですが、その裏側で私が考えていた事を記しておこうと思います。qiitaは技術を行う人同士が研鑽を積むために利用するべきと思うのと、こっちならあまり人目に触れすぎない安心感があるのでエモい内容はここに書いておくことにしました。

私の考えた事

私の見た目に、元記事は一定の良い内容が含まれる反面、通常の開発の想定では逆に落とし穴になること（ex. 全てをアロー演算子で書く）が項目に挙がっていたり、for文についての内容があまり推奨できるものでは無かったりするなど、「概ね良いが、良くないところも混ざっている」内容だと感じました。

普段こういう記事についてはそっ閉じして無かった事になるのですが、はてなブックマークを見ていると気になるものがあったんですね。ある種の諦めの混ざったような「JavaScript自体が難しい」という発言や「多数違反しているけれど、やったらまずいのか」という困惑です。ある程度修行した人なら「どんな前提ならどこまでを信じて良くて、どこまでが良くないか」がわかるのだと思います。

プログラミングは難しいかもしれないけれど、人が勝手に決めたルールに従おうとして苦労する必要はないし（意義のあるルールならもちろん従うべきですし、チームのルールは大事にすべきです）、一喜一憂する必要などないと思います。混乱したり諦めてしまうようなことが私はあまり好きではありません。そう促す外部の存在も好きではありません（この辺りの話とリンクしそうですね）。

そして嫌だ嫌だと言う前に何か行動するのが良いと思うので、言葉を発する前に何かをしようと決めました。

マサカリ？

こういう時に力のある人が「それは違うよ！」するのを マサカリを投げる （参考 ）と言ったりしますが、もともと何かを否定し合う関係って好きじゃないので、否定記事を書く気はありませんでした（私が権威も力も別にないということも、もちろんあります）。物事を好ましい状態に持っていく手段は、なにも否定したり戦ったりすることだけじゃないと考えたいからです。 そうでなければ何でも喧嘩したり権威に訴えたりしないと実現しない世の中になって、とっても面倒だと私は思うのです。

あと、年始から技術ライターさんのツイートに対して何か殺伐としていたりして、こんな心境だったんですね。

なんか年明けから殺伐としているなぁ。仲良くしようよ〜。

— 佐藤正志 (@ms2sato) January 3, 2017

なので補足記事を書きました

はてブを見るとかなり多くのコメントに「理由がない」を挙げています。ここに乗っかると色々とやれることがありそうに見えてきました。この時の私が考えたことは以下です。

• すでに私が背景を納得できているものに関しては噛み砕いた理由を示す。禁止ではなく判断の指針を示す。
• 可能ならより深い勉強のための参照リンクやキーワードを入れる（リンク先への感謝を忘れずに）。
• 私が別の考えをしているものや前提が曖昧なものには疑問を投げかけるか放置。無理に筆者に寄り添うことはしない。

あとは博識な方々が有効な情報をくださるだろうと考えていました。結果色々とご意見頂いて、ブラッシュアップしながら進めることができたと思います。元記事の作者さんは存じあげなかったので、どのような反応をされるかわかりませんでしたが、大変好意的に受け入れてくれたので助かりました。ありがとうございます。

ちなみに元記事の作者さんが「解決編」を用意している可能性があったのですが、コメントからそういう想定では無いと伺えたので、この行動に一定の自信を持って進めることができました。

答えを教える？

こういった文書について「考えさせずに答えを教える行為だ」と思う方がいるかもしれません。ただ、私は「何について考えるべきか」を重んじたいです。今回の内容の多くは「JavaScriptの処理系が昔から抱えている意外な落とし穴」や「最新に追いつくための手法」なので、一回どこかで目にして「あぁ、そういうことあるんだね」くらいで十分だと思っています。落とし穴が気になるならlintなりで抑制できることもあるでしょう。lint使うにもAtomのプラグイン入れるだけでも可能なので手軽さ優先ならこれでも良いはずです。

本当に考えることが必要なのは、概念の獲得だと思います。どう設計するとバグが少なくできるかとか、処理を分割する際にはどう気をつけると共通化しやすい処理になるかとか、抽象度が高い処理とはどのようなものかとか、バグの潰しやすいデバッグの方法はどういうことかとか。そういったことを考えるために、時間と脳のリソースを確保しておくべきです。

あくまで「何をよく考えるべきか」という切り口ですので、全く理解せずに記事を鵜呑みにせよと言っているわけではないとご理解ください。

記事・タイトルの書き方

よく記事のタイトルはバズらせるようにワードを仕込んだり表現を工夫するように提示されています。ただ、読者の期待値と食い違い過ぎるタイトルに価値があるのかは疑問です。今回のエントリも「中級者になりたい人向け」などとなっていたら、ここまで脊髄反射的にブックマークされることもなかったはずです。返信コメントも別の形になったことでしょう。 もしくは最初に前提とする読者像を書くべきだったかもしれませんね。

初級者という言葉

私が考えるのはこんな感じかな？上の方はどこまでも上があるでしょうが、概ねこんな感じかと思っています。

• 初心者: まだ内容が良くわかっていない。提示されている内容を鵜呑みにしてしまったり、本の内容を写してみたり、とにかく試行錯誤しながら何かやっている段階。
• 初級者: より良い方法はわからなくても、とりあえず自分の望む動くものが（仕様を自分で調整したりしながら）ある程度作れる。「何をしたら良いか」が判り始めている。
• 中級者: 基本的なことは身について、より良い方法を求めている。他人から依頼されたり、仕様を外から決められたものもある程度作れる。哲学を獲得しつつある。
• 上級者: ある程度自分なりの哲学を持ってメリット・デメリットを判断しながら進めることができ、外部からの怪情報に惑わされることはあまり無くなる。周囲の他の人が気づいていない考え方に気づいたりする。

その観点で行くと、元記事は「より良い方法を求めている」に近いことをやっていると思うので、中級者に思えるのです。

おしまいに

自分で率先して記事を書いていくよりも、誰かが投げかけたものにレスポンスする方がうまくできそうな気がするので、こういうこともたまにはやってみようと思います。できれば喧嘩せずにやっていきたいものです。

プログラミングは難しい

uxmilk.jp

このエントリ、ズバッと言っててすごく良かったです。乗っかります。

プログラミング習得には時間が掛かる

プログラミングを学ぶのに私がかけた時間は初期の方だけ数えても

• 中学くらいでたまに数時間ずつ使って数ヶ月で完成させた簡単なBASICのゲームらしきもの（もはやゲームじゃなかった）
• 大学二年くらいから触り始めたVBでのプログラミング。その後VC++。 年単位で同じアプリをこねくり回していた。
• それから大学院卒業までの4年程度は趣味として、研究データを編集する道具として、かなりの時間をプログラミング（コードを書くことももちろん、書籍を買って読んだりすることなど含めて）に費やしている。
• 大学院出てからは一年間はWEBのシステムを開発するために、一年間活動している時間はほとんどLinuxの設定やPerlのコードと格闘した。

結構費やしていると思います。断続的ですが数年単位の時間がかかっていますね。その後お金を稼ぐプロになってから15年この仕事をしています。今も記録更新中です。

これだけ時間をかければ大抵のことはある程度上達すると思います。

プログラミングにおける成長曲線 〜 必要な忍耐

成長曲線についてですが、もともとは下記で書いていたことで、拙いながらもこの内容は今でも初心を思い出すための大事な記録です。

最初の成長は頑張っただけ伸びることができないものです。ある一定の経験を積んでからいきなり伸び始めます。私が多数の方の学習を見てきた経験上、伸びることができない長さに影響しそうなのは下記のような要素だと思っています。

• 考える訓練ができているか
  • 物事を突き詰めて考えることや、一つ一つ丹念に確認することに慣れていない人は、集中力が続かないので成果を出しにくい
• 調べ方の訓練ができているか
  • インターネットから必要な情報を得てそれを問題に適用することができないと成果を出しにくい
• 大きな問題を小さく分解できるか
  • 大きな問題をいきなり解決するのはとても難しいので、今対応している問題を小さな単位に分解できることが必要です
• 簡単な英語が読めるか
  • エラーメッセージは英語。本当に簡単でいいので英語を読めること。英語が出たらすぐ閉じる癖の無いこと。

上記は結構な忍耐が必要なタイミングがあります。脳みそがオーバーヒートしそうな程考え込むことも、エラーの原因がわからなくて頭を抱えることもしょっちゅうです。

「簡単」という嘘

「簡単に学べる」と言っているのは、全体の大きな山のうち最初の丘を越えるくらいの部分のことを指している事が多いと思います。そしてそれをあたかも大きな山を登頂するようなミスリードを生む宣伝が存在することは否めないでしょう。

逆に言うと、一ヶ月二ヶ月ちょっとやっただけでその人のセンスは判断できないとも思っています。元記事では自分の頭が悪いと諦めている例がありましたが、それはまだまだ早過ぎる判断ではないでしょうか。

簡単に始められるけれども、しっかりと身につけるには時間がかかると思って取り組んで欲しいです。

どうすればいいの？

私のところに相談に来る人には、一見「プログラミングの習得にかなりの時間がかかるだろう」と感じられる方もいます。「スクールで学んだけれどよくわからなかった」という経験を持つ方もよくいらっしゃいます。「スクールが教えてくれないのでトレーニングして欲しい*1」 という依頼まで受けました。

それでもその人に合わせたやり方を取ったり、問題の粒度を調節して一歩ずつ進んでいけばちゃんと上達していきます（かかる時間についてはマチマチになりますが、放っておくよりは諦めずに続け、成果にたどり着く確率は確実に上がっていると思います）。先述のように「急に一気に成長し出す」モデルになるので、理解を1個ずつ積み重ねるとある時いきなり繋がって回り出す気がします。

そして下記のようなことが大事ではないかと今は考えています。

• 学習の時間を十分に確保する
  • 時間をかけないと難しいので、時間を確保しましょう。短期間に一気にやる方が良いです。最初はすぐ忘れてしまうので、定着するまでは詰めていく形です。
• 忍耐が必要なことを理解して取り組む
  • 問題に当たるのは当然です。プロでも毎日問題を解決し続けて進んでいます。それが日常だと知ってください。
• 問題を適切な大きさに分解して取り組む
  • 大きな問題を小さく分解できれば解決出来る可能性が上がります。そうして一つずつ解決するんですね。

時間の確保以外の部分は、実は人が介在する方が良いことが多いです。つらい時に「今つらい。どう進めたらいい？」と相談できるのは大事ですし、問題を分解するのに一定の経験を必要とすることは多いでしょう。また「そこを掘り下げても今は実りがない」と伝えてくれるのも人の素晴らしいところです。 プログラミングの習得にはこういう部分で人の介在があった方が良いと感じます。より多くの人がストレスを減らしつつ学ぶにはこれらがポイントになるのではないでしょうか。

イメージとしては「うまくいかなくとも簡単に諦めてしまわない」ように組み立てる必要があります。

諦めてしまうケース

ところが元記事では下記のような最終的に受講生が自身の能力を疑って諦めている形で締めくくられているシナリオがあります。

Aさん「えっ、そうなの。一般的にはプログラミングは簡単なのでしょうね。私が馬鹿なだけで。」

Bさん「プログラミングは簡単だと持っていたけれど、どうやら僕が馬鹿だっただけみたいだ。」

これは最悪の結果です。「初期の成長が遅いんだ」という自身の特性への理解ならまだしも「簡単なこれすらも受け入れる能力がなかった」という拒絶で終わってしまうと感じるからです。

私はAさんもBさんも（実在してはいないと思いますが似たような方が世の中にたくさんいると思っています）、訓練次第でやれる人になると考えたい派です。

最初の一歩二歩がうまくいくと自立していける人は世の中に結構いるはずなのですが、その１歩目、２歩目の時点の躓きをカバーする方法があまりないのですね。

「努力していないから」「時間を確保していないから」はまだ理由として納得できる部分はあるものの「能力がないから」という理由にはあまり納得がいかないのです。

気づいている方もいらっしゃると思いますが、 事業者側の目線に立てば、短期的な利益を目指すなら最初に高い金額をまとめて納めさせて早々に諦めさせるのが一番大きな利益になります。辛くても継続してもらうには人的なコストが最も必要なところでしょう。諦めても良いのであれば、受講生に合わせることを拒絶すれば簡単だと思います。どんなに丁寧なドキュメントを用意しても初めてプログラミングをする人にとってはイメージしずらかったり、誤った理解をしてしまって袋小路にはまるものなんです。この話は機会があったら別のところでしようと思います。

難しいのはわかった。それでももっと早く成長できないか？

今は良い世の中になったので、わからないことを聞ける場所も多数できましたし、WEB上に情報もたくさん出ています。私が本格的にやり始めた20年前とは比べものにならない程良い環境になりました。

私も自分なりに色々とやっていて もくもく的にやったり、マンツーマンしたり、動画を利用したり、と試しているところです。成長したい期間や求めるゴールによって様々な手段がありそうです。

最後に

大変なことも多いかもしれませんが、難しいものを解き明かして作りたいものを実現するのは快感ですよ！是非それを感じて欲しいと思います。

*1:訳がわからないと思いますが私もわかりませんでした。念の為当該スクールに確認いただいて了承いただいた上でトレーニングはさせていただきました。デモデイ的なもので入選されていて、サービスもリリースできた様子です。

古い友人との話。振り返ってわかること。

盆休みでもあったので、旧友Sと一杯飲んできた。彼は関東にいるけれども少し遠くにいるので、最近はお互いの中間の都市で待ち合わせて飲んでいる。

私の人生の中で学生から社会に出る数年の間、一緒に最も多くの酒を飲み、最も多くの馬鹿話をした相手だ。下手すればこの時期は家族よりも過ごした時間が長いかもしれない。

最近はお互い歳をとったのか、今だから言えることのような話も出たりする。その中での話。

「でもさ、サトちゃんみたいなヤツだから今社長とかやってるんだろうね。」

「？」

「高校の頃とか、Iみたいなカリスマのある奴っていたじゃん？でも彼らって『そこに組織があるから選ばれやすい』タイプだと思うんだよ。」

「ふむ？それってどういうこと？」

「俺とかお前ってあの当時基本的には二番手ポジションだったけど『俺はこうだ！』って常に出し続けてたのはサトちゃんだなって思ってさ。俺とかそうでも無いし。社会に出たら組織が無い所から始めない限りまずトップにはならないんだから、『俺はこうだ！』って出せなければ何も始まらないと思うんだよね。カリスマのあいつも組織の中で登って行くタイプなんだなって。」

「あぁ、そっか。そんな気もする。」

「だから今こうしてるのは結構当たり前な感じがするんだよ。」

こいつはいつもそうだ。こちらからは見えないどこか高い目線から俯瞰したことをサラッと言ってのける。忌々しいヤツだ。私は過去カリスマに敬服して喜んで二番手三番手を続け、社会に出てからもどこかで私を屈服させる存在に出会えることを期待した。そして出会えなかった。だから結果的に今の場所にいると思っていた。ひょっとしたらそれはちょっと違うのかもしれない。

いつも新鮮な切り口でモノを語ってくれるから、こいつとの時間は貴重なのだ。一時間やそこらの時間をかけて会いに行く価値のあるヤツだ。

「サトちゃんはこうやって時間作り続けるの偉いよな。」

「俺には家庭がないからだよ。奥さんや子供がいないからできるんだ。」

「10代や20代なら時間有り余ってるし、時間作るとかみんな言うけど、40になって仕事も忙しいのにそうそうできないって。大抵ついでがあるからやってくれたりするもんだ。」

「優先度はあるよ。Sはそれだけのモノを俺にくれているって事だ。」

「そんな感じはしないけどなぁ。」

私が受け取っているもの（と、ちょっとした嫉妬）を彼はあまり理解していないのかもしれない。だが、それは大きな問題ではない。 出会った人の印象や状態は年月と共に変わる。その中で、この人には時間をかけたいとか、それだけの価値があると思える事にはあまり妥協しない方がいいような気がする。

中には時が止まっている願望に囚われていたり、関係が変わって欲しくないと思い続けている人がいるかもしれない。でも、変化を許容し、その上で価値を見出し続けられる相手にこそ時間をかけるべきではないか。「過去の一時期、同じ場所にいた」それだけではないから長く続く関係が築けるのだと思う。

Sの奥さんも呼んでくれているそうなので、今度はやっと一歳になる彼の子供に挨拶がてら遠征するのも悪くないな。

システム開発とプログラミングの狭間

はじめに

プログラミングを知らない人がプログラミング教育をする危険性 - WirelessWire News（ワイヤレスワイヤーニュース）

こちらを拝見していたのですが、内容自体に関してはちょっと置いておいて、少し前からひっかかっている言葉のことが脳裏によぎりました。実はこの言葉の感覚について他人と話したことはないので、私だけが勝手に思っていることかもしれませんし、ひょっとしたら誰かが既にちゃんと整理してくれているのかもしれません。もしも何かシッカリした解説があったら教えて欲しいです。

私の思うこと

下の写真のイメージ感が伝わればなあと思っているのですが、プログラミングはコードを書くことを中心にした部分だと私は捉えているので、システム開発のごく一部の部分です（「プログラミング」という言葉の示す領域を一旦表現したい）。

まず最初に「プログラミングの根幹になっているアルゴリズムなどはあるものの、システムを開発するという文脈からすると普段これらはかなり抽象化されて気にしないレベルにされている」という感覚を伝えさせてください。

例えば、WEBシステムを作成している方はSQLを書いている時にorder byを使ってソートすると思いますが、これの中身がどんなソートになっていて、どういうSQLの場合にどれがふさわしいかとか理解している人はそれほど多くないと思います（私も勉強不足のため、存じ上げません）。 また、自分でソートアルゴリズムを実装する場合、ネットワークの方がメモリ上のアルゴリズムの速度よりもはるかに遅い現在の（あくまで現在の話です）WEBシステム運用環境において、ソートのアルゴリズムを何にするかは多くの場合優先度は下がっていると言えるでしょう。もしも既に何かのソートが提供されているならそれを使う（開発効率を上げる）ことを望まれることが多いと思います。 当然ですが、それはソートがどんなものか知らなくて良い理由にはなりませんけれども。

さらにRailsのような秀逸なフレームワークのおかげで、開発において考えなければいけない設計や、よく利用する実装の部分もどんどん考える必要がなくなってきています。「Railに乗るようにする」という言葉が表すように、最近の私たちはオリジナルのクラス構造を編み出す事が少なく、型に嵌ったようにシステムを作ることが良いとされてきていると思います。昔の自分ならそれを設計することが当たり前だった部分が既に提供されているのですね。楽になったけれど一番面白かった部分は無くなってしまったとも感じています。

そうして「プログラミングの根幹」たる部分はどんどんフレームワークに隠されています。システムのコードはフレームワークに乗っかって作成されるので、フレームワークを上手に操作することが良いシステム開発だと暗黙に了解している節があります。開発の効率を目指すならばこれは正しい判断なのでしょう。

ところで改めてシステム開発全体を見ると、プログラミングが担う部分の他に、サーバの扱いやネットワークを構築すること、CIやデプロイに関すること、運用を効率化するための仕組みづくりなど、周辺の要素が多数あります。RailsのようなWEBフレームワークを初学者が学ぶ際には、フレームワークの学びからどんどんプログラミングの根幹へ向かう方向性よりも、周辺の要素の方が重要になります。まずシステムを動かす体験を得てもらうことが大切になるためでしょう。

元記事では「プログラミングを教える」と称して営業されている話が書かれていますが、某T（どこかは存知あげませんが、当たりはつきそうです）の実態としては「システム開発を教えようとしている」だろうと私は理解しています。ですからフレームワークの操り方を中心に教え、簡単なデプロイまでを行うようなカリキュラムではなかろうかと推察します。

営業としては世間によく知られている言葉を使う方が顧客にリーチできるので、「プログラミングを教える」という言葉を使うのは当然なのかもしれませんが、本来は「システム開発を教える」ではないでしょうか。自分のところでやっているトレーニングに「WEBプログラミング」と付けているのも同じような理由ですしね。

ちなみに私が今回の違和感に最初に気づいたのは、どんなものが作りたいかをトレーニングの受講生からヒアリングした時です。プログラミングがどんなものか知りたいだけであれば、私のオススメはJavaScriptです。環境構築せずにブラウザさえあればプログラミングをすることができ、HTMLがどんな風に変化するのかを見た目で確認しながら学ぶことができます。システム開発がどんなものか知りたければ、Ruby（いきなりRailsかどうかは置いておいて）やPHPを薦めるでしょう。言語をどれにすべきかはその人がゴールとしてやりたいことで決まります。脱線するのでこの話はここで止めます。

おしまいに

自分の考えている言葉のニュアンスの違いを示そうと努力してみました。

でも実際「プログラミング」という言葉の領域って私が思っているよりもズッと広いのかな。それとも分けようとし過ぎ？世間でも「プログラミング教育」なんていう時に、それがどこまでを示そうとしているのかなと思ったり。もやっとしたまんまで終わりますが、誰に伝えるでもないブログなので答えがなくても勘弁してくだされ。

私について

言葉の話は持っている背景や文化によって違うと思います。 一応私の技術のバックグラウンドと考え方をだらだら書いておくと、中学生の頃にMSXでBASICをいじったのが最初で、大学の一般教養でC言語やったけどつまらなくてVisualBasicでWindowsアプリ作ったりしてるうちにVC++など弄り始めて、学校出てからPerlでCGI書いたらWEBは結構楽しくて、仕事始めたらWEBのJavaが中心で業務の為のフレームワークのコードばっかり書いて、phpのWEB開発の手伝いしつつガラケーのアプリのプロトをC++で書いてみたり、リッチクライアント的な流れでFlexやら.NETやらやってJSでSPA的なの書いてるうちにnode.jsとかも手を出してめっちゃカオスだけど、二年くらい前にJS中心はちょっと置いといて最終的にはチーム開発をRails使ってやっていたりする、そんな奴です。

言語はあんまり選り好みしません。「ロジックちゃんと書けるなら別になんでもいいんじゃない？」くらいに思っています。チームメンバーが使いやすいのに合わせます。チームの成果の最大化が自分のミッションになることが多いので、自分の開発効率だけで物事判断しません。ちなみに自由気ままにやれるなら、まずフレームワークを作らせて欲しいと駄々こねるでしょう。

人を育てることが会社の方向でもあって自分もやりたいことなので、最近は「お客様に提供するでもなく、趣味でもない」という領域でプログラミングすることも増えてきました。レビューばかりする事も増えたので、たまにガッツリ好きな趣味のコードを書きたくなります。

見て覚えるでもなくマニュアル渡すだけでもなく、本質や概念を適切に掴んでもらうことが大事。

はじめに

www.recomtank.com

こちらを拝見していて考えたことを綴ってみます。 とても勿体無いと感じてしまったので、私なりに整理したいと思いました。

私のスタンス

• 後輩は私よりも早く成長して欲しいです。私が20年かけて体得したことを若い彼らがより短期間で体得することが、人の進歩を生むと思っています。40歳近い私と同じことが30歳より前にできたらそれは10年以上の飛躍です。物凄い価値創出だと思います。
• 願わくば早く私よりも「現在望まれていること」に関してはできる人になって欲しいです。そして私にも最新のことを教えて欲しいです。
• 過去の経緯はロートルの私の方が知っています。それは私が彼らを補ってやれば良いことです。
• これを繰り返せば、人の成長はもっと加速します。加速した成長の結果「今の私には解決できないような問題を解決する人を輩出するのだ」と信じています。例えばAIやロボットが当たり前になった世の中で新しい価値を創造するのは、私のようなオッサンではなくて若い後輩達に間違いありません。

マニュアルがあれば良いのか

まず、単なるルーチンについて、マニュアルはあって良いと思っています。 操作そのものは文書化されていればミスも減りますし、人に伝える際に情報へのポインタを示すだけで委譲できるからです。端的に言えば「全部あれこれ説明するなんて時間がかかる」「見真似で勝手に想像でやれば抜け漏れが出る」と考えています。

身につけるとは何か

私は「本質・概念を獲得する」だと考えています。細かい操作を暗記することは身につけているとは言えません。それは単純に記憶しているだけだからです。その結果不測の事態に対応できないことになります。逆に本質を獲得している人は、今まで起こったことのなかった事態にも、新たに編み出した適切な対策を行うことができます。

手取り足取り教えること or 放置して勝手に身につけさせる「だけじゃない！」

さて、この話題で見落とされていると私が感じるのはこの点です。元記事でも言及されているのですがこの部分の強調が弱く、感情論が先に立っているように見えて、とても勿体ないのです。

• 教えると、考えない。
• 教えない為に何も示さず、見て覚えろ。

この二つには大きな飛躍があります。私も手取り足取り教えることには反対です。ただし「見て覚える」という不確実な方法で果たして本質が掴めるのでしょうか。掴めるとしても多大な時間をかけて会得するのではないでしょうか（「私のスタンス」にも書きましたが、私はこの時間をかけることをすっ飛ばしたいのです）。

大事なことは本質や概念をいちはやく獲得することであって、細かい操作を暗記することではありません。

どうしたら良いの？

本質や概念を獲得するには「自分の頭で考えて、明瞭な形で落とし込むこと」が必要だと考えています。 これはとても大事なことです。そしてそれが短時間で行われるように促すことは先輩がやって良いし、やるべきだと私は思います。「何について沢山考えるべきか」知っているのは同じように悩み苦しんだ先輩だと思うのです。

つまり

• 先輩は全てを手取り足取り全てを教える必要はありませんし、それはやってはいけません。
• 先輩のやるべきことは「本質や概念を獲得する為の大事なポイントについて考えてもらうこと」です。
• 本質や概念に到達するまでの思考の道のりが長い場合には適切な単位で到達ポイントを区切ってやること。

さて、二番目の話は少し抽象度が高いですね。もう少し具体化します。考えてもらう為に下記のようなアクションがふさわしいと私は考えています。

• 考える材料になる適切な体験をしてもらうこと。
• 適切な質問を投げかけること。それに対して十分な理解が感じられるまでは問答を続けてやること。
• ルーチンではない本質の理解が必要な課題を与えること。

よりスムーズにするには

上記の内容は、実は学ぶ側からするとストレスの高い行為です。それは考えることを強いる為です。考え続けることに慣れていない人はその疲れを解消することができず、モチベーションが酷く下がってしまいます。考えることを放棄したり、わかったようなフリをしてしまうのです。

その為モチベーションの維持が大切になります。これはいろいろなシーンで言えることなので、また別の機会に。 ちなみに私は先輩や指導者のやることの殆どはモチベーションを上げることだと思っています。理不尽にやる気を削ぐ先輩は碌な先輩でないとすら思っています（もちろん「相手のモチベーションをあえて下げてでも伝えなければいけない大切なことはある」と認めた上での話ですよ。誤解なきよう）。

おしまいに

物事を二元論で表現している時は、別の切り口を考えると本質に近いことがよくあると私は思っています。