※本記事にはプロモーション（広告）が含まれています。
『一旦それで』――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。
よくある場面
「一旦それで！」
ある作業がある程度片付いたタイミングで、確認を依頼してきた部下が放った言葉です。私はすかさず、こう釘を刺しました。
「一旦って言いますけど、基本的にはもうこの作業には戻りませんよ」
ビジネスの現場で、何も考えずに「一旦（For now）」という言葉を使う人がいます。
誤解してはならないのは、「一旦」で処理を進めること自体が悪だというわけではない点です。アジャイル開発の基本は「一旦」の連続ですし、前提条件が変わりゆくプロジェクトでは、素早くプロトタイプを作って方向性を確認するプロセスが必須です。
システム設計の観点から言えば、「一旦」が成立するのは、処理負荷が全体の5〜10%程度の「方向性チェック（モックアップ作成）」の段階のみです。問題は、明らかにそれ以上のリソースを投下し、本来なら「完了（Done）」のステータスにすべきタスクに対して、思考停止で「一旦」という言葉を使ってしまうバグです。
なぜ起きるのか ― バグの構造
なぜ、彼らは作業の終盤で「一旦」と言ってしまうのでしょうか。それは、自分たちの成果物に自信がないことによる「責任からの逃避（後で言い逃れするための保険）」です。
「今は終わったように見えるけど、後で変更やミスが発覚するかもしれない。だから『一旦』と言っておけば、完全な責任を取らずに済むだろう」
彼らは無意識に、この保険をかけています。システムで言えば、データベースの更新処理（トランザクション）を完了させず、中途半端な状態でロックをかけっぱなしにしている状態です。
本来、タスクというものは「前提が変われば変更が生じる」のが当たり前です。しかし同時に、「もし前提が変わらないのであれば、このタスクはこれで完璧である（これ以上の変更は不要である）」というレベルまでの作り込みとコミットメントが求められます。
その覚悟があれば、間違っても「一旦」という言葉は出てきません。「一旦」という言葉が出た時点で、アーキテクトとしては「準備不十分（不備あり）」というエラー評価を下さざるを得ないのです。
では、この「トランザクションを閉じようとしない部下」に対して、PMはどのようにタスクをコミット（確定）させ、技術的負債の発生を防げばよいのでしょうか？
まず試せる一手：「一旦」を使わず、ステータスを二択にする
システムに「とりあえず」という曖昧な状態はありません。タスクは「完了（Done）」か「作業中（WIP）」のどちらかです。「一旦それで」が出てきたら、どちらなのかを選んでもらいます。
「このタスクは、これで完了として手を離れますか？ それとも確認が残っている作業中なので、期限を延ばして仕上げますか？」
二択にすると、「保険をかけたまま納品する」という逃げ道がなくなり、完了への責任がはっきりします。作業中を選んだ場合は、残っている作業と新しい期限をその場で決めます。
ここまでが、最初の一手です。この一手を習慣にして、同じバグを繰り返さない仕組みにするための残りの手順は、noteで公開しています。
残りの解決策（How）はnoteで公開中
ここから先の具体的な解決策・コマンドは、noteの記事で公開しています。
このテーマを深めるおすすめの本
『アジャイルサムライ』（ジョナサン・ラスムッセン）
「一旦」を正しく使うための、アジャイル開発の基本がわかる一冊。「完了」の定義を最初に合意する考え方は、この記事のテーマにそのままつながります。
▶ 楽天で探す
▶ 耳で読むなら：新作続々追加！オーディオブック聴くなら – audiobook.jp
※本記事は、noteで公開した「「一旦それで」。アジャイルを履き違えた部下の逃避OS」の無料部分をブログ向けに再構成したものです。
コメント