今回は、「数学、競プロ(競技プログラミング)、マラソンマッチ」、「ソフトウェアのドキュメント」、「ウェブで読めるIT関連の読み物」の3つについて話したいと思います。
数学、競プロ、マラソンマッチ
まず、「数学」、「競プロ」、「マラソンマッチ」の3つの関係について説明したいと思います。「競プロ」は、一言でいうと厳密解(最適解)を求めるゲームです。なので、問題の入力が同じであれば、解答プログラムの出力も同じになります。有名なコンテストサービスとして、TopCoderのSRMなどがあります。一方で、「マラソンマッチ」は、一言でいうと近似解を求めるゲームです。最適解を得るためのハイパーパラメータ値やアルゴリズムはわからないので、それらを試行錯誤していくことになります。また、Kaggleなど「データ分析コンペ」と言われるものがあり、そこでは最適モデルを競い合います。「マラソンマッチ」も「データ分析コンペ」も近似解を求めるものですが、「マラソンマッチ」と「データ分析コンペ」の違いはたぶん機械学習の使用有無の傾向で、「マラソンマッチ」では機械学習はあまり使わないですが、「データ分析コンペ」だと機械学習をよく使う印象があります。
「数学」は「競プロ」や「マラソンマッチ+データ分析」の基礎、土台みたいな感じです。HUNTER x HUNTERで言えば、念能力の源がオーラであるように、「競プロ」や「マラソンマッチ+データ分析」の知識の源が数学です。なので、数学に強い人は競プロやマラソンマッチ+データ分析に強い傾向があるように思います。理論派やじっくり派の人は高校数学や大学数学を勉強して、競プロ、マラソンマッチ、データ分析コンペとやっていくのかなと思いますが、実践派やすぐやりたい派の人は競プロ、マラソンマッチ、データ分析コンペの具体的な問題に取り組んで、一問一問から必要となる知識を学習していくのかなと思います。
実際にやってみるとわかりますが、自分自身の知識不足で解答を理解できないということに遭遇することがあります。こんなときは、Twitterを活用するのがいいです。コンテスト終了直後には、自分の成績や自分の解法をつぶやく人がTwitterにたくさんいます。なので、ハッシュタグをつけてつぶやいたりすると、誰かが教えてくれたりします。また、自分から問題を解けた人へ積極的に質問をするのもいいと思います。
ユーザーごとにレートがあって、ある程度やって知識・考え方が十分に定着してやっとレートが上がるという感じなのでなかなか根気はいりますが、「○○色になる！」という目標や「解けなかった！悔しい！」という感情、レート推移やランキングなど始めてみると意外とゲームのようにハマります。
数学やゲームが好きな人はきっとプログラミングコンテストも好きになると思います！が、登山と同じで、自分がいる標高が高くなればなるほど道が険しくなってきて一歩一歩進むのが大変になります。とはいえ、それだけ「わかった！」「できた！」の喜びも大きくなります！いきなり上位を目指すガチ勢にならなくても(=人生のすべての時間を投入しなくても)まずはカジュアルに取り組んで(=休日に数時間取り組んで)新しいことを学ぶ楽しさを感じられれば最高ですね。
ソフトウェアのドキュメント
突然ですが、皆さんに質問です。
「最強のエンジニアとはどんなエンジニアですか？」
何を最強と考えるかで、人によって色々な意見が出てきそうです。
「あるソフトウェアにめちゃくちゃ詳しいエンジニア」
「つくりたいものをつくれるエンジニア」
「誰かがつくってといったものをつくれるエンジニア」
「誰かがなおしてといったものをなおせるエンジニア」
「膨大な経験によってエラーの原因が一瞬でわかるエンジニア」
「新しい言語や規格、ソフトウェアをつくれるエンジニア」
「コマンドやショートカットを使いこなして作業速度がめちゃくちゃ速いエンジニア」
「つくったものがたくさんあるエンジニア」
「作り方をたくさん知っているエンジニア」
「いい作り方を知っているエンジニア」
これらに共通するのは何かと考えるとなんとなく「知識」のような気がしてきます。
それも「ソフトウェア」についての「知識」
となると、あるソフトウェアについての知識が一番ある人が、あるソフトウェアについての最強エンジニアということになります。
そこで、以下のように、あるソフトウェアについての知識量によるグループ分けを考えました。
①そのソフトウェアをつくった人(=作者)
②そのソフトウェアのソースコードを全て読んだ人(=壮大な何かを企んでいる人)
③そのソフトウェアのドキュメントマニュアルを全て読んだ人(=ソフトウェアオタク)
④そのソフトウェアのドキュメントマニュアルの一部を読んだことがある人(=ふつうのエンジニア)
⑤そのソフトウェアのチュートリアルをやったことがある人(=初心者)
⑥そのソフトウェアの名前だけ知っている人
⑦そのソフトウェアの名前を知らない人
あるソフトウェアについて、「上にいけばいくほど詳しく、下にいけばいくほど詳しくない」ということになります。
ソフトウェアを複数人で分担してつくっていた場合は②と①が逆転するかもですし、ソフトウェアが大規模になってくると、そもそも②の人がいないこともありえそうです。
最初の出発点は⑥で、あるソフトウェアについての最低限の知識はそのソフトウェアの名前だと思っています。
そして、「ドキュメントの一部を読んで何かやる」ということをやることで知識が蓄積されていき、最終的に③になったら、そのソフトウェアについては和了となるのかなと思います(もちろん開発が終了されるまではバージョンアップで機能追加されたり機能修正されたりするので、現実的にほぼ和了はないですが)。
開発をたくさんやって、すなわち「ドキュメントの一部を読んで何かやる」ということをたくさんやって、ソフトウェアについての知識を蓄積するのも大切ですが、「ドキュメントマニュアルを全部読む」というのは知識を最大化するという観点からすると一番効率がいい気がします。ひとつソフトウェアを決めて、隙間時間などにそのソフトウェアのドキュメントを読み進め、全部読むということをやってみてはいかがでしょうか。
www.gnu.org
git-scm.com
docs.docker.com
spec.openapis.org
www.postgresql.jp
gradle.monochromeroad.com
mybatis.org
docs.spring.io
oohira.github.io
ウェブで読めるIT関連の読み物
ソフトウェアドキュメント読み進めの気分転換にどうぞ！
cruel.org
practical-scheme.net
practical-scheme.net
www.yamdas.org
practical-scheme.net
