「ソフトウエアの品質をどう測るのか」「リスク要因を見積もりにどう反映すればよいか」。多くの現場では経験を積んだベテラン技術者の頭の中にあるだけだろう。ジャステックでは，それを“指標”という形にまとめて業務の中で回している。ベテラン技術者の暗黙知を，指標の項目とその基準値という形式知に変換している。
考えられるあらゆる現場のノウハウを指標に落とし込む。「見積もりの精度を測る指標」「テストの精度を測る指標」――。
どのような指標を設定するかは現場のノウハウの固まりである。それは通常，ベテラン技術者の頭の中に暗黙知として存在しているものだ。ジャステックの開発現場では，その暗黙知を指標という形で形式知化している。指標をすべての現場で共有することで，現場から現場へ技術の伝承が図られているのである。
ここにジャステックの現場のすごみがある。現場の技術者たちの指標への執念が，営業利益率11％（2006年11月期）という高い収益性を支えている。
長年，同社の開発部門を率いてきた太田忠雄氏（常務取締役 兼 常務執行役員 営業本部 本部長）は，次のように説明する。「技術には3種類ある。一つは業務ノウハウ，二つ目は言語やOSなどの要素技術，三つ目がエンジニアリングの技術。一つ目と二つ目は教育体系の中で引き継いでいける。三つ目は現場のノウハウを標準化することでしか引き継げない。ここにこだわって様々な指標を作ってきた」。
品質や見積もりを指標化する
例えば「ソフトウエア品質目標」を見てみよう。ソフトウエアの品質を測定するための130個の項目が並んでいる（図2左）。
その一つが「顧客クレーム件数」。年間の目標値を定め，顧客からのクレーム件数がその範囲内に収まれば目標を達成できたと判断する。
あるいは「内部レビュー指摘密度」。これは「指摘件数/ソフトウエア（またはドキュメント）規模」で測る。目標から大きく外れていれば，担当者はその理由を説明する必要がある。
システムの品質を測る業界標準は，存在しない。「どんな項目で測定するか」「どの程度の値を標準/目標とするのが妥当か」というのは，現場の勘と経験に任せられているのがこの業界の実情である。
指標化しているのは品質だけではない。例えば「見積もりがぶれるリスク要因」を指標化している（図2右）。
「要件定義にエンドユーザーが参加していなければ後工程で手戻りのリスクが高まる」「製品や技術を初めて扱う場合は習得のための工数が多めにかかる」。そういうことは何となくみんな知っている。しかし，どれくらい多めに見積もればよいのか，そもそも何をリスク要因ととらえればよいのか。多くの現場では，担当者の裁量に任されている。
