What a wonderful world

　以前Anubisさんのコラムで「迷い人オーバーラン」という記事があった。その中でAnubisさんは、「仕事を早く進めるために必要なことは、迷いをなくすことだ」と述べている。

　仕事を早く進めるために必要なこと。それは迷いをなくすことだと思う。
　迷いをなくすことで大きく2つの利益がある。1つは迷って悩んでる時間が省けることだ。その分、精神力も消費しないで済む。もう1つは、正しく判断できることだ。思考がぶれないので、その分判断の精度は増す。
　迷いは精神的なものとして片付けられることが多い。しかし、迷うには必ず原因がある。原因が必ずあるので、細かく解析していけば必ず解消できる。迷いを随時解消していけば、ストレスが少なく迅速に仕事が進むようになる。それができれば理想的だ。

　では、どうすれば迷いを払拭して仕事を進められるのか。それに想いをはせたとき、「熟慮断行」という言葉が浮かんだ。

先人が成し遂げた熟慮断行による勝利

　「坂の上の雲」という歴史小説がある。司馬遼太郎が書いた日露戦争の話だ。2009年から2011年にかけて、毎年年末にNHKでドラマも放送された。

　その「坂の上の雲」の主人公に秋山真之という人がいる。日露戦争において、日本海軍の参謀として活躍した人だ。

　彼は、日露戦争においてロシアの海軍を迎え撃つに当たって戦略を練りに練って、それを実行し、ロシアの海軍を撃滅する。それに当たって、彼は世界中の戦略に関する書物を読み漁り、研究に研究を重ねたという。ドラマでも、彼は入院中に日本中世の水軍の書を読み、訪ねてきた女性にその話をするというシーンがある。

　ありとあらゆる戦略を学び、その要点を把握したうえで最良の戦略を立案し実行した。そんな秋山真之が揮毫した書が彼の出身地である松山にあるのだが、そこに書かれていた言葉が「熟慮断行」である。

システム開発における「熟慮断行」

　そうした「熟慮断行」という言葉が、Anubisさんの言う「迷いを払拭する」ために必要ではないかと感じた。

　では、僕らはその「熟慮断行」を行うために何ができるのだろうか。

　これは僕の持論ではあるのだが、

• 顧客の要望を押さえる
• 顧客の業務を押さえる
• 業務を扱ううえで必要となるデータを押さえる

ということが必要になるのではないだろうか。

　システム開発をお願いしてきた顧客はいまどういった問題を抱えているのか。それをどうやって解決するのか。まずはそうしたビジョンを定める。

　次に、そのビジョンをどうやって業務の形にしていくのかを決める。必要な業務は何か。それをどうやって回すのか。

　そして、その業務ではどういったデータを扱うのかを決める。

　当たり前といえば当たり前のことであろう。もちろん、こうした「ビジョン」「業務」「データ」をしっかりデザインしても実際に作る段階で、これが足りないというものは出てくるだろうし、「業務」や「データ」をデザインする段階でも、いろいろと意見は出てくるだろう。

　しかし、その「上の概念」が定まっていれば、ぶれずに進んでいけるのではないか。そして、その「上の概念」を決めるところに「熟慮」が必要であり、実際に決まったら、その概念を実現させることを「断行」する。そうしたことが必要ではないかと思うのだ。

不安を払拭するために、確信を持つこと

　先に紹介したAnubisさんの記事では、こうも書かれている。

　不安は放っておくと増大する。不安が多いと迷うようことも増える。こういう状況で仕事をしていると、大きく作業効率を落としたり、突然の大失敗につながりやすくなる。
　そんなことで、迷いに対してアプローチを行うことは、業務を円滑に進めるうえで重要ではないだろうか。もちろん迷いに対してアプローチするには、迷ってる人に対して大きく関わることになる。労力もそれなりに必要だ。しかし、それだけの価値はあるはずだ。
　業務の進捗を管理するように、不安や迷いを管理してはどうだろうか。確かに管理をしにくいものではある。しかし、ノウハウを積んでいけば、いろいろな対処方法を編み出すこともできるかもしれない。決して無理ではないはずだ。

　その、不安や迷いを管理するためには、確信が必要になると僕は思う。もちろん、確信というものは、すぐ得られるものではない。だが、熟慮を重ねて得た結論を基にして進む。その結果を確認して次へ進んでいく。そうしたことをくり返していくなかで確信は深まっていくであろう。そして確信が深まるほど、不安や迷いが出てきてもすぐに進むべき道を見いだせるのではないだろうか。

■問いかけ

　「あなたはどうやって技術を学ぼうとしていますか？」

　どうすれば技術を身につけることができるのでしょうか？どれだけ学べば技術が身につき、仕事ができるようになるのでしょうか？

■今回の本

　いつもありがとうございます。たのっちです。4月も3週目となりました。新入社員の方はこの時期研修を受けているところでしょうか。

　4月の頭、毎年そうなのかもしれないですが「この本を読め！」というブログが出てきていました。

　そのブログを読んで、「この本イイ！読んでもらいたい！身につければ相当の力がつく！ ……でも、それまで自分でプロダクトを作ったりしていなかったような人には、このレベルは高いよな」と思いました。

　私がIT業界に入った頃のレベルで、それらの本を読んでも理解できないと思ったからです。では、どうすればこの業界に入ってから技術を学び始めたエンジニアが力をつけることができるのか。

　今回は慶応義塾大学准教授　井庭崇先生の「ラーニング・パターン」を通して、どうやって技術を学べばよいか・私はどうやって学んできたかを紹介していきたいと思います。

■「まねぶ」ことから始めよう。

「まなぶ」（学ぶ）という言葉は、「まねる」（真似る）と同じ語源であり、「まねぶ」とも言われていたという。そのことからもわかるように、自分が真似したいと思う人のやり方を「まねぶ」ことから始めるのは、学びの基本である。その人のやり方にまずはつかることから始めよう。もし、手本となる人が近くにいるのであれば、教わり上手になることで、さらに多くのことを学ぶことができる。しかし、いつまでも真似ていては、自分のオリジナリティを発揮することはできない。最終的には、自分で考えることで、そこから卒業することになるのである。

　プログラム言語でもインフラでも、まずはやり方を学ぶ必要があります。それは職場の先輩や本から学べるでしょう。とはいえ、話を聞くだけ・読むだけでは分かった気になるだけです。写経する。プロダクトを作る。仕事で使ってみる。そのなかでやり方は身についてくるでしょう。
本は読んだ量だけ知識がつきます。そこからアウトプットを出した量だけ知恵になります。やればやるほど力はついていきます。

■広がりと掘り下げの「T字」

「Ｔ字」のような広がりと掘り下げの実現には、量は質を生むということが深く関係している。「広がり」のためには、いろいろな分野・テーマのことを把握する必要があり、「掘り下げ」のためには、徹底した知識・スキルの習得と実践が必要となる。また、鳥の目と虫の目をもち、全体と部分の視点を行ったり来たりすることが重要となる。

　.NETを学びました。それなりに書けるようになりました。ではそれで大丈夫かというと、そうは行きません。DBの知識・UIの知識・設計の知識・業務の知識、他にもいろいろな分野の知識が必要になってきます。
　それらの知識も入門レベルの学びだけでは、入門レベルの力しかつきません。よりレベルの高い本・詳細に踏み込んだ本を読むことが必要です。

　そうやって学んでいくうちに、スキルの質が変わってきます。また、特定のフェイズでのみ考えるところから、いろんなフェイズでの視点・それらをまたいだ視点で考えることができるようになります。

■小さく生んで大きく育てる

誰でも、最初から突き抜けることはできない。どんなに大きな成果でも、最初は小さな成果から始まっており、小さく生んで大きく育てることに成功したのだということに気づくことが大切である。小さく生んで大きく育てるということは、一見するとプロトタイピングやアウトプットから始まる学びに似ているが、それらと違うのは、ここで生み出したアウトプットは、たとえ小さくとも、単なる「試作品」ではなく、1つの成果だということである。この成果を積み重ねていくことで、セルフプロデュースの材料とすることができるだろう。

　技術書を読むところでも、プロダクトを作るところでも、最初から高い目標を掲げてやることはできないでしょう。「この本を読め！」エントリの本を読んで理解するには、相応の力が必要だと考えています。

　技術を学ぶ場合は入門レベルから積み上げる。プロダクトを作る場合でも、最低限の価値を提供できるところから始めたほうがいいと思っています。

　IT業界のトップランナーである多くの先輩も、それぞれはじめの一歩がありました。そこから長い時間をかけて技術を磨き、多くの人とふれあい知識を共有して、成果を積み重ねています。いま、世の中で多くの人が使っているサービスも同じです。ローンチから今日まで、長い時間をかけて多くの人のフィードバックを受けながら成長しています。

　

勉強会に出てトップランナーの話を聞く。その姿に憧れ「いつかああいう風になりたい」と願う。それならば、いま自分が学びたいことを学び、その気づきや成果を発信し積み重ねていくことが必要だと思います。

■私の学び

　私の場合、少し時期が遅れてこの業界に入りました。最初に入った会社は出向メインの会社でした。そこで先輩社員からプログラムの書き方・DBの扱い方を学んでいましたが、その先輩社員が私の入社１ヶ月後に辞めてしまいました。

　また、入社した時期がリーマンショックの直前だったこともあり、すぐに案件がなくなるという自体になりました。そこで自社サービスを立ち上げるという話になったため、自社にこもって黙々とサービスを作る日々が続きました。

　その状況のなか、とにかく技術書を読みました。読んで得た知識をサービス作りに使っていました。その会社に在籍していた2年間で読んだ技術書は40冊。その大半の本は「まねぶ」ことをしていました。そのおかげか、いまではプログラマとしてはそれなりの技術を身につけることができたと思っています。

　とはいえ、まだ道なかば。突き抜けるにはまだまだこれからだと思っています。

■学ぶことを止めるな！

　1つのプログラム言語を学んで書けるようになるだけでも、相応の時間はかかります。ましてや、幅広い分野の知識をつけアウトプットも出すとなると、さらに時間はかかります。勉強会で講演を聞いて、講演者と自分のレベルの違いに愕然とすることもあるでしょう。それでも学び続けていくなかで、その時の講演者のレベルに近づいていくことができるでしょう。

　ときには会社や上司に失望することもあるかもしれません。それでも学ぶことを止めないでもらいたいのです。

　IT業界の仕事は学んだ分だけ価値を提供できるものです。私がお世話になっているエンジニアの方が、昨年のITコミュニティ夏祭りにてこのようなことをおっしゃっていました。

勉強会に限らず、今のIT業界とエンジニアたちに取り巻く環境ってやったことに対する加点が評価得られる。
失敗したことに対する減点ではなく、プラス評価。
なんかやったらいいんですよ。
失敗しても失敗したら教訓が得られるだけ。
私たちと一緒にやろうよ。
[ITコミュニティ夏祭り2011に同僚と計8人で参加してきた]

　何かをモノにするには1000時間かかると言われます。簡単にはできませんが、取組めば必ずできます。この春IT業界に入ってきた皆さんにはまず1年、仕事も学びも本気で取り組んでほしいなと思っています。そのなかで見えてくるものがあります。

　

その1年が終わったあとも、継続的に学び続けてください。この素晴らしい世界のことが、少しずつ分かってくるでしょう。学ぶなかで得た気づき・経験を発信しましょう。あなたの経験は、誰かにとって役立つものです。その人の喜びはいつかあなたに戻ってきます。

　

そして、それらに情熱をもって取り組んでいってください。そうすればきっと、あなたの憧れのエンジニアのようになれる。僕はそう信じています。