記事一覧

エンジニアを工学に集中させるリーン生産統制

方法論

リーン生産統制。未準備の仕事は無駄とし、制約を解消して準備済みの仕事だけをフロンティアへ入れ、約束は割当でなく受諾される。エンジニアは要件とライン停止判断を担い、仕様・テスト・文書は1つの事実に一致する。

タイピングはもはや希少な資源ではありません。工学的判断を続けられる注意力こそが希少です。人間でも機械でも、手数を増やすだけで生産量は上がりません。生産システムがなければ、ボトルネックがレビュー、統合、そしてプロジェクト全体を頭に抱える人へ移ります。最初の追加セッションを開いた日に品質が落ちることはまれです。低下は後から、2つの異なる真実がすでに製品へ入った時に現れます。

私たちはこの観察を、エージェントに関する標語から始めたのではありません。リーン工学が数十年にわたり論じてきた工場の問題から始めました。システムに虚偽、衝突、乖離を持ち込まず、より多くの作業を並行できるようにするにはどうすべきか。AGELAIOSはこの制約の下で構築されています。本稿では、エンジニアが工学に時間を使い、追加能力が未完成在庫ではなく完成した仕事を増やすために、私たちが使う生産システムを説明します。

工場の現場からプロジェクト作業へ

リーンはソフトウェア手法として始まったのではありません。無駄、半完成品の山、ライン終端で発見される欠陥を許容できない物理工場に対する、トヨタの回答として始まりました。大野耐一の生産システムは、少数の揺るがない考え方に基づきます。次工程が実際に引き取れるものだけを生産する、欠陥が現れたらラインを止める、作業状態を見えるようにする、問題を在庫の中へ隠すことを拒む、というものです [1]。後にJames Womack、Daniel Jones、Daniel Roosが、このシステムを西側へリーンという名で紹介し、国民性ではなく生産論理であることを示しました [2]。

プロジェクト作業は自動車工場ではありません。設計には不確実性が満ちています。早すぎる時点で引いた日程は、不明点を推測で埋めます。Glenn Ballardは、Last Planner Systemによって同じ生産論理をその世界へ持ち込みました。統制単位は、もはやガントチャート上のタスクではありません。誰かが実際に受諾した約束であり、仕事の準備が整った時だけ引き取り、守られた約束の割合で測り、破られた理由を分析します [3][4]。リーン製品開発は、ソフトウェアファクトリーに重要な2つの考え方も追加しました。証拠が除外するまで複数の設計案を維持すること、そしてステータスを演じる舞台ではなく、事実を投影した壁にプロジェクトを置くことです [5]。

以上が価値観です。ここから先では、AGELAIOSを構築するシステム内で、それらをどのように機械的に実装しているかを説明します。このシステムを支える社内ツールは生産統制台帳です。チャットログでも、誰かが金曜に緑色へ塗るボードでもありません。

無駄は人の手待ちではなく、未準備の仕事

大野の最初の敵は無駄です。ソフトウェアファクトリーで最も高価な無駄は、開発者が考えるために立ち止まることではありません。条件が揃う前に始めた仕事です。曖昧な要件、欠けた先行成果、誰も下していない裁定、仕様と一致しない文書。そこへセッションを追加してもスループットは生まれません。手戻り、トークン消費、誰も誠実に解消できないレビュー待ちが生まれます。

対策は、準備してからプルすることです。エンゲージメントは、先行する約束が守られ、準備条件が真になった場合だけ、グラフのフロンティアへ入ります。3種類の先行関係が、グラフを正直に保ちます。

  1. Finish to start：Aが完了するまでBを始めない。
  2. Interface：BはAの凍結済み契約に基づいて開始できるが、その契約を変更すればBは無効になる。
  3. Information：BはAの結果を確認する必要があるが、それによって開始を妨げられない。

誰も話題の山へ6つのセッションを押し込みません。調整担当者は、次の準備済みエンゲージメントだけをプルします。作業担当者がグラフ全体を見ることはありません。そのコンテキストには、リポジトリの明文化された規則、約束した範囲、先行作業の契約が含まれます。オペレーターはグラフ全体を見ます。この分離は意図的です。記憶からプロジェクトを再構築しなければならない人は、工学をしていません。会社のDNSとして働いています。

だからこそ、追加能力は混乱を増やさずに行動を増幅できます。フロンティア上では並行セッションを許可します。未準備の仕事では拒否します。速度は、開いているウィンドウ数ではなく、フローから生まれます。

約束は受諾されなければならない

タスクは、引き受けられるかを誰にも問われず割り当てられることがあります。約束はそうではありません。Penroseでは、作業単位をコミットメント、すなわち依頼、約束、納品、受入とします。結果を生成できる人またはセッションが依頼を確認し、期待される結果を理解できているかを確かめ、合理的に約束できるかを判断します。その後に納品し、待っていた側が受け入れるか、不足を伝えます。

この規則は、商業提案でも、範囲を定めた実装セッションでも同じです。営業は顧客の依頼を運びます。他人の名義で納品を約束しません。エージェントセッションは、境界を持つエンゲージメントを担います。製品全体は担いません。文化の章タスクではなく約束は、会社についてこの原則を示します。生産システムは、ファクトリーでそれを強制します。

すべてのエンゲージメントで、5つを明示します。誰が、誰に対して、どの検証可能な成果物を、いつまでに、どの準備条件の下で約束するかです。期限を黙ってずらしません。守れない場合、エンゲージメントを破約として記録し、理由を分類します。曖昧な仕様、依存関係、見積り、放棄、技術、無応答です。作業義務が残るなら、新しいエンゲージメントを提案します。破って再開することで、測定を誠実に保ちます。日付を黙って動かすことは、測定の改ざんです。

Ballardは、この指標をPercent Plan Complete、すなわち約束した件数に対する守られた約束の割合と呼びました [3][4]。私たちはこれを、人の評価ではなくシステムの信頼性信号として使います。この区別は表面的ではありません。キャリアを決める指標は攻略されます。そのため、文化の章月間最優秀社員を演じずに成長するがあります。ここではPPC値を公開しません。台帳から再生成される社内計器だからです。読者が再現する方法を持たないまま商業的主張として公開すれば、測定値を自慢へ変えてしまいます。結果ではなく規則として述べられるのは、破られた約束には必ず理由があり、その理由を守れなかった人を責めるためではなく、システム改善に使うことです。

人間の義務も同じ台帳にあります。裁定への回答、仕様変更の受入、納品物のレビュー。これらはすべて応答コミットメントであり、同じ期限と測定を持ちます。エージェントが人を待っているなら、その待ち時間と、下流で凍結されるすべてがボード上の事実になります。ボトルネックは可視化され、廊下で語られる逸話ではなくなります。

衝突のない並行性、見世物ではない競争

2種類の衝突が並行作業を破壊します。1つ目はファイル衝突、すなわち同じツリー上の2人の書き手です。分離ワークスペースで排除できます。2つ目は意図の衝突、すなわち同じ要件モジュールを所有していると考える2つのエンゲージメントです。分離ディレクトリでは検出できません。予約台帳なら検出できます。範囲をアトミックに確保し、最初の予約が勝ちます。2番目はフロンティア上の次の準備済み項目を取ります。誰が先に発言したかを決める会議はありません。競合に負けることは侮辱ではなく、生産統制です。

予約には期限があります。永久に予約されるものはありません。放棄された確保は、差異理由とともにフロンティアへ戻り、次のセッションがブランチを再開するか、mainから始められます。統合そのものは直列化します。2つの納品物を並行してmainブランチへマージしません。それぞれを最新状態に対して確認します。遅く見えますが、互換性のない2つの真実が同じ朝に製品へ入るのを防ぎます。

このシステムでの競争は、人同士の競争ではありません。設計同士の競争です。リーン製品開発では、これをset-based concurrent engineeringと呼びます。複数案を、明示的な除外基準とともに、証拠によって除外されるまで、判断をまだ戻せる最も遅い時点まで維持します [5]。仕様変更提案は複数案を持てます。エージェントはそれぞれを別ワークスペースで並行試作できます。測定基準に反した案を除外し、その除外を記録します。地位で勝敗は決まりません。最上位者の案だからという理由で採用しません。経験はより良い仮説を作る助けになりますが、仮説を事実にはしません。文化の章残すべきことを書き、見世物なしに決めるも、人間に対する同じ規則です。

製品上の問いが現れたら、セッションを止めます。都合のよい仕様を創作しません。文言の曖昧さは変更提案になります。本物の設計選択は裁定依頼になります。A3パターンに従い、指名した人へ宛てた1ページで、文脈、閉じた質問、コストを付した選択肢、下流影響、推奨、意思決定者が応答しない場合のフォールバックを示します [6]。質問者が準備を行い、決定者は判断するだけです。開かれた質問は公開できません。測定可能な結果を伴わない選択肢は、選択肢ではなく好みです。

セッション周辺の柵をセキュリティ境界とは呼びません。注意喚起は誤りを止められても、意図までは止められません。実際の統制は、エンゲージメントの規約と事後検証です。そう明言することは、公開製品に対する私たちの姿勢と同じです。能力と同じ精度で限界を記述します。

1つの事実、複数の投影

プロジェクトは、正反対に見える2つの形で死にます。知識が誰かの頭にだけあり、会社がその人の予定表になる形。あるいは、すべてがどこかに書かれ、その「どこか」が誰も再現できない6か月分のメッセージスレッドになる形です。リーンの見える化は、両方を拒否します。トヨタ製品開発の大部屋であるobeyaは、作業状態を事実から明白にするためのものです [5]。手書きで埋めるボードは2週間で嘘をつき始めます。私たちのボードは版管理されたファイルから生成されるため、礼儀で緑のままにはできません。

製品成果物にも同じ規則を適用します。

仕様だけが、製品が何をすべきかを定める情報源です。テストはその情報源に対応する名前を持ちます。自動テストのない基準は、未達として扱います。利用者向け文書は仕様から派生させます。善意で維持する第2の小説ではありません。納品物の統合後、変更された要件に依存する文書を再生成します。レビュー担当者が生成文を拒否した場合、マニュアルを直接書き直しません。修正を仕様へ戻し、再びマニュアルを生成します。派生文書の手編集は、システムが排除するために存在する乖離を再び作ります。顧客向け文書は顧客向け文書であり続け、要件資料の内部機構を露出しません。

したがって、トレーサビリティは監査直前に組み立てるスライドではありません。作業がすでに使用する同じファイル、すなわち要件、実装、テスト、文書から生成するマトリクスです。ダッシュボード、マトリクス、マニュアルは1つの状態を3つの形で投影します。一致しないなら、それはコミュニケーション作業ではなく、情報源の欠陥です。

レポートも同じ規律に従います。納品記録に公開する数値は版管理された計器で生成し、記録には生成コマンドを示します。記憶から転記した数値は、気付かれず古くなります。私たちは、物語的要約と、その要約自身が参照する生成レポートが食い違った経験から、高い代償を払って学びました。物語は証拠ではありません。計器が証拠です。

エンジニアが1週間離れても、プロジェクトの索引になる必要はありません。新しい主題に参加する人は、選択の理由、除外された案、どの約束が特定モジュールを所有しているかを読めます。残すべきことを書き、見世物なしに決めるは、会話にこのことを求めました。生産システムは、それを美徳的な個人行動ではなく既定値にします。

エンジニアが実際に時間を使う場所

追加能力の目的は、判断を引退させることではありません。システムが保持できる調整に判断力を使わないようにすることです。

Penroseのエンジニアは、圧縮できない仕事を引き続き行います。要件の枠組みを作り、コストを付した選択肢から選び、完了定義に照らして納品物を読み、続けるべきでないラインを止めます。文化の章手遅れになる前に止めると言えることは、人間にもセッションにも課した最後の義務です。

生産システムは、それ以外を担当者から取り除きます。準備済み作業は特定済みです。意図の衝突は予約済みです。文書が仕様から黙って乖離することはありません。破られた期限には担当がいます。製品上の問いには指名された意思決定者がいます。その上で複数の実装セッションをフロンティア上で並行実行できます。それぞれが境界付きワークスペースを持ち、誰かが受諾した約束に基づきます。

これがチームを置き換えるとは主張しません。生産統制のないチームは、基準を下げずに追加の手を吸収できないと主張します。追加速度を誠実に流す場所がないからです。社内システムは、増幅した行動が同じ完了定義、すなわちテスト、レポート、範囲、再生成文書、最新mainに対する統合を満たすために存在します。製品側の基準はすでに公開されています。約930件の自動テスト、9本の継続的インテグレーションチェーン、ビット単位で再現可能なイメージファクトリーです。ファクトリー側の基準も同じ形です。作業が終わったように感じるから約束が守られるのではありません。完了定義が真になった時に守られます。

この規律をインスタンス、モジュール、アーキテクチャワークショップへ適用する様子を確認したい組織は、お問い合わせください。プラットフォームの証拠は公開リポジトリにあります。ファクトリーはそのリポジトリにはありません。製品はあります。そしてファクトリーは、速度が製品を書き換えないために存在します。

参考文献

  1. Taiichi Ohno, « Toyota Production System: Beyond Large-Scale Production », Productivity Press, 1988
  2. James P. Womack, Daniel T. Jones, Daniel Roos, « The Machine That Changed the World », Rawson Associates, 1990
  3. Glenn Ballard, « The Last Planner System of Production Control », PhD thesis, University of Birmingham, 2000, https://etheses.bham.ac.uk/id/eprint/4789/
  4. Glenn Ballard, « Improving Work Flow Reliability », Proceedings of the 7th Annual Conference of the International Group for Lean Construction, 1999, https://leanconstruction.org.uk/wp-content/uploads/2018/09/Ballard.pdf
  5. James M. Morgan, Jeffrey K. Liker, « The Toyota Product Development System: Integrating People, Process, and Technology », Productivity Press, 2006
  6. Durward K. Sobek II, Art Smalley, « Understanding A3 Thinking: A Critical Component of Toyota’s PDCA Management System », Productivity Press, 2008