需要がなくならないエンジニアであり続けるために　生涯現役で活躍するために必要な“設計力”の鍛え方【一問一答】

江草陽太
大阪府生まれ。ネットワーク、データベース、情報セキュリティのスペシャリスト。洛星中学・高校のロボット研究部創立メンバー。ロボカップジュニアジャパンなどのロボコンに出場。その後、大阪大学工学部電気電子情報工学科に進学。NHK大学ロボコンに出場。学生時代より個人事業としてシステム開発を行う。

2014年10月、新卒採用によりさくらインターネットに入社。「さくらのVPS」等のバックエンド開発を担当。IoTプラットフォーム「sakura.io」の開発責任者を担当し、サービス設計と開発を行う。

2016年7月、執行役員に就任。現在は、さくらインターネット全体の技術統括とコーポレートIT、情報セキュリティを担当。宅急便をSlackから発送できるサービスを開始するなど、コーポレートITに関わるDXのサービス化も行っている。

需要がなくならないエンジニアであり続けるために必要なスキルとは何でしょうか？

設計力ですね。設計力だと思います。ビジネスサイドのやりたいことをシステムの仕様に落とし込むという設計力もそうですし、それが決まったとしてきれいなコードに落とし込むためのコーディングの設計力もそうです。この2つはたぶん今後も重要だと思います。

特に後者はコードレビューをする時にも重要です。こんなコードを書いてほしいと仕様を言ってAIに任せてもきれいなコードにはならないので、設計力は今後もすごく重要だし、それができれば生成AIがもっとすごくなってもエンジニアとして活躍していけるんだろうなと思いますね。

設計力を鍛える方法はなにかありますか？

これはよく聞かれるんですよ。（自分自身に設計力があるのは）たぶん過去にいろいろなシステムを見てきたからかなという気はします。ダメなシステムから「あ、なるほど」と思うようなシステムまで見てきました。

OSSのソフトウェアもそうだし、仕事で関わったシステムもそうだし、仕事で関わることになってしまった他者が作った微妙なシステムなどでアンチパターンを知ったり、良い話を知ったり「そういうやり方はダメなんだね」という選択肢を得たりしてきたなという気はしますね。AIが学習する過程と一緒ですね。

決まりはないんですよね。プログラムから設計する上でやりがちでなのは、自分が一番良いと思っているものをそのプロジェクトに当てはめてしまうことです。やはりトンマナや、やりたいことごとに使うべき言語、使いやすい言語、適切な言語、フレームワークは変わってきます。

ふだんはこれがベストだと思っていても、やはり別のプロジェクトにおいては違う選択をしたほうが良いこともあるわけで、そういったところを押し付けないように周りを俯瞰して見るのは重要ですかね。

あと、私がプルリクをもらってコードレビューをする上で一番よくあるのが、英語の単数形と複数形が間違っているとかですね。これは些細な問題ですが、usersという変数なのにユーザーの配列じゃなくて、そのあとusers.idとかになってきてコードが読めなくなるとか。変な日本語みたいな感じですよね。ユーザーならuserで入れてほしいし、user.idにしてほしいとか。あとは関数名が動詞になっていないとか。

「この関数名が何をするのかが名前からじゃわからん」みたいな、そういった細かなところも含めて、きちんと周りとのトンマナを合わせてやる能力がいると思うので、インプットは大事ですね。自分が新規のプロジェクトに参加するとしたら他のプロジェクトを参考にするし、既存のコードだったら他の人が書いたコードはきちんと見る。それに合わせて書こうという感じで、インプットが重要だなという感じがします。

ぶっちゃけそのへんによくあるシステムのプログラミングって、生成AIができて当たり前で、ほとんど頭の中にあるコピペなんですよね。こういう場合はこういうロジックみたいなものがあるので、周りに合わせつつ、やりたいロジックを頭の中でコピペして生成するというところは生成AIがやっていることと一緒だなという感じがします。そうすると、やはり決まったルールでやるというよりは、いっぱいインプットした中から吐き出すという、生成AIがやっている処理のほうがいいんだろうなとは思いますね。