あけましておめでとうございます！

みなさんにGEクリエイティブのことを知っていただくために、今年もたくさん、インタビューや情報をお届けしていきたいと思っているので、よろしくお願いいたします。

というわけでさっそく、新企画をお届けいたします！

シリーズタイトルは、「〇〇の極意」。

どの技術が好きなのか？　こだわりはあるのか？　これから極めたいこと、注目していることは？　などなど、先輩エンジニアに聞いてみる企画です。

自分自身のことと比べたり、興味を持つきっかけにしていただけると嬉しいです！

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

きっかけは業務、だけど、気づいたらアーキテクチャにハマっていた

保原：
さっそくですが、操神さんの好きな技術や、開発でのこだわりを、教えてください！

操神さん（以下、操神）：
「これから極めたい」という感じになってしまうのですが、アーキテクチャはかなり勉強してます。

保原：
なにがきっかけで、アーキテクチャに興味を持ったのですか？

操神：
会社から「アーキテクチャのモデルとなるようなプロジェクトにしてほしい」という話があったことです。これまでのプロジェクトはアーキテクチャが必要なかったので、興味はあったものの、ちゃんと考えてみたことがなくて。いい機会なので、いろいろ調べてみたら、思った以上にハマってしまったという感じです。

保原：
最終的に、どんなアーキテクチャを選んだのですか？

操神：
クリーンアーキテクチャです。C#、ASP.NET Coreを使うプロジェクトだったのですが、その中でおすすめのアーキテクチャのひとつとして紹介されていまして。一般的なアーキテクチャとはまったく違うもので、おもしろいなと思ったんです。

「最初はたいへんだけど、あとが楽」になるクリーンアーキテクチャ

保原：
クリーンアーキテクチャは一般的なものと違う、というお話がありましたが、どんな違いがあるのですか？

操神：
一般的なアーキテクチャは、画面（ユーザーインターフェイス）、ロジック（ビジネスロジック）、データベースという3層で表現します。3層アーキテクチャと言ったりもしますね。

3層に分けることでどこに何が書いてあるのかがわかりやすく、下の図のように、データの流れやリクエストが一方通行になっているので、構造もイメージしやすいんです（矢印の方向がデータの流れ）。

ただ、この構造にはデメリットもあるんです。依存の方向も一方通行で、ユーザーインターフェイスはビジネスロジックに、ビジネスロジックはデータベースにだけ依存しているんですね。すると、どうなるか。たとえば、データベースを変えるとなったときに、ビジネスロジックも変えなくてはいけなくなってしまうんです。

保原：
なるほどです！　ビジネスロジックがデータベースの変更の影響を受けてしまうんですね。

操神：
そのとおりです。クリーンアーキテクチャは、この依存の関係が逆転していて、データベースがビジネスロジックに依存しています。なので、データベースを変えてもビジネスロジックを変える必要がないんですね。要は、影響範囲を狭くできるというわけです。その中でも最大のメリットは、変更がしやすいので、テストコードが書きやすい、テストがしやすいことかなと思います。

保原：
今、お聞きしたお話だと、クリーンアーキテクチャにはメリットしかないんじゃないかと感じたのですが。

操神：
いやいや、デメリットもありますよ。初めの書き出しが、ものすごくめんどくさいんです。クラス図とかインターフェイスを書かなくちゃいけないので。とはいっても、変更や追加をするときなど、のちのち楽ができるのはやっぱり大きいと思っていますが。

もうひとつ、引き継ぎのむずかしさもあると思います。さきほどお話ししたように、一般的なアーキテクチャとは考え方が違うので、学習コストはかなりかかってしまうかなと。

新しいチャレンジには、下地づくりが必要不可欠

保原：
クリーンアーキテクチャを実践するのは、それほどむずかしいんですね。

操神：
むずかしいと思います。実は、クリーンアーキテクチャでやろうと決めたものの、結果的にはやらなかったんです。

保原：
せっかく調べたのに？

操神：
クリーンアーキテクチャというのはオブジェクト指向の原則に沿ったアーキテクチャなので、オプジェクト指向というものをわかっていないと、納得いかない構成なんです。加えて、クラスが増えるとか手間も発生する。

こうなると、わざわざクリーンアーキテクチャを覚えて使うメリットがないですよね。というわけで、今回は一般的なアーキテクチャで進めることにしたんです。

保原：
学習コストをかけてまでやる必要はない、と。

操神：
クリーンアーキテクチャは知ってる人も少ないですし、玄人向けなので、すべての人が身につける必要はないのかなと。

ただ、エンジニアとして学び続けることは必要だと思っています。一方で、学ばなくても仕事は回るので、そこがジレンマなのですが…。

保原：
知らないことがあっても仕事が回るということですか？

操神：
そうですね。オブジェクト指向が理解できていなくてもコードは書けますし、不具合が起きても改修すればいいよね、というケースが多いので、学ぶ必要性も感じづらいんですよね。

でも、このやり方を続けていると、どこかでボロが出てきてしまうのではと思っていて。たとえば、オブジェクト指向の中に、共通する属性の項目を引き継ぐ「継承」という原則があるのですが、「継承」しまくって本末転倒なものができてしまったりとか。オブジェクト指向を使うというのは手段なのに、目的になってしまっているパターンですね。

そうならないようにするには、オブジェクト指向をなぜ使うのか、どういう時に使うのか、どうやって使うのか、という部分まで理解していなくてはなりません。そして、そこまで理解を深めるには、会社での基礎教育に加え、自分で本を読んだり、不具合が発生した時に「オブジェクト指向じゃなかったから」という原因をきちんと突き止めるなど考え続けることが必要なのかなと思います。

現状だと概要を理解するレベルに留まってしまっているので、その先にも興味を持ってもらうにはどうしたらいいのかを、考えているところです。

保原：
いい開発手法をどんどん取り入れて活用するためには、エンジニアのみんながレベルアップできる体制づくりが必要なんですね。人事部としても考えてみたいと思います。そのときはぜひ、操神さんのお力も貸していただければと思っているので、よろしくお願いします！