見出し画像

入社1年が経過した1人目エンジニアが振り返る「AIRVISAの開発が犯した3つのアンチパターン」

AIRVISA MAGAZINE

迫地 康大 Kodai Sakochi

新卒で株式会社アラタナに入社し、ソフトウェアエンジニアとしてキャリアをスタート。
その後株式会社ゲームエイトに転職し、Ruby on RailsやReactを用いた新規事業開発に従事する。2022年7月にAIRVISAに入社し、一人目の正社員エンジニアとして開発を牽引。

入社して最初の開発はオンライン申請機能のMVP。短期間でリリースし、管理のニーズの方が高いことが明確に

入社1年を振り返って、時系列ではどのような開発に取り組まれていたのですか？
入社後最初の開発はオンライン申請機能で、2〜3ヶ月くらいで作ってMVPとしてリリースしました。

当初はまだプロダクトの方向性が今ほどは定まっておらず、AIRVISAを通して在留資格の申請ができることに最も価値があるのではと考えていたのですが、MVPをリリースした結果、在留資格の申請よりもコンプライアンス遵守のための管理の方がニーズが高いことが明確となり、その後はそのための開発に注力していきました。

また、元々AIRVISAのフロントエンドはVueで作られていたのですが、SmartHRとの連携の観点からも遅かれ早かれReactに移行する必要があったため移行作業をしたのですが、想定以上に時間がかかり結果的に4ヶ月くらいはかかりました。

比較的大きめなfeatureを作ってきた一年だったかもしれません。

開発アンチパターン① 2人のチームで複数プロジェクトを同時進行してしまった


その後はもう一人のエンジニアと二人で手分けをしてアプリ開発と外国人雇用状況の届出の自動化機能を作っています。

実はこの時複数のプロジェクトを同時に進めたのは明確に失敗だったと思っています。

AIRVISAの場合、開発に取り掛かる前には仕様の見通しを立てにくいという性質があって、行政の仕様であったり、顧客のワークフローであったり作ってみたら実はこうだった、というようなことが後からどんどん出てきます。

当然修正が必要なのですが、一人で設計し直して実装もやり直すというのは非常に効率が悪いんですよね。二人で同じ箇所を触っていて、コードがカニばってしまうことも多々ありましたし、当時に戻れるなら絶対に複数プロジェクトを同時に進行することはやらないです。

どちらの機能がより優先されるのかを議論して決めるべきだった

元々自分の中の強い開発組織のイメージとして、みんながお互いを信頼して背中を預け合うというのが漠然とあって、レビューもなくマージして進んでいくような開発の方が良いと思っていたのと、事業計画上両方とも必要なタイミングがはっきりとしていたので、2人でそれぞれが作って出す方が良いだろうと思ってしまいました。

今考えるとどうするべきでしたか？
事業計画上どちらが重要なのかを話して決めますね。当時も頭では複数プロジェクトを回さないほうが良いというのは分かっていたつもりでしたが、そこまで強い拒否感もなかったためそのまま進めてしまいました。

今であれば少ない人数で開発している限りは1プロジェクトで進めようと強く思います。

開発アンチパターン②締め切りのあるスクラム開発をしてしまっていた

もう一つは締切という概念を持ちながらスクラム開発をしていたことですね。
スクラム開発のフレームワークはチームの開発能力を管理しながら、その範囲でやるべきことを取捨選択するアジャイルと相性がよい開発体制ですが、これは開発するもののスコープが決まっていて、顧客にコミットしている締切のあるプロジェクトとは相性がよくありません。

ベロシティ的にはタスクを消化してるはずだが締切には間に合わないということが常態的に発生していて、やりにくさがありました。これは開発内のプロセスだけの問題というよりは、作る機能に対する期待値のすり合わせが重要な側面もありますね。

エンプラ顧客がメインのスタートアップであるが故にAIRVISAが故に直面した課題

一方で、これはAIRVISAがエンタープライズ企業をメインターゲットとするスタートアップだから発生した構図とも言えるなと思っています。

実績の少ないスタートアップがエンタープライズ企業との契約を獲得するためには、ある程度期日等のコミットも必要だと思っています。

ただそれを単純に続けると破綻してしまうことが分かってきたので、今は変えていく方向で落とし所を探っているところです。

開発アンチパターン③短期のスピード重視で設計を詰めずに開発してしまった

あとは、短期の実装スピードを求めて設計を詰めずに開発を進めてしまっていたことですね。

もちろんその時点で考えられる設計はしながら開発していたのですが、ある企業のニーズを満たすためにはこの実装になるが、別の企業ではこういう側面があって違う実装のほうが良いみたいなことがあります。

経験値が高いエンジニアの方であれば、最初の実装のアイディアからして自分とは全然違ったりするので、もし当時に戻れるとしたらもっと経験豊富な方に相談しながらやるかもしれませんし、どんなニーズを持ったクライアントが使うのかというのを機能とセットで考えた上で開発してたかもしれません。

負債を作っている自覚を持ちながら開発することが重要

一方で完全にミスだったかというとそうでもない側面もあって、例えば入社後最初に作ったオンライン申請の機能はMVPの形で早く出したからこそ早めに軌道修正ができたのも事実です。

なので、捨てる前提でお客さんと話しながら仕様を詰めたり、負債を作っていると理解しながら開発を進めることの方が重要なのかなと思っていたりもします。

この辺りはバランスだと思いますがAIRVISAの現在のフェーズとドメイン上、今後は軌道修正の必要を感じています。

Multi Vertical SaaSとしての基盤を磨き上げる1年にしたい

次の1年はどんなことに注力したいと考えていますか？
AIRVISAは外国籍という分野に特化したSaaSなのでSmartHRのようないわゆる典型的なHorizontal SaaSではない一方で、コンプライアンスを管理したいというニーズは業種問わず共通です。

その反面在留資格の申請は業界ごとにことなり、エンジニアのような「技術・人文知識・国際業務」の在留資格しか不要な業界もあれば、特定技能への対応が必要な会社もあるなどVerticalな要素があり、Multi Vertical SaaSの戦略を求められています。

次の1年はまず基盤となるコンプライアンス管理の部分の機能を磨き上げたいですね。

エンジニア採用も強化する必要があり、コンプライアンス管理の部分ではSystem of Record的な側面が強いですが、業界特化の申請機能や構想しているtoCアプリなどはSystem of Engagement的な側面が強く多様なエンジニアが活躍できるポテンシャルがあるかなと思っています。

We are hiring!

AIRVISAに少しでも興味をお持ちいただけましたら、お気軽にカジュアル面談にお申し込みください！