駆け出しのプログラマが「動けばいい」という様子で当てずっぽうにコードを書く姿に触れる機会がありました。こうしたことは今に限った話ではなく、昔からある話です。
最初のうちは、それでも良いのでしょう。今だと生成AIを使えばとりあえず形にはなります。しかし、理解しないままコードを積み上げても、仕事として責任を持つソフトウェア開発者に至ることはありません。必要なのは自分で設計する経験です。
本稿では、動けばいいレベルで終わるのか、仕事として責任を持つソフトウェア開発者になるのか、その分岐点について考えます。
ちなみに、この考察は抽象化すれば他の仕事にも通用する話にも感じているので、エンジニアでない人にも読んでみて頂きたいです。
動く喜びから始まり「動くものを書く」へ
プログラムの楽しさを初学者に聞くと、多くの人から「動くから楽しい」という答えが返ってきます。プログラミングを始めた頃は、画面に結果が出るだけで嬉しくて、少しずつ動く範囲が広がるたびにワクワクしたはずです。
プログラミングの楽しさの原点は、間違いなく「動いた！」という体験にあります。とても古い話ですが、私自身も始めたばかりの頃は、当時でいえば紙の雑誌に掲載されていたプログラムを書き写す写経をして、動かして楽しんでいました。
初心者が学び始めるときに、コピペで作ろうが、生成AIで作ろうが、結果として動くものができることは大切な経験です。続ける動機になります。業務であっても場合によっては、そのレベルでも十分と言えるケースもあるでしょう。
ただし、そうした作り方をどれだけ続けたとしても、ソフトウェア開発の能力が上達することはありません。まして仕事として責任を持つことなどできません。なぜなら、ソフトウェアの設計をしていないからです。
「動くものを書く」だけでは限界がくる
プログラミングを始めたばかりの頃は、よくわからなくても「動いた！」という気持ちは続けていくための大事な要素です。とはいえ、これでは動くものを作るために、試行錯誤を繰り返してプログラムを書いている段階です。
パターンを記憶していくことで少しずつ書けるような実感はありますが、どこかで停滞することになります。簡単なものや、一度作ったことのあるものなら作れますが、規模が大きくなって、複雑なものを作ろうとすると、手が止まります。
プログラムが動かない時には、まずは闇雲にコードを変えてみようとします。動けば正解だと考えているので、何度かチャレンジして動くように直します。なんとなく作っていれば、どうしてもバグが発生するし、そのバグを解消しても、また別のバグを引き起こすこともよくあります。
そこには「動くものを書く」という考えの前提があるからです。こうした状態のまま勘と記憶に頼っている限りでは、いくら時間をかけて努力しても、これ以上の上達はありません。
「動くものを書く」から「書いて動かす」へ
ソフトウェア開発の上達に大事なことは「プログラムを書いて動かすこと」であって、「動くプログラムを書けばいい」ではありません。結果だけ見ると動くソフトウェアになっていても、そのアプローチは全く違います。
「動けばいい」から抜け出すために、どのようなコードを書くか頭の中で設計をしてから書くことを学ぶべきです。もし頭の中だけで考えることが難しければ、最初は手元の紙に書いても構いません。どのような構造になるのか、どういった順番で処理をするのか、事前に考えるのです。それが設計するということです。
そうして設計をしてから、コードとして表現するのです。それが「書いたもので動かす」という状態になります。動くための当てずっぽうではなくなるので、バグがあっても、それは設計の際の想定外や考慮漏れでしかなく、実装で迷うことや試行錯誤することは無くなります。
この段階になれば、上達に必要なのは勘や記憶力では無くなります。抽象化や構造化といった考える力であり、それは経験を積むほどに広く深く様々なケースを考慮できるようになっていくでしょう。そうして設計が上達していくのです。
ここが大きな分岐点です。
「書いて動かす」ための設計と動作確認
「書いて動かす」ことができるようになると、コードにする前に設計が終わっていて、コードは表現手段へと変わります。もちろん、実際に書いてみて直していくこともありますが、それは表現の形が変わっただけで論理的には大きく違いません。
そもそもプログラムは、考えた通りに動くものです。
だから実際に動かしてみるまで、動くかどうかわからないなんてことはありません。うまく動かないことの原因があるとしたら、そもそも正常に動作すること以外の異常系や例外的なケースを想定しきれていなかったことです。だから動作確認とは、実験の検証ではなく、まさしく「設計」に対する「確認作業」になるのです。
設計時点の考慮漏れこそが、バグの原因となるのであれば、いかに考慮漏れをなくすことが大事になります。経験を積めば、様々なケースを想定できるようになりますが、それに加えて、できるだけ設計する範囲＝スコープを小さくすることもノウハウの一つになります。考える範囲が小さい方が考慮漏れも減らせるからです。
私の見てきた経験の浅い開発者で起きがちなのは、動作確認が甘いことです。それは、設計の際に考慮できているケースが少ないからでしょう。なんだったら、最初のうちは正常系しか想定できず、動いただけで「できた」と言ってしまう。まだ経験が浅いことに加えて、様々な状況を想定しようと考えて設計する姿勢も足りていないからです。
熟練のソフトウェア開発者の仕事をみると、さっさと書き始めて、動くところまでいってしまうので、それだけを見て真似しようとしても、うまくいかないでしょう。なぜなら、彼らは非常に速いスピードで、頭の中で設計をしてしまっているからです。未熟なうちは、時間をかけてでも設計することが大事です。
設計できるからこそ仕事で責任が持てる
仕事で責任が持てる状態には、動作すること自体は当然として、それが自分の頭で設計したものかどうか、理解できているかどうかが求められます。動作の原理を理解していないコードには責任を持つことができません。
理解できないものに、責任は取れません。
動くソフトウェアに責任を持つということは、トラブルなど問題が起きたときにも、それを何とかして解決できるだけの力が求められるということです。設計に対する理解がなければ、手も足も出ません。
コードは設計を表現したものなので、仕事で責任を持つプロだとしたら、１行ずつ自分で書いた全てのコードについて、その意図も構造も説明ができるはずです。つまり、設計して書くことができれば、コードで意図を伝えられるようにもなります。自らの意図を込めることが責任を持った仕事といえます。
そして、設計ができることは、開発を進めていくための「タスクばらし」ができることと同義です。目的を把握し、作業に分解して、優先順位を決めたものが設計の結果になります。それができれば、ほぼ正確な見積りができます。責任ある仕事なら、見積りは勘ではなく設計して出すべきでしょう。
生成AIやバイブコーディングは補助輪になる
「書いて動かす」すなわち設計ができる人が、生成AIを活用すると、その生産性は非常に大きなものになります。設計ができていれば「タスクばらし」が終わっているので、あとは作業的にコードを打ち出すだけです。その作業の部分が、生成AIによって圧縮することができるからです。
しかし、まだ「動くものを書く」状態のうちに、生成AIを使ったとしても、それほどの高い生産性には繋がりません。当てずっぽうの試行錯誤は速くなるでしょうが、いずれ人間側がボトルネックになります。
ネットで見つけたコードをコピペしたり、誰かの書いたコードをコピペしたりして作ることと、生成AIで作ったコードのまま使うのは、自分で設計していないという点で本質的には同じです。それでは動くソフトウェアの責任は持てないし、そうした作り方を続けても設計する力は養われません。
経験の浅い人が設計力を訓練することを目的とするなら、生成AIが出したコードのまま使うのはやめた方が良いでしょう。使うとしても、ゼロから考えることが難しい時の叩き台の生成なら有効です。また、既存のコードを理解するための補助としても有効です。このように生成AIは、自分の頭で理解し設計する際の補助輪として使うと良いでしょう。
これは目的の違いです。設計する力の養成ではなく、クイックに動くものがほしいだけの場合もあるでしょう。その時は「動けばいい」ので、生成AIのまま使うことが有効に働きます。生成AIは、あくまで道具であり、どのような目的で使うのかによって使い方は変わります。
責任を持つソフトウェア開発者になるために
これからのソフトウェア開発は「動くものを作る」だけでは仕事にはならなくなるでしょう。それだけなら誰でもできるようになるからです。動くだけ以上に「責任を持つこと」が仕事になっていくとき、そこには設計する力は欠かせません。
設計する力は、「書いて動かす」ことを繰り返し実践していくことでしか上達しません。設計が上達しなければ、より大きなソフトウェアの責任を持つこともできません。「動けばいい」のまま、生成AIやコピペで作っているだけでは、その設計の力はずっと備わることはないでしょう。
大事なことは「動けばいい」から一歩抜け出し、コードを書く前に「どう動くか」を考える設計の習慣を持つことです。それが、これから仕事として責任を持つソフトウェア開発者として歩み始める第一歩になります。
設計する力の向上に伴って、より大きなソフトウェアの開発も担えるようになっていくでしょう。それは同時に、より大きな責任を担うことにもなっていきます。そうした成長こそが、ソフトウェア開発の面白さでもあり、やりがいにもつながるはずです。
ソニックガーデンでは「モダン徒弟制度」という形で「考えて動かす」ための設計する力を鍛えていく育成の仕組みがあります。責任を持つソフトウェア開発者を目指したい方は、ぜひ見てみてください。
採用トップページ:
https://www.sonicgarden.jp/join_us
関連記事：
