見積もりが高い！？仕様変更が拒否される！？知っておきたいシステム開発の裏側

今回の記事では、企業の情シスが業務システムの開発を社外のシステム開発会社に委託する場合に知っておいてほしい、システム開発会社の裏側を紹介します。

取り引きしているシステム開発会社さんは、見積もりも高いし仕様変更にも気軽に対応してくれないんです！

中の人

システム開発会社さんには相応の事情があるんですよ。

システム開発の裏側を理解すれば、見積もりを安くする工夫ができたり、揉めずに仕様変更の交渉が可能です！

情シスとしてシステム開発会社さんとやり取りをしていると、簡単だと思って気軽に依頼した作業に対して難色を示されたり、非常に高い見積もりが出てきたりといった経験はあるかと思います。

これは、システム開発会社さん側の事情があるのですが、システム開発会社の裏側がわからないとなかなか理解ができません。
そこで、過去にはシステム開発会社に勤めており、その後事業会社の情シスに転職した私が、その気になる「裏側の事情」を紹介していきます。

尚、実際にはシステム開発会社の規模や体制、開発対象のシステムの大きさなどによって変わってくるので、御社が取り引きしているシステム開発会社さんでも同様に当てはまるとは限りません。

参考程度で読んでください。
 
 

何故、概算見積もりの算出は難しいのか

新しく業務システムの開発が必要となった場合や、既存システムの大幅なシステム改修が必要となった場合に、具体的なシステム要件が固まっていない状態で「概算見積」をシステム会社さんに依頼することはあるかと思います。

予算取りで使うので、だいたいの金額で良いですよとかそんな軽いノリで依頼されることが見受けられます。

実は、この「概算見積」を算出するのは簡単ではありません。

次項で、「何故、概算見積の算出が難しいのか」を説明していきます。

システム開発費用の金額根拠は工数

ご存知のかたも多いかと思いますが、改めておさらいしましょう。
システム開発に関する費用を算出する場合の費用根拠は「工数」です。

システム開発作業は技術者がプログラミングをしてアプリケーションを作成します。
製造業のように原材料の仕入れといったものはなく、アプリケーションの作成に必要な経費はほぼ技術者の人件費のみです。
その人件費のことを一般的に「工数」と呼びます。

また、この「工数」は、技術者一人が1日作業した場合の工数を「1人日(いちにんにち)」。
技術者一人が1カ月作業した場合の工数を「1人月(いちにんげつ)」と呼びます。

例えば、ある業務システムを開発するために、その開発プロジェクトに3人が参加して3か月で終わる場合は「9人月」の工数になります。
この「9人月」は、技術者1人が9か月間で作業をしても、同じく「9人月」です。

システム開発会社ごとに、この工数の単価が決まっています。
この単価はシステム開発会社の規模やランク、地域などによって大きく差があり、最近の一般的な工数単価は一人月：80万円～120万円といった相場感です。

よって、システム開発の費用を算出するためには、その開発作業に工数がどれだけ必要かを算出しなければなりません。

工数の算出には具体的な作業内容が必要

前項では、システム開発の見積もりを算出するには、その開発作業に工数がどれだけ必要になるかを算出しないといけないと記載しました。

さて、ではその肝心な工数を算出するためにはどうしたら良いのでしょうか？

その時点で顧客から聞いているシステムの要件を元に、そのシステムではどの様や画面が必要で、その画面がいくつあって、システムとして実装されないといけない機能がどれぐらいあって、それらを開発する難易度はどのレベルなのか・・・といった、工数を算出するための根拠を列挙していくことが必要になります。

この工数根拠となるシステムの機能や構成を洗い出すには、当然、顧客がどのようなシステムを要望しているのかが明確になっており、そのシステムを作るうえで必要になる画面や機能が具体的に列挙できる状態にある必要があります。
その列挙した機能数や機能内容が具体的で詳細であればあるほど、正確な工数を算出することができます。

ただ、前述した「概算見積もり」の場合はそうはいきません。
顧客側でもシステムに対する要望は曖昧であり、その時点では要望されているシステムにどのような機能が載れば顧客の要望を満たせるのかがわかりません。
その状態で工数を算出しろと言われても不可能です。

それが「概算見積もり」であり、冒頭の記載した「概算見積を算出するのは難しい」とお伝えした理由です。

それでも「概算見積もり」が欲しい場合

概算での見積もりがシステム開発の仕組み上難しいのは説明しましたが、それでも欲しい場合はどうすべきでしょうか？

まず、システムの要件が曖昧なまま工数を算出しようとした場合、担当するSEは、考えられる機能を漏れなく工数として含めようとします。

概算見積とは言え、最初に提示した金額よりもその後の本見積もりの方が高くなると、後からもめることも有り得るため、なるべく要件の不明なリスクを工数として積み上げます。

これはSEとして適切な判断です。

その結果、顧客側としてはイメージしていた金額よりも遥かに大きな見積金額の提示を受けることになります。

ただ、それでは費用感が合わず、本来進めたかったシステム開発案件を進めることができなくなってしまいます。

そこでオススメしたいのが、

方法です。

工数を算出するSEは、考えられるあらゆる機能を工数として盛り込みますが、それらに対して除外できる「前提条件」があれば、工数として含めなくても良くなります。

例えば以下のような「前提条件」を見積書に盛り込んでもらいます。

• 帳票の印刷機能は不要
• ブラウザはEdgeのみの対応とする
• オフライン機能は不要

システム要件が固まってなくても、このような前提条件を付け加えてもらえれば、概算見積りとは言え、極端に工数が加算された見積もりは出てきません。

当然ですが、指定した前提条件を後から覆す場合は、再度見積もりを出し直してもらうことになるので、確実に約束できる前提条件を指定しましょう。
※間違っても、前提条件を覆しておきながら金額は変えさせないといった無理な注文はしてはいけません。
 
 

何故、ちょっとした機能追加で高額な見積もりが来るのか

既存のシステムに対して、比較的軽微なシステム改修の要望をシステム開発会社に伝え、後日提示された見積もりを見て「こんなに高いの？！」と驚いたことはありませんか？

よくあるやり取りですが、これにはちゃんと訳があり、システム開発会社側の事情があります。

当項ではちょっとした機能追加などのシステム改修を依頼した際に、予想外の高額な費用で見積もられてしまう原因を紹介していきます。

プログラミング以外にも多くの作業が発生する

軽微な修正や機能追加依頼をする場合、技術者がその修正作業や機能追加作業でプログラミングをする時間は実際に僅かだったりします。
ここまでは依頼者の想定している作業範疇です。

でもシステム開発会社側では上記のプログラミング以外にも以下の作業が発生します。

顧客から見えているシステム開発会社の作業は氷山の一角であると言えます。

ちょっとした改修をお願いしたのに大げさだよと思うかも知れませんが、これがお金をもらってモノづくりをするプロの仕事です。

システム開発では、作業に掛かる時間を「工数」として費用換算することは前項で解説しましたが、これらのプログラミング以外の作業でも「工数」が発生します。

これらの作業工数を事前に予測してすべて積算したものが「見積もり」になるため、軽微な作業であっても顧客側の想定より高い見積もりになってしまう原因です。

お得な見積もり提示をしてもらうポイント

前項では、軽微な改修依頼でも高額な費用になる理由を解説しました。

当項では、想定より高い見積もりである「割高な見積もり」ではなく、「割安な見積もり」を提示してもらうためのポイントを紹介します。

小規模な改修を繰り返すよりまとめて一回で

システム改修案件では、可能な限り改修内容をまとめて一度で実施した方が費用は割安になります。

前出したとおり、システム開発の作業では、プログラミング自体は全体の作業の一部でしかなく、プログラミング以外の作業も多く発生します。

改修範囲をまとめて依頼することで、この「プログラミング以外の作業」の比率を小さくすることが可能です。

例えば、改修したシステムをテスト環境や本番環境に適用する作業でも、本番環境への適用作業については、問題が発生しない限り、システムの改修範囲に関わらず一度きりです。

プログラミング作業の工数はシステム改修規模で比例して大きくなりますが、作業内容によっては改修規模の大小で変わらないものも多々あります。

よって、システム改修案件は小規模な改修を頻繁に繰り返すのではなく、できるだけ一つの案件にまとめて実施するほうが作業工数の面で効率的です。

改修規模を大きくして値引きを入れてもらおう

システム開発費用の世界でも、ボリュームディスカウントは存在します。

前述したように、システム開発費用の見積もり根拠は「工数」です。

工数は技術者一人が1日稼働した場合の作業量ですが、実際にはその1日の作業で進めることのできる作業量は個人の能力で大きく開きがあります。
工数の目安は、社内の中間的な能力の技術者か、それより劣る程度の技術者の作業量を目安に想定します。

よって、作業内容ごとで適切に人員を割り当ててプロジェクトを進めることで、予め見積もり上で提示していた工数より少ない作業時間で進められる可能性があります。

実に大雑把な費用算出手法であると言えます。

ただ、開発規模の小さい軽微な改修の場合は、見積もりで提示した工数から大きく前倒しできる余地も少なく、工数の予測は比較的正確です。

その為、小規模の開発プロジェクトでは難しいのですが、ある程度の開発規模のプロジェクトであれば、プロジェクトの進め方次第で、前述したように見積もり工数よりも効率よく作業を進められる余地が大きく、システム開発会社の担当営業側でも値引きを入れやすくなります。

このように、値引き交渉をしやすくすることの意味でも、やはりシステム開発やシステム改修の依頼をシステム開発会社にする際には、小規模な内容ではなく、ある程度まとまった作業ボリュームになるように調整して依頼するように心掛けましょう。

何故、後から仕様変更を依頼すると怒られるのか

業務システムの開発プロジェクトでは、最初にシステム開発会社に伝えていた要件に対して、その後追加したくなったり変更したくなることが多々あります。

ですが、プロジェクトが進むほど、その希望をシステム開発会社に伝えても対応を嫌がられたり、状況によっては拒否されます。

これには、システム開発の作業フェーズによっては、その対応をすることで大きな手戻りが発生したり、予定していた作業量から超過することになるのが原因ですが、何故手戻りが発生したり作業量の超過が起こるのかを理解するには、一般的なシステム開発の流れを理解することが必要です。

よって、当項では、後から仕様変更を依頼すると怒られる原因を理解するために、システム開発の一般的な流れや、変更により発生する手戻りの内容やその影響について解説していきます。

一般的なシステム開発の流れ

システム開発のプロジェクトでは、顧客がシステム開発の発注をしてプロジェクトが開始された以降は、システム開発会社側の作業工程として以下のように進んでいきます。

システム開発の進め方にはいくつか種類があり、そのなかでも業務システムの開発では最も一般的な「ウォーターフォールモデル」で進めた場合の行程例です。

参考までに、その工程で作成、又は使用されるドキュメント名も記載しました。

尚、「基本設計」は「外部設計」とも呼び、その場合「詳細設計」を「内部設計」とも呼びます。
後、順番7の受入テストは、システムを発注した顧客側で行う作業であり、「受入テスト仕様書」は顧客側で作成します。
また、「単体テスト」と「システムテスト」の間に「結合テスト」を挟む場合もあります。

この「ウォーターフォールモデル」では、名前の通り”滝”のように上から下に作業は流れ、下から上へ遡ることはしない想定の開発プロセスです。

ウォーターフォールモデル以外にも、アジャイル開発、スパイラルモデル、プロトタイプモデルなどの様々なシステム開発の手法があります。
ただ、もっとも基本となる開発手法はウォーターフォールなので、こちらの名前と各工程の作業内容を覚えておく必要があります。

ウォーターフォールモデルでは過去の工程に遡らない

ウォーターフォールモデルでは、本来は作業工程ごとに厳格に確定させていき、遡って前工程の作業をすることがないことを前提としています。
したがって、要件定義フェーズで洗い出した要件に漏れがなく、基本設計フェーズで構想したシステム内の各機能に不足がなく、詳細設計フェーズで設計した処理に問題がなければ効率よく開発を進めることができます。

しかし、実際のシステム開発のプロセスにおいて、前工程で誤りがなく、漏れがないことなど少なく、システムの開発規模が大きくなればなるほど、その傾向は顕著です。
そして、前工程での誤りや漏れなどが後工程で見つかった場合、前の工程に遡ることが必要になります。

例えば、詳細設計フェーズで要件漏れが発覚した場合、最初に作成した要件定義書に加筆をして、再度そのドキュメントに対して顧客との同意を取る。
その後、既に作成済みの基本設計書に対しても加筆、修正を行ったのち、要件定義書と同様に顧客に確認してもらい同意を取る。
それらが完了しないと、詳細設計書の作成作業がストップすることになります。

よって、技術者の作業工数が増えて、開発スケジュールもその分遅れます。
ただ、そのやり取りによる、開発中のシステムの納期が延びるかといえば、変更してもらえないことが大半です。

ひどいケースでは、プログラムの作成が完了し、受入テストを顧客側で実施している最中に要件漏れが判明するといった場合、大幅に手戻りが発生することになります。

システム開発プロセスにおいて手戻りが発生すれば、その分システム開発会社側の作業工数は増えます。
作業工数が増えると、システム開発会社のコストは殆どが人件費であり、システム開発会社側の利益が減ることになります。

また、開発スケジュールも余裕がなくなっていき、技術者が残業したり休日出勤などをして、スケジュールの遅れを取り戻していくことが必要になります。

後から仕様変更を依頼されたり、要件の追加を依頼される場合、システム開発会社として、

• 利益が減る(最悪は赤字になる)
• 仕事が増える(費用はもらえない)

となるため、嫌がったり怒られるのは当然なのです。

ウォーターフォールモデルで手戻りを減らすには

前述したように、ウォーターフォールモデルにとって、前工程に遡ることは問題があります。
しかし、現実的には各工程を完璧に漏れや誤りなく終えることは難しく、どうしても発生してしまいます。

ただ、前述したように手戻りが発生することで、システム開発会社側での悪影響だけではなく、システムを発注した顧客側にとっても以下のようなリスクが発生します。

• 予定していた納期に遅れる可能性がある。
• 納品されてきたシステムの品質が低下する恐れがある。

よって、顧客側でもシステム開発プロセスにおける手戻りを発生させないように気を付ける必要があります。

そのためには、システム開発の作業フェーズが次工程に進む前に、顧客側でも次のフェーズに進めて良いかを発注者として責任を持って確認し、システム開発会社に丸投げするのではなく、顧客側でもシステム開発の当事者としての自覚を持ってシステム開発プロセスに関与する必要があります。
 
 

何故、後からの変更依頼はバージョン管理を理由に断られるのか

システム開発会社ではプログラミングをしてシステムを開発する場合に、作成したプログラムのコードをチームで共有して分担しながら開発できるようにしたり、変更箇所の差分を正確に管理するために、「バージョン管理システム」又は「ソース管理システム」を使用しています。
※以降の当記事では呼称を「バージョン管理システム」で統一させていただきます。

これはシステム開発会社の規模の大小に関わらず、必ず何かしらの「バージョン管理システム」を利用してプログラムファイルを管理していると思っていただいて結構です。
プログラミングを生業とする企業においてとても欠かせない、無くてならないツールです。

そのため、御社が発注してシステム開発会社に開発を委託しているシステムのプログラムのソースコードも、このバージョン管理システム内で管理されています。
このバージョン管理システムは、システム開発会社での就業経験が無いと実際に触れる機会もないため、その存在を知らない人も多いかと思います。

システム開発のプロジェクトにおいて、開発作業が進んでしまった後から仕様変更等の変更依頼をしても、このバージョン管理システム内の管理状況次第では、開発会社側での対応も難しい場合があり対応を断れることもあります。

そのため、システム開発を発注する顧客の立場であっても、バージョン管理システムの仕組みを理解しておくことはとても重要です。

バージョン管理システムとは

何らかのアプリケーションをプログラミングで作成する場合、そのアプリケーションは機能ごとや種類ごとに分けられたファイルで構成され、開発者はそのファイルにプログラムを記述していきます。

その”プログラムが書かれたファイル”はメモ帳などのテキストエディタでも開くことができて、Microsoft Visual Studioなどの「IDE(統合開発環境)」が無くても開いて編集することも可能です。

バージョン管理システムでは、そのプログラムファイルの一式をまとめて保管できて、その構成しているプログラムファイルが変更された場合に、テキストの変更箇所の差分も管理します(テキスト毎の差分を管理するためには、テキストエディタで開けるファイルである必要があります)。
そのため、特定のプログラムファイルの変更履歴を辿って、過去の状態に戻すことも可能です。

また、大人数で一つのアプリケーションを開発する場合には、バージョン管理システム内で管理しているプログラムファイル一式を各開発者がダウンロードして、そのファイル一式のなかから必要なプログラムファイルを各自が更新して、バージョン管理システム内の大元のプログラムファイル群に反映をさせていきます。

バージョン管理システムを使用せずに大人数でシステム開発作業を進めた場合、例えば同じプログラムファイルを別の開発者同士がそれぞれ編集してしまったり、古いプログラムファイルで新しいプログラムファイルを上書きをしてしまうといったことも起こりがちですが、バージョン管理システムではそのようなトラブルも発生させないような仕組みになっています。

数あるバージョン管理システムにおいて近年有名なのは「GitHub」です。
このGitHubは「Git」と呼ばれるバージョン管理システムをクラウド上で利用できるようにしたサービスです。
また、一昔前はSubversion(SVN)と呼ばれるバージョン管理システムも広く利用されておりました。

バージョン管理システムの基本的な使い方

バージョン管理システムも様々な種類があり、そのバージョン管理システムごとに仕様は異なりますが、それでも大まかな仕様や使い方は同じです。
当項では大まかな仕様や使い方を紹介していきます。

バージョン管理システムでは、「リポジトリ」と呼ばれる、バージョン管理システム内のプログラムファイル一式を管理するためのデータ保管用の領域を作成して、そこにプログラムファイル一式をアップロードして保存します。

開発者はリポジトリからプログラムファイル一式をダウンロードして自身の担当しているプログラムを作成、更新します。
自身が担当しているプログラムファイルを新しく作成したら、そのファイルをリポジトリに追加します。
また、リポジトリ内のプログラムファイルに変更を加えたら、その変更を加えたファイルのみをリポジトリに反映させます。

リポジトリ内では、頂点の管理領域の配下に複数の管理領域を作成することができて、管理状況によってプログラムファイル一式の変更履歴を枝分かれ(ブランチ)させて平行管理をすることができます。

大元のリポジトリ内のベースとなるプログラムファイル一式から、一つブランチを追加して枝分かれさせて、そのブランチを不具合修正用の変更履歴として分離したり、更にブランチで分離して、次期開発案件を先行して着手していくなど。
バージョン管理システムでは、この「ブランチ」を適切に利用しながらプログラムファイルを管理していきます。

プログラムファイル一式を管理していくなかで、そのアプリケーションの「バージョン」も適切に管理していく必要があります。

一般的に多い例としては、開発しているシステムを顧客に納品して、本番稼働を開始した際のアプリケーションのバージョン番号を1.0.0として、そのプログラムから、軽微な不具合修正などを行った場合は、バージョン番号の末尾の数字をカウントアップして1.0.1とします。
また、機能の追加など比較的大きな改修などを行った場合は、真ん中のバージョン番号をカウントアップして、1.1.0とします。
そのアプリケーションの根幹部分を大きく変えたり、大規模な改修などを実施した場合は、先頭のバージョン番号をカウントアップして、2.0.0とします。

このようにバージョン番号を付けてそのアプリケーションの更新状況を管理していきますが、バージョン管理システム内では、管理下のアプリケーションのバージョンを上げる際には、「tag」と呼ばれるブランチを作り、そこにプログラムファイル一式を格納します。
tagには名前が付けられるため、v1.0.0などのようにバージョン番号ごとの名前をtagに指定します。

tagに格納したプログラムファイルは基本的に変更しません。
このバージョン時点の正式なプログラムファイル一式として保管しておく必要があります。

これを「タグ付け」と呼びます。

実際のバージョン管理例と変更に対応できないタイミング

実際のバージョン管理システムの使用例と、バージョン管理上の理由により、仕様変更への対応が難しくなるタイミングについても紹介していきます。

まずは以下の図をご確認ください。

バージョン管理システムによる、プログラムソースの管理例です。
最近の主流であるバージョン管理システムは「Git」であり、Gitはローカル環境でのコミット(プログラムの変更箇所の反映)ができるので、実際にはもう少し複雑ですが、イメージを掴むだけなら、上記の図の理解で十分です。

まず、リポジトリを作成して、そこに管理対象のプログラムファイルの一式を格納します。

開発者である「山田さん」と「佐藤さん」はそのリポジトリ内のファイル一式を自端末内にダウンロード(チェックアウトとかクローンなどと呼びます)して、担当するプログラムを作成していきます。

図のA、B、Cでリポジトリに対して、山田さんと佐藤さんのそれぞれが作成したプログラムファイルを反映させています。
これを「コミット」と呼びます。

Dでは、左側に「tag v1.0.0」と枝分かれしました。
これは、作成中のプログラムがいったん完成したので、バージョン番号を付けて、その時点のプログラムファイル一式をコピーして保存しました。
これを「タグ付け」と呼びます。

同じくDでは、右側にも分岐して、「branches v2.0.0先行開発」と命名されています。
これは、この時点までのプログラムファイル一式をコピーして、主流の管理領域から枝分かれして並行管理できるようにしています。
これを「ブランチ」と呼びます。

プログラムのバージョン管理において、この「ブランチ」の仕組みはとても重要です。

因みに上記の図では、新しくv1.0.0として、いったんプログラムが完成し、次の開発フェーズ用でv1.0.0と同じプログラムファイル一式をもとに、先行して開発を進めだした状態です。

Eでは、リリースしたv1.0.0に不具合が見つかり、山田さんが「プログラムファイル：γ」の不具合修正をしてコミットしています。

Fでは再度タグ付けをして、v1.0.0の不具合修正バージョンである、v1.0.1をリリースしています。

Gでは、v1.0.1の状態のプログラムファイル一式と、次の開発フェーズとして先行して開発を進めたD’のプログラムファイル一式を「マージ」しています。

バージョン管理システムでは、同じファイルに別々の修正を加えてコミットされた差分同士を融合させてまとめることができます。
これを「マージ」と呼びます。

また、コミット時やマージ時に同じプログラムファイルの同じ行などを修正されてしまい、両者の修正箇所が衝突する場合があります。
それを「コンフリクト」と呼びます。

ここまでが、システム開発におけるバージョン管理システムの大まかな使い方です。

バージョン管理上のプログラム変更が難しいタイミング

ようやく本題です。
システム開発のプロジェクトが進むと、このバージョン管理システム内の状態によっては、仕様変更などのプログラムへの変更が発生する要望については対応ができなくなります。

例えば、上記の図だとAからCまでの間であれば、バージョン管理上はプログラムに変更を加えることは問題ありません。

ですが、Dを過ぎるとプログラムはD以降の本流と、D’の支流に分岐します。
Eのような不具合修正は仕方ないにしても、仕様が変わるようなプログラム変更をEなどで実施すると、D’にも同様に適用する必要があり、かたやD’は次のフェーズの開発をする土台となるプログラムファイルたちなので、そこに仕様が変わるような変更を実装してしまうとプログラムの管理が非常に煩雑になります。

D’で予定している先行開発対象の機能たちは、新しく作る機能であり、D以降の本流の実装に影響を与えないものだったり、またはD以降の本流の機能が完成している前提で、更にそこに対して修正を入れていくような作業です。

だから、システム開発会社のSEはD以降の本流に対する仕様変更などに伴うプログラム修正は何としても避けたいと考えます。
よって、どうしても変更が必要であればGのタイミングで対応すると言う話になります。

このように、プログラムのバージョン管理の都合上、どうしても変更要望に対して断らざるを得ない場合があり、そういったシステム開発側の事情も考慮しながら、円満にプロジェクトを進めることが必要です。
 
 

最後に

今回の記事では、システム開発のプロジェクトにおける、顧客のユーザー側では普段あまり意識することがなかったり、知る機会のないシステム開発会社側の裏側を紹介させていただきました。

システム開発会社に勤めた経験があり、その後に事業会社の情シスに転職した人であれば、システム開発会社のなかの事情についてはご存知ですが、システム開発会社での就業経験が無かったり、就業経験があってもプロジェクトリーダーやプロジェクトを取りまとめる立場になかった人の場合は、システム開発案件を円滑に進めながら管理する大変さや、システム開発業界固有の事情を知らない場合が多く、今回の記事で取り上げたようなシステム開発会社と顧客側との認識のズレや、それに付随した両社間での対立といった不幸なやり取りを多く見てきました。

システム開発プロジェクトの発注側である顧客においても、作業を委託したシステム開発会社にプロジェクトの進行を丸投げするのではなく、相手の事情を考慮しながら、プロジェクトを円滑に進めるための協力を率先してするべきです。
それが本来のあるべき「ベンダーコントロール」だと考えます。

今回の記事がプロジェクトの遂行に迷える情シスさんの参考になれば幸いです。

今回も長々と読んでいただきまして、ありがとうございました。
それでは皆さまごきげんよう！