プログラミング

仕事・チーム開発

新技術の導入提案で何を比較する?工数・移行・運用の見積もり

2021年に公開した、社内の新技術提案を振り返る記事です。Xamarinで開発していたスマホアプリにBlazorを取り入れる案と、リリース環境をDocker化する案がありました。当時の採否と、今の技術状況で比較する条件を分けて整理します。

先に結論

新技術を提案するなら、まず「いま誰のどの作業が詰まっているか」を示します。次に、現行を続ける場合と切り替える場合で、同じ範囲の設計、実装、テスト、運用を比較します。コーディングの短縮が、納期、費用、品質のどこへ効くかは、その範囲をそろえてから判断します。

提案に必要なビジネス視点

たとえばアプリの利用部門が月末までの配布を必要としているなら、実装が早まるだけでなく、両OSの動作確認や配布の承認が月末に間に合うかを見ます。ベンダーの作業が減っても、その分が納期や価格に反映されるかは契約と計画によって変わります。

提案書には削減できる工程のほかに、移行時に増える作業、切り替え後の担当者、測れた値と未確認の値を載せます。誰が判断できる材料なのかまで書くと、技術の利点を実際の意思決定に使えます。

顧客が判断できる条件に直す

当時の提案には、コーディングの効率、デプロイの省力化、既存資産の再利用が挙がりました。いずれも判断するには、どの工程を対象にした数字か、現場でその前提が成り立つかを確認します。

XamarinとBlazorの提案で「40%」が指していた範囲

当時は、iOSとAndroid向けのスマホアプリ開発にXamarinを使っていました。社内でBlazorを使う提案があり、ライブラリの流用とクロスプラットフォーム開発が利点として挙がりました。元の記事で「40%」としたのは提案時に見込んだコーディング工程の短縮で、開発全体の実績は示していません。

その案件には流用する.NETライブラリがなく、チームが新しい開発手順を習得する負担も見込まれました。当時は顧客環境で安定して提供できるかも懸念し、提案を見送りました。実案件で提案されたBlazorの具体的な構成・バージョンは元記事から確認できません。

ここからは計算例です。現行の開発が100人日、そのうちコーディングが30人日だとします。コーディングだけが40%減ると12人日減り、全体は88人日です。学習6人日、追加の移行テスト4人日が必要なら、初回は98人日になります。この例では当初見込んだ工程の短縮12人日に対し、開発全体の差は2人日です。リリース後の運用工数は別に見積もります。

当時の技術資料では、Microsoftは2020年にMobile Blazor Bindingsを実験プロジェクトとして発表しています。その発表と現在の製品状況は分けて読みます。XamarinのMicrosoftサポートは2024年5月1日に終了しました。現在の.NET MAUI Blazor Hybridでは、アプリ内で動くRazorコンポーネントをWebViewに描画できます。いま移行を検討する場合は、対象のXamarinプロジェクトの移行経路と、採用する.NET MAUIバージョンのサポート期限を確認します。2020年のMicrosoft発表、Xamarinのサポート終了、Blazor Hybridの仕様、Xamarinの移行ガイド、.NET MAUIのサポート方針

Docker化ではデプロイ時間と改修全体を分ける

別の提案では、テスト済みの実行環境をコンテナとして配布し、リリース時の環境構築を減らす狙いがありました。対象の環境には他システムも載っており、基盤チームには当時コンテナの管理方針がありませんでした。開発チーム内ではDockerを使いましたが、顧客環境への導入は運用側と調整する必要がありました。

たとえば比較の例として、1回のリリースで2人が各2時間かける構築が各1時間になれば、その作業は4人時から2人時に減ります。改修全体に占める割合を出すには、設計やテストを含む工数の分母が必要です。基盤側にはイメージ更新、監視、失敗時の切り戻しを誰が持つかも確認します。

再利用できる既存資産を一つずつ確認する

既存資産を使えるという別の提案も、対象案件では流用できるものがありませんでした。「後方互換がある」という説明を見ても、資産の名前と版が具体的に出るまで、再利用工数の効果は見積もれません。

確認するなら、たとえば既存の業務ロジック、画面、端末機能を呼ぶ部分を分け、候補技術でそのまま使えるか、修正すれば使えるか、書き直すかを記録します。移行範囲を左右する機能を先に1件試し、対象OSで同じ受入条件を満たすかを確かめます。

大事な観点は「ビジネスにどんな価値を与えるか」

会議では、たとえば「出荷前に両OSで同じ確認を通せるかを1画面で試し、移行の追加工数を出してから採否を相談したい」と持ちかけます。そこで見るのは提案の新しさより、利用者の待ち時間、納期、障害時の復旧、運用を引き継げる条件です。

  • 対象の工程と、比較する現行案をそろえたか。
  • 実測値、試算、未確認の前提を区別したか。
  • 学習・移行・運用の負担と、追加作業の担当を確認したか。
  • どの結果なら進めるか、試行前に合意したか。

-仕事・チーム開発
-