やり始めた経緯

CREというポジションは、コードをガッツリ書く事が少なく、顧客から上がってきた仕様の確認や調査の依頼などの対応が多いため、プライベートでコードを書く時間を増やしたいなと思い始めたのがAtCoderでした。

たまに、改修タスクをこなすのですが、実装する際の思いつく処理のパターンが少ないこと、処理を書く前の言語化があまりできていないこと、PHPの関数をそもそも知らないなどこういった課題もあったため、とりあえず始めてみました。

やってみてよかったこと

上記で述べたように、コードを実務ではあまり書いていない、またPHP自体も今まで触っていない事もあり、レベルとしてはAとBから始めています。（Aでも解けない問題がちょくちょくあり、悔しすぎてAをやり込む流れに…）

まずは、自分のレベルに合った問題から解き始めることをお勧めします。徐々に少し上の問題を解くことは必要だと思いますが。

ちなみに、僕の場合、AtCoderのABC過去問をメインに解いています。（現段階ではレーティングなどは気にしてやっていない）

以下にやってみてよかったことを列挙しました！

PHPの関数を知っている→使えるようになった
言語化の解像度が上がった
実装する際の処理のパターンを前より増やす事ができた

PHPの関数を知っている→使えるようになった

これはやり始めて感じた事なのですが、いざ実装を始めると「あの関数を使おう」とか出て来ないんですよね。自分の頭の中にインプットできていないものから検索をかけてもそもそも、物を知らないため検索のしようがないわけです。もちろん、今はGoogleさんがいますからそこで検索を掛ければいいわけですが、実装する中で基本的な関数を毎回調べて使うのも面倒であり、時間もかかります。僕は新しい語彙を増やす際、「認知語彙」と「使用語彙」を意識するのですが、これと同じことがPHPの関数にも言えるわけです。使用語彙を増やすには、認知語彙を増やす必要があり、認知語彙を増やすには、そもそもの触れる機会を作る。このサイクルを繰り返すことにより、少しずつ認知語彙が増え、結果として使用語彙も増えるわけです。

新しい問題を解く度に、知らなかった関数を知る事ができ、少しずつその過程を繰り返すことで使用関数が増えることを実感しました。

言語化の解像度が上がった

僕は処理を書く際、一度言語化してから処理を書き始めることを意識しています。理由は単純で、日本語で説明できないことはコードレベルに落とし込む事はできないからです。抽象→具体へ解像度を上げるのに、抽象の材料が抜け落ちてるとそもそも具体化できないよねって話です。

去年CREというポジションについてから、カスタマーサポートから上がってきた問い合わせ（エンジニア視点だと、抽象にあたる）から具体に落とし込んで挙動の確認や処理の流れなどの確認を行うわけですが、このとき必要な材料がないとそもそも具体に落とし込むことも難しくなります。（問題の切り分けが難しくなるため）

これと同じことが、処理を書く際もいえると思い、AtCoderの問題を解く際は、ひたすら言語化を繰り返しました。

面白いのが、AtCoderの問題は問題文を読解する力も必要なわけで、ここから解像度を上げるためには最初の読解で如何に必要な情報を正確に拾い上げ、理解することができるかが重要なわけです。ここで躓くと処理もうまくいきません。

こんな感じで、抽象⇄具体の訓練を繰り返し、少しずつ言語化もできるようになっていき、コードレベルに落とし込めるようになってきました。

実装する際の処理のパターンを前より増やす事ができた

AtCoderに限った話ではないかもしれませんが、自分が解いた問題を他の方も解いていることもあり、自分では思いつかない方法で解いてるコードもあります。それらを読み解き、理解し、次の実装で試すということを繰り返していると自然と自分のコードパターンが増えていきました。「この問題はこのパターンで解くこともできるけど、これはどうだろう」という感じで、思考パターンが増えたので、これを増やすことであらゆるテストケースにも対応できる力が身につくのかなと考えています。

改善点

やり始めて色々課題が見えてきたので、今後はその辺を意識しつつ、レベルアップしていこうかと思います。

言語化がまだまだ抽象的であるので、コードレベルに落とし込むために何が必要でどういった処理を書きたいのかを具体化していく
実装する際の処理パターンをもっと増やせるようにする

今後の方針

とりあえず、100問は達成したので、次は200問を目指していこうかなと思います。A問題に取り組みつつ、B問題にも取り組んでいく方針です。今年中にB問題は余裕で解ける、C問題は解けるものと解けないものがあるレベルにはなりたいなと思っています。