キックオフで使う資料を見直していて、気づいたことがあります。良かれと思って書いた約束が、いくつも紛れ込んでいました。
悪意はありません。むしろ誠意です。手厚く報告します、すぐ対応します、細かく管理します。書いているときは、それが信頼を得る道だと思っています。
この回は、その約束を削っていった話です。
契約より重い約束を、契約に合わせた。
いちばん大きかったのが、報告の約束です。
契約には「週に1回、定例会での報告をもって充てる」と定めてありました。ところが資料側では「定例の前日までに報告書を送付し、費用の消化状況もあわせて報告する」と書いてありました。
契約より重い約束です。しかも重いほうが親切だと思って書いています。
これを見直しました。週次は定例の場で進捗・課題・決定事項・翌週の予定を報告する。費用の消化状況は月次で報告する。ただし超過の見込みが立った時点では、月次を待たずその週に伝える。
薄くしたのではありません。頻度を落として、代わりに悪い知らせを早く出す約束にしたのです。
毎週すべての数字を出す運用は、必ず形骸化します。作業のための作業になり、報告書を作る時間が開発から差し引かれます。そして肝心の「予算が超えそうです」は、定型の報告書の中では目立ちません。
回らない運用ルールを、先に消した。
同じ観点で、他にも削ったものがあります。「1営業日以内に回答します」「課題は1件ずつ管理します」といった類です。
できる日もあります。できない日もあります。そして守れなかった1回が、他の全部の信頼を削ります。
約束は、忙しい週でも守れる水準で書くべきです。上振れは実績で示せばよく、資料に書く必要はありません。
「凍結」という言葉を、資料から外した。
言葉づかいも直しました。資料に「要件凍結」と書いていたところを、「要件の確定(ご承認)」に置き換えたのです。
意味は同じです。ある時点以降は変更を管理下に置く、という話です。
ただ、業務の担当者が同席する場で「凍結」という言葉が出ると、受け取り方が変わります。もう言えなくなる、という圧力として響きます。そうすると、本当は言いたかった要望が出てこなくなる。出てこなかった要望は、消えるのではなく、作ったあとに「これでは使えない」として戻ってきます。
「確定」なら、決めることが目的だと伝わります。同じ管理をするなら、要望が出やすい言い方を選ぶべきです。
資料のフォントまで、相手の環境に合わせた。
細かい話ですが、この期間には資料のフォントも全部差し替えました。
当社の資料は、当社の環境にしかないフォントを指定していました。お客様の環境で開くと別のフォントに置き換わり、文字の幅が変わってレイアウトが崩れます。調べると、お客様の資料は一般的な環境の標準フォントだけで作られていました。
だから資料全体を、その環境で崩れないフォントに統一しました。文字数にして400箇所以上の指定を差し替え、残っていないことを確認しています。
資料が崩れて表示されると、内容の前に「こちらの環境を確かめていない」が伝わります。中身で判断してもらう前に減点されるのは、もったいない話です。
進め方も、この時点で決めておいた。
そしてこの期間の終わりに、開発の進め方そのものを文書で決めました。課題をどう登録し、誰がどの単位で作業を持ち、変更をどう取り込み、レビューをどこで入れるか。
要件定義の途中で決めようとすると、目の前の課題への対応と、進め方の議論が混ざります。混ざると、たいてい進め方のほうが後回しになり、気づいたときには誰も全体像を把握していない状態になります。
約束の設計は、AIでは代われない仕事だった。
この回に書いたことは、AIが速くしてくれた話ではありません。
むしろ逆です。実装が速くなった分だけ、こういう判断に時間を使えるようになったという話です。
報告の頻度をどう約束するか。どの言葉を選ぶか。守れない約束をどこで削るか。これは相手の立場を想像する仕事で、プロジェクトの成否に対する効き方は、機能ひとつよりずっと大きい。
手を動かす時間が減ったときに、その時間をここに回せるかどうかが、これからの進め方の差になると思っています。
次回は最終回。机上の比較をやめて、実測で決めた話です。
※本記事の内容は当社案件での判断です。お客様・システムを特定できる情報は記載していません。契約や報告の在り方は案件の形態により異なります。
連載「案件日誌」(全7回)第1回:受注した日に、プロトタイプを82箇所直した第2回:初回打合せのアジェンダから、自社の説明を削った第3回:分かっていないことを、数えて表に出した第4回:プロトタイプを、本物の作りに寄せた第5回:「動いたように見えて何も起きない」を潰した第6回:守れない約束を、資料から削った(本記事)第7回:机上の比較をやめ、実測で決めた