タグ

SIerとtestingに関するimai78のブックマーク (2)

  • 指標化しないと気が済まない!膨らみ続ける「形式知」

    「ソフトウエアの品質をどう測るのか」「リスク要因を見積もりにどう反映すればよいか」。多くの現場では経験を積んだベテラン技術者の頭の中にあるだけだろう。ジャステックでは,それを“指標”という形にまとめて業務の中で回している。ベテラン技術者の暗黙知を,指標の項目とその基準値という形式知に変換している。 考えられるあらゆる現場のノウハウを指標に落とし込む。「見積もりの精度を測る指標」「テストの精度を測る指標」――。 どのような指標を設定するかは現場のノウハウの固まりである。それは通常,ベテラン技術者の頭の中に暗黙知として存在しているものだ。ジャステックの開発現場では,その暗黙知を指標という形で形式知化している。指標をすべての現場で共有することで,現場から現場へ技術の伝承が図られているのである。 ここにジャステックの現場のすごみがある。現場の技術者たちの指標への執念が,営業利益率11%(2006年

    指標化しないと気が済まない!膨らみ続ける「形式知」
  • サービスインに間に合わなかった原因は何だったのか?

    プロセスを改善するということ 開発プロジェクトの現場では、大なり小なり必ず問題が存在する。それらの問題は最終的に低品質、予算超過、納期遅延などプロジェクトの失敗につながることもある。この状況を打開しようとさまざまな手を打っている企業は多いが、その打ち手は必ずしも大きな成果を挙げているとはいえない。 よくある要因の1つに、問題が顕在化した際に安易に個人や組織・ツールを原因と特定し、対策を講じようとすることが挙げられる。個人を原因として対策を施した場合、問題は解決したとしても組織には何も蓄積されない。そればかりか、人格否定など別の問題を発生させることもある。また、ツールおよび組織についていえば、そもそもなすべきことを効率的に実行するために組織は編成され、ツールは選定されるべきだ。なすべきことをきちんと分析せずに、組織やツールに対症療法を施しても、成果が出ない場合が多い。 そこで、なすべきこと、

    サービスインに間に合わなかった原因は何だったのか?
    imai78
    imai78 2008/10/06
    でも、途中で要件変わったらどうするんだろ。
  • 1