業務委託の初回の打ち合わせで、発注側から「技術選定はお任せします。決めてください」と言われました。組織にいたときの調子で即答しかけて、その決定を誰が承認し、誰の名前で残るのかを聞いていないと気づきます。フリーランスとして受けるITアーキテクトは、決める権限を持たない立場で仕事が成り立つのでしょうか。答えは一言です。「ITアーキテクトの業務委託は、決めるのではなく、決められるようにします」。

1. 組織の中と外で変わる、決定権の位置

組織の中で決めてきた範囲

この記事では、組織の中のITアーキテクトを、技術を選び、全体の構造を設計し、チームをその方向へ導く立場として話を進めます。ここでいう「決める」には、二つの作業が含まれます。選択肢を比べて推奨を出す作業と、その結果に承認を出す作業です。

書き手の見立てでは、組織の中ではこの二つが同じ人の手元に置かれます。比べた人がそのまま承認するので、どこまでが比較でどこからが承認なのかを、分けて話す機会はあまりありません。冒頭の「決めてください」に即答しかけたのは、この癖が自然に出たからだと読めます。

外から関わると変わる点

一方、業務委託で外から関わると、承認は発注者の側に残ります。選択肢を比べて推奨を出す作業は引き続きITアーキテクトの仕事ですが、承認は発注者の名前で行われます。「お任せします」と頼まれたとき、この境目を飛ばして渡されている可能性があります。

ただし、承認が発注者の側にあるからといって、ITアーキテクトの仕事が小さくなるわけではありません。判断の材料となる選択肢、比較の軸、推奨とその根拠を整える作業が、そのまま成果になります。承認する人が迷わず決められる状態をつくるのが、外から関わるITアーキテクトの役目です。

そのため、最初の打ち合わせで確かめたいのは、技術の好みよりも決め方です。誰が最終決定を出すのか、決める場はいつ開かれるのか、決定は誰の名前で記録に残るのか。この三つが分かれば、「お任せします」の中身が見えてきます。

図の作成：Remogu編集部。書き手の見立てを整理したもので、統計データではありません

次は、ITアーキテクトの役割がIPAの資料でどう書かれているかを見ます。

2. IPAの資料での役割の書かれ方

試験の対象者像に書かれた役割

先に呼び名を整えます。この記事は「ITアーキテクト」の語で話を進めますが、IPAの資料に出てくる名前は異なります。国家試験ではシステムアーキテクト試験、デジタルスキル標準ではビジネスアーキテクトなどのロールです。資料の呼称と記事の呼称が混ざらないよう、資料から引くときは資料の名前を使います。

IPAのシステムアーキテクト試験の案内は、対象者像を、ITストラテジストによる提案を受けて、システムの開発に必要となる要件を定義し、それを実現するためのアーキテクチャを設計し、開発を主導する者としています¹。戦略を提案するのは別の役割で、アーキテクトはその提案を受ける側に置かれています。ただし、これは国家試験の対象者像であり、職務の法的な定義ではありません。

業務委託で外から関わる場合も、読み方は同じです。提案を受けて設計し、開発を主導するという並びは、先に依頼の方向があり、設計はそれを受けて行う順番を示しています。受ける側に置かれた役割だと分かると、冒頭の場面で手が止まった理由を説明できます。

固有技術と専門家の支援

同じ案内の業務と役割では、ネットワーク、データベース、セキュリティなどの固有技術については、必要に応じて専門家の支援を受けるとしています¹。全体の設計を担う人が、あらゆる固有技術を一人で深く持つ前提では書かれていません。外から入るときに、固有技術の詳細まで背負う必要があるのかを考える材料になります。

この一文があるので、全体の構造は自分が見て、固有技術の詳細は専門家に任せる、と範囲を切り出す話ができます。ただし、資料が述べているのは試験の業務と役割の整理で、個別の案件の分担を決めるものではありません。分担は案件ごとに発注者と合意します。区切り方は第5節で扱います。

スキル一覧に出てくるアーキテクチャ設計

デジタルスキル標準 ver.2.0 のスキル一覧には、アーキテクチャ設計に関する項目の内訳として、全体最適を意識したアーキテクチャ原則の定義や、現行アーキテクチャの理解および問題整理が挙げられています²。どちらも、新しいものを選ぶ前に、全体と現状を見る作業です。

経歴書や面談で話す言葉の手がかりにはなります。一方で、これらはITアーキテクトに必須のスキルを定めたものではありません。スキルの一覧であって、案件の要件ではないからです。

資料ごとの書かれ方の比較

下の表は、ここで取り上げた三つの記述を並べたものです。システムアーキテクト試験の案内からは対象者像と固有技術の扱いを、デジタルスキル標準のスキル一覧からはアーキテクチャ設計の項目の内訳を取り上げています。いずれも試験の対象者像や学習項目に近い整理であり、職務の定義でも案件の要件でもありません。読み取れるのは、提案を受けて設計し、固有技術は専門家の支援を受ける形で、役割が書かれている点です。

項目	IPAの資料での書かれ方	どの資料か
対象者像	提案を受けて要件を定義し、アーキテクチャを設計し、開発を主導する者	システムアーキテクト試験の案内
固有技術	ネットワーク、データベース、セキュリティなどは、必要に応じて専門家の支援を受ける	システムアーキテクト試験の案内
アーキテクチャ設計の項目の内訳	全体最適を意識したアーキテクチャ原則の定義、現行アーキテクチャの理解と問題整理	デジタルスキル標準 ver.2.0 のスキル一覧

次は、意思決定を誰が担うのかに絞って、資料の書き方を見ます。

3. 意思決定を支援するという書かれ方

ビジネスアーキテクトの責務に書かれた意思決定の支援

デジタルスキル標準 ver.2.0 は、ビジネスアーキテクトの責務の一つとして、経営者の投資判断・意思決定の支援を行うことを挙げています²。これはITアーキテクトの定義ではありません。全体を設計する役割が、意思決定を「支援する」側として書かれている参照点として読みます。

この書き方に沿うと、設計する人は決める人の隣にいて、判断に必要な材料を渡す側に立ちます。組織の中のITアーキテクトが自分で決める場面を否定する資料ではありません。ただ、決める人と支える人が別にいる形が、標準の中に書かれていると分かります。

非機能要件の検討での分担

IPAの「情報システム・モデル取引・契約書」の講演資料は、要件定義での非機能要件の検討について、ユーザ（発注者）が十分に検討を行い、ベンダは専門家として必要な情報提供等を行って意思決定を積極的に支援すると整理しています³。これはモデル契約の考え方であり、法令の義務ではありません。

資料の主体はベンダで、個人のフリーランスやITアーキテクトを名指ししたものではありません。ベンダが専門家として支える構図を、外から関わるITアーキテクトに当てはめて読むのは、書き手の見立てです。それでも、決めるのは発注者、材料を出すのは専門家という分担の例として、参照できます。

図の作成：Remogu編集部。IPAの資料の記述をもとに役割の向きを整理したもので、統計データではありません

決定権が無いときの仕事

では、決定権が無いとき、ITアーキテクトの仕事は何になるのでしょうか。書き手の見立てでは、判断の材料を作る仕事になります。選択肢を並べ、比べる軸を決め、推奨とその根拠を渡す。承認する人が自分の言葉で決められる状態にするのが、成果です。

たとえば案が二つあるとき、「こちらにします」と決める代わりに、「どちらの案も実現できます。違いは運用の手間と変更のしやすさです。後者を重く見て、この案を推します」と示します。決める手前の作業を、発注者がそのまま使える形で渡す動きです。

次は、発注先の規模によって、引き受ける役割の数がどう変わるかを見ます。

4. 発注先の規模で変わる、引き受ける役割の数

ロールの想定規模

デジタルスキル標準 ver.2.0 のソフトウェアエンジニアの類型では、ロールの定義は、ソフトウェアエンジニアのチームを擁する規模の企業を想定しています²。そのうえで、これより小規模な企業では、定義した全てのロールを少数または一人のソフトウェアエンジニアが担うこともあると書かれています。

注意したいのは、この記述がソフトウェアエンジニアの類型のロールについてのもので、ITアーキテクトの役割の数を述べたものではない点です。そのまま当てはめず、役割が分担される規模と、少数の人に集まる規模があるという参照点として使います。

発注先の体制ごとの役割の持ち方

下の表は、発注先の体制ごとに、役割の持ち方と、外から入るときに起きやすいことを並べたものです。第2列は先に引いたデジタルスキル標準 ver.2.0 の記述に沿っています。第3列は、その記述をもとにした書き手の見立てで、資料が直接述べているわけではありません。発注先がどちらの体制にあたるかによって、打ち合わせで最初に聞く内容が変わります。

発注先の体制	役割の持ち方	外から入るときに起きやすいこと（書き手の見立て）
チームを擁する規模	ロールごとに分担される	決まった範囲を頼まれやすい
小規模	少数または一人が全てのロールを担うこともある	全体を丸ごと頼まれやすい

小さな発注先ほど全体を丸ごと頼まれやすい、という見立ては、資料の記述から導いたものです。頼まれ方が広いほど、最初に範囲を言葉にしておく価値が上がります。次は、その範囲をどこで区切るかです。

5. 引き受ける範囲の区切り方

全体設計で引き受ける範囲

全体設計を頼まれたとき、最初に決めたいのは、どこまでを自分の仕事として引き受けるかです。この記事の見立てでは、ITアーキテクトが外から引き受ける中心は、全体の構造、技術の選択肢と比較、設計レビューの三つです。

たとえば、全体の構造は図に描いて見せられます。技術の選択肢と比較は、軸をそろえた表にできます。設計レビューは、他の人が書いた設計への指摘として記録に残ります。三つとも、発注者が承認に使える形で成果を渡せる作業です。

専門家に任せる範囲

一方、固有技術の詳細は、同じ線の外側に置きます。IPAの案内は、ネットワーク、データベース、セキュリティなどの固有技術について、必要に応じて専門家の支援を受けるとしています¹。全体設計を受けても、これらの詳細まで一人で背負う前提にはしません。

ただし、任せるといっても、分からないまま手放すわけではありません。固有技術の専門家に何を頼むのか、その結果をどの判断に使うのかは、ITアーキテクトが全体の側から言葉にします。専門家の手配をどちらが持つかは、受ける前に発注者と決める項目です。

図の作成：Remogu編集部。IPAの案内の記述と書き手の見立てを整理したもので、統計データではありません

次は、範囲を区切ったうえで、受ける前に決めておく項目を整理します。

6. 準委任でも負う責任と、受ける前に決める項目

準委任でも残る責任

IPAの講演資料は、要件定義作業はユーザが行いベンダが支援する準委任契約を前提としつつ、準委任だからといってベンダが責任を一切負わないわけではなく、受任者として善管注意義務を負っていると解説しています³。主体はベンダで、これもモデル契約の考え方です。

決定権が無くても、支援の質には責任を負う。モデル契約の考え方として読むと、そうなります。責任の中身や期間は、資料の抜粋には書かれていないため、この記事でも扱いません。契約書の文言は、案件ごとに確かめます。

そのため、「決めるのは発注者だから、何を出しても責任は無い」とは読めません。材料の質が支援の質になるので、比較の軸が偏っていないか、根拠が残っているかが、仕事そのものです。成果物と検収、運用に入った後の責任は、別の記事で詳しく扱っています。

受ける前に決める項目の例

下の表は、受ける前に発注者と決めておきたい項目を並べたものです。資料が項目を定めているわけではなく、これまでの内容から書き手が整理した例です。どの項目も、決定権が発注者の側にある前提で、誰が何をいつまでに行うのかを明らかにする役目を持ちます。打ち合わせの議題として、そのまま使えます。

決めること	例
最終決定する人と承認の場	誰が承認し、どの会議や連絡手段で出すか
決める時点	どの工程までに結論が必要か
比較する選択肢の数と比較の軸	案をいくつ出し、何を基準に比べるか
推奨と根拠の残し方	文書の形式と、保管する場所
固有技術の専門家の手配	発注者とITアーキテクトのどちらが持つか
判断の記録の受け渡し先	決定の記録を誰に渡し、どこに残すか

次は、これまでの内容を一本の順番にまとめます。

7. 決める立場から支える立場へ移る順番

五つの順番

これまでの内容を順番に並べると、まず役割の確認、次に決定権の所在、範囲の区切り、責任の形、契約の順になります。どれかを飛ばすと、冒頭の場面のように、決める前提だけが先に進んでしまいます。

最初に確かめるのは役割です。発注者が頼んでいるのは、技術を決める人なのか、決められる状態をつくる人なのか。次に決定権の所在を聞き、承認が誰の名前で残るのかを確かめます。

三つ目は範囲です。全体の構造、技術の選択肢と比較、設計レビューを引き受け、固有技術の詳細は専門家に任せます。四つ目の責任の形では、支援の質に責任を負う前提で、材料と根拠の残し方を決めます。最後に、これらを契約に書き入れます。

図の作成：Remogu編集部。ここまでの内容を順番に整理したもので、統計データではありません

冒頭の場面に戻る

冒頭の打ち合わせに戻ります。「決めてください」と言われたとき、即答しなくて構いません。誰が承認し、誰の名前で残るのかを先に聞けば、そこから先の話は、選択肢と根拠をどう渡すかに移ります。

組織で技術を決めてきた経験は、外でも使えます。変わるのは使い方で、決めた結果を示す形から、決められるようにする材料を示す形へ移ります。

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。まず登録して、自分の経験に近い条件を確かめるところから始めてみましょう。

打ち合わせで言われた「決めてください」は、こう言い換えられます。ITアーキテクトの業務委託は、決めるのではなく、決められるようにします。

8. よくある質問

経歴書では、組織で技術を決めてきた経験をどう書けばよいですか

決めた結果だけでなく、比べた選択肢と根拠を書きます。何を選んだかより、何と何をどの軸で比べ、なぜその案を推したかのほうが、外から関わる仕事の材料と重なるからです。デジタルスキル標準のスキル一覧にある、全体最適を意識したアーキテクチャ原則の定義といった言葉は、書き方の手がかりになります²。資料の項目をそのまま並べず、自分が行った作業の言葉で書きます。

「最終判断も任せたい」と言われたらどうしますか

推奨は出し、承認は発注者の名前で記録に残します。モデル契約の考え方でも、ユーザが十分に検討を行い、ベンダは専門家として意思決定を積極的に支援すると整理されています³。判断を任されても、承認する人と記録の残し方を先に合意しておくと、後から誰の決定だったのかが分かります。

全体設計だけでなく実装まで頼まれたら受けてよいですか

受けられますが、範囲と責任の形を分けて合意します。発注先が小規模だと、定義した全てのロールを少数または一人が担うこともあります²。そのため、全体を丸ごと頼まれる場面は起きやすいと見ています。設計の範囲と実装の範囲を別々に書き出し、それぞれで何を引き受けるかを決めてから返事をします。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「システムアーキテクト試験」（2026年7月6日・2026年10月確認）
＊2 独立行政法人情報処理推進機構「デジタルスキル標準 ver.2.0」（2026年4月・2026年10月確認）
＊3 情報処理推進機構「システム開発の健全化に向けて」（2025年4月24日・2026年10月確認）