はじめに
ほとんどの開発組織においては、
#64:重症患者の取扱い方~トリアージ
ソフトウェア開発における主な成果物をその工程の順に見ると、
戦場や大規模災害時において患者の数が医療者側の資源
- トリアージ
(triage;選別) 患者の容態の軽重の程度を4分類し色分けする。救命処置の優先順位は、
Ⅰ→II→IIIの順とし、 0は無処置とする。黒はカテゴリー0 (死亡群) 救命の見込みがないもの。赤 はカテゴリーI (最優先治療群) 生命に関わる重篤な状態で一刻も早い処置をすべきもの。黄はカテゴリーII (待機的治療群) 赤ほどではないが、 早期に処置をすべきもの。緑はカテゴリーIII (保留群)。
Wikipedia
#65:とりあえずの結論に飛びつくヒューリスティクス
ヒューリスティクス
- ヒューリスティクス
脳の働きで驚くべき特徴の一つは、
めったにうろたえないことである。ふだんは出合うものすべてについて、 直感的に感じたり判断したりする。完全に理解できていない質問に対しても何かしら答えを持っている。ただし、 そのときあなたが根拠とする証拠は、 説明もできず立証もできないような代物ではあるが。 ヒューリスティクスの専門的な定義は、
「困難な質問に対して、 適切ではあるが往々にして不完全な答えを見つけるための単純な手続き」 である。ヒューリスティクスという言葉は、 「見つけた!」 を意味するギリシャ語のユーレカを語源に持つ。
ダニエル・
#66:最初から完全を望まないこと
最初から完全を望んでも普通は適わない。ましてチェックの対象物の正体をおぼろげにしか把握できていないものを完璧に仕上げることなどできるわけもない。未知のものをできるだけ正確に把握するためには事前調査に時間をかけ、
- 減災という考え方
今後の復興にあたっては、
大自然災害を完全に封ずることができるとの思想ではなく、 災害時の被害を最小化する 「減災」 の考え方が重要である。
御厨貴
#67:統合しないと機能しない
バラバラに散らばったものはシステムとして機能しない。分散したもの同士を一定のルールに従ってまとめ、
- ラグビー式アプローチ:scrum
逐次段階的すなわちリレー式のアプローチのもとでは、
プロジェクトは段階ごとに一つ一つのフェイズを通り抜け、 前フェイズの要求がすべて満たされたときはじめて、 次のフェイズヘと移っていく。このようなチェックポイントはリスクを最小化するが、 同時に、 このアプローチでは統合の余地はほとんどない。あるフェイズで生じた難関によって全開発過程のスピードが遅くなったり、 停止したりしてしまうからである。 全体的すなわちラグビー式のアプローチのもとでは、
フェイズは相当に重なり合い、 そのことによってグループは、 開発プロセス中に生じる振動や” ノイズ” を吸収できる。ボトルネックに直面したとき、 ノイズのレベルは明らかに増す。しかしそれによってプロセスが突然止まってしまうわけではなく、 チームは何とかして前へ推し進むべく努力するのである。
野中郁次郎・
#68:類似不具合の解消法
類似不具合を解消するには類似不具合とその解決法をまとめた
- 不祥事の再発を防ぐ四つの
「安全文化」 情報を隠さない
「報告する文化」、 信賞必罰を行う 「正義の文化」、 失敗の経験を生かす 「学習する文化」、 必要に応じ組織や仕組みを改編する 「柔軟な文化」。
ジェームズ・
#69:逸脱の法則
一定の割合で販売台数が増えていくビジネスプランは販売現場のコミットメントを取っていない企画者の創作であり、
規則的すぎるデータは、
観察の結果ではない。作為の結果である。
G.
#70:RASUI~商品の命は信頼性だけではない
優れた商品の5つの条件はRASUIにある。耳慣れない言葉であるが次の5つの特性を備えたものが良い商品の条件である。
- Reliability:信頼性
- Availability:可用性
(継続的稼動能力) - Serviceability:保守性
- Usability:使用性
(使いやすさ) - Installability:設置容易性
総合テストは、
- 儲かりますか、
その製品で 当たり前のことだが、
儲かるかどうかは、 製品に盛り込まれた技術が高度か否かで決まるのではない。自社以外に同等品を提供できる会社が何社あるかで決まっている。たとえ盛り込まれる技術が高度であっても、 同じくらい高度な知識を製品に盛り込める会社が世界中に何社も存在するなら、 残念ながら利益は手に入らない。
沼上幹
おわりに
総合テスト・
- ベンダー側においては既に評価業務についての実行能力は大幅に低下しており、
また下請け評価チームの評価業務能力が低いため、 適正な評価業務が遂行されていない。 - 仕様検討工程・
設計製造工程の不良および評価業務遂行能力の不足により十分なテスト計画・ チェックリスト・ 評価用ドキュメントの策定ができていない。 - 不具合に対する感覚の鈍さ、
不具合に対する実務能力の不足により、 適切な不具合対応ができていない。
ベンダー側においては、