MARUTTO案件で分かる！テクニカルディレクターの1案件まるっと実況レポート（WP保守つきバージョン）
問い合わせ〜営業と「ざっくり整理」するフェーズ
ある日、営業担当とのチャットに「MARUTTO＋WP保守で相談きました！」と一報が入ります。ここでテクニカルディレクターが最初にやるのは、いきなり技術に入ることではなく、営業と一緒に「案件の輪郭」を整えることです。
例えば、チャットボードにはこんなメモが並びます。
- 目的：採用強化／更新は月1〜2回
- 規模：10P前後、ニュース更新はクライアント側
- 保守：問い合わせフォーム不具合時の一次対応も希望
この段階では「できる／できない」より、「どこまでをMARUTTOに任せたいのか」を営業と一緒に言語化していきます。
見積サポート〜どこからテクニカルディレクターが主導権を握るか
案件の輪郭が見えたら、見積の粗組みは営業、内訳の精度を上げるのはテクニカルディレクター、という役割分担に切り替わります。タスクボード上では、
- 構成案・ワイヤー有無の確認
- WP機能要件（カスタム投稿・検索など）の洗い出し
- 保守で想定される「軽微修正」の範囲定義
といったチェック項目をテクニカルディレクターが埋めていきます。「ここまでならMARUTTO標準」「ここからは追加開発」という線引きも、このタイミングで営業とすり合わせます。
制作進行〜どこまで自分で手を動かし、どこから任せるか
受注が決まったら、テクニカルディレクター主導でプロジェクトが動き出します。キックオフミーティングでは、
- クライアント：ゴールと運用イメージを共有
- 社内コーダー：技術的な制約とスケジュールを共有
という二つのレイヤーを橋渡しします。コーディング自体は社内コーダーが担当しますが、テクニカルディレクターが手を動かす場面もあります。例えば、
- ベーステーマの選定と環境構築
- 複雑なテンプレートの設計だけテクニカルディレクターが先に組む
といった「土台づくり」を自分で行い、量産部分をチームに渡すイメージです。
公開〜サーバ／ドメイン周りの“最後の砦”として
公開前後は、テクニカルディレクターの存在感が一番濃くなるタイミングです。タスクボードには、
- ステージングでの最終表示確認（レスポンシブ／フォーム／速度）
- DNS切り替え手順の確認と夜間公開の段取り
- バックアップ取得とロールバック手順の共有
などが並びます。公開当日は、営業とのチャットで「今から切り替えます」「フロントOK／管理画面OK」などを実況しつつ、クライアントにも状況を報告。トラブルが起きた場合の初動判断もテクニカルディレクターの役割です。
運用保守〜“受注後の伴走役”としてのリアル
公開後、WordPress保守がスタートすると、案件は「短距離」から「マラソン」に変わります。問い合わせの多くは、
- 文言修正・画像差し替えといった軽微改修
- 固定ページ追加などの小規模拡張
- 「ここ自分たちで更新したい」のレクチャー依頼
です。オンラインミーティングで管理画面を共有しながら、「このカスタム投稿がニュースです」「ここを触るとレイアウトが崩れやすいです」といったポイントを解説。クライアントが自走できるほど、保守は「攻めの提案」にシフトしやすくなります。
チャットログとタスクボードに見る、テクニカルディレクターの思考プロセス
実務で残る「痕跡」は、チャットとタスクボードです。テクニカルディレクターの仕事は、ここにどれだけ“判断ログ”を残せるかで質が変わります。例えば、
- チャット：仕様変更の背景や、代替案をテキストで整理
- タスク：誰が見ても分かる粒度で分解し、期限と優先度をセット
を徹底しておくと、後から参加したメンバーも迷いません。「なぜこうしたのか？」が追える状態をキープすることが、複数案件を並行するテクニカルディレクターには重要です。
未経験からテクニカルディレクターを目指す人が“上流に寄っていく”ためのステップ
今はコーダーだけど、いずれテクニカルディレクター側に回りたい人は、いきなり肩書きを変える必要はありません。まずは日常業務で、
- 実装前に「この仕様の目的は？」と一言確認する
- タスクの工数見積を自分なりに出してみる
- 納品時に「次に困りそうな点」を1つメモして共有する
といった“小さな上流行動”を増やしてみてください。MARUTTOのような代行サービスでも、こうした積み重ねが、気づけば「プロジェクトのハブ」になっていく近道になります。
あわせて読みたい
