現場が編み出したワザ(2)
今回は、「レビューをしやすくする設計」「レビュー会議の無駄の削減」「支援ツールの活用」という3つのテーマについて見ていこう。 レビューをしやすくする設計：ひと手間が欠陥の見逃しを防ぐ 設計にひと手間を加えて，レビューでの重大な欠陥の見逃しを防ぐ。そんな取り組みをしている現場がある。 日立製作所の一部のプロジェクト・チームでは，詳細レベルのユースケース・シナリオを作成している（図1）。石川貞裕氏（情報・通信グループ プロジェクトマネジメント統括推進本部 担当本部長）によると「狙いは，基本設計書のレビューにおいて，性能や信頼性，ユーザビリティなど非機能仕様の妥当性を検証しやすくするため」である。 日立製作所では，石川貞裕氏らが主導し，基本設計において詳細レベルのユースケース・シナリオを作成している。レビューアがこれを使って利用場面の具体的なイメージをつかみながら，性能や信頼性など非機能仕様につ
頑張るだけのレビューはもう限界
上流で品質を作り込むことを狙い，設計レビューを強化する現場が増えている。しかし，長時間に及ぶレビューは現場の負荷を高め，メンバーを疲弊させる。それだけの労力を投じても，重大な設計ミスが必ずしも減らないのが現実だ。3人のITエンジニアが座談会でその実態を語った。（聞き手は中山 秀夫＝日経SYSTEMS） 情報システムの信頼性に対する要求が厳しくなるなか，品質管理を強化し「設計ミス」をなくそうとする動きがあるようです。みなさんの現場では，いかがでしょうか？ Aさん：私は製造業のシステム部門に勤めています。設計の品質向上は，大きな課題になっていますね。テストでバグをつぶすのではなくて，もっと上流できっちり品質を作り込んでいこうという方針です。最近はレビューの強化に取り組んでいます。レビューの回数を増やしたのに加えて，設計レビューで有識者を必ず入れるルールになりました。 有識者は具体的にはどんな人
設計ミスをなくそう！現場を救うレビューの秘訣：ITpro
設計レビューは決して，次工程に進む儀式ではない。設計ミスをなくし後工程での手戻りを防ぐ，貴重な機会だ。やり方を工夫すれば，そんなレビューを実現できる。現場が編み出したレビューの秘訣を紹介する。
スルガ銀-IBM裁判の判決全容が判明
勘定系システムの開発失敗を巡るスルガ銀行と日本IBMの裁判について、東京地方裁判所が3月29日に下した判決の詳細が明らかになった。日経コンピュータは『スルガ銀が事実上の全面勝訴 IBMの責任認めた判決の深層』として判決の概要とその影響を速報した。ただ、日本IBMが判決について閲覧制限を申請していたため、これまでは約74億円の賠償を命じた判決理由は公開されていなかった。 今回、本誌が入手した判決文によれば、日本IBMが敗訴した最大の理由は、同社が米フィデリティ・インフォメーション・サービス（FIS）の勘定系パッケージソフト「Corebank」の選定に際し、リスクの回避策など十分な検討を怠った点（図）。上流の工程で日本IBMに重大な不備があった以上、スルガ銀が支払った費用は全て返還すべきという論理だ。 東京地裁は合計3回実施した要件定義が迷走したことを判断根拠とした。日本IBMは1回目の要件定
DIコンテナ【Dependency Injection Container】
DIコンテナは，「DI（Dependency Injection：依存性の注入）」と呼ぶデザインパターンに基づいて作られたコンポーネント群を集中管理するためのソフトウエアです。 DIは，コンポーネント（クラス）間の依存関係をソースコードから取り除くことで，プログラムの実行時までコンポーネント同士が依存関係を持たないようにするデザインパターンです。 例えば，あるクラスAの中で別のクラスBのインスタンスを生成して利用しているとき，AはBに強く依存してしまっています。つまり，Bを別のクラスに差し替えたときなどにはAも変更しなければなりません。このような依存関係は，AとBを別の人が作っている場合などに特に困ります。 こうした依存性をクラスから取り除くのがDIパターンです。Bへの依存性をAから排除するには，まずBの機能を抽象化したインタフェースIを定義し，Iを実装したクラスとしてBを作ります。 Bの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
