TL;DR

応用情報試験まであと1ヶ月頑張りましょうね。

「共通フレーム」ってほんまに要るん？

と思いませんか？

「IPA資格試験では必須の知識なのに、実際に現場で使われているの見たことねえぞ…」という同志がいらっしゃりましたらぜひ一緒に考えていただきたいです。

そんな共通フレームの内容や実用性について、色々と考えてみます。

共通フレームの概要

まずおさらいしておくと、共通フレームとは、、、

■共通フレームとは
ソフトウェアの構想から開発、運用、保守、廃棄に至るまでのライフサイクルを通じて必要な作業項目、役割等を包括的に規定した共通の枠組み。
何を実施するべきかが記述されている、「ＩＴシステム開発の作業規定」である。

■目的は日本において、ソフトウェア開発に関係する人々（利害関係者）が、「同じ言葉で話す」ことが出来るようにするため。

＊以下からの内容はすべて上記「共通フレーム２０１３の概説」独立行政法人情報処理推進機構(IPA)から引用しています。

一言で言うと。

共通フレームを一言で表すなら、

「IT開発現場の共通言語・共通認識のための枠組み」

です。

発注側と受注側が「同じ言葉で会話できる」ようにするための共通の土台といえるでしょう。
例えば「要件定義」という言葉一つとっても、会社や担当者によって範囲や内容の解釈が異なることがあります。そんな混乱を防ぐための「標準用語集+作業工程表」と考えるとわかりやすいかもしれません。

4つの構造

共通フレームは主に4つの構造から成り立っています。

1.プロセス
システム開発作業を役割の観点でまとめたもの。

2.アクティビティ
相関の強いタスクをまとめたタスクの集合のこと

3.タスク
アクティビティを構成する個々の作業のこと

4.注記
タスクを構成する要素のこと。

これらの階層構造によって、開発工程を詳細に定義・管理できるようになっています。

（私は普段注記という言葉を全然使わないのですが、結構大事な言葉なんですね）

プロセス一覧

システム開発作業を役割の観点でまとめた「システム」がこちら。

たくさんあります。
文字にする気が起きないな…。そこに愛はあるんかと突っ込みたくなる瞬間。
幾何的な意味とかあるんかな…。

日本独自性

共通フレームは、国際標準であるISO/IEC 12207:2008に基づいて作成されています。
ただし、特徴としてはその日本独自の視点と背景が挙げられます。

欧米のソフトウェア開発標準が主にグローバル企業内での開発管理を想定しているのに対し、共通フレームは日本特有の「多重下請け構造」や「協力会社間の連携」を前提に設計されています。（これはこれできっと一大テーマで語れる所かと思います。）

特に、発注者と受注者の役割分担、責任範囲の明確化、そして企業間の「すり合わせ」を重視する点は日本のビジネス文化を色濃く反映しています。
また、日本語による統一された用語定義を提供することで、国内IT業界における言語の壁を解消し、「阿吽の呼吸」に頼りがちな曖昧なコミュニケーションを改善する狙いもあります。

この日本の商習慣と開発文化に根ざしたアプローチは、グローバルスタンダードをそのまま適用するだけでは解決できない国内IT業界特有の課題に対応するための工夫と言えるでしょう。

原理原則一覧

以下は、IPAの共通フレームに関する原理原則の表に「関西弁でわかりやすく言い換えた内容」を追加したものです。

原理原則番号	原理原則内容	わかりやすく言い換えた内容（関西弁）
原理原則【１】	ユーザとベンダの想いは相反する	ユーザーの思いと、開発側の考え方はだいぶ違うことが多いんやで。
原理原則【２】	取り決めは合意と承認によって成り立つ	何か決めるときは、みんなで合意して確認しないとあかんねん。
原理原則【３】	プロジェクトの成否を左右する要件確定の先送りは厳禁である	必要なことが決まらんと、プロジェクトがうまく進まんから先延ばしにしたらあかんで。
原理原則【４】	ステークホルダ間の合意を得ないまま、次工程に入らない	みんなの合意を取らんと、次に進んだらあかんで。
原理原則【５】	多段階の見積りは双方のリスクを低減する	見積もりは一回きりじゃなくて、段階を踏んだほうがリスクが減るんやで。
原理原則【６】	システム化実現の費用はソフトウェア開発だけではない	システム作るお金はソフトだけやなくて、いろんなところにかかるんやで。
原理原則【７】	ライフサイクルコストを重視する	システムのコストは長い目で見たほうがいいってことやねん。
原理原則【８】	システム化方針・狙いの周知徹底が成功の鍵となる	みんながシステムの目的や狙いをよー理解しておくことが、成功のカギやで。
原理原則【９】	要件定義は発注者の責任である	必要なことを決めるのは、依頼する側の責任やからね。
原理原則【１０】	要件定義書はバイブルであり、事あらばここへ立ち返るもの	要件定義書は、システム開発の大事な基礎やから、困った時はまずここを見ろってことやな。
原理原則【１１】	優れた要件定義書とはシステム開発を精緻にあらわしたもの	いい要件定義書は、システム開発に必要なことがちゃんと書かれてるもんやね。
原理原則【１２】	表現されない要件はシステムとして実現されない	ちゃんと書かれてない要件は、システムには反映されんねん。
原理原則【１３】	数値化されない要件は人によって基準が異なる	数字で表せへん要件は、人によって考え方がバラバラやから注意やで。
原理原則【１４】	「今と同じ」という要件定義はありえない	「今と同じ」って要件は絶対にないから、常に改善が求められるんやで。
原理原則【１５】	要件定義は「使える」業務システムを定義すること	要件定義は、実際に役立つシステムを作るために必要なことを決めるってことやな。
原理原則【１６】	機能要求は膨張する。コスト、納期が抑制する	要求される機能はどんどん増えるけど、コストと納期には限界があるから注意やね。
原理原則【１７】	要件定義は説明責任を伴う	要件定義は、しっかりと説明して納得してもらわんとあかんで。

ふと抱いてしまう疑問

PM見習いの立場のくせに、いやPM見習いの立場だからこそ、
「これって本当に現場で活きているの？」
という疑問がわいてきます。

共通フレームの大まかな概念はわかるけど、その膨大な規定が実際のプロジェクトでどう活用されているのか、リアルな現場感が見えにくいんですよね。
特に新しい開発手法やアジャイル開発が広まる中で、2013年に策定されてから変更がないこの枠組みはどのように現場に適応しているのか気になります。
時代の変化と共に進化する柔軟さはあるのでしょうか？

なぜ必要？？？

日本のIT業界では、受発注の関係が複雑で多重構造になっていることが多いです。元請け、下請け、孫請けと言ったピラミッド構造の中で、同じ言葉を使っても互いの解釈が異なることでトラブルが発生しやすい環境があります。

共通フレームは、こうした「言葉の解釈の違い」によるトラブルを減らし、スムーズな連携を可能にするために作られました。特に契約の場面では、作業範囲や納品物の定義を明確にする助けになるはずです。

…はい。一旦書いてみました。

PMBOKとは違うん？？？

共通フレームとPMBOK（Project Management Body of Knowledge）は似ているようで異なるものです。

PMBOK：プロジェクト管理の知識体系で、グローバルスタンダード
共通フレーム：日本のIT業界特有の事情に合わせた、ソフトウェア開発特化の枠組み

PMBOKが「どうプロジェクトを管理するか」に焦点を当てているのに対し、共通フレームは「ソフトウェア開発の各工程で何をすべきか」という点に重きを置いています。

2013年から更新してないけど、必要ないん？？？

これが1番の疑問でした。
上記IPAの資料にも、
「ISO/IEC 12207と整合性が取れていること」「国内と国際基準の変化に合わせて対応していること」などは記載されています。

また、日本国内では、ISO/IEC 12207やJIS X 0160の改訂があったとしても、共通フレーム自体がそのまま適用できる範囲は広く、直接的な更新が必要ない場合もあります。

以上の通り、現在の共通フレーム2013は"基本的には"有効ですが、
ただ今後のソフトウェア開発における新しい技術や手法への対応が求められる場合は定期的な見直しや新しいフレームワークの導入が必要になることもあると思っています。

共通フレーム2013はウォーターフォール型開発に重点を置いていますが、アジャイル開発などの新しい手法が反映されていないことは問題となる可能性があります。

特に生成AIのサービス開発戦争時代が勃発している今、ソフトウェア開発の現場でのニーズや技術の進展はめちゃくちゃ早いので、共通フレームがそれらの変化に対応しきれていない場合があり、その場合は新しいフレームワークの導入が検討されるべきではないでしょうか。

ここからもっと本音。

大事なんやろけど…実用性あるんかな。

IPA様様は共通フレームについて熱心に推進しており、以下のような利点を挙げています。

発注者と受注者間のコミュニケーション円滑化
開発プロセスの可視化と標準化
品質向上と生産性向上への貢献
契約トラブルの予防
業界全体の成熟度向上

こうした理念は素晴らしいですが、実際にどこまで浸透しているかは別問題かもしれません。
実際の現場でも「共通フレームに則って」と明示的に言及されることは未だ一度も見たことがありません。

SNSやネットもリサーチしたのですが、現状としては多くの企業で、

自社開発Metodologyがある
スクラムなどのアジャイル手法を採用している
独自の開発プロセスを持っている

という状況が多いと思います。

まぁ、でも多分大事。

しかし、共通フレームの「考え方」自体は、知らず知らずのうちに現場のプロセスに取り入れられているケースが多いです。
特に大規模な発注・受注の関係では、その基本概念が役立っていることも事実です。

実務では明示的に言及されなくても、「ウォーターフォール開発の工程の考え方」や「各工程での成果物の定義」などは、共通フレームの影響を受けているといえるでしょう。

特に以下のような場面では、価値が発揮されているのかと思います。

複数の企業が関わる大規模プロジェクト
発注者が IT に詳しくない場合の共通理解の土台
契約トラブルを未然に防ぐための作業範囲の明確化
新人エンジニアへの教育・指導の基準

「暗黙知」になりがちな開発プロセスの知識を「形式知」として蓄積・共有できる点は、業界全体の底上げにつながる可能性がありますね、多分。

ほんなら資料をもっと見やすくして欲しい。

今ある資料がですね。古いとはいえ、、、

文字ばっかり。読みやすさ皆無。
2007との差異に注目しすぎ。
長い。

もし共通フレームが本当に現場で活用されることを意図しているなら、資料の改善は急務だと思います。例えば、

図解やインフォグラフィックスの活用
実際の現場事例に基づく具体例の追加
短くわかりやすい概要版の作成
デジタル時代に合わせたインタラクティブな資料形式
アジャイル開発との関係性の明確化

などできる気がします。

また、応用情報などの過去問を解くとわかるのですが、共通フレームに関する問題すごい多いんですよね。となると、現実とのギャップがより大きくて、なんだか「資格試験のための形式化した知識」という印象が強いです。資格の価値を上げるためにも、もっとできることがある気がします。

まとめ

「共通フレーム」について、私の主観含めまとめると以下です。

実際の現場では「明示的に」言及されることは少ない。
しかし、その考え方や用語の標準化という意義は確かに存在する。
でも現代のソフトウェア開発に合わせアップデートが必要な箇所もある。
それに「読みやすさ・使いやすさ」の面で課題がある。
IPA資格試験では必須知識。

まあそんなん言うたらキリないやろって事実はあると思います。
つべこべ言わず勉強しろよと。はい、します。
同じく応用情報の勉強を頑張られている、皆さんどうですか？
「共通フレーム」という言葉を聞いたことがある方、実際に使っている方、息抜き程度にぜひコメントで教えてください。