Comments
Description
Transcript
組み込みソフトウェア開発に おけるレビュー技術
6 組み込みソフトウェア開発に 特集 高信頼性組み込みソフトウェア開発－最新技術動向と取り組み－ おけるレビュー技術 金子 龍三 日本電気通信システム（株） [email protected] 日本での専門技術教育の見直しの必要性 ▪商品の複雑化 自動車，携帯電話，そしてインターネット関係の通信 家電製品，自動車，携帯電話網・携帯電話などで障害 装置などは多くのソフトウェア，データファイルを含み， が発生している．その他の業界でも障害が起きている． 複雑化し，さまざまなシステムに接続されている．その このような障害に関連して専門家の倫理と能力に厳しい 結果，直接原因を究明するトラブルシューティング技術 非難がある． が必要になる ．仕様も多様で変化しやすく，検討項目が 日本の開発文化では，開発期間の短縮や費用削減など 膨大になっていて，それらの商品に組み込まれるソフト の圧力があると専門家が手抜きすることがある．また ウェア量は増大している．課題の変化を図-1に示す． 1） どのような課題にどのような方法を適用するかについて は特定の技術者の固有技術（暗黙知）であることが多く ▪連続商品化・短期間開発化 その個人がいなくなれば組織としても技術がなくなるこ 従来は研究開発試作，実用評価機試作，商用開発を数 とがある．組織の技術として確立して（暗黙知を形式知 年間で行っていたので，技術修得も，ツール開発も，技 化し組織知とする）いても組織外に公表することは少な 術者教育も開発中に可能であった．最近は競争条件の変 い．そのため日本では専門知識・技術が累積し難く，専 化のため3カ月程度の開発期間も珍しくないので，上記 門家になろうとすると初級段階から修行することが必要 開発や教育が間に合わず各種のリスクが顕在化している． になり，失敗を繰り返しやすい． 従来の航空宇宙，防衛産業で開発された高信頼性技術は 日本では開発技術教育やマネジメント技術教育でも基 基本ではあるが実務では適用できなくなっている．無理 本知識・基本技術から説明する必要がある．このことに に適用すればレビューやテストで手抜きが発生しやすい． 対して，あるアジアの専門家集団から 「インターネットや 書籍に記載されていることは省略して説明するべきだ」 ， ▪複数機種，複数市場向けの同時並行開発 「文書に記載されていない内容（実践的技術）が日本人の 市場が成熟しており，競争も激しいので単一市場・単 コア技術だ」と言われた．以下に社内での開発経験から 一商品だけでは収益が出ないことが多い．収益力を向上 得た内容と社内外で開発マネジメントについて指導して するために複数機種・複数市場・複数顧客向けを同時に いる内容から，改革方法とレビューの実践的技術に限定 統一的に並行開発する傾向にある． して，専門家が専門家になる人を指導する（技術を伝承 する方法の教育） 際の参考情報として紹介する． ▪外部購入品の増加 開発費用の削減と開発期間の短縮のために，先行開発コ 開発要求条件の変化 ンポーネントを国内外から購入する場合が増えている．そ の場合にそれらが信頼性問題を起こすことが少なくない． 短納期，低価格化など，組み込みソフトウェア開発の 要求条件が変化し，変化に気がつかずに問題を起こしたり， ▪開発投資負担の増加 変化に対応できずに問題を起こしたりしている．レビュー技 自社の商品以外との接続評価を工夫せずに行うと検査 術も開発の要求条件の変化に対応して革新する必要がある． 設備投資は膨大になる．販売額より開発投資額が大きく IPSJ Magazine Vol.47 No.5 May 2006 519 特 集 高信頼性組み込みソフトウェア開発 −最新技術動向と取り組み− 管理 •費用削減 •効率化 条件 •短納期 •競争 プロジェクト IN •多様な仕様 •仕様変更 •海外調達 大 プロジェクト 仕様定義 設計 規 検証 模化 OUT •高信頼性 •拡張性 •接続性 外部 調達 既存資産 •大規模 •複雑化 技術 •膨大な検討項目 •技術の変化 資源 •外部組織 •海外要員 図-1 課題の変化 なり，収支を悪化させることもある．特殊な検査機材に クトにおける品質マネジメントの指針（JIS Q 10006）にプ よる評価をできるだけ減らす方策が必要になる． ロジェクトマネジメントの知識体系に対応した記載があ り，考慮することが望ましい． 組み込みソフトウェア開発における 変動対応方法 品質マネジメントシステムのパフォーマンス改善の指 針（JIS Q 9004）の「4.3品質マネジメントの原理」に従うと， これらの活動および関連する資源（人々，インフラスト 組み込みソフトウェア開発の高信頼性技術は政府発注 ラクチャ，作業環境，情報，供給者およびパートナシッ の航空宇宙産業での高信頼性技術とは異なり，レビュー プ他）が1つのプロセスとして運営管理されるとき，望ま 技術も異なる．レビュー技術の前提となる変動対応方法 れる結果がより効率よく達成され（プロセスアプローチ について記載する．以下の記載内容は日本企業が欧米や の原理），これらの相互に関連するプロセスを1つのシス アジアの国との競争に勝つための方法として社内外で指 テムとして，明確にし，理解し，運営管理することが組 導している内容である． 織の目標を効果的で効率よく達成することに寄与する （マネジメントへのシステムアプローチの原理） ．組み込 ▪品質マネジメントシステムの適用 みソフトウェア開発での最新のマネジメント技術はこれ 上記開発要求条件の変化に適応しつつ高信頼性を確保 らを総合したプロセスネットワーク技術である ．その するためには，組織全体で品質マネジメントシステムに 1つのサブプロセスネットワークとしてプロダクトライ 取り組むことが必要不可欠である．しかし品質マネジメ ンマネジメントを適用して組み込みソフトウェア開発を ントシステムの要求事項（JIS Q 9001）に記載された内容 改革することが先進企業での動向である．レビューはプ では内容が一般的で効果がない．実務では品質マネジメ ロダクトラインマネジメントの一環としても行う． 2） ントシステムのパフォーマンス改善の指針（JIS Q 9004） も適用する．技術者だけではなく，経営者・管理者の役 ▪プロダクトラインマネジメント 割も重要である．トップマネジメントの分担事項には， 組み込みソフトウェア開発では開発要求条件（期間・ 組織目的と一致したビジョン，方針，および戦略的目標 費用・人的資源など）の変化に伴い，商品リリースごと を設定すること，品質および品質マネジメントシステム にプロジェクトを設定することは困難になっている．商 に関する組織としての方向性と価値観を伝えること，改 品群全体（プロダクトライン）を1つのマネジメント対象 革プロジェクトに参画すること，製品実現プロセス（情 として設定し，方針設定・計画・実行・監視と制御・改 報処理でいえばエンジニアリングプロセス）を明確にす 善・保証する．その部分として特定商品・特定市場ごと ること，支援プロセス （マネジメントプロセスを含む） を にプロジェクトを設定する．組み込みソフトウェア開発 明確にすること，要求事項に加えて顧客の現在および将 ではソフトウェアライフサイクルプロセス，あるいはプ 来のニーズと期待を理解すること他がある．レビュー技 ロセス成熟度モデルなどのプロセスをプロダクトライン 術者の育成も経営者・管理者の責任事項である． にも適用する．追跡可能性の保証，成果物の管理などの プロジェクトの製品実現プロセスについてはプロジェ 支援プロセスもプロダクトラインにも適用する． 520 47 巻 5 号 情報処理 2006 年 5 月 6 組み込みソフトウェア開発に おけるレビュー技術 プロダクトライン 憲章（charter） プロジェクト憲章 マネジメントシステム プロダクトラインマネジメント能力群 マネジメント 管理項目 ルール 市場・顧客他 商品計画群 プロセス DB プロセスフロー DB 要求仕様 データベース(DB) プロセスネットワーク群 プロダクトDB 母体・プラットフォーム・購入資産 プロダクトDB 群 プロダクトライン能力群 技術 スコープ 知識ベース 人的資源 定義書・マニュアル他 組織・パートナ トレーニング 方式 設備・ツール 要求条件の論理構造 開発ツール 動作設計 方式設計 検証ツール 図-2 プロダクトラインマネジメントのフレームワーク Input 開始条件 Output 開発プロセス 終了条件 順序 資源・知識・技術・情報・資産 詳細項目 組織・人 メトリクス 技術 知識 資産・資料 設備・ツール 点検情報 結果情報 管 訓 練 プロセ ス 採 用 パートナリング プロセ ス 理 プロセ ス 管理指導 プロセ ス 技術開発 知識整備 プロセ ス プロセ ス 資 産 ・資 料 準 備 プ ロ セ ス 設備ツール 準 備 プロセ ス 図-3 プロセスネットワーク部分図 プロダクトライン全体を範囲にして，顧客の現在お ▪プロセスネットワーク技術の適用 よび将来のニーズと期待に基づいて仮説設定（Peirceの 経営者の担当プロセスも含めて組み込みソフトウェア abduction法）をも用いた要求エンジニアリング，要求分 を開発するために必要なプロセスをすべて相互に関連し 析モデリングを行い，アーキテクチャを設計し，追跡可 た1つのプロセスとしてプロセスネットワークを設計し， 能性の保証を行い，構成要素である部品を体系的に先行 適用する．従来のプロセス改革とは異なりプロセスを個 開発する．プロダクトラインマネジメントの方法は各企 別に改革するのではなく，製品実現プロセス全体をプロ 業での企業秘密であるため，詳細な情報を他社から得る セスフローとして相互の関係をも改革する．さらに各プ ことはできないので欠落した断片的な情報から得たプロ ロセスの能力の整備プロセスも設計し改革する．その結 ダクトラインマネジメントのフレームワーク仮説を図-2 果プロセスはネットワーク状になり，それにトップマネ に示す．プロダクトラインマネジメント全体はプロダ ジメントレベルのマネジメントプロセスをも含め統合的 クトラインのマネジメント能力，プロセスネットワーク に改革する（社内外への指導内容）．プロセス能力要素に （開発プロセスフロー他） ，プロダクトライン能力，プロ 関連したプロセスの例を図-3に示す． ダクトデータベース，および商品計画群から成り立って いる． IPSJ Magazine Vol.47 No.5 May 2006 521 特 集 高信頼性組み込みソフトウェア開発 −最新技術動向と取り組み− ▪工程別品質保証 顧客の現在および将来のニーズと期待を実現するため 効果的レビューの方法 には「プロセスネットワークにおいてどのプロセスで何 ソフトウェアのマネジメント技術についての米国の某 を保証するか」を設計する必要がある． 企業（複数） の技術者との討議において，上記に説明した 詳細は省略するが，組み込みソフトウェアの工程別の 組み込みソフトウェア開発における変動対応方法の不足 要点は次のとおりである． を指摘されたのに加え， 「日本の企業の技術者のレベル ・要求エンジニアリングプロセスでライフサイクル中の が低すぎてソフトウェアのマネジメント技術については ニーズと期待を満たす要求仕様書を作成する 日本とは討論にならない」と日本の専門家グループが言 組み込みソフトウェアではノイズやハードウェア故障 われ，日本のソフトウェア技術者の能力が疑われた．そ 時の処理も妥当性確認の対象である．カーナビでの地図， の反省から日本の専門家教育の向上のために日本国内で 駅務システムでの駅ごとの料金表などは詳細な内容ごと のレビュー方法の再評価と米国の専門家のレビューの実 に保証する必要がある． 地観察（レビュー技術を見抜く）を行った．その結果から ・要求仕様書記載事項を満たす作り込みを行い，追跡可 得たレビュー技術（社内外での指導内容）を以下に説明 能性の保証を行い，設計もれを防止する する． ・作り込みプロセスにおいて設計検証・レビューを行う 組み込みソフトウェアではハードウェア障害時の処理 ▪レビュー教育の実務 などはテストできない．ハードウェア障害時処理の妥当 組み込みソフトウェア開発でも，学校で専門教育を受 性などは設計検証あるいは単体テストで検証する． けていないで企業内で数カ月研修を受けただけの技術者 短期間開発ではレビューの時間も限られるし，特定技 が開発していることがある．専門教育を受けていない人 術者への業務負荷集中によりレビューする人の確保も の設計を，専門教育を受けていない人がチェックリスト 難しい．レビューもれを再発防止するためにレビューも を見てレビューしているようでは国際競争には勝てない． れ項目をレビューチェックリストに反映しても，短期間 また専門教育を受けていない人が個人ですら保証してい 開発ではチェックリストの記載事項すべてをレビューす ない成果物をレビューしている暇はない．このような場 ることはできない．プロセスの結果をレビューチェック 合はレビュープロセスの着手条件を満たしていないので， リストに基づいてレビューする技術はレビューに長時間 レビューは終了し，セルフチェックをさせ，さらに同僚 かけることができた時代の技術である．レビューを効果 がチェックしてからレビューを再開する．日本ではレビ 的で効率的にするためには，プロセスそのものをレビュ ュー教育以前に専門家としての自覚指導，セルフチェッ ーしその後にプロセスの結果をレビューする．この方法 ク指導とソフトウェア開発技術教育が必要である． をプロセスネットワークに基づくレビューといっている 要求仕様書のレビューの終了基準は設計および妥当性 （これは実務に基づく提案である） ． 確認で必要な項目を満たしているかどうかである．1行 ・要求仕様書記載事項を満たしているかを検証する の設計仕様（備考1参照）のレビュー教育でも工程別品質 組み込みソフトウェアでは開発規模は小さくても出荷 保証を指導するので2時間以上（実績値）必要であり，10 母体は大きく，全体を保証しようとするとテスト項目は 行の要求仕様（備考2参照）のレビュー教育でも追跡可能 膨大になる．既存評価済み部分のテストを少なくする技 性の保証を指導するので1日以上（実績値） 必要である． 術が必要になる．テストを少なくするために影響度解析 も行う．また部品レベルでの保証，単体レベルでの工程 ▪組み込みソフトウェアのレビュー方針 別保証を強化し，システムテストの負担を減らす． ライフサイクル中の顧客のニーズと期待を満たすため のレビュー方針は次のとおりである． ▪品質目標 品質保証項目を割り付けるだけではなく品質目標も設 ・ライフサイクル中の最大構成・最大負荷を含めた全シ ーン･シナリオでの動作も検証し，拡張性の検証も行う 定する． ・ライフサイクル中の例外・異常時の動作も検証する 「プロジェクト全体でのバグ検出率を机上で70％，検 ・組み込みソフトウェアでは例外・異常時のシーンとし 査で30％」が実現可能な品質目標の例である．検査期間 の短縮を図るために作り込み品質を向上することがねら いである．小集団活動では実績例から「バグ検出率を机 上で80％，検査で20％」 の目標で指導した． 522 47 巻 5 号 情報処理 2006 年 5 月 てハードウェアの劣化，故障時の動作も検証する ・異常時の特殊なシーンとしてパニック時の妥当性検証 も行う ここでパニック時課題について簡単に説明する．電力 6 組み込みソフトウェア開発に おけるレビュー技術 ■備考1 次の仕様をレビューせよ（カウンタCCNTを10カウントアップせよ）． CCNT＝CCNT＋10 ■備考2 次の電子マネーカード販売機の仕様書をレビューせよ． • REQ0010：1,000円で新規に電子マネーカードを販売する． • REQ0020：1,000円札でのみ使用できる． • REQ0030：1,000円が入力されたら，カード代500円を徴収することを表示する． • REQ0040：前受け代金は500円であることを表示する． • REQ0050：発行ボタンを入力するよう表示する． • REQ0060：発行ボタンの入力を監視する． • REQ0070：発行ボタンの入力を検出したらカードに前受け代金500円を記入する． • REQ0080：カードを払い出す． • REQ0090：領収書を発行する． • REQ0100：発行前に取消ボタンが入力されたら，1,000円札を払い出す． ＜備考＞ システム，通信システム，交通システム，ガス・水道他 ▪技術的問題解決思想（情報工学） のインフラシステム関連商品などにおいて，大震災や大 レビューの基礎は課題をレビューし，技術問題解決手 火災発生時に顧客や運用者がパニックに陥り緊急操作し 順をレビューすることにより，技術問題解決手順の誤 た場合などでの異常操作，高負荷をパニック時課題とい り・もれの有無を確認することである． う．「関西・淡路大地震では通信トラフィックのパニッ 組み込みソフトウェアの開発においてしばしば問題に ク時リスク係数（通常トラフィックとパニック発生時の なるのが，状態遷移問題である．シーケンスチャート トラフィックの比）は平常時トラフィックの50倍になっ やタイミングチャートで設計し，状態遷移表を作成して た，首都圏大地震では何倍になるであろうか」これがレ いないため，例外・異常処理が抜けているケースがある． ビュー教育での演習（リスクマネジメントでのリスク発 このような状態遷移問題の解決手順を知らずに設計した 生確率見積り技術，変動要因構造の解析技術を適用しレ 資料はレビューに値しないのでレビューは中止する． ビューせよ）例である． ▪段階的検証思想 （品質学） レビューの前提となる基本思想 アクティビティごとの質をレビューし，プロセスごと の質をレビューする． 専門家として自覚を持たせるためにレビューの前提と なる基本思想から指導する． ▪組織原則・階層別分担思想 （経営学・品質学） プロセスネットワークベースレビューの 要点 レビューも組織内の行動（バーナード経営学での協働 ▪プロセスネットワークベースレビューの順序 の1つ）であり，組織原則の1つである階層による分担（専 上記の基礎となっている理論からも分かるように，プロ 門化・特殊化）協働が基礎である． セスの定義書あるいはプロジェクトマネジメントでのス 個人，小グループ，チーム，事業，そして会社として コープの定義書に基づいて，工程別品質保証計画で求め の自律的分担が信頼性問題でも基礎である． られている品質を満たしているかどうかをレビューする． ①設計課題に応じた着手条件である仕様書類をレビュー ▪プロセスアプローチ思想（品質学） する 確実にレビューする方法は設計課題を確認し，設計課題 組み込みソフトウェア開発での着手条件不備には，例 に応じた技術者で妥当な技術を適用しているかどうか，技 外条件・異常条件定義もれ，連続商品開発での機能追 術の弱点を知っていて補正しているか，誤りや見逃しはな 加時の既存機能との機能関連分析の不備，アーキテクチ いか （追跡可能性は保証されているか） である．そのために ャ設計方針の欠落，データの論理構造設計書欠落などが はプロセスネットワークに基づくレビューを行う （後述） ． ある． ②当該設計課題を解決する技術を修得している技術者が 担当しているかをレビューする．妥当でない場合には IPSJ Magazine Vol.47 No.5 May 2006 523 特 集 高信頼性組み込みソフトウェア開発 −最新技術動向と取り組み− 仕様書 プロセスマネジメント 情報 Input １ 計 設 順序 開始 条 件 Output 設計書 終了条件 ６ 資源・知識・技術・資産 工 プロセスマネジメント 情報 Input 設 開始条件 １ 計 順序 Output Input 終了条件 開始条件 程 順 序 ３ プロセスマネジメント 情報 設 計 ｎ 順序 Input Output 終了条件 開始条件 資源・知識・技術・資産 資源・知識・技術・資産 ２ 技術者の 知識・能力・ 行動習性 ４ 採用した 技術 プロセスマネジメント 情報 品 質 保 証 順序 Output 終了条件 資源・知識・技術・資産 ５ セルフチェック クロスチェック ペアレビュー チーム内レビュー 図-4 プロセスネットワークベースでのレビュー レビューには時間をかけるか，あるいはレビューでは グなどが疎かになりやすい．インプット・処理･アウト なく指導を行う プットの対応づけやデータ構造定義は30年前の技術であ 組み込みソフトウェア開発での技術者条件不備には， るが現在でも組み込みソフトウェア開発技術者に対して 要求分析モデリング技術未受講，データ設計技術未受講， は指導が必要なことが多い（紙に書いて設計していた時 アーキテクチャ設計指導欠落，プログラム作法訓練不足 代は書式テンプレートを使用したので開発者自身が整合 などがある． 性を確認していたがPCを使用するようになってからイ 課題と担当技術者が妥当であれば技法をレビューする． ンプット，処理，アウトプットを別々に設計するように ③選択した技法での順序を守っているかをレビューする なり整合性が問題になっている） ． ④技法を適切に使用しているか成果物を見てレビューす ⑤階層別品質保証をレビューする る（目次を見て技法の選択を確認し，該当項目の内容 階層別品質保証ではセルフチェック欠落（追跡可能性 を見て技術修得レベルを確認する） 違反による設計もれなど） ，ペアレビューもれ（勘違い 的確な技法を使用していなければ，レビューはその部 程度のミス），チーム内レビューが説明会程度でQuality 分を中止する，あるいは技術指導する． Gateになっていないなどが対象である． 技法不適切には着手条件である受領物件に対する例外 以上のプロセスネットワークベースレビューを基に， 処理条件・異常処理条件レビューもれ，先に記載した状 実際に行う詳細レビュー項目を決定する． 態遷移設計もれ，シーン・シナリオなどのテスト仕様書 ⑥結果をレビューする 作成技術欠落などがある．組み込みソフトウェア開発で は先に述べたように短期間連続並行開発のために機能設 ▪レビュー重点項目の決定 計に気をとられ，インプット・処理･アウトプットの対 時間的余裕があればすべての項目をレビューするが実 応づけ，データモデリング，シナリオベースのモデリン 務では絞らざるを得ない場合がある．その場合でも必ず 524 47 巻 5 号 情報処理 2006 年 5 月 6 組み込みソフトウェア開発に おけるレビュー技術 保証するべき項目は前提条件に記載する．重要品質問題 はない． を前提条件として定義し，信頼性設計を行い，重要品質 問題の発生を防止するための工程別・階層別品質保証項 ▪技術者倫理・安全性など基本前提の徹底技術 目を定義する（プロセスネットワーク設計） ．検証もれを 経営層からの開発費用の削減や，要員の削減，開発期 起こすと火災事故，人身事故，顧客データの喪失，顧客 間の短縮などの要請に過度に対応し過ぎると，専門家と 事業の停止などが発生する．絶対に行うレビュー項目は しての倫理を忘れたり，商品開発で最も重要な安全性な このような重要品質問題発生防止対応項目である． どを軽視したりして事故が起きることがある． 同様に組み込みソフトウェア開発で忘れてはならない ▪レビューの形式と技術の検証方法 項目に法的・規制要求事項がある．製品安全関係法令 レビューにはチーム内レビューと専門家が参画するレ 以外にも組み込みソフトウェアでは貿易関係法令も関係 ビューとがある．チーム内レビューでもプロセスネット する． ワークマネジメントに基づくレビュー方法では技術者の 行った結果をレビューするのではなく，技術者の行った ▪技術のマネジメント プロセス内のアクティビティを分析し（プロセスネット 組み込みソフトウェア開発のマネジメントで必要な暗 ワーク分析を行う） ，アクティビティにもれがあればそ 黙知をプロセスネットワーク設計に織り込み，プロセス のアクティビティで保証するべき項目（プロセス定義書 ネットワーク設計書に基づいてマネジメントし，レビュ 記載項目）のもれを指摘する．アクティビティが妥当で ーする必要がある． あれば，各アクティビティのプロセス定義内容に従って 品質保証項目を確認し，妥当でなければ指摘する．プロ ▪アーキテクチャ技術の強化と継承 セス定義書があればそれに基づいて行うが，なければ 海外から，顧客からアーキテクチャについて厳しい批 （プロセス成熟度モデルを適用していないとほとんどが 判を受けており，日本の技術教育でのアーキテクチャ教 この段階）専門家が自身のプロセス定義項目に従ってレ 育が疑問視されている．テスト工数増大の有力な要因は ビューする． アーキテクチャ設計能力不足からくるパッチワークプロ 専門家によるレビューは技術者の行った結果をレビュ グラム（外付け・類似設計プログラム） にある．レビュー ーするのではなく，技術者の行ったアクティビティに基 で最も不足しているのがアーキテクチャレビューであり， づいてレビューするのでもない．技術課題から考えたプ アーキテクチャ設計思想の維持である．バグ修正時にア ロセスの定義内容に基づいて，アクティビティ（詳細プ ーキテクトが修正方法についてレビューすることが重要 ロセス）設計順序に従って専門家が技術的な内容を検討 である． する方法でレビューする． 今後・現在の課題 組み込みソフトウェア開発における，開発要求条件の 変化を説明し，変化に対応したレビューの実務を紹介し 参考文献 1）金子龍三：先端技術者のためのトラブルシューティング技術，― 組 込 み シ ス テ ム の 品 質 問 題 を こ の 一 冊 で 原 因 究 明 ―， 日 科 技 連 ISBN4-8171-9169-4 C3050 (2005)． 2）金子龍三：急性・慢性問題に有効な新しいISO9000技術プロセスネッ トワーク, ―デジタルエンジニアリングと品質保証研究会報告終了報 告―，第35回品質管理学会年次大会研究発表会（2005）． （平成18年4月10日受付） たが，課題の変化に対応したレビュー技術だけが重要で IPSJ Magazine Vol.47 No.5 May 2006 525