はじめに
以前、機械とシステムの作り方の違いについて投稿させていただきました。
ありがたいことにその中で、システム開発の現場についてもう少し細かく構造化してまとめてほしいというご意見を頂きました。
そこでこの記事では私が体験してきた範囲の中で、
- 提供しているサービスの内容
- 事業のフェーズ
- 内製と外製
の切り口でケース別にどのようなシステム作りが現場で行われているのか、ご紹介したいと思います。
転職や就職の際に、自分のやりたい実務をやるためには、どんな会社にジョインすべきか？を検討中の方のお力になれれば幸いです。
エンジニアの実務
プロダクトマネージャ、システムエンジニア、ソリューションアーキテクト、プログラマー、コーダーなどなど、様々な呼び名がありますが、開発手法の変化や開発ツール、PCの進化の台頭で、徐々にそれらの役職の垣根は曖昧になってきています。
本記事ではそれらの役職を明確に分けずに、エンジニアという言葉で全て表現します。
エンジニアの実務は大まかに
- 何を作るか決めて
- どう作るか決めて
- 作って
- 問題ないか確認して
- 作ったものが使えるようにする
のサイクルで構成されています。
要件定義、設計、開発、テスト、リリース、という言葉で説明されることが多いでしょう。
システム開発が、これらのステップで構成されることはどんな現場でも共通かと思いますが、開発現場によって、これら5つのステップへのリソース配分は大きく異なるように思います。たくさん開発ができる現場もあれば、要件定義ばかりの現場もあります。多くの場合、ジョインしてみないとどんな配分で実務にあたるのかはわからないと思いますが、本投稿では事前情報からどんなことが予想できるかを共有させていただきます。
サービスの内容による違い
サービスに求められる堅牢さに応じて、エンジニアの仕事内容は変化します。
ここでの堅牢さとは、サービスがいかに継続的に間違いなく、どんな時、どんな状況であっても同じように動き続けることができるか、という指標です。
金銭の授受があるか否か
金銭の授受があるシステムの場合、例えば自動販売機の中のプログラムを作ります、というケース等ではテストやリリースに割かれるリソースが増加します。
「ここのボタンを一分間高速で連打し続けると、画面が固まります」という内容のご指摘をもらいがちなのはこうしたお金が関わるケースですね。お釣りを出したり出さなかったりする自販機は困ってしまいますから、当たり前と言えば当たり前かもしれませんが、よくよく考えるとアメリカではお札を吸い込む自販機はめずらしくなかったように思います。
金銭の授受がどうこう、というよりは、世間の雰囲気が許すかどうか、というところが大きいかもしれません。
利用者の温度感
サービスが止まった利用者へのダメージがどれだけあるのか、というのも指標の一つです。
例えば、特に私などはXのサービスが停止したとしても、どうしようもなく困ることはありません。
温度感が低いサービスでは新機能を作る、すなわち要件定義、設計、開発へのリソースがよく投下されるようになります。他方、例えば自動運転の制御のプログラムや医療機器など、不具合によって人の命が危ぶまれるようなサービスについては漏れの無い確認が必要になることは、言うまでもありません。
継続的な変更の予定
作って提供してしまったらそれっきりで、その後の手入れが不可能なシステムではテストへのリソースがよく割かれます。先ほどの自動販売機の例などはまさにその一つで、インターネットでつながっておらず、プログラムの修正は現場でないとできないようなアーキテクチャの場合は、不具合のあるプログラムのリリースは後に大ダメージを与えてしまいます。
事業のフェーズによる違い
スタートアップの界隈では、会社の規模や提供しているサービスの成熟度に応じて、以下のような事業フェーズで呼称されることがあります。自分は以下のように理解しています。
- シード：事業のやり始めであり、売り上げはほぼ立っておらず、提供するサービスの仮説検証を繰り返している状態
- アーリー：サービスの仮説検証は終了し、一部売上が立っており、サービスの磨き上げをしている状態
- グロース：ほぼ完成されたサービスを持っており、販売拡大を加速度的に進めている状態
- レイター：サービスが世の中に浸透している状態
基本的にレイターに向かうほど、品質要件が高くなります。すでにサービスを使用しているユーザーの数が多く、何か失敗があった際に発生する損失がその分大きいためです。また、成熟の過程で積み上げられた業務の進め方のルールや、技術的な負債（成長への投資でもあります）が比較的多く、全体の開発スピードは劣る傾向にあるように思います。
また、（これは個人の偏見とも取れる話かもしれませんが）アーリーやグロースのスタートアップに参画しているエンジニアは比較的自己主張をはっきりするタイプが多く、意見のぶつかり合いによる開発の停滞もよく目にしました。
逆に、シードに向かうほど、要件定義や設計の時間が多く発生するようになります。というのも、利用者からのフィードバックや同業他社の動向、法令の変化、キャッシュの状況などに応じて、開発の優先順位（もっというと事業内容そのもの）が日夜変化するためです。
開発者は経営者と常日頃からよく話をして、今なにをすべきなのかを明確にして合意しておかないと、成果物の上がるペースに齟齬が生じ、トラブルになるケースがあります。
内製か外製かによる違い
システム作りを外部に委託する場合、サービスに不備があった場合に損をするのは発注者側です。従って委託側は、発注内容が自社が求めている内容になっているか、発注通りのものができているのかを精査する必要があります。これにより受託側は開発、テスト、リリースの工数（ここでは納品という側面ですね。例えば使い方ガイドや手入れの仕方の説明、資料作成など）が増加します。
委託側である場合は、要件定義、設計の工数がかかり、開発やテストの工数は減ります。（実務上、最終的な受け入れのテストは多くの現場で実施しているように思います）
もちろん、現場によってどこから先の作業を切り出しているかは様々で、
いわゆる丸投げ状態になっている現場もあると思います。参画する場合は、実際にどの実務に自分があたるかはきちんと確認をしておいた方がよいでしょう。
おわりに
本記事では、どのような現場に参画したらよいかを見極める指標として、サービスの内容、事業のフェーズ、内製外製の3つを提案しました。ジョイン先を探されている方の一助となれれば幸いです。
LOKIARでのシステム作り
私の所属する株式会社LOKIARはシード～アーリー期のスタートアップで、配送管理のSaaSであるMeechを全て内製で開発しています。
Meechには現状では金銭の授受の機能はないものの、配送管理機能が搭載されており、特に日中に停止してしまうと利用者が業務を実施できない状態になりかねません。
アプリケーションには日々改良、機能追加が走っています。
という状況ですので、比較的、要件定義や設計、開発の業務が優先されています。品質については二の次、ということではなく、CI/CDツールの活用や、コードレビューおよび作成者以外の動作確認、そして不具合発見時には即座に対応できる環境を整えています。
- エンジニアとして、「何を作るか考えて、実際に作る」ということに重きを置いて働いてみたい方
- 利用者に近い環境で、開発と運用の手触り感を持ちながら、働きたい方
に、マッチした職場環境です。
ご興味のある方、まずはカジュアルに情報交換させて頂ければと思いますので、
ぜひこちらからお問い合わせください。