技術標準のライブラリを構築する

なぜ自前の技術標準ライブラリを作るのか

和田は、圧力容器メーカーの設計部門を率いています。3つの専門にまたがる26人の技術者。そして、誰も全体を見通せないコーパス。溶接施工要領書、ノズル荷重の設計指針、材料代替の覚書、そして1件あたり数百万円の手直しを払って手に入れた所見のメモ。そのすべてが、いま有効なフランジの標準がSTD-114_revC_FINAL2という名前のPDFであるようなフォルダの樹の中にあり、いちばん速い検索は、いちばん長くここにいる人に尋ねることです。

文書システムは、文書を綴じます。標準は文書ではありません。歴史を持つルールです。日付から発効する改訂。ある版で見積もられ、決して黙って次の版へ移されてはならない案件。そして、なぜ6.2項が厳しくなったのかを説明する覚書の連なり。Klivは、まさにその形の記録としてライブラリを構築します。会話で伝え、スキーマの中で強制します。

6.2項が、厳しくなる

ひとつの改訂を、現場から部門全体まで追いかけます。

赤入れ

案件4468の仮組みで起きた問題が、STD-114の赤入れされた一項になります。提案はライブラリの中の改訂の草案です。標準に紐づき、所有者に見え、メールでどこかへ流れていくことはありません。

レビュー

標準の所有者と、独立した検図者が、記録の中で承認します。レビューの状態は列なので、「誰がこれを承認したか」は送信済みメールの探索ではなく、参照です。発効日は、翌月1日に設定されます。

公開

その日、新しい版が、標準が読まれるすべての場所で最新になります。古い版は残ります。アーカイブされ、日付を持ち、その上に建てられた案件のために、いまも答え続けます。

通知

#engineering に1通。変わった条項、その理由、そしてSTD-114を引用している進行中の3件の案件。

次の見積

次に見積もられる案件は、自分で新しい版に結びつきます。案件4468は、契約が凍結した場所に留まります。そしてエージェントは、どちらの案件について尋ねられても、正しい改訂版から答えます。

荷重の通り道

版に固定されたエージェント。 エージェントは、部門自身が書き込んだナレッジベースに基づきます。コーパス全体を、改訂ごとに。これをチャットの窓ではなく設計の道具にしているのは、その固定です。案件4468について尋ねれば、その案件が見積もられた版から答え、その版が書いたとおりに条項を引用し、読んでいる改訂版を名指しします。検索が結びを尊重するのは、結びが、それ自身の読める行だからです。

レビュー状態を持つファイル。 ネイティブファイルとPDFはファイルストアに乗ります。けれど記録であるのは標準のほうです。草案、レビュー中、最新は、専門分野ごとの編集権を伴って強制される状態であって、ファイル名の中のラベルではありません。公開とは、発効日を伴う状態の変化です。

Slackの中で動く通知。 ライブラリは、KlivのSlack連携を通してチャンネルに投稿します。公開の告知、滞留しているレビュー依頼、今週動いたもののダイジェスト。通知のルールは、あなたが編集する行です。誰かが保守しているスクリプトではありません。

和田のライブラリは、3世代のCADと、それを育てたすべての技術者より長く生きます。ひとつの会社の中でそれだけ長く生きなければならないソフトウェアは、それ自体がひとつの技能です。Klivの社内ツールの流儀が、その技能です。

「どの改訂版が支配するのか」、ほか部門の言い争い