今回は「〇〇の達人」の第2弾！　“いいソースコード”を日夜（？）、追求している組み込み系エンジニアの服部さんに、お話をお聞きしました。

▼第1弾、アーキテクチャの達人・操神さんのインタビューもぜひ、ご覧ください！

＊聞き手は、採用や人事業務担当の経営管理部・保原です

自分が書いたコードなのに…わからない！？

保原：
なにがきっかけで、ソースコードを意識するようになったのですか？

服部さん（以下、服部）：
実は、自分が書いたコードがきっかけなんです。入社1年目から続いている案件で、ソースの改修や機能の追加をしたことがあったんですね。そのときに、1年目に自分が書いたコードを見て、愕然としたんです。

保原：
そういわれてみると、過去の自分が作ったものを見るって、ちょっと恥ずかしいですよね。

服部：
恥ずかしいくらいのレベルならよかったのですが…ほんとにダメダメで。とにかく見にくいし、わかりにくい。それほど大きな変更をするわけではないのに、どこを触ったらいいのかわからないし、どんな影響が出るのかもわかりづらい。書いた本人ですらこんな状態なのに、他の人が対応することになったらと考えると、すごく申し訳ないなと思って。それで、わかりやすいソースコードを書けるようになろうと決意したんです。

いいソースコードは、処理の流れがひと目でわかる

保原：
わかりやすいソースコードというお話がありましたが、服部さんが考える「いいソースコード」の定義みたいなものと教えていただけますか？

服部：
あくまでも僕の考えなのですが、可読性と処理の効率の良さを意識して書くと、いいソースコードになるんじゃないかなと思ってます。

可読性とはソースコードを見た時のわかりやすさで、要は、処理の流れが簡単に目で追えることです。たとえば、何度も同じ処理が出てくると、どうしても長くなるし、見にくくなってしまうんです。そんなときは「共通化」すると、見た目もスッキリするし、ソースコードを書く時間も短縮できます。

共通化以外にも、可読性や効率を良くするためにできることがないかどうか、いつも新しい方法を探しています。10行書かないとできないと思っていた処理が、1行でできる方法があるかもしれませんし。短縮できるところはできるだけ短縮したほうがいいですからね。

保原：
短ければ短いほどいい、という感じなんですか？

服部：
そうは言い切れないんですよね。1行の中に詰め込みすぎて、すごく意味の重い行になってしまうと、これもまたわかりづらくなってしまうので。

保原：
奥が深いんですね…。少し話が戻るのですが、たとえば共通化できるものをすべて共通化すると、どうなるんですか？

服部：
たぶん、逆に、わかりづらくなってしまうかと。

保原：
わかりやすくするために共通化したのに、わかりづらくなる。

服部：
そうですね。「年齢から生まれた年を求める」という処理を共通化するのはいいのですが、そこに星座占いを入れると、他で使えない、汎用性のないものになってしまうのでよくないですよね。要は、共通化する範囲を間違えると、共通化の意味がなくなってしまうんです。

また、共通化した部分は省略されているので、ぱっと見でどんな処理なのかがわかりづらくなってしまう、という問題もありますよね。ハイパーリンクだらけのサイトで、すべてのハイパーリンクを参照しないと意味がわからないサイトみたいなもので、すごく読みづらいと思います。

保原：
それはなんか…読むのがめんどくさそうです。

服部：
ですよね。つまり、共通化を上手く使いこなすには、使いどころや範囲、全体のバランスなどを考えなくてはならない、と。今は、ちょうどいい塩梅を模索しているところです。

保原：
ほかにも、わかりづらいソースコードになってしまう原因ってありますか？

服部：
コメントも可読性に深く関わってくると思います。ソースコードを見ただけで、処理の仕方などすべての情報がわかればコメントを付ける必要はないのですが、基本的に英語の羅列で、ソース上には表せないものもあるので、ある程度のコメントはあったほうがいいのかなと。

例を挙げると、共通化では名前をつけて処理を呼び出すのですが、大きな処理になってくると名前からどんな処理をするのか、どんな結果がでてくるのか、わからないことも多いんです。こういう場合は、コメントがあるとわかりやすいですよね。一方で、「1を足す」という処理であれば説明しなくてもわかるので、コメントはいらない。感覚を掴むまではむずかしいかもしれないですが、共通化と同じで適度にできるのがいいのかなと思います。

プログラミングが大好き！ だからこそゼロから作れるようになりたい！

保原：
現状は、わかりやすいソースコードが書けるようになる、ということに注力してるということですが、「こんなエンジニアになりたい」といった理想や目標はありますか？

服部：
ひとつあります。今、僕がやっているのは、先輩が作った構想の中にある単体アプリの開発だけなので、構想そのものを作れる人になりたいんです。

お客さまから「こういうことをしたい」（＝要件定義）という話が出てきたときに、「この方法で、こういうことが実現できますよ」（＝全体の構想）という提案をしたり、開発方法を決めたりできるイメージです。

保原：
そういうことができるようになるためには、どんな知識やスキルを身につける必要があるんですか？

服部：
システムの全体像や全体の流れを考えて開発できるようになることだと思います。そのためには、たとえば、データを受け渡す時に一番いい形や方法なども考えられるようになる必要があるかなあと。本を読んだり、先輩が作った構成図を見たりしてはいるのですが、ゼロから考えて構成図を作るというのは、やはりむずかしいですね。

保原：
なにごともゼロから生み出すのはたいへんですよね…。

服部：
そうですね。でも、いつかはできるようになりたいです！
あとは、プログラミングをするのが好きなので、ずっとプログラマでいたいです。プロジェクトリーダーとかプロジェクトマネージャーとか役職に就いて、管理がメインの仕事をするのは、自分はちょっと違うかなって。

保原：
服部さんは本当にソースコードを書くのが好きなんですね！　わたしたちも無理に、マネジメントをやってほしいとは言いませんし、これからも「ずっとプログラマーでいたい！」という想いを持ち続けていただければと思います。わたしたちも応援＆サポートしていきますね！