「アクアビット航海記」では、個人事業主から法人を設立するまでの歩みを振り返っています。
その中では、代表である私がどうやって経営や技術についての知識を身につけてきたかについても語っています。
経営や技術。それらを私は全て独学で身につけました。自己流なので、今までに数えきれないほどの失敗と紆余曲折と挫折を経験して来ました。だからこそ、すべてが血肉となって自分に刻まれています。得難い財産です。
本稿では、その中で学んだ技術の学び方を語りたいと思います。
私自身が試行錯誤の中で培ってきたノウハウなので、これを読んでくだった方の参考になれば幸いです。
ただし先に断っておきますと、私の技術力などそれほど大したものではありません。しょせんは独学ですし。
今までに参画してきた常駐現場では多くの凄腕技術者を見てきました。私が最近棲息しているkintone界隈でも私より技術力の優れた人は無数にいます。
そのため、技術力だけで考えれば、私など手本にする価値はありません。
私が皆さんにお伝えできるのは、最小限の努力で必要な技術を身に付ける嗅覚です。それは備えてきたと思います。本稿ではそれを参考にしてもらえればと思います。
モチベーション
ずばりいうと、私の技術へのモチベーションは、面倒くさがりから来ています。さらに飽きっぽさと。
例えば仕事で何か面倒な作業が必要になったとします。
そう、Excelのブックからブックへの転記のような。
これ、一回や二回ならまだいいのです。でもそれが十回繰り返されてくると、とたんに繰り返しに飽きてしまうのです。そして作業が面倒に思えてしまうのです。これは毎日、同じ場所に通勤する営みについても同じ。
そうなると、この面倒くさい作業をやめるためにどうすればよいか、私の脳内がざわめきだすのです。
多分、新たな仕組みやアルゴリズムを考える労力の方が、繰り返す作業よりも大変なのでしょう。でもそんなことは関係がありません。それ以上同じ作業をしたくない。その思いの方が圧倒的に強いため、私を衝き動かします。アルゴリズムや仕組みを考えることは、繰り返しの作業とは無縁です。飽きないし面倒くささも感じません。本連載第二十五回で書いたように集計作業が面倒でExcelのマクロを作ったのはまさにこの実例です。
選ぶ
今までのキャリアで、私はさまざまな技術や言語に触れてきました。この言語や技術の選び方は、案外大切ではないかと思います。
私はどちらかというと新しいもの好きです。ところが、私のキャリアを振り返ってみると、言語や技術の選択に当たってそこまで冒険をしていません。
例えば、PCはWindowsとMs-Officeを主に使ってきました。サーバーを自分で構築する際も、ファイルサーバーはSamba、LAMP(Linux＋Apache＋MySQL＋PHP)でウェブ環境を構築してきました。CMSはWordPressを主に扱いました。クラウドにしても、βテスターとして関わり始めたころのkintoneは無名でしたが、運営元のサイボウズ社はそのころからすでにグループウエアの雄として業界に地位を確立していました。今やkintoneはわが国でも著名なPaaSに成長しています。
今までに私が携わった技術や言語の中で衰退してしまったものを挙げてみます。ファイルサーバーのSambaやその際にMacをつないだAppleTalk。サービス連携の言語はJSONではなくXMLを学びました。常駐先で触る必要があったLotus NotesやLotus Scriptは衰退の最たるものです。あとはLinuxでサーバーを構築した際、採用したDistributionのRedHat LinuxやMiracle Linuxも今はあまり聞きません。
若い頃に得たVisual Basicの知識やLampの知識が今も生かせることは、私のキャリアにとってとても幸運だったと思います。衰退した言語や技術の習得に使った時間が無駄にならずに済んだので。このことは私のキャリアを考える上でとても重要だと思います。
その際、私がどういう基準で言語や技術を選んだのかは、あまり覚えていません。ただ、その当時からシェアが高いものを選んだように思います。また、安価な環境で使える言語であることも重要でした。例えばスクリプト言語はphpであれば安価なレンタルサーバーでも使えましたが、pythonやgoはサーバーにインストールする必要があったため、学びの対象から外しました。
シェアが高いということは、サポートサイトも多いということ。サポートサイトを必死に読み込めば、たいていのヒントはおのずから公開されていることに気づきます。おそらく私はそれらを踏まえながら、自分の学ぶべき言語を選んでいったように思います。
この時に単に新しいからといって新奇な言語や技術にあまり手を出さなかったことが、私のキャリアをあまり回り道に進ませずに済んだと思います。
調べる
自分が知りたいこと、実装したいことをどう調べると効率的か。
これはとても重要なところです。私が自分でプログラムに関心を持ち始めたのは1999年。まだインターネットが世間に広く使われ始めたばかりのころです。今のように少し検索するだけで技術資料が閲覧できる時代ではありません。つまり、書籍が頼りでした。
書籍は、その分野の全てを語ろうとします。まず、総論から始まり、その後で個別の説明を展開していきます。私はそうした総論の類を読みません。まっすぐ自分が求める機能を探します。書籍の場合は目次や索引が付されていますので、そこから探すと目指す機能を学べます。
その機能の説明を読むと、自分の知らない事が次々に出てきます。メソッドや関数の記述。名前空間や言語体系。細かい文法など。それらを総当たりで調べていきます。その際も、名前空間についての総論は読み飛ばします。直接、該当する名前空間の書き方を探します。そうやって個別の自分の知りたいことだけを拾いながら、その積み重ねで全体を把握していく。それが私のやり方です。
ちなみに私は読書が大好きです。が、本を読む際は全く逆のアプローチをとります。途中の部分を読むなどもってのほか。必ず最初から最後まで通して読みます。ところが不思議なことに技術書を読む際だけはそのやり方だとうまく覚えられないのです。
私が技術の世界に触れ始めたころと違い、今はネット上から情報を得ることができます。ですが、その情報には書籍のような目次・索引がありません。つまり検索エンジンを使うしかないのです。この検索の際にキーワードを入力しますが、そのキーワードにもコツがあります。
技術の言語は国際的に英語が使われています。そのため、日本語だけで検索しても求める検索結果にヒットしないことがほとんどです。まず具体的な文言を英語も含めて検索します。また、エラーメッセージにあたった際はそのメッセージを検索文言に含めます。すると、求める結果が得られると思います。その際、英文が出てきたら大意ぐらいはつかめるぐらいの英文読解力があると楽です。その上でGoogle 翻訳やDeepLのような翻訳サイトを使って日本語で意味をつかみます。
なお、当たり前ですが得た結果をきちんと読解する力は必要です。私は文系学部で学んだ技術者ですが、読解力が私のキャリアを助けてくれたと確信しています。パッと読んで分かったつもりになってしまうと、結局遠回りになります。じっくりと文章を読むように心がけましょう。
実装する
この後の連載で、私がどのように実装の経験を積んでいったかは書いていく予定です。独立するまでにはかなりの回り道と試行錯誤と無数の失敗を繰り返しました。
日中は現場に常駐していた私が、個人の業務で無理せずに実装するにはどうすればよいか。全ては五里霧中の中でした。少しずつ実績を積み上げられ、しかも安価な投資額で実装環境が整えられるような案件を痛い失敗の中で少しずつこなしていったのが私のキャリアです。kintoneに出会うまでは。
私のように個人事業主から法人を設立するまでの歩みは、自分でいうのもなんですが、相当難しいと思います。
私のようにホームページの制作から始め、まずHTMLやCSS、JavaScriptを操るスキルを身に付け、そこからサーバーの選定や調達に進み、さらにphpなどの言語がデフォルトであるWordPressのようなCMSに手を染めていくと、キャリアとしてよいのではないかという気がします。この路線は、今のところまだ衰退の兆しがそれほどなさそうですし。
その際も、自分でサーバーを立ち上げ、LAMPをインストールし、AWSやGCP、Azureといったより高度な環境を選ぶより、まずは小規模な環境から始められる規模の案件をこなすとよいでしょう。要するに安価なレンタルサーバーでも十分要件が満たせるようなものです。
ブレイクスルー
とはいえ、ロジックの構築や予期せぬバグの出現など、実装にあたっては問題が生じます。
それをどのように克服していくかは切実な問題です。それで挫折し、折れた心を抱えながら情報処理業界からも去っていく人もいるでしょう。
そもそも、どれだけ本やウェブサイトを読んでも概念がちっともつかめない場合、どうすればよいのでしょう。正直、私にも概念がつかめずに苦戦したことが何度もありました。本連載第三十二回で書いた、行列のExcelからAccessの三次元を理解したのはまさにその一つ。
そこでも書きましたが、当時チームの部下だった年下のOさんに教えを請いました。そこで教えてもらったことで私は一つ目のブレークスルーを果たしました。この時、妙なプライドや自負があって独学にこだわっていたら、今の私はなかったと思います。
私はキャリアのほとんどを独学で積み上げてきたことに誇りも自負も持っています。ですが、今でもまだまだ分からないことが無数にあります。今の私がそうした事態にぶつかった時、二回り以上も年が離れた部下に教えを請い、頭を下げられると確信できます。しょせんは私のキャリアなど独学であり、正当に大学で情報科学を学んだ方には絶対に勝てないことが分かっていますので。
ブレークスルーを果たすには、自分の中で突き詰めて考えることは必要です。でも、概念を理解するためのちょっとした気づきを自分の中だけで得るのは難しいでしょう。その時、相手が誰であろうとヒントを与えてくれる方には頭を下げ、謙虚でいられるかどうか。それが出来る技術者こそが、年配になっても現役でやれる人だと思います。
加齢による好奇心の枯渇
かつてはプログラマー35才限界説、というものがまことしやかに言われていました。35才を超えるとプログラマーとしては使い物にならない、というやつです。
この説はある部分ではあたっています。ただし、それはアルゴリズムの構築が35才を迎えた途端にできなくなる、という意味ではありません。当たっているのは年齢による体力の問題です。それはどうしようもありません。徹夜でコーディングする作業は40歳を過ぎると難しくなるのではないでしょうか。
むしろ、ロジックの組み立てをきちんと自分の頭で考えた経験を35歳までに積んでいることのほうが大切かと。そうした経験があれば、60歳の半ばであっても第一線で問題なくやれると思います。身近にその生きた例を知っています。私自身、50歳の声が聞こえ始めていますが、まだやれると思っています。
また、今の言語はフレームワークなども充実しています。また、基本的なアルゴリズムについてはライブラリが豊富に用意されています。そのため、それを呼び出すだけでよいのです。加えてkintoneのようなPaaSを使えばデータベースの構築や通知・権限設定も手間をかけずに実装できます。
そうした意味ではプログラマー35才限界説とは、かつて情報処理業界の言語や環境が発展途上だったころの名残だと思っています。ちなみに私は文系学部の出身なので、文系プログラマー限界説にも反対の立場です。女性エンジニアの方も優秀な方が多いので、男性だけが優位というのも間違っています。
ただし、それ以外に限界説が当てはまる人はいます。それは体力の問題ではなく、心の柔軟さの問題です。肉体とともに心は徐々に柔軟さを失っていきます。実年齢が30歳であっても、自分が持っている技術や環境から学ぼうとしないと、35才よりも前に限界を迎えます。上に書いたように、自分より詳しい若手に頭を下げられるかも限界の年齢を決めるでしょうね。
例えば新卒で情報処理業界に入り、会社が用意してくれた既存の業界や言語や環境の中で安定した仕事をこなしていたとします。その状態に甘んじて新たな言語や環境を学ぼうとしなかったとすれば、老いはより早くあなたをむしばむはずです。そして気が付いたときには技術者としての活躍の場がない、という悲劇に遭遇します。
私自身、今からDeep LearningやMachine Learning、ブロックチェーンや3Dプリンターを学ぶには億劫な思いを感じます。概念は大体理解しているつもりですが、それを新たな実装として試してみようとする気概が出てきません。私にも間違いなく老いは忍び寄っています。
それを防ぐには好奇心を持ち続けるしかないと思います。これは私の価値観ですが、仕事だけが毎日ではないと思います。さまざまなプライベートの趣味や出会いや楽しみを持ち、仕事以外に多様な刺激を受けるような環境に身を置く。それが40代50代になって少しずつ効いてきて、あなたの身を助けてくれるはずです。
まとめ
私なりに技術との関り方をまとめてみました。もちろんこれは私の例にすぎません。人によってそれぞれのやり方があるはず。ここに書いた内容を基に、皆さんがそれぞれの立場で取り入れられる点があれば、取り入れていただければと思います。
