・コストベースラインを超えないようにコントロールする。原価（固定費）の量を把握する。

・何に使ったのか、使うべくして使ったのか、本当に必要なコストだったのかを明示的に資格化する。使用項目ごとにIDを割り当てて管理し、トレーサビリティを確保する。

・借方、貸方を明示的にする。

・人的アサインを明示的に行う

・工数算出、工数算定

・工数コントロール、工数肥大化防止

・人月計算

・１人月の場合、２人投入すれば半月で終わるというものではない。（ブルックスの法則）

・追加開発における予算確保、あるいはエビデンスの提示、コンセンサスの獲得、予算の承認プロセス

・故障、予備、保守のためのコスト削減、別枠コスト確保

・本来必要なコストと、未知の部分に対して必要になってくるコストの重要性

・部品ごとの性能やバージョンに応じたコストの選定

・部品管理表の重要性

・経験に基づいたコスト選定、有識者への諮問、密なコミュニケーション

・財務諸表との兼ね合い、データ連携

・固定費、変動費の明確化

・損益分岐点

・コスト削減、投資によって得られる効果

ITパスポート（セキュリティ分野）、情報セキュリティマネジメント試験、基本情報技術者試験（情報セキュリティ分野）、応用情報技術者試験（セキュリティ分野）、情報処理安全確保支援士試験

問　社内の情報セキュリティ対策に関する以下の文章を読んで、設問に答えよ。

　A社は、不正行為とコンプライアンス違反が得意な、弱小オンボロシステム開発企業である。この度、社内のオンボロなシステムの脆弱性がとんでもないことになり、社内のろくでなしどものPCから流出した大量のエロ動画と粉飾決算だらけの財務諸表や偽造会計資料などが膨大な数に上り、えらいこっちゃって感じである。

　まず、社内の管理規定においてはエロ動画の閲覧方針に関する規定が皆無だったため、プロキシサーバ上で業務上必要のないコンテンツの排除を行っているのだが、ハッキング技術だけは達者のためプロキシサーバへ不正ログインして特権IDの権限を奪取し、強制的に不正なサイトへ接続させるある意味ツワモノなろくでなしも存在していた。

　この問題を解決するため、O主任は社内の情報セキュリティ管理規定を見直すこととし、非モテ・DT・彼女いない歴＝年齢のT君と、新たに調達してきたSちゃん（23歳・カワイイ・アイドルのようなルックス）を共同で業務につかせることにした。T君にとってはチャンスであり、夢のような瞬間であり待ってましたって感じである。

Sちゃん「はじめまして。A社のセキュリティについて真剣に検討しましょう。」

T君「あの・・・彼氏とかいるんですか？」

Sちゃん「ログインに関するセキュリティ方針の検討が必要です。A社の権限は、各IDに対して不必要な権限が割り当てられてることでセキュリティインシデントが発生します。例えば、特権IDを社内の誰でも使えるような設定になっていると、管理職しかできないような承認や重要書類の編集、書き込み、作業などができてしまいます。そうするとセキュリティ上問題なので、速やかに特権IDを使用できる対象人物（ユーザ）を限定する必要があります。また、一般ユーザ（従業員）などに不必要な権限が与えられてはいけません。例えば、重要書類へのアクセスは認めない、編集や削除などを認めないといった方策が必要となります。」

T君「Sさんが可愛すぎて、業務に集中できません・・・」

Sちゃん「

問１　A社のセキュリティ対策として、プロキシサーバにおいて必要とされる機能を、「ログ」「復号化」の字句を用いて３０字以内で述べよ。

問２　A社のセキュリティインシデントに鑑みて、流出した資料およびドキュメントに対して必要であったと思われる方策を、「暗号化」「バックアップ」の文字を用いて３０字以内で述べよ。

問３　プロキシサーバのセキュリティを維持するため、特権IDに対して施しておくべきセキュリティ対策を、３０字以内で述べよ。

この度、私の友人であるA子が社長をやっているP社の従業員の一人であるアラフォー婚活独女（毒女）P子が結婚できないとわめいているので、このP子の結婚に関する要件定義、プロジェクト目標、スケジュール、予算などをまとめた上で下記のような婚活プロジェクト計画書を策定した。

・プロジェクトの目標

結婚相手を探すこと。以上。

・いつまでに

今すぐにでも。スケジュール？スコープ？何それ？

・要件定義

３０代、年収６００万以上、偏差値６５以上の大学卒、身長１７２ｃｍ以上、会社員役職付きまたは公務員、ヒゲの剃り残しがない、鼻毛が出ていない、化粧水を毎日やっている、毎月美容院へ通っている、性格が合う、清潔感がある

・予算

０円に決まっている。なんで女のあたしがおごらないといけないの？男性なら、おごって当然。女のコ相手におごれない男って、どんだけ経済力ないんだよって話。

・想定されるリスク

ファイブフォース分析によると、若い女の参入リスクで年齢で負ける、とにかく２０代前半の超ハイスペ女子にイケメン高収入男子をかっさらわれる、相手の男性が若い女子を選ぶ、などリスク山積み。けどあたしは周囲から年齢より若いですねって言われるし、若い時はモテモテだったし、あたしはまだまだ選べる側の人間よ。

・トラブル発生時の管理体制

あたしは美人で黙ってても男の方が寄ってこなければならない神に選ばれた女なのだから、トラブルなど起こりようがない。

　まずプロジェクトの目標に関してだが、当然ながら結婚することが目的に決まっている。ほかに何かあるの？ないよねって話である。とにかく、結婚することが最優先議決事項であり、その後の生活など知ったこっちゃねえって話である。そのため、本プロジェクトのKPIは漠然と「結婚すること」が究極であり、結婚後の育児ロードマップや家計簿の管理、コスト管理、予算配分などについてはまったくの無関心のようである。

　次にスケジュール感であるが、当然ながら「いますぐに」という漠然とした事項が記載されているのみであり、四半期ごとのマイルストーンや実績の記載、スケジュール差異などについてはまったくの無頓着なのである。

　要件定義に関しては、どう考えてもこんな男はどこにも存在しないのだが（いたとしても0.1%以下、とっくに２０代前半高スペック女子と結婚している）、本人曰くこれが「普通」のスペックらしい。

　予算に関しては、概算見積もりやボトムアップ見積もりなどの特性を考慮した上での見積もりをやってもいいようなもんだが、結局はこの通りである。定量性など皆無なのである。

　想定リスクに関しては、リスクだらけである。言うまでもない。

　トラブル対応にしても、体制図や時系列図の作成などがあるわけでもなく、この通りである。

　結局、P子はそのまま婚活に挑んだが、とりあえず数うちゃあたる方式で男性３００人にテキトーに申し込んで全部断られ、ヒステリックになった。「男は年齢で女を判断するなんてひどい。歳なんて誰だって平等にとるものなのに、年齢で判断するなんて差別だ。差別は許せない。」自分がとんでもない要件定義をしておきながらこんな言い分をするのだから、救いようの無いものである。

問１　O主任が考えたプロジェクトの目標に関する問題点について、１００字以内で述べよ。

問２　P子は結婚相手の条件としてとにかく「フツーの男」を求める。そのフツー男の定義が偏差値５０であると仮定した場合、年齢・年収・学歴・身長・性格・清潔感・鼻毛・ヒゲの剃り残し・化粧水・美容院通い・ルックス・・・（以下永遠に続く）など無数に存在する項目がすべて偏差値５０を満たしている必要がある。１つでも偏差値５０未満だと「フツーの男」ではないと判断される場合、「フツーの男」が存在する確率を求めよ。

※問２の補足だが、仮に偏差値５０の存在確率が０．５だとすると、上記のように相手の男性に求める条件が11項目あった場合に0.5の11乗で約0.000488という恐ろしい数値が出た。約0.05パーセント。この１パーセントにも満たない男性を「普通」と定義するP子。

P子「はぁ？数字とか確率なんて意味わからないしどうでもいい。とにかく普通の男と結婚したいのよ。」

問３　概算見積もりとボトムアップ見積もりの特性と使用されるべき状況を、１００字以内で述べよ。

問４　本プロジェクトでとるべきリスク対策を、「回避」「挫折」「潔く」「撤退」の字句を用いて３０字以内で述べよ。

問５　トラブルやインシデントが発生した場合、恒久的対策も策定されずPDCAサイクルも機能しないことが考えられる。その理由を３０字以内で述べよ。

　　　（失礼なので省略）

・上長の承認プロセスも、適切であるべきである。例えば、実行権限や承認権限は適切に上長IDに付与されているか。

・社外に持ち出すPCには、最低限の資料やドキュメントに限定されるべきである。営業であれば、顧客に見せる最低限の資料、ドキュメント、商品関連情報のみが記載された資料の持ち出しに限定されるべきである。

・外出先での外部インターネット接続などには注意が必要である。ランサムウェア等への感染リスクを防ぐべきである。

・ファイル名に拡張子が記述されている場合、実際にはEXEファイルであり実行した瞬間にマルウェアが動作してC&Cサーバやボットネットなどに接続されてしまう可能性がある

・社員のID、上長のIDなどのように、役職や責任の所在などに応じて適正な権限アサインがなされるべきである。社内の情報セキュリティ管理者はこの権限アサインに関して的確なポリシーの策定を行うべきである。

・ポートスキャンを防止するため、サーバの不要なサービスは停止する。不要なポートは閉じる。

・ファイヤーウォールはポートやフローの攻撃を防止する。アプリケーション脆弱性に起因する攻撃は防げない。

・偽のDNSキャッシュを返す攻撃を防止する。古いキャッシュは信頼性の観点からExpireされるべきである。

・C&Cサーバとの接続を開始したマルウェア感染のクライアントがSSL接続を確立した場合、プロキシサーバでの閲覧・データ採取・ログ取得は困難になるため、一時的にSSLトンネルを終端する必要がある。

・SYNフラッド攻撃を回避するために、ハーフオープン状態である場合にメモリの確保を行わない、などの対策がある

・SYNフラッド攻撃回避のために、SYNパケットの上限に達した場合はSYNパケットを破棄し、下限にまで下がった場合はSYNパケットの破棄をやめる、といった対策も考えられる

・社内に接続してもいいPCなどは、十分に検査されたものを接続すべきである。

・検査サーバで正規のPCであるかを検査し、適正なPCであればLANへの接続を許可する。適正でない、ポリシー準拠でない場合には治療サーバに接続し、パターンファイルの更新、セキュリティパッチの適用、社内ポリシーへの適合処理などを行い、LANへの接続を許可する

・適正なDHCPポリシーに準拠させるため、DHCPスヌーピングを適用する場合がある。サーバなどを接続するポートには、DHCP Trustの設定を行う

・仮想サーバ内のセキュリティも重要である。異なるテナントにアクセスできてはならない。また、不要な仮想サーバへのリソース割り当て、不適切なリソース割り当ても回避すべきである。

・サーバのパフォーマンスの低下は、サービスに影響する

・サービス低下の許容するベースラインを策定し、あらかじめクライアントやユーザ部門と合意を得ておく

・サービスの重要度（ユーザ数など）に応じて、復旧の優先順位を策定しておく

・故障率の測定、トップダウン分析、ボトムアップ分析(FTA、FEMA）によって故障の原因を究明し、再発防止策を策定する

・試験方法には加速試験、ステップストレス試験、非破壊検査などがあり、経済性を考慮する

・試験項目があまりに多く重複やダブりが多い場合は、コストが非常にかかり経済的とは言えない

・パケットの重複を防止するための仕組みが、より上位レイヤ（TCPやアプリケーション層など）で必要である

・MQTTとREST APIの特性の違い

・キャッシュサーバなどが間に入っている場合、クライアント側とサーバ側で必ずしも同期がとれているとは限らない

・TCP通信の方向、ファイヤウォールのパケット入力の方向。SYNやSYN+ACK（ビット）の方向を考慮する

・シーケンス番号による重複検知、順序判定

・セッションIDによる負荷分散

・TLSで暗号化した場合、LBにおけるヘッダ処理について考慮する必要がある

・リモートサーバへのバックアップ。伝送距離、伝送路における時間やパフォーマンス等に注意

・ハッシュ値が重複すると、異なるメッセージまで同じものとして見做してしまう

・伝送路の冗長化（リング構成）、IP-VPN、広域イーサネットでの冗長化

・ルーティングプロトコル（BGP）で冗長化するか、スパニングツリー（STP）のようなプロトコルで冗長化するか

・非同期通信では、送信と受信のタイミングが必ずしも一致しない

・移行、夜間切り替えの手順。どのサーバは停止してもよくて、どの機器は撤去してもよいのか、どのケーブルは抜いてもいいのか

・移行手順書、切り戻しの判断基準

・移行手順書に齟齬があってはいけない。書き方についての意識合わせを行っておくべき

・夜間移行作業を行う際には、ユーザ側にあらかじめ通知を行うべきである

・トラブル発生時の復旧手順、連絡体制を明示的にしておく

・サービス復旧のためのRTOなどを示しておく

・クラウドサービスを分散しておくことで、災害時の負荷分散を行う。自社作業保守メンバーの作業負荷を軽減する

・ソースコードの書き方にメンバー間で齟齬があってはいけない。標準化されたプロセスに沿って書かれるべき

・APIへのリダイレクト先URL

・DNS問い合わせパケットの送信先は、キャッシュサーバ等になる。コンテンツサーバに直接問い合わせたのでは負荷が大きい

・無線は、高周波数（波長が短い）ほど、より多くの情報を運べる

・無線は、高周波数ほど、直進性が高い

・無線は、降雨や濃霧などにより減衰する

・減衰した無線は、何らかの増幅処理が必要である

・WLC（無線LANコントローラー）を経由する無線トラフィックは、データ用トラフィクを圧迫する可能性がある

・5Gが多数接続できる理由は、周波数が非常に高いからである

※真面目に勉強されたい方は、回れ右でお願いします。

・監査とは、仕事・業務のやり方・方法・プロセス・業務フロー等が間違ってないか、誤りがないかなどを点検・監視することである

・社内の情報システム（例えば勤怠管理サーバ、生産管理サーバ、受注管理サーバなど）のシステムの仕様、動作、バージョンなどに誤りが無いか点検・監視する

・間違っていたら、指摘して改善を促す。改善命令はやってはならず、あくまで指摘のみを行う。

・監査だけで終わってはいけない。その後、どのようにコントロールするか（監視、改善策など）を考える

・監査の効果がどのくらいあったのか、点検・監視・モニタリングなどを行って監視していく。

・問題点があれば、それを改善していく。

・監査分野におけるコントロールとは、改善・監視とかそういう意味（？）。

・ID監査の基本は、使われてないIDはないか、もしあればそれをきちんと削除しているかどうかの点検である。

・使われてないIDがないかどうかを点検する。これをIDの棚卸しという。

・使っているIDであっても、もし不必要な権限（読み込み、書き込み、実行など）が割り当てられていないか確認する。

・もし不要なアクセス権限が割りあてられていた場合、必要最小限のものに限定すべきである。

・課長にしか書き込み権限が無い場合、従業員のIDに書き込み権限を与えてはいけない。

・システムを使用して承認する場合、上司への承認フローに誤りはないか、上司の承認権限は正しく割りあてられているか、などの確認を行う。

・手作業などで非効率な作業がある場合、システム監査人がそれが業務や会社の経営・利益等にどのように影響を与え、改善改善を促すことがある。

・受注管理システムとは、いつ誰がどの取引先から何を何個受注したのかを管理するシステムである。

・受注管理システムがもし誰かからの受注を受け付けた場合、その受注者、取引先、年月日、時間、商品名、数量、納期（納品期日）などをユーザー部門などに対して通知する

・受け付けた上記の情報は、受注管理データベースなどに保存される。

・当然、そのデータベースにも改ざん、内容の非完全性、内容の齟齬、不整合などがあってはならない。

・データベースを他のサーバやシステム等と連携している場合は、データベースに不整合がないかを確認・監視する。

・例えば、商品Aの在庫管理システムでは1200円なのに、受注管理システムでは120円など、桁数が謝った表示になるといったことがあってはならない。

経営戦略（応用情報）基礎

・IT投資によって、いかに高い企業価値や利益を創出できるか

・いかにROIを上げることができるか。投資に対して、いかに高いリターンを得ることができるか。いかにレバレッジ性を持たせるか。

・財務諸表の分析によって、企業経営の健全性が把握でき、またステークホルダー（株主など）に説明できコンセンサスを得られるか

・宿泊業界であれば、顧客のデータベースとホテルの部屋情報、予約データベースなどとの兼ね合いからデータベースの連携は必須。データベース不整合およびデータベース不完全性の排除は重要ポイントとなる。観光地との連携やキャンペーンなども重要になってくる。

・医療業界であれば、請求書、レセプト、カルテ、患者、日時、処方箋、薬剤の種類、ジェネリック使用の有無などの情報をデータベースで管理する。患者や診断名などの傾向からデータマイニングにしてより適切な診療ができ、昨今の医師不足や高齢者の増加もITの力（医療のDX）などで対応出来るものと思われる。

・自動車業界であれば、若者の車離れや高齢者増加に伴うAIを駆使した安全運転制御の仕組みを自動車に導入することで、GPSと連携して安全に制御する仕組みに導く。

・レストラン業界であれば、従業員によって品質に差が出るのを防ぐために業務フローを体系化させ、マニュアル化する。顧客の意見をまとめ、特性要因図で問題点を把握する。食材を過剰に仕入れる問題点を防ぐために、在庫管理、在庫の棚卸しが必要となる。その外、原価管理、適正な簿記によるお金の流れの可視化も重要になってくる。

・Webページの表示の遅さはSEOにも影響するため、ネットワークの性能の改善は必要である。ネットワークの性能改善にはLBの導入、QoSの実装などが考えられる。

プロジェクトマネジメント（応用情報）基礎

・いかに出戻りをなくす、か

・納期に間に合わない場合は、スコープの変更。要件定義、見積もりの段階で謝っている場合は、基本的にスコープの変更で対応する。

・スコープの変更でなんとかしたい場合は、体系的・定量的エビデンスをもってしてステークホルダーのコンセンサスを得る。

・変更は適切に管理する。変更によって影響の出る箇所も念頭に入れる。

・ステークホルダーは関心度が高く影響力もあり決裁権を強い人を重点的にコミュニケーションする。けど、逆の人ともコミュニケーションとらないと信頼を失いそうなので、前者ばかりに気をとられるのはよろしくないかもしれない。

・工程の遅れには、作業を明確化、作業にIDをつけてトレーサビリティを上げる、問題点を報告しにくい環境や雰囲気の排除などを行う

・工数の増大には、要件定義およびコスト制約、時間的制約、人的制約、スキル的制約などをもって根拠、コンセンサスを示して定量的にステークホルダーに伝え、工数の増大を防ぐ

・コストがコストベースラインを上回る問題についても、工数の増大を防ぐことが基本であり、また作業ごとにかかるコストをメンバーのスキルや資源のバージョン、種類ごとに客観的かつ定量的に把握することで防ぐ。

・ステークホルダーとうまくいかないことについても、やはり客観的かつ定量的にコンセンサスを得ることが重要であろう。そのために概算見積もり→ファンクションポイント法に至るまで粒度の高い見積もりが必要であろう。専門家や有識者に意見を伺うことで自身の知識不足を補いコストを算出の判断材料に用いる必要も出てくるであろう。

・メンバー同士がコンフリクトが起きる場合、プロジェクトの目標が明確になっていない、あるいは各メンバーの役割が明確でない、共有されているはずの情報やドキュメントがメンバー間で齟齬があるなどの場合は、意識共有を図れる仕組みが必要である。また、コンフリクトはプロジェクト序盤に起こりやすく、プロジェクトが進むにつれて収まってくる可能性があることも念頭に入れる。

・テストケースが少なすぎると、欠陥を摘出できない場合がある。時間的制約でテストケースが不足している、テストケースが用意できない、経験不足により適切なテストが設定できない、などの問題が考えられる。あらかじめスケジュールにバッファなどの余裕をもたせておき、予期せぬテストケースの必要にも対処できるようにしておきたい。

・テストケースが多すぎてテストに時間やコストを要するのも問題である。テストケースが多すぎると時間もコストも人的リソースもかかる。テスト内容が重複している可能性も考えられるので、重複やモレは排除していく必要がある。本当にそのテストケースは必要かどうか考える必要もある。

組み込みシステム（応用情報）基礎

・組み込みシステムは色々なものにわたり使用されている。例えば、自動車、LED、ドローン、工作機械、体温計、炊飯器、エレベーター、信号機など挙げればきりがない。

・身の回りの様々なIoT機器に組み込みシステムは備わっている。IoT時代に組み込みシステムの知識はあった方がいい。

・さらにネットワーク分野におけるwebsocketやMQTTなどの送受信技術などを知っておくとなおよしか。

・ドローンを飛ばして、農地の測量をする。現地の地質、気温、風速、湿度、土壌などを調査し、その上でサーバに転送し、データマイニングによって適切な意思決定を行う。

・安全な自動車運転を実現化するためにGPSやAIを使った自動車運転制御を実現する。GPSによって自動車の現在位置、移動情報、速度、移動方向などを解析し、データマイニングによって自動車の運転の安全性を評価する。

・もし交通上の危険を感じたら、信号に従って安全に停止する、人や物との接触を防ぐために安全な運転に切り替えるなどの処置を行う。

・幼児にGPSで監視可能なデバイスを持たせ、自動車と同様にGPSにより現在位置情報、移動情報、移動方向、移動速度などを収集し、幼児の行動パターンを学習する。その上で、幼児の行動の安全対策を行える。

・LEDの制御においては電圧のオンオフなどの切り替えによって、LEDの点灯、消灯の制御を行う。

・MPUとは、マイクロプロセッサユニットとよばれるもので、微妙に違うがCPUと同じようなもの。CPUをLSI（集積回路）に搭載したようなもの。

・組み込みシステムに異常負荷や停止などが発生した場合は、直ちに管理者に通知する仕組みが必要である。これはネットワークでいうところのSNMPと共通している。