競技プログラミングの解説に必要な要素

AtCoderの解説についての議論があったので、考えたことを書いてみました。最近あんまりratedに参加していない中、外からなんやかんや言うのはあれなのですが、何かの足しになれば。
（私のアカウントは https://atcoder.jp/users/threecourse です）

解説に必要な要素

解説を構成する要素は以下だと考えています。

解法の実装の概要
解法の正当性の証明
解法をどうやって思いつくか

この中で核となるのは、「1.　解法の実装の概要」で、これがないと解説（解答？）として不完全であるように感じます。結局ACするには解法の実装が必要で、それに直接結びつく要素であるためです。

ABC170の解説 https://img.atcoder.jp/abc170/editorial.pdf についてtwitterが盛り上がったのは、この部分が省略されたからではないでしょうか。

手法をどのレベルまで説明するかといった粒度、手順をソースコードなどを使って詳細に説明するかどうかといった細かさは、難易度によっても変わるだろうし、また解説を書く人の趣味や優しさで幅がありうると思います。
例えば、DPで「DPテーブルを何と何をインデックスとして持ち、以下の更新式で更新していく」くらいの記述で十分なところ、低難易度であれば丁寧にDPの概念を説明することもできますし、高難易度であれば「この部分はDPでO（N)で求めます」で良いこともあるでしょう。

また、コーナーケースもここに含まれるのが基本かなと思います。コーナーケースを処理できないことにはACできないので。

なお、「1.　解法の実装の概要」を記述する積極的な意味として、他の部分の文章を誤解したときに正しい方向に戻って来やすい点があります。
例えば「～を思いつけば簡単にできます」と書いてあったとして、なるほどとACできることもあれば、実力がある人であっても日本語の意味の取違いで明後日の方向に思考が飛んでしまうこともあります。このとき、「1.　解法の実装の概要」が書いてあれば、誤解に気づきやすいです。

「2.　解法の正当性の証明」「3.　解法をどうやって思いつくか」については、自明で書く必要がない問題も多いでしょう。
ただ、「本質」がこれらに含まれる問題もあります。「その方針は思いついたけど自信がなく、証明できなかったので実装するに至れなかった」「それで解けるのは分かったけどどうやって思いつくんだ」という参加者が出るような問題です。この場合には、「2.　解法の正当性の証明」はないと不完全な感じがあり、「3.　解法をどうやって思いつくか」は説明した方が親切かなと思います。

解説の位置づけ

「解説（PDF）はおまけだよ」vs「解説はコンテストを構成する一要素」という認識のずれが、議論している人の間であるように感じました。

私は後者の考え方に近いです。解けなかった問題の解説がどこにもない場合、自力でACするには半日などその問題について考える必要があってつらくなることもあるので。現状、解説（PDF）が分かりづらい場合でも、動画もありますし、コミュニティの力でどこかに分かりやすい解説が落ちているため、困ることはあまり無いですが。