社内ツール開発を職務経歴書に書く方法｜見えにくい効果を根拠付きで示す

社内ツールの価値は、実際の業務が変わったときに生まれます。利用者、作業、頻度、以前の方法、失敗や待ち時間、なぜ問題だったかを書きます。「Reactで管理画面を開発」だけでは、作った物は分かっても効果は分かりません。

社内向けの仕事に、明確な売上数字がないことは珍しくありません。作ってはいけません。利用者数、削減した依頼、処理時間、ミスや手戻り、リードタイム、セルフサービス利用率、問い合わせ数、可用性、監査可能性を使えます。

第1段階は成果物、つまりツールをリリースしたこと。第2段階は利用、対象者が実際に使ったこと。第3段階は業務変化で、時間、ミス、待ち行列、引き継ぎが変わったこと。第4段階は、帰属を説明できる事業成果です。支えられる最も高い段階を使い、その理由となる下位の事実も残します。

毎日30人が使い、保守担当が決まっている小さなツールは、利用されない全社展開より強い根拠になり得ます。観測期間と、アプリログ、チケット件数、時間計測、承認済みアンケートなどの情報源を書きます。

「一回あたりの削減時間 × 作業頻度 × 対象人数」で計算し、単位を残します。手作業のレポートが20分から5分へ短縮し、週2回、12人が実施するなら、概算は15分 × 2 × 12 = 360分、週約6時間です。

次に前提を書きます。全員が同じ手順だったか。2週間の計測か、記憶による見積もりか。確認作業が別の場所へ移っていないか。「2週間のサンプルから推計」と書くか、範囲を使います。短い試行結果を年間の確定削減額にしません。

「[利用部門]の[導入前の業務]を[ツールまたは自動化]へ変更。[調査・設計・開発・展開の担当境界]を担当。[期間]で[実利用者または利用率]を確認。[時間・ミス・リードタイム]は[導入前]から[結果]へ変化し、[情報源]で計測。[サポート、監視、文書、引継ぎ]を整備。」を使います。

結果指標がない場合は、確認できる定性的な根拠を使います。セルフサービス化、監査証跡、統一された承認、特定チームでの正式採用などです。何を根拠に言えるかも説明します。

Before:「生産性を向上する社内ツールを複数作成。」利用者、課題、利用状況、自分の担当が分かりません。

After:「スプレッドシートとメールで行っていた権限確認を調査し、業務担当45名向けのセルフサービスツールを開発。調査、実装、展開、最初の3か月のサポートを担当。4週間の比較で、申請完了の中央値は2営業日から4時間、承認者不足による手戻りは120件中18件から128件中3件へ減少。監査ログ、当番手順、保守責任者を整備。」これは架空例です。すべてを実際の根拠へ置き換えます。

社内ツールは、作成者の退職後に止まりがちです。認証、権限、監視、文書、問い合わせ負荷、引き継いだ責任者を示します。意図的に廃止した場合は、恒久的成功に見せず、チームが得た学びを説明します。

応募職種に合わせて最初の行を変えます。エンジニアは設計と信頼性、プロダクトや業務職は課題発見、利用、業務結果が中心です。履歴書マッチ分析で要件に答える根拠を選びますが、効果は誇張しません。別チームの仕事を変えた場合は、利用された事実と引き継ぎを示し、事業成果全体をツールの効果として扱わないようにします。