💻
コーディング練習会の感想@一般社団法人ソフトウェアエンジニアリング協会
これは何の記事?
一般社団法人ソフトウェアエンジニアリング協会に生徒として参加して、3ヶ月ちょっとが経過しました。協会参加直後から取り組んでいたコーディング練習では、Arai60というLeetCodeの問題集に取り組んでいました。これをひと通り終えたので、取り組んだことや感想などについてまとめました。
そもそもソフトウェアエンジニアリング協会とは?
ソフトウェアエンジニア(SWE)の育成や就職支援を非営利で行なっている団体です。
ご指導いただける協会理事の講師陣は、元ビッグテック所属のプロ中のプロのSWEです。
一般社団法人ソフトウェアエンジニアリング協会
LeetCodeを題材にしたコーディング練習会だけでなく、コンピューターサイエンス(CS)の基礎知識を学ぶ勉強会の開催や、模擬面接やレジュメ添削など、SWEの育成や就職支援のための様々な取り組みがなされています。
最近では将棋AIエンジンの個人開発なども行われていました。
コーディング練習会の目的
前提として、SWEというのは医者や弁護士などと同様に専門職の一種ですが、非資格職という違いがあります。非資格職では、その専門家集団内で共通基盤として持たれている「常識」というものがあり、これを身につけていれば専門家集団の仲間と認められます。
協会ではSWEに必要な「常識」を習得することを目的にしています。
「常識」について
コーディングにおいては、書いたコードがLeetCodeでAcceptedされるだけでは不十分で、その上でコードを前にしたときの、知識・反応・行動・感覚・判断といったものを専門家の「常識」に合わせることを目指しています。
講師の方が仰っていたことで印象的なのは、「感情を育てましょう」「審美眼を鍛えましょう」というものです。これについては後述します。
コーディング練習会の詳細
まず、題材となる Arai60 は下記の問題精選集のことを指します。
具体的な練習方法は例えば下記のようなものです。
Step1
- 答えを見ずに考えて、まずAcceptされるコードを書いてみます。
- もし、5分くらい考えて分からなかったら答えのソースコードを見ます。
- 答えを見て理解したと思ったら、答えを隠して書きます。
- 書いたコードを送信して、Acceptedされたら、まずは Step1 クリアです。
Step2
- 次に、可読性や直感性などを意識して、コードが読みやすくなるようにできるだけ整えます。
- 同じ問題を解いた先人のPR(プルリクエスト)の内容も見て、自分の解法以外の選択肢を見つける(しっくりくるものがあれば自分でも試す)、ドキュメントなどで調べ物をして知識を補う、ということをします。深さ優先探索みたいに自分の興味の赴くままに、やりたいことはやり尽くしておいた方がベターだと思います。
- わからない事があれば、GPTを質問攻めにして理解しました。どうしても動かないコードができてしまったらデバッグをお願いすることもありました。私はよくギャルを召喚して面白おかしく解説してもらっていました。生成AIを使わないのは損だと思いますが、コレは意識した方がいい気がしています。
- 関連するライブラリ(@cache や LRU Cache)をゼロから実装することもありました。
Step3
- Step2で納得して整えたコードを、再現性高く書けるようになるまで練習します。
- 10分以内に1回もエラーを出さずに書ける状態になるまで続けます。
- 3回続けてこれができたら Step3 クリアです。
- 最後に、GitHubでPRを上げて、PRのリンクをDiscordサーバーのレビュー依頼用チャンネルで共有して、既に解いている生徒に向けて、レビュー依頼をします。講師の方々も見てくれます。
コーディング練習会に参加した感想・気づき
参加のきっかけ・私の信条
- プログラミングを学ぶのにこんなに良い環境が他にあるだろうか?という、率直な感想がまずあります。え、これが無料なのか...という申し訳ない気持ちすら生じました。
- 私は、協会に入る前は1人でAtCoderなどの問題を解いてました。
https://qiita.com/e869120/items/eb50fdaece12be418faa#2-3-分野別初中級者が解くべき過去問精選-100-問
これをやる中で、「後で自分が読んだときに読みやすくしたい」や「直感性やシンプルさを大事にしてコードを書きたい」という気持ちが生じて、これが重要視されるSWEという職種に興味を持ち、協会に参加させていただきました。この選択は正しかったと思います。自分のやりたかったコーディングを存分に練習会で学べていると感じます。 - 人間1人ではできることや体験できる世界に限界があり、例に漏れず個人学習にも限界があるので、この協会のコミュニティに参加して、本当に良かったと感じます。
- 他生徒や講師のコードレビューコメントが非常に勉強になります。特に講師の方には、私の理解の足りない点を、書いたコードや私の振る舞いから的確に察知・コメントいただいたおかげで、私一人では到達できなかったであろうレベルまで、理解が深まったように思います。
- コードを書くときの信条も定まった気がします。「シンプルさと直感性」です。協会に参加した当初に漠然と大事にしたかったことを、より解像度高く大事に思うようになった感覚です。
感情・審美眼を養う
- 「感情や審美眼を養いましょう」という講師の教えが個人的に非常にしっくりきています。そもそも、コードの書き方というのは大変自由なもので多くの選択肢がありますが、その中で、「これは個人的には好みで良いと感じるが、あれはこういうところが気に食わない。」という自分が納得するためのこだわりを持つことが性に合っている気がします。
- ただ、独りよがりは良くないので注意ですね。人の話はよく聞いて、より良いものが見つかれば柔軟に自分の考えを変化させなければならないと思います。
- 感情や審美眼を十分に養うことができれば、数ある選択肢の中から個人としてより良い手段を選択できるだけでなく、合理性の幅を持つことで他者との協調にもつながる、というメリットがありそうです。個人的には、コーディング自体が楽しくなるというメリットもあると思っています。
- 興味・関心のあるモノを前にして、その良し悪しがわかるというのは面白いことだと感じるはずです。これとか、(良し悪しというより判別をしているという違いはありますが)感情としては近いと思います。
https://x.com/052ysk/status/1848023234031284412 - ちょっとスケールがデカい話に脱線しますが、真善美でいうところの(自分にとっての)真と美の追求がイメージとして近い気がしています。誰かのためにという観点では善も大事になってくるのではないでしょうか。
学部入学式における総長のことば - 私は内向感情が比較的強い自覚があり、これをはたらかせながらコードを書くのが楽しいです。例えば、動的計画法の肝は遷移式・漸化式にあると思っていますが、これだけ覚えても何も面白くないのでストーリーや人格みたいなものを自分なりに見出して、面白おかしく理解するようにしていました。再帰呼び出しは、親分から子分への引き継ぎなど、ストーリーをつけて楽しく書いていた気がします。こうすることで、より自然な形で頭に残ってくれる感覚があります。そもそも、コーディングは楽しくやるのが一番だと思っています。(たぶん継続が大事なので...)
https://github.com/kstoneriv3/tips-for-studying-and-working-abroad-ja/blob/main/misc.md?plain=1#L11 - 出力や計算時間の面で問題ないコードが書けた後に、直感性やシンプルさ追求したり、感情や審美眼を持ってコードを読むのって感性工学とかの話になってくるのではと感じています。人が見るものなので、そりゃそうという気もしたり、設計哲学(例：Pythonだと、The Zen of Python)とかも言語ごとにあるようなので、たしかになあと思います。左脳的なロジック中心になるのがコーディングだと思っていましたが、右脳的な感性も大事なのかもしれないです。
- これは最近気づきましたが、プログラミングってプラレールによく似ていると思います。子供の頃は、某蒸気機関車にハマってずっとこれで遊んでいました。(途中からプラレールに満足できなくなり、Nゲージで遊んでいました。)
構築したものを思い通りに動かせると嬉しいという感覚はコーディングもプラレールも同じだと思います。
https://edu.watch.impress.co.jp/docs/news/1499148.html - 他の例だと、ゼルダの伝説のダンジョンや祠の謎を解いていくのにも似ている気がします。たくさんの方法がある中で自分好みのものでクリアするという点などが似ていると思います。
- 感情や審美眼は、カオスを切り開くのに必要？：
ソフトウェアエンジニアリングはカオスとの闘いである、ということを聞きました。感情や審美眼があることで、カオスを前にして、このやり方・方向性が良いのだと自ら積極的に、より良い方向に向かって選択できるようになるのでは？と直感的に感じました。(世の中を実存主義や積極的ニヒリズムを持って生きることに似ている気がします。)
この直感と、審美眼と感情を働かせることで、最近業務で「あ、こういう実装にしちゃうと、未来においてカオスが増長され得る気がして忌避感があり、カオスを抑えるであろうこのような実装の方が好みですが、いかがですか？」と、同僚に提案したところ同意を得られた、ということがありました。実践知として経験できて非常に嬉しかったです。
感情を働かすのは、細かいコードの話だけでなく、未来の帰結がどうなるか？を想像して考えて、より一段抽象化された実装方針などを決める方によく活かされている気がする。
コーディング ≒ 箸を持つようなもの・体を動かすようなもの
- 協会で学ぶ前は、コードを書くことは特殊な技能によってなされるものだと思ってましたが、「箸を持つようなものである」「体を動かすようなものである」というのを知り、変な気負い?のような感情が、なくなりました。ただ、書けるととても嬉しいですね。純粋な内部動機が満たされる感覚です。
- 知らないコードが出てきても「あ、知らない子ですね。これを自分がしっくりする体(思考)の動かし方で覚えましょう。どんなストーリーを見出そうかな?」というマインドになれるので、良い意味で気が楽になった気がします。(「こんなもの、思いつかないんだが・・・」みたいに感じてしまうのは時間がもったいないと思います。ゼロからアルゴリズムを発見する必要はないはずなので、さっさと体を動かして、自分にとってしっくりくる体の動かし方で覚えてしまいましょう。)
- 最近だと、この問題はダルマ落としみたいなアルゴリズムだなと発見して、もうそれにしか見えなくなりました。自分が納得できる直感的なストーリーを見出せると、それが頭に鮮明に残りますね。
https://leetcode.com/problems/merge-k-sorted-lists/description/ - こちらの問題では、エッジ使用回数制限付きのベルマンフォード問題が、個数制限付きのナップザックDP問題とほぼ同じ構造をしていると気づいて嬉しい気持ちになりました。アレとコレが似ているぞと気づいて理解の整理の抽象化に成功すると、覚えることも減りますし応用の幅も聴くようになるのではと思います。野球の投手に例えると、カーブが投げられる体に馴染んでいる投球フォームで、スライダーも投げられるということに気づく、みたいな感覚でしょうか。野球素人なので適当なこと言ってたらすみません。
https://leetcode.com/problems/cheapest-flights-within-k-stops/description/ - この問題は、全くダイクストラ法ではないのですが、ダイクストラ法的な考え方をしていると気づいて理解が進みました。昇順ソートしたクエリを１つ進めることで、新たに候補となりうるインターバルをヒープに追加し、その後小さいものから順に取り出し、条件の合うものを発見していきます。ダイクストラでも、新たにある地点の最小距離が決定すると、その周囲の地点への最小距離を次の候補地としてヒープに追加して、その後最小距離を取り出していきますよね。どちらもヒープを闇鍋のように使っていて面白いなあと感じました。
https://leetcode.com/problems/minimum-interval-to-include-each-query/description/ - これは、トポロジカルソートではないのですが、入次数で処理するトポロジカルソートと非常に近い処理をしていると気づきました。
https://leetcode.com/problems/minimum-height-trees/description/ - これは筆算の掛け算を実装していく問題なのですが、なんだか水時計みたいなアルゴリズムだなあと思って、ルンルンでGeminiかGPTに共有したら、うむそれは漏刻という水時計にそっくりですよと教えてもらって、なるほどと思いました。
https://leetcode.com/problems/multiply-strings/description/
https://www.asukanet.gr.jp/ASUKA4/mizutokei/mizutokei.html - (まだまだですが…)スムーズにコードを書くということに、特別な感情は持たなくなりました。
- 直感的に納得できたコードをStep3で何度も書きますが、連想ゲーム?のように必要なことを自然と紡ぎながら書いていく、みたいな感覚も生じてきた気がします。
下記のスライディングウィンドウの問題ですが、最終的に出来上がるコードは割と量が多くて、できたモノだけ見ると「う〜ん書くのがちょっと大変そうだ」という気持ちになるのですが、「これをやったら次はあれが必要だ」という連想を連鎖させていくと自然とスムーズに書くことができることを実感しました。
https://leetcode.com/problems/minimum-window-substring/description/ - 趣味でギター弾くときは、感覚的に自分に馴染む体（主に指や手ですが）の動かし方をメカニクスとして見つけるイメージで繰り返し練習します。コーディング練習ではStep1~Step3でコードを改善・整理していって最後に何度も書くということをしますが、これは直感的に納得できて馴染んでいる(はずの)思考のメカニクス的な動かし方を頭の中で繰り返す感覚で、ギターを練習するのと近い感覚だと感じます。良い練習方法なのではと感じると同時に、「箸を持つようなものである」「体を動かすようなものである」ということが明らかに感じられる気がします。
- ギターは手に余計な力が入っていたり、手にしっくりきていない無駄があるような弾き方だと上手く弾けなくて、コーディングは理解が頭の中にシンプルに納得して整理されていないと(カオスに発散してしまっていると)書けない、みたいなのも感覚としては似ているかもと思います。
- 記憶が曖昧ですが熱力学のエントロピーは低い方がうれしい、みたいなイメージでしょうか。
- ちょっと記憶が曖昧ですが、20問目あたりを過ぎたくらいから、なんだか急にコードが書きやすくなってきた気がします。(理由は分かりません…体の動かし方が分かってきたという事だったのかもしれません。)
- コードを書くのは元から好きでしたが、最近は毎日やらないとソワソワするようになりました。
- 見る専ですが、割と野球が好きで最近はピッチャーに興味があります。ピッチャーのコントロール向上については、例えば、一定のリリースポイントで球を投げることが１つ重要な要素としてあるらしく、メカニクスとして自分に合った体の動かし方を再現性高く繰り返すことができるのが大事、という点ではコーディングと同じだと思います。
惑星最高の投手と称されているMLBのジェイコブ・デグロム投手は、コントロールに非常に優れているのですが、この投手のリリースポイントは機械のように一定の位置にとてつもない精度で制御されています。
https://note.com/nabeyakiu/n/nca9e9792ea06
他の投手と比較すると一目瞭然ですね。
https://nanjpride.blog.jp/archives/5430194.html#google_vignette
「体の動かし方」の一般化・学習転移（「経験知」というより「身体知」？）
体の動かし方という観点で、コーディング、英語、走るときのランニングフォーム、ギターを弾くこと、にすべて相互に通ずるものがあることが分かってきました。
- うまくいかない違和感を感じたらそこに解決すべきメカニクス的な問題があるはずで、試行錯誤して解決を目指すべき。闇雲に体を動かしても意味がない。どうすれば上手くいくかを仮説検証していかなければならない。コードをただ写経するのでは意味がないし、ただ長い距離を走れば走るのが上手くなるわけではないし、英語を漫然と大量に聞いても会話が聞き取れるようにはならない。
- メカニクスや体の動かし方をなるべく早く身につけてから鍛錬した方が良さそう。間違ったメカニクスだと得られるものが薄くなったり、不要な負担やコストを自らに強いることになる。特に後者は辛い。英語の細部を100%聞き取ろうとすると本当に不毛だし、膝下だけを使って走ろうとすると疲労骨折になったり、ループや再帰呼び出しの流れの全てを追おうとするのは思考をおかしな方向に使っている。ただ、間違ったメカニクスやを知ってるということも、無駄ではない。それを知っていることで正しいメカニクスが相対的に際立ってより強く明らかに感じられるし、「ああ、このメカニクスはダメなんだ」いうことがわかっていることがリスク回避になる。つまり、反面教師として使えるなら使うと良さそう。
他のメカニクスを理解するのも同様に、（点をつなげて線にするように）複数のメカニクスも含めて理解が深まって良い。英語は音声情報に強弱があって効率的だけど、視覚文字情報が均一で受け取りづらい。一方で、日本語は視覚文字情報に強弱があって効率的だけど、音声情報が均一で受け取りづらい。逆の構造をしているということに気づいて理解が深まる、というのを英語のメカニクスを理解することで体験できた。 - 英語は強勢拍子言語なので大事なことしか言わないことを認知した上で、強調度合いの閾値を超えてきた音だけを音声情報として回収して、残りは文法知識や会話の文脈から予測することが肝要（6:4くらいのイメージ）だと思う。
走る時は股関節から動かして地面を掴みながら前へ前へ進む・足の付け根と手の動きによって瞬間的な激力を加えることを繰り返し与えることで「スーッと前に慣性で進んでいくような感覚」が良いと感じる。ずっと力が入っている状態は、力の選択と集中の仕方があまり良くない。
forループは文字固定＆whileループは主役を頭に掲げる＆再帰は親分子分間の作業と終了条件といったポイントを押さえれば十分な気がします。
あと、タイピングは英語みたいにアクセントつけて打つと速くできる気がする。マシンガンは無理。
（ただし、勿論、メカニクスを見つけるための鍛錬もまずは必要。偶然見つかることもあるし。） - ちなみに、メカニクス的な問題、という表現は、2回トミージョンで肘を手術した大谷翔平のピッチングをトレバーバウアーというピッチャーが分析した際に使っていた「メカニック的な問題」という表現を印象的で覚えていたのが由来です。（てか、メカニクスの方が響きがかっこいい）
https://www.youtube.com/watch?v=3XHDDC7wGhk - 毎日やる必要がある、やらないと忘れる。でも、以前にある程度身に染み付いていれば、ゼロから構築するよりかは短い時間で元の感覚に戻れる。
- 最初は味(報酬)がしないが、繰り返し継続すると味がするようになってくる(たしか、講師の教えの受け売り)
- 少しずつ慣れてきた、というくらいのフェーズが特に楽しい。当初と比較したときの成長の差分の実感が強く報酬として感じられる、解像度が上がって前気づけなかったことがわかるようになっている、などの感覚がある。ここまでくると一山越えた感覚になる。この方向で続ければ良いのだという安心感がある。（まだ認知できていない山がある可能性もありますが...）
- 一度良い動かし方が見つかるとそれをずっと続けられるが、実は認知できていないだけでもっと良い動かし方が見つかる(嬉しい)時もあり、自分より上手い他人の介入があると尚良い
- コードを書くことや、英語を正確に聞き取ること、良いランニングフォームは手段であって、一段抽象化された階層にあるはずの目的の達成が大事。手段が目的になってはダメ。（目的思考の項でも後述しています。）
- ランニングフォームは、体への負担を最小限にしつつ、速く、気持ち良く走れるようになるのが大事なのであって、決してカッコつけるためのものではない。
私は最近自分が下記の「うで体」であることを知って、走り方と、業務中の椅子の座り方を少し変えました。（座り方が上手いというのは奇妙な日本語ですが）効率的で心地よい身体感覚を得られたので、どちらも改善できたのだと思います。
https://www.kounoe.com/type - 英語であれば、正確に聞き取ることよりも会話を理解することのほうが大事だと思う。穴埋めリスニングの問題を解くことが目的なのではない。（意味の重要度が高い強く発音される単語をベースに、その他の接着剤としての単語を予測する、のは穴埋めに近いですが、これは文脈理解が目的。）コミュニケーションが本質。最近アメリカのシットコムを見ている。楽しい。日本の英語教育は文法だけをやりすぎだと思う。多分自分は実践駆動で物事を習得するのが楽しくて合っている。受験生の時は、（情報が全て目の前に与えられてそれを精緻に理解する）和訳が得意で（巻き戻しできない大量の情報を与えられて概要を掴む）リスニングが苦手だった。私のメカニクスは今まで細部に注目しすぎていたんだと最近分かった。コーディングなどには比較的良い方向に働きそうけど、英語を聞き取るのには相性が悪すぎたんだと思う。コーディングをきっかけに様々なことに気付けて本当に良かった。
- （野球の経験はないですが）私は山本由伸というドジャースの投手のファンで、（ムキムキのメジャーリーガーが多い中）この人はウェイトトレーニングを一切しないらしく、体の動かし方が上手い人、なんだろうなと推測しています。彼はピッチングトンネル理論の体現者で、変化球（スプリットやカーブ）の軌道が美しくて大好きです。自分の軸を持っていてブレないストイックな姿勢もカッコいい。ワールドシリーズでMVP取りましたね。
https://www.dailyshincho.jp/article/2025/10300602/?all=1 - 落合博満というプロ野球で打者として三冠王を3回取った職人気質のおじいさんがいるのですが、現役打者の分析をするときに「自分のスイングを貫く」という表現をしている時があり、これも自分に合った体の動かし方を見つけるということなのだと推測しています。
https://youtu.be/iKhajjyW_CE?si=qADQRYiZYrsOddMK&t=119 - ランニングフォームで姿勢が良くなり、直感で同じ感覚でギターを弾いてみたのですが、なぜかいつもより脱力して弾くことができるようになっていました。なぜやろうと思ったのかは説明できませんが、無意識と直感で、これも適用できる気がする、と思いました。
- メカニクスの修正がうまくいくと嬉しいのは、修正によって以前よりも心地よい or 効率的な感覚が即座に得られることだと思っています。私がメカニクスに対して工夫を凝らすことで、上手くいけば、良い応答がすぐに得られるんですよね。ちなみに、これはソフトウェアエンジニアリングという仕事に私が感じている魅力とまったく同じものです。（PCは正直で、変更という工夫を与えると、即座に振る舞いを変えてくれます。昨日よりもわずかながら、物事が確実に良い方向へ向かう、ということがなぜかとても嬉しいんですよね。）
工夫をすることで、物事が良くなる、というのが一般的に好きですね。茄子の味噌汁作る時は、ごま油でトロトロになるまで炒めるという工夫をすると、とても美味しくなってくれるのが好きです。 - 私は音楽聴くのが趣味だが聴き方も変わった。メカニクスとして、外界からの入力を調整する。具体的には、デフォルトで小さめにしておいて、必要な時だけ大きめにするということ。
つまり選択と集中ということ、英語の聞き取りも、ソフトウェアエンジニアリング(細部の詳細把握と、抽象化のバランスをとる)も通ずる点があると感じる。
カオスとの闘い
- 初めて、英語・ランニング->コーディングという適用ができて嬉しかったのでメモする。
下記の問題(stackで電卓みたいな計算する)で、「メイン処理は四則演算実行」と、強弱をつけて理解したらグッと書きやすくなった！
https://leetcode.com/problems/basic-calculator-ii/description/
下記の問題(二分探索でT/Fの切れ目を見つけて最適値を見つける)でも、以前はただ上から順番に、つまり bool を返すヘルパー関数を先に書いていた（<- コードの中においては先に書いてあげる必要があるため）のですが、自分がまず書き始めるのはメインの二分探索のループにする方が、思考のメカニクス順としてはしっくりきて、スムーズに書けると感じました。
https://leetcode.com/problems/koko-eating-bananas/description/
他の例だと、再帰関数書く時にも、早期returnも大事だけど、意味の重心であるメイン処理に強く注目するはず。（実は気付いていたけど、今回の適用のおかげでより一般化できた感覚。）
➡️上記は全て最終的なコードは以前と変わっていないが、思考メカニクスを変えることで、私の中の認知負荷をより削減して書きやすくなった。これを「脳内リファクタリング」と呼ぶことにしよう。
➡️「脳内リファクタリング」は、英語やランニングで最近目指していることと本質的に一致している。メカニクス上手く変えることで、コードは認知負荷が軽くなって、ランニングは疲れにくくなり、英語は余計なことを考えなくなる！
➡️これ、(身体を通して知覚できる)カオスとの闘いってことじゃん...!(悟り)
(ソフトウェア開発は、コンピューターの中のカオスとの闘い、と聞いたことがあります。)
➡️実存主義とか積極的ニヒリズムが何となく好きなのは、自分の人間としての生き方におけるカオスとの闘いのために無意識にこれらを採用していたのだと考えると腑に落ちる気がした。
➡️音楽を聴くのも散歩や入浴が好きなのも、無意識のうちに何らかのカオスを整理するためにやっているということなのかも。（これはカタルシスみたいだなあと感じる好きな音楽があります。） - 英語の聞き方について：音ではなく、意味の波に乗るという感覚がシンプルかつ的確で良い。 話の流れに注目することが、最高の抽象化・効率化・cache?になる感覚が得られ、カオスと闘えるようになる。
あと、「音は最低限な情報に圧縮エンコードされてるが、自分や相手が受け取るときは補完デコードするもの」という前提の理解をしておくのも良い感じ。イメージは下記の問題。
https://leetcode.com/problems/serialize-and-deserialize-binary-tree/description/ - 下記のようなことを最近思ったのですが、これも、カオスとの闘い（特に、選択と集中？）と通ずるところがありそうです。
・「コードを書くとき変数の定義は必要になってからするのが良い。パラシュート型の学習が効率良いのと同じ。最初に全て揃えようとするのは理論構造（<- しかも書いていくうちに変化するかもしれない不確実性を孕む）を自分の脳で上から下までスキャンして舐めることになって効率が悪い。」
・「変数だけでなく、関数も似たようなことが言えそう。「あ、これは何回もやることなので抽象化してパッケージにした方が良いな。」と必要性に駆られて行うものなので。」
・と言うことをGeminiに言ったら "Premature abstraction is the root of all evil." という格言を教えてくれて締めてくれた。
・関数を早く決めすぎると変数とかよりも変更コストが高そう。他の関数との接続導線が出来上がったりしたら、関数名を変えることにすら神経質にならないといけないので。。。
コードを読むこと・他者との関わり
- 他の人のコードを読む、というのも初めての経験でした。最初は先人のPRを読むのが結構大変でしたが、徐々に読む時の負荷が下がっていった気がします。私はPythonメインで書いてますが、まだ、CPythonなどをちゃんと読めている感覚がないので精進したいです。
- 書くよりも読む能力の方が大事ということを講師の方がよく仰っていましたが、感情や審美眼を養い「常識」を身につけるためにはこれが必要というのは、納得です。
- これもまだちゃんと上手くできている自信はないですが、人のコードを読んで、コメントをつけるというのも、以前は恐る恐るでしたが、最近少しずつ自分の納得いく形でできるようになっている、気がします…
- コメントするときは自分の感情は伝えつつも強制はしたくないので、相手がより良い状態になるために必要かもしれないことをご提案する、みたいなイメージで書きたいと思っています。
- まだ修行が足りませんが、講師の方が自分にしてくれているようなコメントを、私も他の人のためにできるようになりたいと感じます。
- 私は基本的にビビリなので、「勉強会では火傷を恐れずに」というのをどこかで見て、良い意味で気が楽になった気がします。
- あと、これも練習会に参加した大きなメリットですが、まさに自分が目指すコードをよく書かれている目標になるような先人を見つけられたのも学習効果の面で非常に大きかったと感じます。この方のコードは真っ先に確認して、よく参考にさせていただくようになりました。すると、「この人のコードにはいつも自分のやりたいことが書いてあるなあ」「なんか最近コードが似てきているかも?」みたいな親近感?を最近感じるようにもなりました。特定の一人ではあるものの、他のSWEとよく似た振る舞い・同じ反応ができるようになるという意味では良い傾向なのではと感じます。
- あと、そもそもソフトウェアエンジニアリングにおけるコーディングというものは、いつ爆発するかわからない爆弾を埋め込むようなものであるらしく、生成AIという強力なツールを使うのであれば、AIが出力したコードをよく読んで理解して、最後に人間が責任を持って介入する、ということが大事なのではと思っています。自動車は傷が多少ついていても十分走行できますが、一文字でもおかしな文字が混入すると動かなくなるのがコードやソフトウェアだと思うので、納得できる気がします。
- 生成AIを用いたコーディングに対する個人的な感想としては、出力されるコードは入出力はしっかり合うことは多いかもしれないが、書き方が気に食わないと感じることが多かったり、ハルシネーションを含み得るのでAIの出力をそのまま使うのは、不安と忌避感がありますね。
- あと、例えば、三項演算子のコードをよく生成AIが出力する気がするのですが、これを読むときに目が横方向に振れて読みづらいという感覚をAIが理解するには、あえて知識としてそう教えてやるか、あるいは人間と同じような目の器官を持たない限りは難しいのではないかと思います。現状、こういうところの感覚はまだ生身の人間しか実感として持つことができないのでは、と思っています。
（以下AI＆ソフトウェアエンジニアリングに関する参考リンク）
https://type.jp/et/feature/30031/
https://nowokay.hatenablog.com/entry/2025/03/22/020514#:~:text=ということで,もいいです。
https://nowokay.hatenablog.com/entry/2025/03/22/020514#:~:text=それと、AIエージェント,もあります。
https://x.com/ainsophyao/status/1870481549357174972
https://x.com/GergelyOrosz/status/1907470584650285080
https://x.com/kaityo256/status/1883106307957473397
https://zenn.dev/dyoshikawa/articles/developers-still-need-to-understand-ais-code
https://type.jp/et/feature/30031/
https://x.com/iwashi86/status/2020326215392035319?s=46
目的思考
- ソフトウェアエンジニアリングの目的は「ソフトウェア技術を用いて公共の安全・健康・福祉のために有用な事物や快適な環境を構築すること」です。先日の協会の対面勉強会に参加して印象的だったのは「肉を切ることに喜びを覚える外科医」にはなるな、つまり手段に固執して目的を見失うな、という講師のコメントです。
- 私は書くこと自体が楽しい、という感じでこれまでコードを書くことが多かったのですが、こうならないようにしたいと感じています。例えば、深さ優先探索が好きで、関数名に dfs と入れたのを思い出して反省しました...(これに対する講師のコメントは、関数を呼ぶ側からしたら中身のアルゴリズムには興味がないはずだ、というものでした。その通りだと感じます。)
- 最近の実務で並行処理のコードを書いており、処理を高速化することに理由のない報酬と内部同期が満たされる感覚を覚えてしまい、ターミナルと睨めっこしながらそれは嬉しそうに開発していたのですが、顧客とのMTGで、速度はまあ大事だが精度の方が大事です、ということが判明して、「ウッ、ヒヤリハット。。。」という気持ちになりました。（結局は、並行処理時のパラメータ調整で精度にも対応できる実装にしていたので問題がなかったのですが、もし対応できない方向に実装を進めたいたら...と考えると冷や汗が💦）
- コードを書くという手段に観点を移すとすると、下記のことを意識できれば良いのかもしれないと思っています。端的に表現されていると感じます。
https://qiita.com/miketako3/items/3085e225a35cdf89cd55#:~:text=ソフトウェアエンジニアリングとは時間で積分したプログラミングである。
今後
- 工学部/工学系研究科の非情報系出身というのもあり、エンジニアリングという広義の意味では共通する部分が少しはある気がするものの、コードの読み書きをする中でCSの知識が全く足りていないことを痛感しており、ぜひCSZAPで学びたいと感じています。
- Arai60はじっくりと取り組むやり方で進めましたが、私は飽き性で、変化が欲しいと感じるので、LeetCodeの数を多くこなすというやり方でもやってみたいと感じます。コーディングは、箸を持ったり、体を動かしたりすることに近い、ということなので、数をこなすのは理に適っているかもと感じているのもあります。色々なポーズが出来るようになりたいです。とりあえず、Grind75を解き始めてみています。8割くらいトライしましたが、Arai60で学習したことが活きていて楽しいです。Hardの問題も割とあって、手強いですが歯応えがあって良きです。何かを習得するときは実践駆動でやるのが好きですね。
- 【追記】一ヶ月くらいで Grind 75 を一周しました。Step1(+やりたいこと)をこなすイメージで取り組みました。Arai60で学んだ内容の応用編のような問題があったり、Arai60の範囲外のトピック（2ポインタ, トポロジカルソート, Trie木など）のカバーもしている、良い問題集だと感じました。難易度もちょうど良かったです。
少しArai60とも被っていましたが、Arai60の後にやるのはオススメできると思います。
https://www.techinterviewhandbook.org/grind75/?order=topics&grouping=topics - 【追記】2025年6月末、SWEJP75・NeetCode(Greedy以外)を追加で解き終わりました。これで合計190問程度解きました。LeetCode始めてからちょうど半年くらいになります。問題を解き進める速さと、色々な体の動かし方を習得できるようになる喜び(?)が加速度的に大きくなっていくのを感じていました。Arai60で、正しいピッチングフォームで基本のストレートを投げる練習をしていたおかげで、色々な変化球が投げられるようになってきた、みたいな感覚です。Mediumの初見の問題でも、今まで経験した体の動かし方で対応できるものが増えてきました。あと、Hardの問題をこの前初めて初見で解けました。好きなグラフの問題だったので尚嬉しいです。
とりあえず、これ以上は広げずに復習をしていきたいと思います。気に入った曲を数ヶ月〜数年に渡りずっと聴いてしまうなど、気に入ったものを繰り返すのが好きな性分なので、気に入った体の動かし方を体に染み込むまで繰り返して練習していきたいです。 - 【参考】ある協会理事のコーディングに関する考え方は、下記のようなものらしく、この方法でも最終的な到達点も到達時間もそれほど変わらないようなので、これでも良いようです。
- とりあえず200問を解く(Step1までを繰り返す)
- あまり分かっていないようであれば、さらに200問解く。
- なぜかというと、書いて入出力が一致したところで満足してしまうのは、解くことの負荷が大きすぎるからであり、それなりの量をこなせば負荷が相対的に小さくなって周りを見る余裕ができてくる。
- (時の運というものもありましたが)この協会での学習が身を結び、未経験から希望の会社でソフトウェアエンジニアとしての転職が決定しました。以前から興味のあったAI技術に携わるSWEをやります。大変嬉しく思います。選考のコーディングテストで個人的にわりと満足のいくもの(←こう感じることができること自体が成長の結果なのではと感じます)を提出できたのは、ひとえに協会での学習のおかげだと感じています。ありがとうございました。引き続き精進したいです。
- おまけですが、ノートPC付属のキーボードが使いづらい感覚があったので、最近外付けキーボードを買いました。この辺りは完全に好みの世界ですが、しっかりとした打刻感のあるキーボードを使うと作業効率が上がりますね。スコスコ・カタカタやるのが快感です。姿勢も良くなりました。
最後に & 関連リンク集
SWEという専門家を目指すのであれば、専門家と直接関わることができるコミュニティに参加するのが最も良い方法なのではと感じています。ソフトウェアエンジニアリング協会は、最終的には毎年1万人の桁でSWEを育成することを目標としています。これを達成するには多くの仲間が必要です。
SWEを目指している方は、ぜひソフトウェアエンジニアリング協会への参加をご検討ください。
協会の活動の様子がわかる記事などのリンクを、下記に掲載いたします。
- ソフトウェアエンジニアリング協会のホームページです。(再掲)
一般社団法人ソフトウェアエンジニアリング協会 - 協会理事の方が作成された、SWEになるために必要なことやマインドがまとめられた資料です。
人生のチュートリアルを終わらせるたったひとつの冴えたやりかた - 上記資料の簡略化バージョンの資料です。
国際経営Ⅱ - 協会理事の方が書いた記事です。あるSWE未経験の医師の方がSWEとして就職するまでの過程について主に書かれています。
Twitter で医師を拾ってきて Google のソフトウェアエンジニアにするだけの簡単なお仕事 - 別の協会理事の方が書かれた記事です。Googleの面接にフォーカスした内容が書かれています。
Twitter で医師が拾われて Google のソフトウェアエンジニアになって 3 年半が過ぎました - 他の参加生徒によるコーディング練習会に関する記事たちです。
- 他の参加生徒によるCSの知識の勉強会に関する記事です。
CSZAPのご紹介
PR(対面勉強会のお知らせ)
対面勉強会が2025年4月26日に予定されています。
協会の活動目的・ソフトェアエンジニアリングに関する説明や模擬面接デモなどがあります。ぜひご参加ください。
Discussion