Shun Bibo Roku

結論

• アプリケーションが求めているものが何か

• チームの学習コスト

• 開発スピード

• オレオレ設計を避ける

背景

念の為、実務2年目の私が技術選定をすることになった背景は以下の通りです。

• 自社サービスでの開発経験を一年積み、事業ドメインの知識もある程度ついてきた

• 今回、「事業のピボット」と「開発チームの分業化」をすることに

• 「開発チームの分業化」の一環としてこれまでフロント・バック両面開発していたのが、「フロントチーム」と「バックチーム」に別れることに

• そのフロントチームのリーダを今回私が担当することに

技術選定で意識したこと

結論の内容について、ここで詳細を説明していきます。

アプリケーションが求めているものが何か

大前提です。「アプリケーションが求めるもの(要件)」をどう技術的に満たしていくかが大事ということです。これは至極当然のことですね。これだけを考える分には楽なのですが、これ以降の項目とトレードオフになりうるというのがミソです。

チームの学習コストを意識

「アプリケーションが求めるもの」は、「最低条件」のようなものです。これを満たせば、どんな技術を入れてもいいかというと、そうではありません。例えば、私の場合「TypeScript(以下TS)いれよう！」「Vue使うならNuxtだ！」とはじめ思いました。つまり「選定者が使いたい技術」を組み込もうとしたのです。

ですが、今回のチームはTSどころかJSの経験もあまりない新卒メンバが参画する可能性がありました。つまり、「本当にTSを組み込んで、納期までに間に合うのか」を考慮する必要がありました。

今回はそれらの考慮の結果としてTSを組み込むことになりましたが、「学習コスト」を意識して選定することの重要性を感じました。

開発スピード

こちらは、「学習コスト」にもかかってくるところですね。そのためこちらは「どのツールを起用することで、効率をあげるられるか」という項目になります。こちらに関しては、メジャーどころの「ESLint」「Prettier」などが該当します。それプラス「Tailwind」の導入することにしました。

オレオレ設計を避ける

これは、属人化を防ぐのが目的です。私の場合サービス開発のプロジェクトに参画しています。サービスが潰れない限り、開発は続きます。ずっと同じメンバーで開発することはまずありません。

それを踏まえ、できるだけ「世間的によく使われている」「有名なアーキテクチャを利用する」など、「ネット調べればわかる」ような設計にしました。

逆に、「1から自分で考える」はできるだけ避けました。過去にサービスのブログメディアを作成した際、外部のCMSを利用せず、「オレオレCMS」を作成しました。DB設計が残念なことや、記事を書く側、リプレースのしやすさなど、あらゆる点で残念なものを作ってしまいました。

5~10年と経験を積んでいけば、知見を生かした最適な設計ができますが、私のようなジュニアクラスのエンジニアは、「巨人たちの知恵」をふんだんに活用することが大切だと考えます。

まとめ

思いついたことをガーッと書かせていただきました。

今回は皆さんに知見を共有するというよりは、「現在の自分がどう考えていたか」というログとして本記事を書いています。

数ヶ月経ったら、同じようなテーマで記事を書ければと思います（覚えていたらですが…）

誰にも読まれないだろう、という前提で記事書いていますが、じわじわとPVも伸びているので、ちゃんと考えて文章を書いていきたいと思います。