はじめに
よく目にしたり耳にすることに「成長するために激務をこなす」とか「追い込まれなければ成長しない」というようなことがありますが、私はこれに関して異なる意見を持っています。このエントリではそれを整理しようと思った次第です。様々意見ありそうですが「私の経験を振り返るとこういう意見にたどり着いているよ」という話です。そして私が人を育てる時の方針はこの考えに立脚しています。
言いたいこと
| 分類 | 成長度合い | きっかけ | 備考 |
|---|---|---|---|
| 習熟 | 低い | 同じやり方で同じことを繰り返して結果を出す | 要領が良くなって短時間でこなせることを成長と感じている |
| 概念獲得 | 高い | 今までとは違うやり方でより効果的な結果を得る | 新しい概念を獲得することで成果の質が大きく変わる |
言いたいことはほとんどこの表の通りです。私は大きな成長は新たな概念を獲得することによって起こると思っています。だから、新しい概念を獲得できるような余裕ときっかけを上手に配することで、不連続な成長を生めると信じています*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>
- 影響範囲もかなり広いので、テストも含めて何日かかかると考えて、見積もる。
Pull Requestを送ると、レビュアーの先輩が時間をかけてレビューする。先輩はこの実装が微妙だとは思うが既に時間をかけて書かれてしまったコードを突き返すわけにもいかず、いくつかの抜け漏れを発見した後「とりあえず大丈夫じゃない？」とマージする。- デプロイ後、抜けに何点か対応して安定。
- 上記のようなことを何回か繰り返して、影響範囲の考え方や、このシステムでの 落とし穴には詳しくなり、なんとなく成長したと思う。
余裕のある人にできそうな方法
先輩に相談しに行って簡単なアドバイスを受けます。ポリモーフィズムという言葉やデコレーターのような言葉を教わり、調査を始めました。書籍なども調べてデザインパターンを確認してみます。 どうやらそれらを使えば根っこの一箇所でうまくやるだけで全てを修正できるとわかりました。
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の変更はありません。
- 画面の簡単な確認で終わると判断し短期間で達成できると見積もる。
Pull Requestを送ると、レビュアーがごく少ない変更コードを確認して、素早くマージする（この仕組みなら一箇所のView確認でうまく動くならほとんどがうまくいく想定ができるため）。- デプロイ後、抜けなどなく、安定。
- 以後は同様の変更なら誤り少なく対応できる方法があると知る。以前に比べて確実な対応ができる能力の向上を成長と感じる。
ここでのポイント
前者は「抜け漏れがそもそも存在する可能性を残す方法」を、習熟によって正確さを増すように 頑張る アプローチ。後者は「抜け漏れがそもそも存在しない方法」を新しい概念として獲得するアプローチ。後者の方がはやく正確に作れる概念を身につけられました。 ある程度の余裕があったから、調査したり理解をして今回の仕事に導入もできました。先輩にも余裕があったため、アドバイスも適切に受けられたことでしょう。
言い訳
User#name に Viewの情報である （休止中） を教えてしまうことが気になってしまう人は、何か良さげな例を教えてくだされ。ただ、大事なのはそこじゃないことはわかっていただけるはず。ごめんなさい。
おしまいに
もうちょっと良い例もありそうなんですが、ちょっと力尽きてきたので、これくらいで。 新しい概念を獲得するために、よく考えたり試したりすることこそが大きな成長の鍵だと思います。それは激務だからできることではないと思うのです。なので、成長と激務を並列に並べて表現することには違和感を覚えてしまいます。もちろん、ある種の責任感によって成長が促進されることはあり、それが仕事の中によくあるというのは当然同意しています。
ちなみに今回出したコードの例は、内容を変えてはいますが似たようなものが実際に最近弊社の中でもあった事です。
