本番直前の悪あがき、午前まとめ１

はい、なんとブログを放置すること、数年。
今再び、戦いを挑む時がきました。
今週末に試験です。２０１６年度春試験。

以前受けた時は、はっきり言って自信があったが、これは無知ゆえの自信であったことがその後（つまり前の試験から今日まで）に得た経験と知識によって実感した次第である。
知らなすぎでどの程度の理解度が求められているかがわかっていない状態であったのだ。

この空白の数年でやってきたのは、とにかく実際の技術なり知識体系なり、本物の知識、理解を得ることだ。つまり、一旦試験に合格するとか出題されるとかはなしにして、現代の情報技術を構成している要素を実際に知るようにした。具体的には、それぞれ分野の専門書（コンピュータアーキテクチャの本、ITILの本など）を見たり、ネットワークスイッチをジャンクショップで買ってきてPCクラスタを構築も実際にやってみた。また、ネットワークアナライザを使ってパケットを見てみる、あるいはセキュリティに関しては実際に自分のPCをハッキングするようなイメージでとにかく色々やってみた。

さてAPの試験に話を戻すと、午後は若干問題数が変化したようなので、以前よりは楽になったようだ。
午前は頻出問題を確実に取れれば問題ないが、午前クリアが前提なので、油断しないで臨みたい。


以下は、直前にまとめた知識をメモとしてブログに残す。

今回はiTECの市販の問題集「応用情報技術者、予想問題集、極選分析、ココでる」を使って知識を整理した。直接の試験対策として使ったのはこの本だけ。今は２サイクル目。空気入れと同じである程度知識が入っていると、その分押し戻されるのでより強くプッシュしないと頭に入らないようだ。



予定；
4/13 水　今日 (午前まとめ１）
4/14 木　午前まとめ２
4/15 金　午前まとめ３
4/16 土　調整　（勉強は午前で打ち切り、やりすぎ注意、特別食でパワーアップ）
4/17 日　本番


メモ；

　９、企業と法務　
法務
・労働基準法における３６協定とは
・請負契約の指揮命令権

企業活動
・売上計算式；　利益＝売上高 −（固定費＋変動費）
・OC曲線；　抜き取り検査、不良率、合格率
・減価償却計算；固定資産の除去損、定額法
・ゲーム理論；競争環境下で他社の意思決定を勘案、不確実な将来に対して取り得る幾つかの選択肢に対して、相手より有利な立場に立つための意思決定モデル。マクシミン、マクシマックス原理。


　８、経営戦略　
ビジネスインダストリ
・SEO；検索エンジン最適化
・セル生産方式；多種類かつフレキシブルな生産に適する
・EDI；電子データ交換、レベル１　情報伝達規約、レベル２　情報表現規約
　　　　　　　　　　　レベル３　業務運用規約、　レベル４　取引本規約
　エディー、でん、ぴょう、うん（こ）、とり

技術戦略マネジメント
・ラディカルイノベーション；経営変革
・技術のS字カーブ

経営戦略マネジメント
・コモディディ化；他社製品との差別化が価格以外の点で困難になること
・KPIとKGI、CFS（事業成功要因）；KPIはCFSの業績評価尺度。KGIはゴール
・バランススコアカード（BSC）；４つの視点で企業の業績をコントロールする。
「財務」「顧客」「内部ビジネスプロセス」「学習と成長」　雑魚流せ
・PPM；マーケティング。市場成長率、市場占有率それぞれの高低により4つの分野

　　　　高　　　　　花形　　　　　｜　　　　問題児
　　　　　　　（成長期待、維持）　｜　　（競争激化、脅威）
市場　　↑　　　ーーーーーーーーーーーーーーーーーーーーーーー
成長率　↓　　　　金のなる木　　　 ｜　　　　負け犬　
　　　　　　　　（成熟、安定）　　｜　　（停滞、衰退）
 　　　　低
　　　　　　　　　　　　　大　　　←→　　　小
　　　　　　　　　　　　　市場占有率（シェア）

　７、システム戦略　
システム企画
・IT投資ポートフォリオ；バランスの良い最適なIT投資配分を行う
・総合評価落札方式；調達。価格、提案内容が点数化
・RFI；Request for informationはRFP, request for proposalの作成に先立って必要となる情報をベンダから提供してもらうための依頼文章
・アクディビディ図；業務フロー、処理の条件分岐や並行処理、同期

システム戦略
・全体最適化計画で業務モデルを定義する目的；組織全体の情報システムのあるべき姿を明確化
・エンタープライズアーキテクチャ（EA）；業務とシステムを同時に改善する最適化手法
ビデアテ
・情報戦略の立案；経営戦略との生合成を必ず取る

　６、サービスマネジメント　
システム監査
・ITへの対応；COSOには含まれていない
・受注伝票に関する監査手続；プループリストと伝票との照合の確認
・事業継続計画(BCP)の監査；大規模な災害の発生時に、事業への影響を最小限に抑えるための経営活動計画。事業継続に必要な要件についての復旧時の対策。周知、更新の有無
・システム監査人が負う責任；監査報告書に記載した監査意見

サービスマネジメント
・リポジトリ構築の理由；各工程での成果物の一元管理
・DAとDBA；論理データベース設計者。データ項目を管理して標準化する
・ITILの各管理プロセスに関わるKPI；例、サービスの中段回数は可用性と信頼性管理

　５、プロジェクトマネジメント　
プロジェクトマネジメント
・PMBOKにおけるアクティビティ；プロジェクトの成果物を生成するために実施すべき具体的な作業を特定する
・教育技法；インバスケット
・生産性；成果量（ステップ数）➗所要工数（人月）
　１ステップあたりの総所要人月の逆数、と理解可能
・ファンクションポイント法；
・PMBOKのリスクへの対応戦略；回避、転嫁、軽減、受容
・WBS；階層構造
・プログラム開発工数；

　４、開発技術　
ソフトウエア開発管理技術
・マッシュアップ；公開されている複数のサービスを組み合わせて新しいサービスを構築
　グーグルマップをwebページ上で表示する機能などの例。
・エクストリームプログラミングのプラクティス；アジャイル開発

システム開発技術
・モジュールの結合度；ローカルかグローバルか、データ項目かデータ構造か
　デスセガキナ
・命令網羅；全ての命令を少なくとも１回は実行する
・アサーションチェック；プログラムの正当性の検証手法
・データ中心分析・設計技法；データ構造の安定性を考慮した方法。
　データ構造を基にしてプロセス設計（対象業務のモデル化）を行う
・モジュールの強度；一つの機能だけ、特定のデータ構造だけを扱う、のが強い。
・UMLのシーケンス図；オブジエクト間でのメッセージの相互作用を表現
・ブラックボックステストのテストデータ；機能仕様書に基づくテスト
　同値分割法、限界値分割法　　「ブラックはもう限界」
・ER図
・エキスパートシステムの開発に向くプログラミングパラダイム；論理型プログラミング
　Prolog、事実と規則を記述

（今回はここまで。次回３から）

本物志向

つまり、本物の力をつけるよりほかはないということだ。

つまり、単なる資格対策だけで合格しても、無意味。そしてなによりもつまらない。

ネットワークの知識が必要なら、実際にネットワークを自分で作ってみるのがよい。自宅ランを作るべし。

組み込みシステムの知識を深めたければ、タブレットやスマートフォンなどのシステムプログラミングをやるとよい。アンドロイドアプリを開発せよ。

ひとつの言語を極めよ。C++なら設計者が書いた専門書を読むべし。設計と進化、プログラミング入門、あるいは動画サイトで本人の講義を聞いてみるのもいいだろう。


本物だけが現実を変え、未来を拓く。

さあ～、どうする？

今回からはあまり深刻にならず、脱力系で試験対策をします。継続は力なりです。
パラドックスです。過ぎたるは及ばざるが如しです。はい。

さて、どうすればよいのかですが、これが分かれば苦労しません。

まぁ残りは午後対策だけなのですが、まずは午後の出題範囲を振り返って見ましょう。
一年放置して全部忘れたわ。ほんとに、試験の仕組みそのものを。ひどいね（泣）。

しらべるのめんどいから前に作った記事を見ることにしよう。

いま、ちょっと自分が去年書いた記事を見直してみた。以外にいいこと書いてある。復習すべきだね。（私は復習が苦手なのです。。。）いままでほとんどやったことない。やるとすごい力が付きそうだ。

それで、まとめると

１、トップダウン的な問題の選択、読み方をする必要がある。
２、定番問題のみを解く。（あとは捨てる。）

昨年度の学習の結果決めた午後の流れは、


問１　「情報セキュリティ」

問５　「ネットワーク」

問１１　「システム監査」

問９　「プロジェクトマネジメント」

問４　「システムアーキテクテャ」

問２　「経営戦略」

ということだったが、テクノロジ系を得点源にするのが重要だ。安定するはず。
私の戦略では１、５、４が重点分野だと分かった。

今回は以上。

捲土重来

さて、しばらくぶりですが再開します。
ということは、そう、しくじりました。。。
結果が出たのはもうかなり前になってしまいましたが。
結果をみると午前は七割程度で十分でしたが、
午後はなんと48%という始末。あれ、一問解き忘れた⁉
マークミスかも。ああああ。

です。

まぁ午後対策を納得するまでやり今度こそは受かってやる❗

てなわけで、午後の内容を充実させます。
思考方向がトップダウン的にやらないと時間が足りませんね。これが重要な点だと思われます。昨年実際に試験を受けた経験からは、午前はボトムアップで知識をひとつひとつ覚えて行くだけで済みますが、基本情報の時と同じで、いやそれ以上に戦略がものをいいそうでした。

参考書読んだほうがいいかも。ちょっとブックオフで探して見ます。
これも記事にします。

明日から再開します。

とにかくなんとか無事終わった

今日試験を受けてきた。会場は東京調布の電気通信大学だった。9:30から試験開始だったので、８時くらいに家を出た。試験会場ではFEの試験もやっていた。試験はやはり空席が目立った。私が受けた教室は受験番号から８０人いるはずだったが、実際数えてみると３０人だった。確かに試験センターが発表している数字どおり棄権する人が多かった。あと遅刻する人も結構いた。
　いま試験を終えてみて思うのだが、結果はどうであるにせよ、受けてきてよかったと思っている。朝眠いから一瞬やめようかとも思ったが、でもさすがにいかなかったらすべて腐りそうでがんばった。とりあえず、終わってよかった。
　時間配分やマークミスもなく終わったので、ちょっと期待している。うまくいってないかな～。試験では午前は１時間ちょっとで普通に終わった。見直しして結構修正で答えがわかった問題が多かった。見直しすべきだね。これを学習した。午前はやっぱり頻出問題を暗記する方針で学習していたのがよかった。同一の問題がたくさんあった。それで、結局時間余ったので３０分はやく退出した。近くの西友に栄養ドリンク買いに行きました。午後は時間との戦いだと思って多少気にしていたが、なんとかそれほど時間不足にならず終えられてよかった。なんかすぐ退出する人が結構いたが、午後途中退出は時間的に不可能でしょうよ。あきらめたんだろうね。よくないわ。最後まで粘るのが戦士だろうよ。なんか高齢の受験生にかぎって態度悪いような気がした。おっさんとかだめだわ。
　最後に、総合的な印象としては今回は簡単だったと思う。合格発表までこのブログはしばらく放置します。見てくださった方、ありがとうございました。この体験談には必ず役に立つヒントがあるはずです。だめだったら、秋の試験に臨むかな。でもちょっと忙しい時期なのでねぇ。今回突破できたら最高なのだが。。。

前日の悪あがき

いよいよ明日本番となった。あとは、体力勝負だ。試験中に寝てしまう可能性が高いので、今日はすこしリラックスでもしようかと思う。

最後に、気になっている項目を整理して終わることにする。

・待ち行列モデルの計算方法
自分の前に待っている人数　×　一件あたりの処理時間　＝　待ち時間

・RAID0~6の暗記
隅の葉っぱ、ブロック循環パブ２つ
ストライピング、ミラーリング、ハミング符号、パリティ、ブロック、巡回、パリティブロックを２つ

・ISMS適合性評価制度
経営者の運用管理体制をチェック

・DBの正規形
　第１正規形；繰り返し属性が存在しない。
　第２正規形：どの非キー属性も、主キーの真部分集合に対して関数従属しない。
　第３正規形；どの非キー属性も、主キーに推移的に関数従属しない。

・企業内PBX内線網の接続構成
 VoIPゲートウェイ、PBX(構内交換機)
構成図；(電話機)-(PBX)-(VoIPゲートウェイ)-(ルータ)-(IPネットワーク)

（e-words サイトから引用）
電話網とIPネットワークの間の中継を行う機器。インターネットやイントラネットを使って通話を行うVoIPにおいて使用されるしくみ。VoIPゲートウェイは、企業の支社間などでVoIPによる電話網を構築するために使われるのが一般的である。
VoIPゲートウェイは電話網とIPネットワークの境界に置かれ、電話線から入力されるアナログ音声データをデジタルデータに変換し、IPパケットに分割してIPネットワーク上に送信する。同時に、IPネットワーク側から受け取ったIPパケットをアナログ音声に復元し、電話網へ送り出す。デジタル音声データの圧縮および伸張もVoIPゲートウェイが行う。通常、企業のひとつの支社内の内線電話はPBX(構内交換機)と呼ばれる機器によって集約されている。従来は、各支社のPBXを公衆の電話回線や専用線で接続することで企業内電話網を構築していた。このため通話料や専用線敷設のコストが多大にかかっていた。
VoIPゲートウェイを利用すれば、従来公衆の電話回線や専用線を用いていた部分をIPネットワークに置き換えることができ、コストが大幅に削減できる。また、電話やFAXの回線とコンピュータネットワークが同一のIPネットワークに統合されることで管理コストの削減にもつながる。

・テストケース設計技法
ホワイトボックステスト（めぶんりょう、メイブン城）
　命令網羅C0；全ての命令を実行。
　分岐網羅C1；判定条件網羅ともいう。全ての分岐で、全ての方向を実行。
　条件網羅C2；複数条件で起こりうる真偽の組み合わせを実行。

ブラックボックステスト

同値分割
　限界値分割

なお、役に立ったサイトはこちら

・モジュール設計の指針（強度が強く、結合度が弱いほうがよい）

モジュールの強度（強い順）
　機能＞情報＞連絡＞手順＞時間＞論理＞暗号（的強度）
モジュールの結合度（強い順）；ローカル＜グローバル、データ項目＜データ構造
　内容＞共通＞外部＞制御＞スタンプ＞データ（結合）

・ガントチャート
　各作業の開始時点と終了時点が一目で把握できる。

・バランススコアカード（雑魚ナビが成長した）
企業の業績管理手法。「財務」「顧客」「内部ビジネスプロセス」「学習と成長」

・損益分岐点の計算
損益分岐点の売上高＝固定費/(1-(変動費/売上高))

H25秋午前

試験まで残り５日。ちょっと集中力が切れてきたが、がんばりたい！

まだまだ知識があいまいな部分がある。
特に情報セキュリティとストラテジとマネジメントの用語だ。

ぱすしまくったが、結果は如何に？

問１、場合の数　ｐ
問２、桁落ち
問３、負の整数の表現
問４、論理式 ｐ
問５、待ち行列モデル
問６．完全２分木
問７、ハッシュ
問８、再帰
問９、アルゴリズム　ｐ
問１０、メモリインターリーブ
問１１、平均アクセス時間
問１２、DMA
問１３、RAID0, RAID1
問１４、分散処理システムのアクセスの透明性
問１５、データ処理件数の計算　ｐ
問１６、フェールセーフ
問１７、稼働率
問１８、ガーベジコレクション
問１９、ラウンドロビン方式のプロセススケジューリング
問２０、コンパイラの仕組み
問２１、OSS
問２２、DRAM,SRAM
問２３、RTC(real time clock)　ｐ
問２４、フリップフロップ回路
問２５、ユーザビリティ
問２６、SMIL
問２７、ストアドプロシージャ
問２８、RDBMSのオプティマイザ　ｐ
問２９、DBの正規形
問３０、関係演算
問３１、SQL　ｐ
問３２、可変長サブネットマスク
問３３、ビット誤り率計算
問３４、ブロードキャストフレーム
問３５、OSI基本参照モデルのプロトコル
問３６、パケットのヘッダ情報
問３７、ネットワーク層での暗号化
問３８、RSA暗号化方式
問３９、ディジタル署名生成と鍵
問４０、ISMS
問４１、ビヘイビア法
問４２、クロスサイトスクリプティング
問４３、デジタルフォレンジックス
問４４、パスワード不正取得と対策
問４５、ER図
問４６、ウォークスルー
問４７、オブジェクト指向
問４８、ソフトウエアの誤り率　ｐ
問４９、分岐網羅と条件網羅
問５０、マッシュアップ
問５１、ファンクションポイント法
問５２、プロジェクトの日数見積もり　ｐ
問５３、EVM  ｐ
問５４、PMBOX
問５５、ITILのインシデント管理
問５６、バックアップ方式
問５７、ミッションクリティカルシステム
問５８、システム監査人
問５９、監査手続き
問６０、コントロール統制
問６１、ITポートフォリオ
問６２、EA
問６３、現行論理モデル、物理モデル
問６４、システム管理基準
問６５、KPI
問６６、スケールメリットとシナジー効果
問６７、デルファイ法
問６８、マーケティング要素４P,４C
問６９、バランススコアカード
問７０、プロダクトイノベーション
問７１、EDI
問７２、エスクローサービス　ｐ
問７３、VICS(Vehicle Information and Communication System)
問７４、リーダシップ論
問７５、OC曲線
問７６、営業利益計算
問７７、減価償却計算
問７８、在庫評価額　ｐ
問７９、著作権　設問読み間違え
問８０、準委任契約

さて、今回はめんどくさそうなものはかなりパスしたが結果は52/80~65%。時間は２時間。
まぁこんなもんで突破できるんだね。
知らない用語の問題は、選択しの文章をよめば判別できるものが多かった。問題設定のキーワードとの対応がわかれば選べるようになっているようだ。


今回の補強と対策をしよう。

問４、真偽の判定方法
　　　基礎知識；真∧真＝真、真∨偽＝真　など
　　　「含意➡」；真理値表を使う
　　　　　　　　X真かつY真ならばX➡Yは真、X偽かつY真ならばX➡Yは真　など
　　　　　　　　　「ならば」で偽になるのはXが真でかつYが偽の場合のみ

問２４、フリップフロップ回路
　　　否定論理和の真偽結果に注意。なんとなくすっきりしない。

セキュリティ分野は要チェックだ。
問４３、デジタルフォレンジックス
　　　；コンピュータシステムに対する不正アクセスなどの犯罪の証拠となりうるデータの収集、分析、保全の技術手法の総称。

問４４、サーバへのログイン時にもちいるパスワードの不正取得に対する対策。
　　　；辞書攻撃、スニッフィング、ブルートフォース攻撃

問５３、プロジェクト管理技法であるEVMによる、完成時総コスト見積もり(EAC)の計算公式を覚える必要がある。米国防総省の調達規則の一部として制定、ってなんかすごいね。
     EAC=AC+(BAC-EV)/CPI
     コスト効率指標；CPI=EV/AC
　AC＝実コストActual Cost,
    BAC=Budget at Completion
    EV=Earned Value

問７６、売上高と支出は別物。前者は販売単価を使う。後者は固定費、変動費で計算可能。

問８０、準委任契約、レンタル契約、派遣契約、請負契約の違いに注意。
ネット情報でこんな説明があった。「請負と準委任の違いは納品物が明確に定義されているかされていないかです。簡単に言うと、請負は決められたものを納品するもので、請負う側は期日までにきちんと完遂する義務があります。準委任は完遂する義務がありません。そのため契約の依頼側にリスクがあります。もちろん準委任だからと言って何をやってもいいわけではなく、善管注意は発生します。要は真面目に作業する義務はあります。」だってさ。

以下はwikiから持ってきた情報。

アーンド・バリュー・マネジメントでは、ある時点までにプロジェクト・チームが完成した成果とプロジェクト開始時に予測した見積りとが比較される。この比較から、プロジェクトが完了状態からどれほど離れているかについての標準が与えられる。既にプロジェクトに投入された作業量から推定することによって、プロジェクト・マネジャーは完了時点までにどれほどのリソースが使用されるかの見積もりを得ることができる。

アーンド・バリュー・マネジメントをプロジェクトに適用しようとするプロジェクト・マネジャーには以下に挙げる基本情報が必要である。

ワーク・ブレークダウン・ストラクチャー (WBS, Work Breakdown Structure)

階層化され詳細化された、全てのプロジェクト構成要素のリスト

プロジェクトのマスター・スケジュール (PMS, Project Master Schedule)

各タスクの納期と担当者が示されたガントチャート

プランド・バリュー（計画価値） (PV, Planned Value)

当該期間末までに完了しているものとして計画された作業の予算

アーンド・バリュー（出来高） (EV, Earned Value)

当該期間末までに進捗した作業を、その作業の計画価値に対する比から評価した価値

実コスト (AC, Actual Cost)

当該期間末までに実際に投入した総コスト

完成時総予算 (BAC, Budget at Completion)

プロジェクトの完了時点におけるPV

プロジェクト・マネジャーは、これらの情報を基に次のような評価値を算定することができる。

コスト差異 (CV, Cost Variance)

EV - AC（0以上であれば良好）

スケジュール差異 (SV, Schedule Variance)

EV - PV （0以上であれば良好）

コスト効率指数 (CPI, Cost Performance Index)

EV / AC（1以上であれば良好）

スケジュール効率指数(SPI, Schedule Performance Index)

EV / PV（1以上であれば良好）

完成時総コスト見積り (EAC, Estimate At Completion)

AC + (BAC - EV) / CPI

残作業のコスト見積り (ETC, Estimate To Completion)

(BAC - EV) / CPI = EAC - AC)

問５４、PMBOX；プロジェクトにおいてマイナスのリスクに対する対応戦略を４分類。

　　　　回避、転嫁、軽減、受容

 

以下は問８０の契約に関するネット記事を拾ってきた。

 

　システム開発にかかわる作業をITベンダーに委託する場合、一般的に次の三つのどれかの契約を結ぶ。成果物の責任を負わせる「請負」契約、業務支援などを依頼する「準委任」契約、そして技術者など人材を供給してもらう「派遣」契約、である。
　これらの違いは、なかなか正しく理解されていないのが実情だ。「準委任契約なので完成責任を負っていない。そのため、成果物が完成していなくても、労働に対する対価を（ユーザー企業は）支払う義務がある」といった発言を、ユーザー企業とITベンダーの紛争で聞くことは珍しくない。
　システム開発にかかわる紛争を見ると、請負契約と準委任契約に関連する理解不足が原因であることが多い。まずは準委任契約を中心に紹介しよう。専門家としての責任である「善管注意義務」についても知っておいてほしい。

「 委任」と「準委任」は同じ

まずは「委任」「準委任」の言葉の定義に関する誤解を解いておこう。ごくたまに、「委任という言葉に“準”がついているため、委任よりも効力などが低い契約なのか」という質問をされることがある。確かにそう感じなくもないが、実際には委任も準委任も同じである。
　委任とは「法律行為」を委託する場合、準委任は「法律行為でない事務」を委託する場合の契約である。物品の売買契約などの法律行為を委託する場合は委任、システムの要件定義など法律行為ではないことを委託する場合は準委任契約となる。ある仕事を別の人や会社に依頼するという意味は同じなのだが、その中身によって法律では呼び方が違っているのだ。
　民法には「売買」や「賃貸借」といった13種類の契約類型が規定されている。これらのなかに「請負」と「委任」の契約類型が含まれている（図1）。ここに準委任は記されていないが、民法の規定は委任の規定をそのまま適用している（法律の世界では“準用する”という）。そのため「準委任」と呼んでいるにすぎない。法的な効力は、委任と準委任とで違いはないのである。

図1●民法で規定されている13種類の契約類型

成果物の完成責任を負わない

続いて、請負契約と準委任契約の違いを説明しよう。最も重要な違いは、受託した側が受託した仕事を完成させる義務を負うかどうかである（図2）。請負契約は、引き受けた仕事を完成させる義務が定められている。これに対して、準委任契約では仕事を完成させる義務はない。

図2●請負契約と準委任契約の違い

[画像のクリックで拡大表示]

準委任の例としてよく挙げられるのが、医師の診療や手術である。患者は診察や手術などの仕事（民法では「事務」という）を医師に委託した場合、医師は病気を完治させる責任は負わない。医療過誤に当たる場合を除けば、医師は病気を完治できなくても債務不履行責任を負うことはない。患者が完治しなかったとしても、医師は診察や手術に費やした対価を請求することができる。
　塾の講師との契約も準委任だ。子供の学習指導という“法律行為ではない事務”を親が講師に委託する契約であるからだ。親は子供の成績向上や志望校の合格を期待しているのだが、講師はそれらの目的を達成する義務までは負っていない。きちんとした講義を行えば、成績が伸びず志望校に合格できなくても、債務不履行責任を負うことはない。

ITベンダーは善管注意義務を負う

準委任契約においては、受任者は成果物の完成責任を負わない。これを文字通り解釈すると、要件定義など準委任契約を結んだ仕事については、プロジェクトが途中で頓挫して成果物（要件定義の場合は要件定義書など）が完成しなくてもITベンダーの責任を問えないことになる。
　確かに原則はそうである。だが、プロジェクトが頓挫した原因によっては、ITベンダーも責任を負うことになる。例えば、ITベンダーが専門家として適切な支援を行わなかったときがそうだ。プロジェクトが失敗する（要件定義が頓挫する）恐れがあるのに、それを未然に防ぐ行動や助言をしていなかったら、たとえ準委任契約であってもITベンダーは債務不履行責任を負うことになる。
　それはなぜか。この答えとなるキーワードが「善管注意義務」である。民法は「受任者（仕事を委託された側）は、委任の本旨に従い、善良な管理者の注意をもって、委任事務を処理する義務を負う」（民法第644条）と定めている。仕事を委託されるのは、専門家としてそれだけの知識や経験を持っていることが背景にあってのことだ。つまり、委託された仕事に労働力を費やすだけでなく、プロフェッショナルとして一般的に期待されるレベルの注意義務を果たす必要がある、というわけだ。
　ユーザー企業のシステム部門に比べれば、ITベンダーはシステム開発の経験が豊富だ。規模の大小を問わず様々なプロジェクトを行っているため、成否を分ける勘所も分かっている。従業員もITに精通している。これに比べてユーザー企業は、システム開発に対する経験や知識は劣る。大規模なプロジェクトは数年に1回という企業が大半だろう。それゆえ、経験や知識を補うために、ユーザー企業はITベンダーにお金を払って支援を仰ぐ。
　こうしたことを踏まえた上で、仕事を受託したITベンダーは、善良な管理者の注意義務を果たすという民法上の義務を負う。例えば、ITベンダーが要件定義業務を支援していた際、要件定義の前提として設定されていた予算を超過することが途中で分かったとしよう。この場合、ITベンダーは予算超過の可能性を伝えた上で、要件を削らない場合の追加費用を見積もったり、予算を超過させない代替手段の有無を検討したり、プロジェクトのスケジュールに対する影響などを具体的に示したりすることが求められる。
　こうした行動や助言をしていなかったとしたら、成果物の完成責任を負わない準委任契約であっても債務不履行責任をITベンダーが負うことになる。

契約書に潜んでいる落とし穴

ここまで準委任契約の特性や善管注意義務の存在について解説してきた。実はこうしたことを理解しているにもかかわらず、法的リスクを減らしたり紛争時の交渉を有利に進めたりするために、契約書の文面を巧妙に作成するITベンダーはある。ユーザー企業は契約書を交わす段階で問題を発見できないと、あとあと問題が生じる可能性がある。しばしば目にする典型例を二つ紹介しよう。
　一つめは善管注意義務に関する規定を盛り込んでいないケースだ。「当社は経済産業省のモデル取引・契約書に沿っていますのでご安心ください」と言いつつ、実は一部分を書き換えているケースによく見られる。
　経済産業省が2007年4月に公表した「情報システム・モデル取引・契約書」（モデル契約書）では、要件定義の契約を準委任としている。それを示す第14条の第2項では、「乙（ITベンダー）は、情報処理技術に関する専門的な知識及び経験に基づき、甲（ユーザー企業）の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする」という条項を設けている。ところが、この条項をまるまる削除した契約書をユーザー企業に提示しているITベンダーは少なくない。
　実のところ、善管注意義務を受任者が負うことを契約書に書いていなくても、民法の規定は適用される。だが、ユーザー企業に気づかせないようにするために、あえて善管注意義務を削除しているとみられる。法的には書いても書かなくても同じだとはいえ、ITベンダーのプロとしての責任を再認識させるためにも、ユーザー企業としては善管注意義務に関連する規定を契約書に明記しておくべきだ。
　契約書を巧妙に作成しているもう一つのパターンが、支払いに関する規定だ。成果物の完成責任を負わないという準委任契約の性質を強調しつつ、「予定の期間や工数が満了したら、ユーザー企業は速やかに対価を支払う」という規定が盛り込まれていることがある。あえて成果物について言及していないのは、要件定義書などが完成していなくてもITベンダーが対価を請求できるようにするためだ。
　このままでは、プロジェクトが頓挫しても、ユーザー企業は対価を支払わなければならないことになる。こうした問題を防ぐために、モデル契約書の第17条と第18条では、「ユーザー企業とITベンダーが共同で、要件定義書がきちんと完成していることを確認することをITベンダーの業務の終了条件とする」ことを定め、ユーザー企業が確認するまでは、ITベンダーは対価を請求できないようになっている。これらの重要な条項も、契約書から削除しているケースがあるので注意が必要だ。