【問題】設計仕様書（設計成果物）は、作成した技術者により個人差が出やすい。設計仕様書の品質を安定させるための工夫を異なる観点から二つ上げ、それぞれを25字程度で述べよ。
解答
【解答例】
観点例１ 標準化と徹底（普及）方法に関する観点
観点例２ 設計技法と徹底（普及）方法に関する観点
観点例３ 仕様書の測定に関する観点
・目次と内容を標準化し、教育とレビューで徹底する
・目次と記述例を示し、教育とレビューを実施する
・定石やデザインパターンを利用し、レビューで徹底する
・レビュー密度や工数、時間の基準を定義して適用する
【解説】
設計技術者の個人差を排除して設計仕様書の品質を安定させるためには、論理の集合体であるというソフトウェアの特徴を十分に理解したうえで、品質管理の基本原則を適用する必要がある。
定石やデザインパターンなどを用いて設計技法を標準化し、個々の技術者に依存する設計の自由度を高めさせないように、レビューで徹底するとよい。また、目次や記述例など仕様書の書き方の標準様式を定め、それを徹底させることも仕様書の品質の安定につながる。手本となる設計仕様書の標準様式を用意し、教育・レビューすることは効果的である。設計の標準の徹底はなかなか難しいので、徹底のための工夫が求められる。さらに、レビュー密度などの設計仕様書の品質を評価するための尺度を定義し、品質確保のための基準値を設定し、設計仕様書を評価することも、設計仕様書の品質の安定化に寄与できる。
解答には、用語の定義、チェックリストの活用、設計品質を測る尺度の決定、設計仕様書の標準様式の作成、設計仕様書のレビュー、設計に関する教育などに関する記述が多くみられた。いずれの記述も重要であり、設計仕様書の品質の安定化に寄与できる。
一方、レビュー・教育の実施が多くの解答の中に記述されていたが、異なる二つの観点からの記述は少なく、類似の観点からのレビュー・教育に対する解答やただ単にレビューを実施するといった解答が多かった。さらに、仕様書の書き方や設計技法の徹底が重要であるが、徹底の工夫に言及していない解答も散見された。設計の標準化（設計部品の標準化と設計プロセスの標準化）の実施とその効果的な徹底・普及方法の工夫をセットとして考えることも品質管理の重要な観点である。
|
【問題】システムをお客様に提供してから一ヵ月が経過した。この間、システム停止に至るような重大故障は発生していないが、お客様から不具合や苦情が毎日のように寄せられている。システムの品質責任者として、寄せられた不具合・苦情をどのような観点で整理し、対処するか。整理の観点と対処方法の組合せを具体的に三つあげ、それぞれを50字程度で述べよ。
解答
【解答例】
①業務への影響度の観点で整理し、対応緊急度が高い不具合を優先的に改修する調整を顧客と実施する
②使用性のユーザーにとって仕様が判り難くなっている場合、マニュアルを改善し説明会を実施する
③性能面の苦情を整理し、ボトルネックを特定の上、顧客に使い方や運用変更で対応可能か申し入れする
④不具合や苦情が多発する日、時間があるか整理し、多発時間にはメンバを増強し対応を強化する
⑤ＳＬＡ順守（または要件との一致不一致）の観点で整理し、不一致個所について無償／有償での対応可否について顧客と調整する
【解説】
問題の狙い：
システムのサービス開始直後は、何かと業務の運用現場からの不具合指摘が発生する。
品質責任者として、現場の困り具合、仕様問題、システムの安定性をどのような観点からとらえるか、また、どういったアクションを取れば顧客の迷惑を解消することができるのかを問う。
解答のポイント：
システム本稼働直後、サービス開始直後には、これまで気付かなかった問題が噴出することがある。これらを適切に切り分け、対処することが必要である。特に、システムの利用者がどのような点で困っているかを明確にしていかないと、お客様からの不満が爆発することが多い。
まず、不具合かどうかを切り分け、業務への影響度を整理した上で緊急度が高いものから優先的に改修を行う。何らかの要因で、画面レスポンスなど性能が明らかに出ていない場合は、ユーザーの業務遂行のストレスや阻害要因となるため、ボトルネックを調査の上、顧客と早めに調整する必要がある。
新しいシステムに不慣れなエンドユーザーから、使い方について問合せが多く発生する場合もある。マニュアルの説明会開催や、ヘルプデスクの増強、FAQ の開設など、一時的に直接ユーザーにコミュニケーションを取ることで対処を行うことも検討する。
不十分な解答の特徴の例：
・リリース後一ヵ月の間に起きた不具合／苦情の整理により、今現在発生している顧客迷惑を解消するという目的から外れているものについては誤答とした。
（例）不具合分析として混入工程や原因分析、作り込み担当者の追及等を行う。（自社のプロセス改善に向けた対処は今後のシステム開発に有効だが、当該顧客への対処に繋がっていない）
・不具合、苦情を整理した観点ではないものについては誤答とした。
（例）主要ユーザーの年齢層を整理した上で、ボリュームゾーンについて対処する。
・問題文に「品質責任者として」と記載がある。対処として、お客さまに対して品質の責任を果たす行動となっていないものについては、誤答とした。
（例）不具合かどうかを切り分けて、開発担当者に連絡する。（連絡だけでは不具合解消に至る行動となっていない）
|
☞■中級ソフトウェア品質技術者資格試験（JCSQE）に合格しました。
【問題】大きなプロジェクトで新しい技術を使うことになったので、設計原則をドキュメントに纏めた。設計原則に精通すべき設計者が100人程いるが、当該技術に詳しくない人もいるため、徹底が難しそうである。設計原則の徹底を図るためにどのような対応方法をとるべきか、異なる二つ上げ、それぞれを25字程度で述べよ。 解答
【解答例】 ①専門家による教育の観点 新技術の教育専門部隊を設立し、設計原則を指導する ②指導者数増大の観点 指導者が次の指導者を発掘・育成し、累積的に人数を増やす レビューや指導を通じて、有望な指導者候補を発掘する ③ツール活用の観点 設計原則をツールに反映することで、原則逸脱を未然に防ぐ 設計原則をツール化することで、若手設計者へ技術継承する
【解説】
本問題は、新しい技術を使う大きなプロジェクトにおいて、設計原則を徹底するための対応方法を、複数の異なる観点から説明できるかを問う問題である。
設計原則の徹底は小さいプロジェクトでもなかなか難しい。本問題のように、設計原則に精通すべき設計者が 100人程いる大きなプロジェクトでは、より一層の工夫が求められる。
設計原則を教育・指導するためには、設計原則をドキュメントにしたり、教育テキストを用意することが大切であるが、大きなプロジェクトでは、どうしても徹底漏れが生じやすい。この徹底漏れをいかに防ぐかが鍵である。
また、大きなプロジェクトでは、設計原則の指導者やレビューアが不足することが予想される。この不足状況をいかに克服していくかも鍵となる。解答には、新技術であることに着目したものが多く見られた。
例えば、既存技術の場合より早いタイミングでレビューするとか、新技術に精通した設計者やレビューアを外部から調達するなどという解答があった。これらは有効な対応方法ではあるが、大きなプロジェクトという今回の設問では、他の対応方法と組み合わせなければ、限定的な効果に留まる恐れがある。徹底漏れを防ぐ際に、プロジェクト規模の大きさを克服するためには、レビューや指導を通じて、プロジェクト要員の中から有望な指導者候補を見つけ出し、次の指導者として育成することによって、プロジェクト内の指導者層を階層的・累積的に増やすという観点も併せて重要である。また、設計原則をツールに反映することによって、設計原則からの逸脱を未然に防ぐことや、プロジェクトに参加している若年設計者への技術継承を促すことは、大きなプロジェクトにおける徹底漏れ防止に役立つことにも着目して欲しい。 |
☞■中級ソフトウェア品質技術者資格試験（JCSQE）に合格しました。
【問題】あるプロジェクトで、Ｃ社へ初めて発注する。Ｃ社に発注するに当たって、下記の３項目についてはすでに確認済みである。これに加えてプロジェクト側で確認すべき事項を、初めての発注であること、および請負契約であることを踏まえて三つあげ、それぞれ50字程度で述べよ。
①これまでの開発実績、特に今回の開発対象の業務分野および技術分野の実績を確認する。
②技術者派遣や準委任による作業実績ではなく、請負契約での作業経験、実績を確認する。
③会社幹部の経営姿勢や品質を重視していることを確認する（例えば、品質に対する社長方針、ISO9000認証など）。 解答
【解答例】
①開発標準、品質管理方法、レビュー方法など、品質マネジメントの具体的な取り組みについて確認する。
②開発体制の編成方法、ならびに技法、技術、業務知識に関わる教育など、Ｃ社の考え方について確認する。
③納品物に瑕疵があった場合でも影響が限定的となる部分について、明確な仕様で発注できることを確認する。
④仕様確認、質問、相談など、開発が開始した以降に生じるＣ社からの問合せ時期や対応方法について確認する。【解説】
問題の狙い：
準委任契約や派遣契約ではなく、請負契約を初めて行う会社に対して発注するときに確認すべき事項を問う問題である。
請負先企業の実績や経験、品質に対する基本方針に加えて、品質マネジメントに関わる具体的な取り組み内容、開発体制の編成方針や社員教育の方針、リスクマネジメント、コミュニケーションマネジメント、さらにはセキュリティなど、確認すべき観点とその具体的な確認事項をあげられることを問うている。
解答のポイント：
リード文中に「請け負ってもらうことにしている」とあることから、すでに C 社は請負先として選定されている。したがって、C 社の財務リスクなどのように、C 社を請負先として選定する前に評価すべき事項については出題の狙いと異なる。また、「請負契約であることを踏まえて」とあることから、発注側に指揮命令権があってはならない。
このように、文章に記載された前提条件を正しく読み取ることが求められる。
その上で、すでに確認済みの事項のほかにどのようなことを確認すべきであるか、品質マネジメントやプロジェクトマネジメントの知識体系などを念頭に置きながら、未確認の領域について具体例をあげていくとよい。さらに、C 社について確認するだけでなく、自分のプロジェクトにおける C 社への発注の仕方にリスクがないか確認する必要がある。解答例③はその一例である。
このように、問題の前提条件を正しく理解した上で、参照すべき知識体系に示された知識領域の幅を考慮し、考慮対象とする主体の違い（C 社、自社）に着目しながら、具体的なキーワードを含めながら解答するとよい。
不十分な解答の特徴の例：
・ すでに確認済みの 3 項目に含まれる内容に関わるものは誤答とした。
・ 請負契約であるのに、発注側に指揮命令権があることを想定した解答になっているものは誤答とした。
・ C 社の財務状況に関わるリスクなど、請け負ってもらうことを決める前に検討すべきことは不十分な解答とした。 |
【問題】コーディング規約を定めることの効果とその理由について異なる観点から２つあげ、各25字程度で述べよ。効果と理由の間は『：』で区切って記述すること。 解答
【解答例】
①保守の観点
コードが読み易い：コード記述が統一されるから
コードが理解し易い：コードの属人性が低減されるから
②信頼性の観点
不良が減る：不良リスクの高いコーディングが減るから
再発が防止できる：過去の失敗を規約に反映できるから
③移植性または再利用性の観点
テストし易い：コード記述が統一されているから
再利用し易い：コンパイラへの依存度を下げられるから
【解説】
本問題は、コーディング規約を定めることの効果とその理由について、複数の異なる観点から説明できるかを問う問題である。
組織において、効果的なコーディング規約を定め、規約利用者に周知し、規約活用を推進していくためには、コーディング規約を複数の異なる観点から多面的に捉えておくことが大切である。
多面的に捉えることによって、規約活用の機会を広げたり、組織の状況に応じて規約を適切にテーラリングしたりすることができる。技術の進歩など、組織やプロジェクトを取り巻く状況は常に変化しているので、コーディング規約の内容と適用方法は、適宜見直すことが必要である。
解答には、保守性の観点が多く見られたが、信頼性、移植性、再利用性などの観点も併せて重要である。
特に、組織の過去の失敗をコーディング規約に反映することによって、組織の知識を明示的に蓄積できるので、若年技術者への技術継承に役立つことにも着目して欲しい。また、効果と理由の組み合わせが正しくない解答が一部見受けられた。解答に際しては、記述した理由が効果を正しく説明するものであるかの点検・確認を勧めたい。
|
☞■中級ソフトウェア品質技術者資格試験（JCSQE）に合格しました。
【問題】システム動作を確認するためにユーザ環境シミュレーションテストを実施する場合の利点と注意すべき点を各25字程度で述べよ。 解答
【解答】
利点の例
・実運用環境で起こりうるトラブルや不良を防止する。
・実運用環境で起こりうる初期不良を未然に防止する。注意すべき点の例
・実際のシステムとは違いがあることを十分注意しておく。
・高コストのため、ビジネス影響を考慮して対象を選定する。
【解説】
本問は、ユーザ環境シミュレーションテストの内容・性質を理解しているかを問う問題である。
ユーザ環境シミュレーションテストは、顧客納入前に顧客システムに近いシステムを構築して実施する最終的な試験・検査である。
このテストでは、各種のソフトウェアツール、ハードウェアツール、設備に加えて、必要に応じて顧客の設備、プログラム、データや模擬データを借用して実運用に近い環境で検査を行い、システムの機能、性能、運用性等が要求を満たしているかどうかを確認する。
ユーザ環境シミュレーションテストを実施することにより、社会や顧客ビジネスに大きな影響を与えるシステムのトラブルや初期不良を未然に防止することが可能となり、その結果として社会や顧客からの信頼感が向上することが期待できる。
留意点としては、ハードウェア構成、ソフトウェア構成、ネットワーク環境、データベース、運用、負荷、障害などの観点でできるだけ顧客の実運用に近い環境を実現しなければならないことが挙げられる。また、その上で実際の顧客システムとの違いを明確にして、検査する必要がある。さらに、すべてのシステムに対して、システム検査が必要なわけではないので、社会的影響度、顧客ビジネスへの影響度、システムの新規性、性能要求が厳しいものなど、あらかじめ選定基準を明確にして、システム検査が必要なシステムを漏らさないようにすることが大切である。
|
☞■中級ソフトウェア品質技術者資格試験（JCSQE）に合格しました。
【問題】結合テストを終えてシステムテストに入ろうとしている。モジュール当たりの障害（バグ）の密度を測定したところ、モジュールにより測定値が大きくばらついていた。品質の現状を把握するために階層化したい。異なる２つの階層の観点と、それぞれの階層により明らかにできる事柄を各25字程度で述べよ。層別の観点と事柄の間は、『：』で区切って記述すること。 解答
【解答】
規模別：大きなモジュールに障害が集中しているか
規模別：小さなモジュールに障害が集中しているか
開発担当者別：同じプロセスでも担当者能力は異なっているか
開発担当者別：特定の担当者が多くの障害を作り込んでいるか
開発担当者別：熟練者の担当個所は障害が少ないか
障害重大度別：モジュールにより重大な障害が集中しているか
障害原因別：障害が特定の障害原因に集中しているか
機能別：複雑な機能に障害が集中しているか
テスト方法別：テストの回数や実行有無が異なっているか
テスト担当者別：同じプロセスでも担当者能力は異なっているか
テスト担当者別：特定担当者が軽微な障害を多数報告しているか
テスト担当者別：熟練者が経験により効率的にテストしているか
【解説】
本問題は、品質を分析・評価するとき、層別という技法を適切に用いうるかを問う問題である。
ばらつく測定情報を手にしたとき、ばらつきの原因を考察することは品質管理の基本である。
QC 七つ道具のひとつである層別技法を、特定の目的のために適切に適用するためには、分析者の観点が決め手になる。
明らかにしたい事柄が異なれば、層別の観点を変えなければいけない。
このとき、ひとつの観点だけではなく、複数の観点によって、得られた情報をもとに多面的に分析を進めることが大切である。
多面的な分析によって、ばらつきに大きく寄与している要因を浮彫りにすることができ、その結果、有効な対策につなげることができる。
|
【問題】非ソフトウェア設計において、プロジェクトのメンバーがこれまで経験したことのない新技術に挑戦することとなった。この技術はソフトウェア開発の成否に関わる重要な技術である。もちろん、プロジェクト開始前に中核メンバーの何人かは、この技術研修を受講している。社内にこの技術を経験した技術者もいたが、このプロジェクトには参加できなかった。なお、この技術は数年前によく使われた技術の延長線上にあるが、適用方法を誤ると期待効果が得られない。ソフトウェア設計のレビューにあたって注意すべきことを３つあげ、それぞれ50字程度で述べよ。 解答
【解答】
①社内の新技術経験者をレビューに参加させ、新技術の特徴や、適用上の注意点などを重点的に確認してもらう。
②当該技術を過去に適用したときに期待効果が得られなかった原因を調べ、チェック項目として挙げる。
③既存技術と新技術の違いを調査し、流用可能な既存チェック項目や、新技術に固有のチェック項目を整理する。
④新技術に精通した社内の技術者がレビューに参加できない場合は、社外の有識者にレビューに協力してもらう。
【解説】
問題の狙い：
既存技術の延長上にある重要な新技術について、社内での技術蓄積が限られており、プロジェクトのメンバーには技術経験がないという状況における設計レビューの留意点を問う問題である。レビュアとして適切な人員を選定し、当該技術を適用する上でのポイントを把握し、社内に蓄積された技術ノウハウを利用するなどして、適切なレビューを実施できる体制を整えることが求められる。そのような観点に受験者の目が向けられているかどうかを判断することが、この問題の狙いである。 解答のポイント：
当該技術はソフトウェア開発の成否に関わる重要な技術であるため、まず、この技術に精通した技術者をレビュアとして選定することが求められる。そのような人材が社内にいない場合は、社外のコンサルティングを受けるなどして適切なレビューが実施できる体制を整えておくことが望ましい。また、既存技術の延長上にある新技術であるため、既存技術と新技術の違いを分析することで、新技術を適用する上でのポイントを洗い出すことも求められる。 不十分な解答の特徴の例：
・レビューの目的を明確にする、レビューの観点を挙げる、早期にレビューを行う、適切なレビュー技法を用いるなど、問題が設定された状況とは無関係に、一般的なレビューの留意点しか挙げられていない。
・新技術経験者ではない技術者をレビューに参加させて、その技術者のスキル向上や組織内での横展開を図るなど、当該プロジェクトの成否とは関係のない副次的な効果を狙った内容を記述している。 |
☞■中級ソフトウェア品質技術者資格試験（JCSQE）に合格しました。
人生100年時代。40代・50代は「人生の中間点」。今を乗り越え新たなステージへあなたが目指すセカンドキャリア・セカンドライフを実現するために今やるべき事
