タグ

2010年8月9日のブックマーク (5件)

  • レビューの目的と進め方

    レビュー会議が失敗する背景に,典型的な三つの原因がある。それらを回避し効果を高めるには,プロセスを踏み,3回に分けて実施するとよい。レビューの専門家に,その方法とコツを解説してもらう。 細川 宣啓  日IBM みなさんの現場では,こんなレビュー会議をしていないだろうか。議論が発散して時間が掛かる割に,重大な欠陥を検出できない。議論が活性化せず,みんな下を向いている。なじり合いやケンカの場になっている─。 そもそもレビュー会議には,スキルの高いITエンジニアが参加するはず。それなのに,どうして冒頭のようなレビュー会議になってしまうのか。 筆者は現場の開発リーダーや品質保証部門という立場で,数多くのレビュー会議を見てきた。その経験からいえるのは,レビューが失敗に終わる背景には典型的な原因が存在し,それらを回避するための工夫やコツがある,ということだ。 以下では,組織的なレビューの要といえる「

    レビューの目的と進め方
  • 新聞社に学ぶレビューの秘訣

    記事中のわずかな間違いも見逃さない。そんな新聞社の校閲部門のレビューとはいかなるものか。そこには,設計書のレビューに通じるテクニックと,二重チェックの体制が存在した。 「米海軍普天間飛行場」「漱石は1901年,政府から文学博士号を授与される」──。これらは,読売新聞社の校閲部門が間違いを見つけ修正した記事の該当個所である。どこが間違っているか分かるだろうか。 普天間飛行場の所属は米海兵隊なので「米海兵隊普天間飛行場」が正しい。夏目漱石が文学博士号を授与されたのは,正しくは1911年。 そんなの分かるわけがない,と思ったかもしれない。しかし実際にそれを見抜いているのが,新聞社の校閲部門である。しかも校閲作業を行うのは,記事の原稿が書き上がってから印刷工程に進むまでの限られた時間だ。新聞社の校閲部門には,専門家集団として磨き上げた「レビュー力」が存在する。 では,校閲部門のレビュー力とはいかな

    新聞社に学ぶレビューの秘訣
  • 現場が編み出したワザ(2)

    今回は、「レビューをしやすくする設計」「レビュー会議の無駄の削減」「支援ツールの活用」という3つのテーマについて見ていこう。 レビューをしやすくする設計:ひと手間が欠陥の見逃しを防ぐ 設計にひと手間を加えて,レビューでの重大な欠陥の見逃しを防ぐ。そんな取り組みをしている現場がある。 日立製作所の一部のプロジェクト・チームでは,詳細レベルのユースケース・シナリオを作成している(図1)。石川貞裕氏(情報・通信グループ プロジェクトマネジメント統括推進部 担当部長)によると「狙いは,基設計書のレビューにおいて,性能や信頼性,ユーザビリティなど非機能仕様の妥当性を検証しやすくするため」である。 日立製作所では,石川貞裕氏らが主導し,基設計において詳細レベルのユースケース・シナリオを作成している。レビューアがこれを使って利用場面の具体的なイメージをつかみながら,性能や信頼性など非機能仕様につ

    現場が編み出したワザ(2)
  • 現場が編み出したワザ(1)

    限られた時間のなかで重大な欠陥を一つでも多く見つけるため,レビューのやり方に,独自の工夫を重ねている開発現場がある。軽微な欠陥の一括除去や設計書間の整合性の見える化など,現場が編み出したレビューのワザを紹介しよう。 「設計レビューを実施しても,重大な欠陥を見逃してしまうことがある。そのため,どうすれば効果的なレビューを実現できるか,いつも試行錯誤している」(ウルシステムズ シニアコンサルタント 小森裕介氏)。 このようにレビューに対して問題意識の高いITエンジニアは,従来のやり方に満足せず,自ら工夫を重ね,独自のやり方を試している。今回と次回は,そうした現場が編み出したワザを,「軽微な欠陥の一括除去」「設計書間の整合性の見える化」「レビューをしやすくする設計」「レビュー会議の無駄の削減」「支援ツールの活用」という五つのテーマに分けて紹介する。 軽微な欠陥の一括除去:繰り返し型の手法が抜群の

    現場が編み出したワザ(1)
  • 頑張るだけのレビューはもう限界

    上流で品質を作り込むことを狙い,設計レビューを強化する現場が増えている。しかし,長時間に及ぶレビューは現場の負荷を高め,メンバーを疲弊させる。それだけの労力を投じても,重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。(聞き手は中山 秀夫=日経SYSTEMS) 情報システムの信頼性に対する要求が厳しくなるなか,品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では,いかがでしょうか? Aさん:私は製造業のシステム部門に勤めています。設計の品質向上は,大きな課題になっていますね。テストでバグをつぶすのではなくて,もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて,設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人

    頑張るだけのレビューはもう限界