平成28年秋季 午後 問9 （
応用情報処理技術者試験ドットコムさんのページはこちら）
設問1．
(1)
＜俺の解答＞A社の要件を既に理解しているため
＜解答例＞A社の業務に精通しているから
⇒ たぶん正解と言えるだろう。特に文中それを明記している箇所はないものの、現時点（新システム導入前）の料金システムを開発している経緯から、会計システムとの連携や料金システムに求められている要件などを既に把握しているものと思われる。
(2)
＜俺の解答＞a． ウ．
⇒ 正解。解答群の他の選択肢はイ．を除くとどれも要件を決めてから考えるべきもので、「イ．業務環境」に関してはシステム側でどうすることもできないものと言える。
(3)
＜俺の解答＞開発工数
⇒ 正解と言えるだろう。「b．を見積もり要員単価を当てはめて・・・コストを算定」とあるので工数以外当てはまらないと思われる。
設問2．
(1)
＜俺の解答＞利用者側要員の関与を深め、適切なフィット＆ギャップ分析を行うため
＜解答例＞ギャップを業務変更で対応した時の影響を正確に把握するため
⇒ これは正解とは言えない。本文中、「・・・ギャップは追加プログラムで対応するか、業務の変更で対応することになる・・・」とあるのでだと思われるが、それだけじゃないのではないかという感想を持ってしまう自分が確かにいる。
(2)
＜俺の解答＞パッケージで対応できる機能を充分に活かすため
＜解答例＞アドオンで対応可能かを正確に判断したいから
⇒ こちらも明確に正解とは言い難い。設問2．だけを見ても、そこまで小難しい解答は求められていないのかもしれないという感触を持った。
設問3．
(1)
＜俺の解答＞c． ウ．
⇒ 正解。RFP(Request for proposal)の略だと思うが、これに惑わされなければ普通に選択できると思う。
(2)
＜俺の解答＞d． 準委託
＜解答例＞d． 準委任
⇒ 答えを知っていると思って、同じ過ちをしてしまったｗ
どうやら用語として、「請負契約」と「準委任契約」は一対のものと考えた方がよさそうだ。IT法務.COMさんの「
請負と準委任契約」をある程度まとめると、完成品に対して対価を払い、瑕疵担保責任を請負人が負う契約を「請負契約」、善良な管理者の注意をもって委任事務を処理する義務を負う、瑕疵担保責任を負わない契約を「準委任契約」と考えるらしい。
このページは実際の判例なども含めて書いてくれているので非常にわかりやすい。この用語は結構な頻度で出題されているような気がするので丸覚えした方がよさそうだ。
(3)
＜俺の解答＞要員への直接的な指示を行わない
＜解答例＞作業者に直接業務指示しない
⇒ おそらく正解だと思うが、「作業者」という文言は重要な気がする。
この点について調査したところ、そのものずばりで答えてくれているのがIT入門マニュアルさんの「
IT業界の派遣契約と準委任契約の違い」だと思う。
ここでは派遣契約と準委任契約の違いについてはっきりと区別して詳述してくれているので参考にするとよいと思う。
平成28春季 午後 問9 （
応用情報処理技術者試験ドットコムさんのページはこちら）
設問1．
(1)
＜俺の解答＞まったくわからなかった
＜解答例＞モジュールごとに品質の偏りがないかどうかを確認する必要があるから
⇒ はっきり言ってこの問題の趣旨がほとんど飲み込めず、一体テスト密度とは何か？欠陥数とは何か？という部分でつまづいて、買ってきてほとんど読んでいない応用情報処理のテキストを探しまくって確認してみたり、手当たり次第にウェブ検索したりしてみたが、結局はっきりとこういうものだという説明をしているところが見つからなかった。
色々探していて、「Sacrificed & Exploited」さんの２ちゃんまとめ記事「
ステップ数の非常識1．ステップ数からテストケース件数を推定する」を斜め読みして「結局机上の空論に過ぎないのではないか？」という結論に及びそうになり、試験三日前にして愕然としてしまった。
が、少し引いて考えてみると日本にありがちな物事を難しい方に考えているだけではないだろうかと思い至り、英語で検索してみて「Software Testing Help」というサイトの「
Important Software Test Metrics and Measurements - Explained with Examples and Graphs」というサイトを一通り見てみて、まあ細かくはわからないものの何となく概要と、端的にこの当たりの概念が見つかりにくい理由も推測がついた。
上のサイトの記述を俺なりに解釈すると「指標としての数値を設定しておき、ある程度の閾値を超えた場合に即座に関係者にアラートを出せるようにすることで『寝耳に水』な納期遅れの連絡をするのを防ぐ」ものだということだ。
個人的な経験になるが、アメリカ人のものの考え方と日本人のそれとは根本的なところが全く違うと思われる。端的な例で言うと、品質と統計というところで、アメリカ人が「不良率3%以下で製品を納品してほしい」と日本の業者に頼んだところ、「納品する理由はわかりませんが、弊社で不良として検出されたものを納品分とは別に3%分、別梱包して送付いたしました。お納めください。」と言ったやり取りが本当にあったという逸話をMBAの授業で聞いたときに苦笑いした覚えがある。
ここらあたりが日本でシステム開発という分野が成熟していかない理由だとも思う。
アメリカ人はその適当さからか、「完璧な製品を作り上げるのは無理だ」と考え、「見つかった時にどのように対応するかを決めておこう」と考えるのに対して、日本人は「完璧でない製品を納品するのは恥だ」と考え「不良を作りだした原因を追究しよう」となる。システムは人間が作るものだから、原因の追究はともすれば個人のつるし上げに終始してしまう。これでは失敗が怖くて作る速度が落ち、スピードが要求される製品リリースに後れを取ることでいつも二番煎じを演じることになる。後はおなじみの追従者が故の薄利多売と利益率の低下の無限ループにはまるのだろうと予測した。
それではこの設問に対する答えはなんだろう？と翻って考えてみると、おそらくモジュールX1の開発難易度が唯一「高」となっているので、同じ尺度で見るのは危ういのではないか？ということで「モジュールごとに品質の偏りがないかどうかを確認する必要があるから」という答えになっているのではないかと予測した。それ以外に確定的に「この部分がこうだから」という解釈が成り立つ資料は俺の調査では見つからなかった。
くそう・・・こんなところで時間を割くことになろうとは・・・
(2)
＜俺の解答＞a． 詳細設計レビュー
＜解答例＞a． 単体テスト
(3)
＜俺の解答＞b． N社の手順書の項目漏れ
＜解答例＞b． 詳細設計での品質不足
⇒ (2)と(3)はひとくくりに考えるとわかりやすそうだ。
サブシステムZの欠陥数を見てみると、「詳細設計レビュー」が3.5、「単体テスト」が1.2、そして結合テストが4.1となっている。さらに、単体テストのテスト密度（kステップ当たりのテストケース数）がXの実に半数以下となっているため、「単体テスト」のテストケース・項目数が不足している可能性は内容が分かれば一目瞭然である。
仮に単体テストに問題がないとした場合、結合テストで欠陥数が品質判定基準を超えた理由は、単体テストの品質がとても良いことを考えると、詳細設計時点で全体的なデータの引き渡しなどの部分の設計が甘く、モジュール単体の品質は非常に良いものの、結合すると問題だらけになったといううがった考えもできる、と、こう言うことを言いたいのだと予想した。こちらも調査で確定的な資料が得られなかったのであくまで予想に過ぎないことを申し添えて置く。
設問2．
(1)
＜俺の解答＞c． コーディング規約の順守状況
＜解答例＞c． 開発メンバが正しく理解したこと
⇒ この解答例には少し驚かされたが、この部分が定量的でなくても良いというのは日本人の精神論的な仕事文化が背景にあるのだろうかと思ってしまう。
「正しく理解」とはどのようにして判定できるのだろうか？会話の中で「こいつは正しく理解しているようだな・・・」と判定するのもやはり人間であり、間違った解釈をしている可能性が否定できないわけで、その時点で論理としては破たんしているのではないかと思ってしまうのは俺だけだろうか。
せっかくプロジェクトマネジメントの色々な手法を用いてコミュニケーションギャップを少なくしていこうとしているのにも関わらず、この辺が精神論で賄われているから色んなプロジェクトが破たんするのではないかと思えてしまう。
まー、あまり深く考えるのはよろしくないので、ここは「このぐらいの解答でよいのだ」と通り過ぎたい。別にプロジェクトマネジメントみたいな建設現場の現場監督よりもひどい仕事をしたいわけではない。
(2)
＜俺の解答＞d． 開発工数の増大 e． 設計全体の見直し
＜解答例＞d． 開発コストの増大 e． 納期の遅延
⇒ d．に関しては微妙と言いたいところだが、ここはやはり間違いになるのではないかと思う。
ここで俺が解いている問題の出題もとはあくまで「プロジェクトマネジメント」であり、「コスト」と「納期」こそがプロジェクトマネジメントの最大の目的だろうと思うからだ。
そこを聞いている問題なのだろうから、工数とか設計全体の見直しとか増えたところでプロジェクトマネジメントという視点からすると些末なことで、その結果費用がどれだけ追加でかかったか？納期がどの程度遅延するのか？というぎすぎすした感じを伝えられなければ不正解なのだと思う。あくまで個人の感想だが・・・
(3)
＜俺の解答＞f． 開発の難易度
＜解答例＞f． モジュールの開発の難易度
⇒ 「モジュール」が抜けているので微妙だが、俺の言い訳としてはモジュールまで言及すると言いすぎか？という理由で省いた形である。ある程度限定的に言っても大丈夫ということであまり深く考え無いようにしよう。
プロジェクトマネジメントの設問を一通り確認してみて思ったのは、「あまり深く考えすぎるとはまり込んでしまう」ということと、色々な指標だったりQA七つ道具とか言うものが出てきたりするのだとは思うが、結果として得られる数字の解釈自体はおそらくかなり曖昧で、ともすると精神論的なのだろうと考える。
あまり深く考えすぎるのは禁物だ。ここで落ちたからと言って死ぬわけではあるまい。日本の開発現場のデスマーチの愚をこんなところで犯しても仕方があるまいｗ
