未知の連携が残るプロジェクトで、既知の納品まで止めないための目標設計

新しいシステムには、いつもの方法で作れる機能と、初めての取引先につなぐ機能が混在する。責任者が全体の期限を早めても、相手のデータで処理できるかは分からない。一方、案件全体を「まず学習」と扱えば、仕様も方法も決まった機能まで完成が後ろへ回る。

既知の作業には納品の約束を置き、未知の依存事項には、次の採否を決められる証拠を求める。 本稿で考えるのは、この二つを同じプロジェクトでどう並べるかだ。未知の部分が解けないとき、既知の部分を先に渡せるのか、それとも提供範囲や日付を変える必要があるのかまで判断する。

目標を変える単位は、案件全体ではなく残る仕事

成果目標は、期限、品質、提供範囲などの到達したい結果を示す。学習目標は、その結果に必要な方法を発見・習得するための到達点を示す。「連携を勉強する」では曖昧だが、「変更と取消を含むデータを再生し、予約を誤って残す条件と修正方法を説明する」なら、何を確かめる仕事かが見える。

この区別は、新規案件か既存案件かでは決まらない。初めてのシステムでも、権限管理や帳票は経験済みの方法で作れることがある。反対に既存システムの更新でも、相手側の仕様が変われば、以前の方法が使えるとは限らない。成果物の一覧を、使える方法がある仕事と、まだ方法の成立を確かめる仕事へ分ける。

未知の事項は、依存する成果物も一緒に示したい。外部の予約識別子が確定しなければ、連携の設計は止まるかもしれない。しかし手入力の予約画面や一覧出力が、その識別子を使わずに成立するなら、そこまで止める理由にはならない。逆に識別子が基本データ構造を決めるなら、独立していると見せることはできない。

変更できる境界や契約条件の整理はアジャイル開発の記事で、複数案件の受け渡し条件は依存関係の記事で詳しく扱った。ここでは境界を合意した後、既知の仕事の履行を保ちながら、未知の仕事を何が分かれば終えるかに焦点を絞る。

学習を先に求める根拠と、求め過ぎない根拠

Seijtsらの2004年の実験の著者掲載本文では、ビジネススクール最終学年の学生170人を、成果目標、学習目標、最善を尽くす指示の三条件へ無作為に割り付けた。米国の携帯電話産業をモデルとした個人の経営シミュレーションで、市場シェアを測った研究である。

有効な戦略を探す必要があるこの課題では、具体的で難しい学習目標の群が、他の二群より高い成績を示した。ただし学習群の平均所要時間は102.26分で、成果群の90.66分、最善を尽くす群の95.02分より長かった。学ぶ時間を含めた結果であり、同じ時間内の生産性向上や、企業の納期短縮を証明した実験ではない。

反対側の根拠は、LockeとLathamの2002年の研究レビューにある。具体的で難しい目標が努力や持続、既に持つ知識の活用を促す一方、技能、目標への関与、フィードバック、課題の複雑さによって働き方が変わると整理している。方法を既に使える仕事まで、方法探しへ戻す根拠にはならない。

節目を細かくすれば解決するとも言えない。2001年の実験の抄録では、知識獲得が必要な時間割作成課題を96人が行い、遠い成果・学習目標へ近い成果目標を追加しても、追加しない場合より成績は高くならなかった。以下の判定日や試行条件は、こうした研究を踏まえた編集上の運用案である。研究が実証した最適な期間や合格基準ではない。

仮想例：基本の予約機能と、未知の自動連携を並べる

倉庫の荷受け予約システムを、四週間で切り替える仮想例を考える。倉庫担当者が予約枠を手入力する画面と、当日の荷受け一覧は、既存の手順と経験済みの実装方法で作れる。取引先から予約を自動で受け取る連携は初めてで、日時変更や取消が正しく反映されるか分からない。現行の手入力を残す案もあるが、繁忙時に処理できるかはまだ確認していない。

基本機能には、切替日に提供する範囲と受入条件を置く。予約枠の重複を防ぎ、変更履歴を残し、当日の一覧を出せることを、倉庫担当者が受け入れる。これらの仕様が決まり、方法も使えるなら、主な評価対象は完成した成果物である。連携の研究資料を増やしても、基本機能の未完了を補ったことにはならない。

自動連携には、初週の終わりに採用の可否を決める学習目標を置く。この日を選ぶのは、残り期間で基本機能の受入れと切替準備を行うためであり、一週間が一般に最適だからではない。試す人、使える試験環境とデータ、費やせる時間を先に確保する。基本機能と同じ担当者を使うなら、その時間を納品作業の計画から引く。

学習の問いは「通信が成功するか」より狭く、業務の失敗へ近づける。通常の予約、同じ通知の再送、日時変更、取消、古い通知の遅着を相手の試験データで再生し、最終的に残るべき予約と実際の記録を突き合わせる。検証対象の取り決めが不明なら、相手の仕様確認も初週の仕事に含める。未確認の条件は成功件数へ混ぜず、残る依存事項として示す。

判定日に決めるのは、採用・切り離し・約束の変更

採用へ進む証拠は、試行の回数や報告書の枚数ではない。先の変更・取消・再送で期待した予約状態へ戻せる記録と、異常を誰が見つけて直すかの手順である。取引先が通知の識別と更新順の扱いを確認し、倉庫担当者がその手順で処理を終えられるなら、連携を選び、残る実装と受入れを成果目標へ移す。試した条件の外まで成立したとは扱わない。

連携が成立しなくても、手入力で必要な運用を満たせるなら、基本機能を先に渡す案がある。ただし「手入力はできるはず」で決めない。繁忙時間帯を想定した予約量で担当者が処理を試し、必要な人員、処理遅れ、誤入力の確認までを運用責任者が受け入れられるか確かめる。成立すれば初回の提供範囲から連携を外し、後の採用条件を残す。連携担当の学習は完了しても、自動化による省力化はまだ得ていない。

条件を変え、手入力では必要な荷受けをさばけず、自動連携が切替の必須条件だったとする。この場合、基本機能が完成しても約束した運用は開始できない。未知の連携が解けない事実を受けて、対象取引先を絞る、現行運用を継続する、提供日を変える案を責任者が選ぶ。基本機能の完成日と、業務を開始できる日を分けて報告する。

さらに、取消が本当に伝えられるかを取引先が確認できず、試験を増やしても採否が変わらないなら、同じ学習目標を延長する理由は弱い。必要な仕様をいつ誰が確定するかへ依存事項を戻す。期限を厳しくするだけでも、調査件数を増やすだけでも、この待ちは解けない。追加試行を選ぶのは、残った問いと、その答えで変える判断を説明できるときだ。

学習が終わったかと、約束を果たしたかを分けて追う

進捗報告では、基本機能の受入状況、連携について分かった条件、採否の決定を並べる。「連携不可と分かった」は必要な学習の結果になり得るが、連携機能の納品とは数えない。「基本機能完成」も、代替運用が未確認なら切替可能という意味にはならない。両方の到達点を一つの進捗率へ混ぜると、次に必要な判断が隠れる。

採用後は、試験で通った条件が運用でも成立するかと、荷受けや入力負担が実際に改善したかを追う。運用の結果が変わらないときに、実装・利用・業務変更のどこへ戻すかは、システム投資の便益経路の記事へつなぐ。学習の成功を、事業成果の代わりに置かないためである。

混在する案件では、既知の作業の納期と品質を守りつつ、未知の依存事項を判定に必要な証拠へ絞る。証拠がそろえば納品へ移し、そろわなければ代替運用の成立を確かめて初回の範囲を変える。代替も成立しないなら、使い始める約束を変更する。 目標設計の役割は、全員を同じ強さで急がせることではなく、完成させる仕事と、まだ選ばなければならない仕事を同時に前へ進めることにある。