LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

外部の専門家に設計レビューに入ってもらってから、設計書の質は上がった。けれども、専門家が来ない週はレビューが止まり、何を基準に見ればよいのか社員は今もはっきり言えない——。内製化支援を受けている開発の現場では、こうした状態が起こりがちです。内製化支援の伴走で行う設計レビューとは、社員が書いた設計書を外部の専門家と一緒に見直しながら、誤りを見つけるだけでなく、見直し方そのものを社員に移していく進め方を指します。

ただし万能ではなく、レビューの場だけで設計の経験が身につくわけではありません。本記事では、開発の現場を預かるマネージャーに向けて、社員に任せる決めごと、観点の分け方、問いで返すレビュー、専門家の手を引く4つの段階を整理します。

内製化支援の伴走で行う設計レビューとは

設計レビューに外部の専門家を招く目的は2つあります。いま作っている設計書の誤りを見つけることと、社員だけでも同じ水準のレビューをできるようにすることです。内製化支援の伴走では、後者が本来の目的になります。

2つの目的は同じ会議の中でぶつかりがちです。専門家が直し方まで示せば、その回の設計書は良くなります。しかし社員の手元に残るのは指摘の一覧だけで、なぜその観点で見たのかは残りません。伴走の設計レビューでは、回を重ねるごとに後者へ比重を移していきます。

進め方の手がかりとして、本記事では情報処理推進機構（IPA）が公表している情報処理技術者試験のシラバスを使います。シラバスは試験で問う知識と技能を細かく並べた文書で、IPAは受験者の学習の指針としてだけでなく、「企業，学校の教育プロセスにおける指導指針として」役立つことを期待するとしています。^*1 ここでは応用情報技術者試験（レベル3）とシステムアーキテクト試験（レベル4）の2つを見ていきます。

なお、内製化支援でどこまでの範囲をどれだけの期間支援するかは、支援する会社と契約によって異なります。伴走を受けたからといって、社員だけで設計を回せるようになることが約束されるわけでもありません。

レビューの手順と社員に任せる決めごと

応用情報技術者試験のシラバスは、開発技術の「設計」の中にレビューの項目を置いています。そこでは、レビューは「文書の作成，レビューの実施（レビュー方式の決定，レビューの評価基準の決定，レビュー参加者の選出），レビュー結果の文書への反映作業という手順で行われる」と整理されています。^*1 設計書を書くこと、レビューをすること、指摘を設計書に反映することの3つの段に分かれ、真ん中の段の中に3つの決めごとが入っている形です。

伴走で見落とされやすいのが、この3つの決めごとです。どの形式で、何を基準に、誰を呼んで見るかを専門家が決めてしまうと、社員はレビューを受ける側にとどまり、レビューを組み立てる力が育ちません。専門家が来ない週にレビューが止まるのは、この3つを社員が持っていないからです。

シラバスはレビューの種類として、ピアレビュー、デザインレビュー、インスペクション、モデレーター、ウォークスルー、共同レビューといった用語を挙げています。^*1 一般に、ウォークスルーは作成者が中身を説明しながら参加者と一緒にたどる形、インスペクションはモデレーター（進行役）が仕切り、決めた観点に沿って点検する形を指します。伴走の初めはウォークスルーで社員に説明させ、慣れてきたら社員がモデレーターを務めるインスペクションへ移ると、方式を選ぶ経験も一緒に積めます。

妥当性評価の13項目を分担する

評価基準を社員が作るとき、出発点になるのがシラバスの「妥当性評価の項目」です。レビューで確かめる項目の例として、機能、性能、容量・能力、信頼性、操作性、安定性、運用の容易性、技術的整合性、合目的性、実現可能性、開発の合理性、経済性、投資効果の13が並んでいます。^*1 設計レビューの観点を一から考えなくても、この13項目のどれを今回の設計書で重く見るかを選べば、評価基準の骨組みができます。

13項目を最初から全部社員に任せる必要はありません。業務を知る社員が判断しやすい項目と、技術の経験がものを言う項目があるからです。初めは先に見る側を分けておき、専門家の側の項目を少しずつ社員へ移します。

専門家が先に見る項目でも、社員を聞き役にとどめないのが要点です。性能の懸念を挙げたら、どの数字を見てそう考えたのかまで記録に書いてもらいます。次の回は同じ項目を社員が先に見て、専門家は答え合わせに回ります。

方式設計の評価基準を問いに変える

もう一段具体的な物差しが、システムアーキテクト試験のシラバスにあります。ソフトウェア方式設計の評価の項目では、方式、インタフェース設計、データベース設計を評価するときに考慮する基準として、要件への追跡可能性、要件との外部一貫性、ソフトウェアコンポーネント間の内部一貫性、使用している設計方法及び作業標準の適切さ、詳細設計の実現可能性、運用及び保守の実現可能性の6つを挙げ、評価結果を文書化するとしています。^*2

伴走の設計レビューでは、この6つの基準を専門家が指摘として使うのではなく、社員への問いに言い換えて使います。指摘として「この画面の要件が設計に反映されていません」と伝えると、社員はそこを直して終わります。問いとして「この要件は設計書のどこで満たしていますか」と聞くと、社員は要件と設計を自分で突き合わせることになり、次の設計書では聞かれる前に確かめるようになります。

問いで返すと、社員が考えるのを待つぶん時間がかかります。問いを事前に設計書のコメントで渡し、会議は社員の答えを聞くところから始めると進めやすくなります。表記の揺れのような軽い誤りは、直接指摘して構いません。

共同レビューで社員が身につける力

システムアーキテクト試験のシラバスは、ソフトウェア方式設計の共同レビューの実施に要る技能として、レビューを実施する能力、レビューに適するコミュニケーション方法を選んで効果的に進める能力に加えて、「ソフトウェアコンポーネントの設計論理を説明する能力」「異なる意見を適切に評価する能力」「代替案を提示する能力」を挙げています。^*2 伴走の設計レビューで社員に身につけてほしい力は、ほぼこの3つに重なります。

設計論理を説明する力は、レビューの冒頭で社員に設計の考え方を話してもらうことで鍛えられます。専門家はそれを聞いてから問いを返します。説明に詰まったところは、たいてい設計書でも書き込みが足りない箇所です。

異なる意見を評価する力は、専門家の指摘を社員がそのまま受け入れないことから育ちます。指摘のたびに、採るか採らないかを社員が決め、その理由を記録に書きます。予算や納期の事情で採らない判断もありえます。その場合は、どんな危険を引き受けたのかも書いておきます。

代替案を出す力は、設計書に案を1つしか書かない習慣を変えることで伸びます。主要な方式を決める箇所では、社員に2つ以上の案と、それぞれを比べた結果を書いてもらい、専門家はその比べ方を見ます。同じシラバスは、データベースの最上位レベルの設計に要る技能として、「必要に応じて専門家の支援を受けながら」設計を円滑に進める能力を挙げています。^*2 設計を主導する立場でも専門家の手を借りること自体は想定されており、伴走が目指すのは専門家に頼らない状態というより、何をいつ頼むかを社員が決められる状態だと考えられます。

専門家の手を引く4つの段階

専門家の関わり方は、4つの段階で減らしていきます。各段階で何回レビューを行うかはシラバスに定めがなく、設計書の大きさや社員の経験で変わります。

段階1は、専門家が進行役を務める段階です。レビュー方式と評価基準は専門家が決めますが、社員は設計書を書き、レビューでは自分の言葉で説明します。専門家の指摘には理由を添えてもらい、記録に残します。段階2では、方式、評価基準、参加者を社員が決め、進行も社員が務めます。専門家は答えでなく問いを返し、社員が見落とした観点を会議の最後に補います。

段階3では、レビューを社員だけで行います。専門家は後から記録を読み、指摘を採らなかった理由に無理がないか、見落とした観点がないかを書面で返します。段階4は、ふだんのレビューを社員が回し、性能や信頼性のように社内に経験の少ない観点が絡む設計のときだけ専門家に相談する段階です。

次の段階へ進むかどうかは、期間ではなくレビューの記録で決めます。見るのは2点です。1つは、専門家が後から足した指摘が回を追って減っているか。もう1つは、社員が指摘ごとに採否とその理由を書けているかです。指摘が減っていても理由の欄が空いたままなら、専門家の判断をなぞっているだけかもしれません。追加の指摘が増えたら、1つ前の段階に戻すのも一つの選択です。

つまずきやすい点

一つめは、専門家が設計書を直接書き直してしまうことです。急ぐ案件ほど起こりがちですが、書き直された箇所は社員が説明できない部分として残ります。直すのは社員、専門家は直し方を問う、という分担を最初に申し合わせておきます。

二つめは、指摘の一覧だけが残り、採否の理由が残らないことです。シラバスがレビューの手順の最後に置いているのは、レビュー結果の文書への反映作業です。^*1 反映したかどうかだけでなく、反映しなかった指摘とその理由まで残しておかないと、社員だけでレビューしたときに同じ議論を一からやり直すことになります。

三つめは、レビューに出る社員が1人に偏ることです。参加者の選出を社員に任せても、毎回同じ人が出ていれば、その人が異動したときに伴走の成果がまとめて抜けます。設計書の作成者とモデレーターを持ち回りにすると、レビューを組み立てる経験が複数の社員に広がります。

外部に委託するときに確認しておきたい点

伴走の設計レビューを外部に頼む前に、契約や打ち合わせで確かめておきたいことがあります。専門家が指摘を答えで返すのか問いで返すのか、レビューの進行役をいつ社員に渡すのか、記録の様式は誰が用意するのか、次の段階へ進むかを誰がどの記録で決めるのか、の4点です。支援の範囲と期間は会社と契約によって違うので、書面で確かめます。

発注側が基本設計書を要件と突き合わせるときの観点は外部エンジニアの技術レビュー・設計レビューで要件の漏れを防ぐで扱っています。

研修と伴走の違いは内製化支援の選定と育成方法、研修と伴走の違いを比べるにまとめました。

支援を終える時期の見極め方は内製化支援から自走へ、自走化判断で確かめる3つの基準で整理しています。

まとめ：伴走の設計レビューで確かめる3つの点

内製化支援の伴走で設計レビューを進めるうえで、確かめておきたい点は3つに整理できます。第一に、レビュー方式、評価基準、参加者を決める役を、早い時期から社員に持たせること。第二に、外部の専門家は誤りを直す代わりに問いを返し、指摘を採るかどうかの判断とその理由を社員が記録に残すこと。第三に、専門家の関わりを進行役、補う役、事後の確認、難所の相談と段階を追って減らし、進めるかどうかを期間ではなく記録で決めることです。この3点を踏まえておけば、「専門家が来ない週はレビューが止まる」という状態から抜け出しやすくなります。設計を担う社員の層が薄いときは、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：情報処理推進機構（IPA）「応用情報技術者試験（レベル3）シラバス Ver.7.2」（PDF）（https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf）。出典：はじめに、大分類4「開発技術」中分類12「システム開発技術」2.設計（15）レビュー ①レビューの目的と手順・②レビューの対象と種類・③妥当性評価の項目を参照（確認日2026年10月6日）（2026年10月確認）
2. *2　参考：情報処理推進機構（IPA）「システムアーキテクト試験（レベル4）シラバス Ver.5.2」（PDF）（https://www.ipa.go.jp/shiken/syllabus/nq6ept00000014gx-att/syllabus_sa_ver5_2.pdf）。出典：10「ソフトウェア方式設計」の10-3（データベースの最上位レベルの設計）、10-5（ソフトウェア方式設計の評価）、10-6（ソフトウェア方式設計の共同レビューの実施）を参照（確認日2026年10月6日）（2026年10月確認）

Tweet