クラウドワークス Advent Calendar 2021 7日目です！
クラウドワークスで「クラウドログ」というBtoB SaaS事業の開発を推進してます。
5年ほどSI開発を経験してから、クラウドログ（SaaS開発）にジョインして気づいたら3年半が経ちました。
せっかくSI開発とSaaS開発の両方を経験したので「SI開発ならではのよさ」について書いてみようかと思います。
巷では、SIエンジニアは技術力が無いという話も聞きますが、
SI開発にも良さもあるんだということ、そして、SI開発からSaaS開発に進む可能性も感じてもらえれば幸いです。
※あくまで、経験を元にした自分なりの解釈ですので参考程度にしてもらえればと思います。
SI開発とは
ここでいうSI開発とは、大手企業へのシステムへの請負開発です。
ウォーターフォール型で「要件定義 → 設計 → 実装 → 試験 → リリース・納品」を行います。
いわゆるV字モデルで進めて、一連の流れが1つのプロジェクトとして完結する形です。
基本的には、プロジェクト開始時（受注時）に「システム要件、工数・金額、納期」が決まります。
そのため、受注時に決まったものをいかに正しく、予算内および期限内で完成させることがプロジェクトの成功すなわち利益につながります。
自身のSI開発経験
SI開発っていっても色々あるので、自分の経験を先に書いておきます。
全体を通じて、とある携帯キャリア企業へのシステム開発を手掛けることが多かったです。
二次請けでのシステム開発 2年半
- 大手SIerを一次請けとしたシステム開発（三次請け・四次請けとかはない）
- 主な工程は設計〜実装〜試験＋保守運用。プロジェクトによって多少異なる
- 対応顧客は一次請けのエンジニア
- プログラマーから開発リーダーまでやった
一次請けでのシステム開発 2年半
- 上述の一次請け側に立ってシステム開発
- 工程はシステムの全行程（要件定義〜リリース＋保守運用）。プロジェクトによってかなり異なる
- 内製（自社開発）もあれば、二次請け企業へに依頼することもある。ケースバイケース
- 対応顧客はエンドユーザーの非エンジニア（利用者や事業担当者など）またはエンジニア
- SE（エンジニア）からPM（プロジェクトマネージャー）までやった
一次請け・二次請けそれぞれを経験した自分としては、
二次請けの時のほうがバリバリ開発をしてました。手を動かすという意味では二次請けのほうが数をこなせました。
ここで開発経験を積めたからこそ、一次請けになっても手を動かすPMとしていられたと思います。
一次請けでも開発することはあったけれど、要件定義など上流工程がメインとなるので数は減りました。
一方で、一次請けでは対応する工程が広いので、裁量や影響度合いが大きく難易度も上がり、やりがいも大きかったです。単純にシステムを作るだけでなく、エンドユーザーと話して「何を実現するのか」といった視点も大切でした。
技術的にもサービス全体の構成検討やインフラ構築など二次請けとは異なる領域も経験できたと思います。
SI開発の中でも一次・二次それぞれで違いがあって面白みがありました。
SI開発をしていてよかったこと
本題です。
当時は意識してなかったですが、SI開発から離れてみるとSIなりの良さが見えてきた気がします。
細かいところまで考えるとたくさんあるので、3つに絞りました。
- 多種多様なシステム開発経験
- スケジューリング（計画と推進）
- 説明力・トーク力
1. 多様なシステム開発の経験
SI開発では、プロジェクトが終わるとすぐに別のプロジェクトに関わります。
工程によって人数も異なるので、実装と試験だけ担当して次のプロジェクトに入ることもよくあります。
そのため多くのプロジェクトに参画する機会があり色々なシステムを触ることができます。
自分の場合は、事業部内で複数の顧客やシステムを担当していたのでプロジェクトが異なれば別システムとなることも多く、5年の間に「17プロジェクト・10種類のシステム」を関わりました。
全体を通すと以下のようなシステム開発に関与しました。
- プログラミング言語はJava, C# ,PHP, Ruby, Lua
- Linux系(Cent OS, Nginx, Apache, Tomcat)やWindows系(IIS, Active Directory), AWS
- WEBアプリケーション、モバイル（Android, iOS）、マイクロサービス（RabbitMQ）
- 基幹システム（社内システム）、コンシューマー向けシステム
- 利用ユーザ数（DAU）は数十人のときもあれば、数百万人まで
- スクラッチ新規開発プロジェクトが5つ
また、単に技術的な部分だけでなく、以下のようにシステムごとの特徴も異なります。
- 実現したいこと、利用用途
- 必要なドメイン知識
- 利用ユーザ層（一般消費者、社員など）
浅く広くというところは否めないですが、多くのシステム開発に関与して知見が広がったと思います。
利用ユーザが数百万と数十人での抑えるべきポイントや、社内システムとコンシューマー向けではデザインに対する意識の違いなど、実務としてやることで、知識だけによらない経験を積めたことは非常によかったと思います。
エンジニアは手を動かしてなんぼですね。
加えて、新規開発をそれなりに経験出来たのはよかっと思います。
SaaSの新規開発（0->1開発）よりも手軽に経験できるかもしれないですね。
2. スケジューリング（計画と推進）
SI開発の性質上、ちゃんと計画どおりに進めることが非常に重要でした。
うまくやるには、計画すなわち見積もりと、それを推進していくという2つの側面があります。
計画すなわち見積もり
SI開発での見積もりが最も重要な点だと思います。
見積もりとは、「いくらで（予算）、何を（要件）、いつまでに（納期）」を顧客と約束することです。
プロジェクトが始まると上記の約束事を変えることはまず出来ないので、見積もりを誤ることはデスマーチすることに直結します。
プロジェクト開始前に、開始から完了までを計画するのは大変です。
細かいところは設計フェーズまでわからないこともあるけど、それも見越して見積もりを立てます。
具体的には「スケジュール、体制、工数、金額」を抑えます。
これらが、机上の空論とならないように実現可能性を高めるためにドキュメント構成、実装イメージ、難所の把握、各メンバーのスキルなどを考慮します。
また、トラブル発生のリスクも考慮した上で計画を立てました。
推進
当然ながら、よい見積もりを立てもプロジェクトを完遂させないと意味がありません。
最終的にシステム完成させ本番稼働という形で顧客に納品する必要があります。
そして、良い見積もりでも、想定どおりにプロジェクト終わることはほぼ無いです。
残念ながらどんなに何かしら問題が発生します。
手戻りや想定を超える不具合・メンバーのアサイン遅れ・突然の仕様変更など、内部要因/外部要因含めて様々です。
そのため、いろんな問題に対応しながら全体的に帳尻を合わせて完了させるという、推進力が必要となります。
例えば、以下のようなことをしました。正直、やることはいくらでもあり、ケースバイケースだと思います。
- リスクを下げた仕様や設計に落とし込む
- 顧客調整（仕様を広げない・スケジュールの見直し・追加費用の相談）
- スケジュール見直し・ヘルプの調整
- 開発メンバーのフォローアップ
- 一つ一つの作業の効率化
正直、SaaS開発ではスケジューリングは大切とは思うけど、SI開発ほどの厳密さは不要だと思います。
それより、アジャイルソフトウェア開発宣言の「計画に従うことよりも変化への対応」を大切にしたいです。
中長期的な視点では、計画通り進めるよりも拡張性を高めたり、負債の少ない開発をするために計画を変更することが大切だったりすると思います。
それでも厳格なスケジューリングを経験してきたことで、全体やゴールを意識する習慣がついて、ロードマップの計画立案や開発推進に役立っていると思います。
SaaS開発では、良いものという気持ちが強いと必要以上に工数を費やしてしまうこともあるかと思います。
そういう時に「本当にそれは今やって大丈夫なのか？」と一旦全体をみて考えるようになっていると思います。
3. 説明力・トーク力
SI開発では、顧客が首を縦に振らない限りはプロジェクトが進行しません。
エンドユーザーが顧客となる場合、エンジニアでない方々とやりとりを行うことも多いです。
大きなポイントとしては以下のような場があります。
ここで顧客に理解してもらい合意形成を取って攻略していくことが必須となってきます。
- 要件の整理、見積もり説明
- 各種定例
- ドキュメントレビュー（要件定義、設計、テスト仕様書、リリース計画）
- 障害報告
エンドユーザーはお金を払ってシステム依頼するので要望が多く、システムへの期待値も高いです。
要件の整理では、なんでもできると思っていたり、漠然としていてシステム化するイメージがないこともあります。
また、認識齟齬が生じたままシステム開発が進み、要望と異なってしまった場合は大抵こちらの瑕疵となりプロジェクト進捗に影響がでます。
プロジェクトを円滑に進めるために以下のようなところ意識してきました。
- エンジニア知識がなくても伝わる説明
- 顧客のニーズを汲み取り、システムによる実現方法の説明
- 認識齟齬が発生しないような説明
- 文章だけでなく図・ポンチ絵等を用いた視覚的なドキュメント作成
これらはSI開発によらずチーム開発全般で必要なスキルだとは思います。
SaaS開発でもOP・デザイナー・営業・マーケなど事業メンバーへの説明することもあります。
SI開発においてこれらをより厳しく、スキルを磨ける機会だったんじゃないかと思います。
まとめ
色々考えてみると他にもたくさんありそうです。
無駄と思えるくらい丁寧なリリース手順書、障害に対する危機感、大規模障害の恐ろしさなど。
こういったSI開発での経験は現在のSaaS開発でも色々なところで活きていると思います。
もちろんSaaS開発にも多くの良さがありますので、色々な開発バックグラウンドの経験は大切だと思います。
ここで書いたこともSI開発じゃなきゃできないってことは無いと思います。
より良いものを、早く効率的に作るって側面ではどんな開発でも大切だと思います。
クラウドログにおける開発
SI開発をメインに語ってますが、クラウドログではBe Agileとして、スクラム開発を行っています。
SI開発の経験も開発手法の中に含んでいるところはあるんじゃないかとは思いますが、
ウォーターフォールでは無いですし、SI開発っぽさは全然ないと思います！笑
クラウドログでは、SI出身のエンジニアもいますし、SaaS出身・自社サービスのエンジニアもいます。
また、フィリピンのエンジニアもいて、多種多様なバックグラウンドをもったメンバーで開発を推進しています。
これが正解という開発手法は無く、規模・事業フェーズ・メンバーによって最適解は変わるものだと思います。
色々な開発のいいとこ取りをしながら改善をしていきたいですね！
最後に「We are hiring」
興味をもったら気軽にカジュアル面接を受けにきてください！
明日は @Katsukiniwa が新規事業の経験について語ってくれますー！