はじめに
界隈で話題になった、
の中で「Flutterはどのくらい工数を圧縮できるのか？」という話題があり、
これは自分も感覚値だと1.5とか1.7とかなのだけど、営業と話していても顧客と話していても話題に上がるので、もうちょっと考えてみようとなった。
自分はFlutterの案件を3年前から取り組んでいて、3案件ほど開発や保守を行なってきたエンジニアです。
主にPMをすることが多いですが、レビューやたまにコードを書いたりもしています。
考察
自分の担当する案件ではいわゆるV字モデルでの開発をすることが多い。
なので、おおまかな工程で区切って考えてみます。
| 工程 | 概要 |
|---|---|
| 要件定義 | お客様の要望を取りまとめて、アプリで実現する目処を立てる。次工程以降の見積もりをすることもある。 |
| 基本設計 | 画面、機能のアプリの外観を整理する。細かい仕様もここで詰める |
| 詳細設計 | アプリのHow Toを決める。画面間、機能間の共通機能の取り決めやコンポーネントの設計をする |
| 製造 | アプリの実装、パターンよりも粗いレベルで挙動の実現度を確認する（動作確認） |
| 単体試験 | アプリに対しての試験、ホワイトボックスをベースにブラックボックスレベルでも確認する |
| 結合試験 | 画面間、機能間、あるいはモジュール間の連結を確認する |
| 総合試験 | 本番相当の環境を用意し、シナリオベースの試験、性能・負荷などの非機能試験、ユーザーシナリオ以外の運用想定シナリオの試験を行う |
これをFlutterで対応する場合は、
| 工程 | Flutterでやる場合 |
|---|---|
| 要件定義 | 開発言語の生産性は関係しない。ただし、クロスプラットフォーム言語の場合、OSレイヤに近い機能を使う場合には制限やAPIがない場合、結局2OSそれぞれ実装しないといけないこともある。とはいえ、それらの事情は基本設計以降に回す。 |
| 基本設計 | 2OS独自の機能がなければ、１OSの工数で進められる |
| 詳細設計 | 2OS独自の機能がなければ、１OSの工数で進められる |
| 製造 | 2OS独自の機能がなければ、１OSの工数で進められる |
| 単体試験 | この時点で実機や2OSそれぞれの試験を行うか次第だが、１OSでも十分な感覚 |
| 結合試験 | この時点では実機で実際の動作確認をした方がいいので、２OS分の工数がかかる |
| 総合試験 | この時点では実機で実際の動作確認をした方がいいので、２OS分の工数がかかる |
完全に個人感覚になりますが、基本設計〜単体試験が１OSで十分なので、
それぞれNative開発した時に１００＋１００＝２００のような計算だとすると...130程度でしょうか（※）。
※要件定義(10)+基本設計(10)+詳細設計(20)+製造(20)+単体試験(20)+結合試験(10)+総合試験(10)で雑に計算した場合。
まとめ
気になったので、雑にまとめてみました。
作るアプリや会社としての知見、その時の体制やPJの進め方によって前後すると思います。
Flutterでの生産性を上げていく場合、どこまでがFlutterで工数を圧縮できて、それ以外の部分はどう品質を保つかは知見の蓄積が必要かな、と思いました。