TOKI｜発注と開発をつなぐ人

会社の売却は、経営者の引退だけを意味するものではない。IT企業でも、事業の成長や次の挑戦につながる選択肢になり得る。経営者自身の希望に加え、事業や社員にどのような可能性が広がるか。会社を持ち続けることだけにこだわらず考えたいですね。

リリースの打ち合わせで「問題があれば戻します」。その手順だけでなく、戻す判断まで決めているか。 事前に確認したいのは、次の5つ。 ① 何が起きたら戻すか 主要な処理が動かない、データに不整合があるなど、切り戻しが必要となる条件を具体化する。 ② いつまでに判断するか 切り戻しにも時間がかかる。業務開始に間に合わせるには、作業時間から逆算して判断期限を決めておく必要がある。 ③ 誰が判断するか 開発側とお客様側の責任者を明確にする。当日連絡が取れることも確認しておく。 ④ 切り替え後のデータをどう扱うか 新しいシステムで受け付けた注文や入力データは、元に戻すとどうなるか。プログラムを戻すだけで済むとは限らない。 ⑤ 戻した後に何を確認するか システムが起動するだけでは不十分。必要な業務を再開できることまで確認する。 戻す手順があっても、判断する人や条件が曖昧なら、障害発生時に協議が始まってしまう。 「戻せること」と「必要なときに戻す判断ができること」の両方を、事前に確認しておくことが大切です。

金曜日。もう今週の仕事は終わりにしたいと思っているのは、人間だけじゃないらしい。 Hermesに任せている月次処理。先々月も先月も問題なかったのに、今月はなぜか動かない。 理由を聞いてみた。 Hermes「前回の処理が完了済みであることを確認した後、10月分の対象判定へ進む前に応答を終えてしまいました。」 私「先に進めるための問題は何？」 Hermes「進行を妨げる問題はありません。前回、私が処理を早く止めてしまったのが原因です。」 人間にも、理由なく仕事したくないことはあるしね。

これは要件定義にも通じる話。お客様が求める機能をそのまま実現するだけでなく、なぜ必要なのか、もっと良い方法はないのかを考える。AIによって実装が容易になるほど、何を作るべきかを見極める力の価値が高まると思います。

文章だけで伝えた内容は、人によって思い浮かべるものが違う。要件定義でもよくある話。だからこそ、図や画面にして可視化することが重要。AIを使えば画面の試作も容易になり、早い段階で具体的なイメージを共有できるのは大きなメリットです。

システムのエラーメッセージに「エラーが発生しました」とだけ表示される。これでは利用者は次に何をすればよいか分からない。入力を直すのか、待つのか、問い合わせるのか。だから要件定義では、「エラー発生時に利用者が次に取るべき行動を判断できるメッセージを表示する」と明確にしておく必要がある。こうした細かな要件を定義することも発注者は忘れてはいけません。

システム開発でも「聞いていない」で止まる前にできることはある。ただし、お客様への影響や仕様の判断まで推測で進めてはいけない。自分で調べることと、確認して決めることを区別する。その上で、分かったことと不明点を整理して質問したいものです。

開発会社でも、役職と技術の専門性は分けて考えたい。技術的な根拠より上司の意見が優先されるなら、専門家の力を生かせない。詳しい人の説明を聞き、予算や納期などの条件も踏まえて判断する。任せる部分と責任者が決める部分を明確にすることが大切です。

「高いですね」と言われて、すぐに値引き。まずやるべきことは別にある。その価格は、提供するサービスの対価として妥当なのか。自分たちの検証が先。妥当な価格なら、その根拠や価値をお客様に説明することが先決。安易な値引きで受注できる保証はなく、受注できても利益を減らすだけです。

AIのタスク管理だけでなく、人のタスク管理にも共通する課題。特にプロジェクト全体を管理するPMにとって、誰が何を担当し、今どのような状態にあるのかを把握することは重要。作業中、判断待ち、外部待ちなど、タスクの状態を整理し、次に必要な対応を明確にすることが大切ですね。

納品したのに、休日まで開発担当者に連絡が来る。 「引き継ぎ資料は渡しました」で終える前に、別の担当者が次の4つをできるか、実際に確認しておきたい。 ① 契約情報を確認できる サーバーや外部サービスの契約者、請求先、更新日を確認できるか。更新通知が特定の担当者のメールにしか届かない状態では、担当交代の際に見落とす可能性がある。 ② 自分の権限で管理できる 管理者は誰か、認証情報はどこで安全に管理されているか。特定の担当者のアカウントを借りなければ操作できないなら、引き継ぎは完了していない。 ③ 異常に気づいて連絡できる 稼働状況をどこで確認し、どのような異常が起きたら、誰に連絡するのか。監視通知が誰も確認しない宛先に送られていては、通知の仕組みが正常でも意味がない。 ④ 復旧を依頼できる バックアップはどこにあり、誰が復旧できるのか。復旧作業を外部に任せる場合も、依頼先と対応範囲を明確にしておく。 引き継ぎ資料を見ながら、別の担当者に実際の手順を確認してもらう。そこで出てくる「これはどこですか」という質問こそ、資料の不足を見つける機会となる。 納品前なら修正もできる。 引き継ぎ資料はページ数や形式だけでなく、担当者が不在でも業務を回せるかという視点で確認することが大切です。

システム開発でも、担当者を替えるたびに同じ問題が起きるなら、任せ方や管理の仕組みも見直す必要がある。見積もりや要員配置に無理がないか。お客様側の要求や意思決定の進め方に問題はないか。個人の能力だけで説明せず、同じ失敗が起きる条件を変えることが大切です。

在席表示を見ても、仕事がどこで止まっているかは分からない。リモート勤務を管理するなら、何をいつまでに完了するか、何に困っているかを確認する。席にいるかを監視するより、仕事が進むために必要な支援を考えたいですね。

作業が遅延している担当者に、人をアサインし「この人への説明もお願い」。それ、本人の仕事はいつ進めるのか。人を増やせば、教育時間が必要となるのでスケジュール調整は必須。PMが見るべきは何人増員したかだけでなく、誰が教えて、その間の作業をどうするか。助けるつもりの増員が、余計に追い込むこともあります。

「できます」と即答するより、実現できる条件を確認し、約束した期限に回答する。開発会社の信用は、提案時の説明だけで決まるものではない。持ち帰った質問に答え、約束を一つずつ守る。そうした日々の対応を積み重ねたいです。

どのサービスに、どんな情報を登録したか。会社でも、契約した担当者しか把握していない状態は避けたい。サービス名だけでなく、登録情報や管理者、解約時の扱いも整理する。使い始めるときから、管理する仕組みを考えておくことが大切ですね。

「発注します。あとはお願いします」。発注側にいると、その気持ちはよく分かる。しかし、社内データの意味や、実際に業務が回るかまでは、開発会社だけでは判断できない。発注側にも判断や確認が必要な仕事がある。外部委託に不慣れなら、まずは開発会社に自分たちが何をすべきか、いつまでに対応すべきかを確認する。完成間際になって慌てないよう、発注側も担当者と時間を確保しておくことが大切です。

自分では気づかない課題を指摘してもらえる価値、分かります。何百時間やったかだけでは、同じ癖を繰り返すこともある。社員の研修も、受講時間より、普段の仕事で何を直せたかを見た方がいいですね。

「データ移行」。この一工程にはお客様にしか決められない仕事が隠れている。 開発会社の作業日数だけでスケジュールを組むと、最後にお客様の判断待ちが並ぶことになる。 データ移行の打ち合わせでは、次の4つに分けて考えると整理しやすい。 ① 何を移行するか 全件なのか、利用中のデータだけか、過去何年分か。移行しないデータを後から確認する必要が生じた場合、その参照方法も決めておく。 ② 元データの何を修正するか 同じ取引先が異なる名称で登録されている場合、統合してよいのか。開発者の推測で判断せず、お客様側の判断者と回答期限を決める。 ③ どう試して、何を照合するか 本番前に移行テストを実施し、件数・金額・代表的な明細を照合する。 件数が一致していても、データが誤った項目に入っていれば正しく移行できたとはいえない。誰が何を確認し、合格と判断するのかも明確にする。 ④ 切り替え中の更新をどう扱うか 元のシステムへの入力をいつ止めるか。止められない場合、その間に発生した更新をどう反映するか。切り替えを中止する条件や、元のシステムに戻す手順も決めておく。 「お客様に確認してもらう」という作業も、担当者と期限が決まって初めて工程に組み込める。 お客様の通常業務や判断に必要な時間を考慮しなければ、システムは完成したのに移行できない、という事態になりかねません。

システム開発の現場で痛感すること。障害や緊急対応の要請を受け、信頼関係を前提に夜間・休日作業を先行させたものの、後追いの注文書発行が進まないことがある。お客様の緊急性に応えることは大切だが、それと契約手続きは別。緊急時であっても、最低限メール等で発注合意を確定させてから着手する社内統制の必要性を改めて感じています。