Swebok（ソフトウェア工学体系知識体系）

今月はIEEEのソフトウェア工学体系知識体系（Software Engineering Book of Knowledge）の見直し月です。これは、資格のある専門職のための基盤を築く方法で、私たちの専門分野の知識体系を定義しようとする試みです。

通常であれば、このようなことは無視するでしょう。商業ソフトウェア開発に従事する人々によって日常的に無視されている、無数のIEEE規格が存在します。ほとんどは学者や大規模な政府プロジェクトに従事する人々によって書かれたものです。ビジネスマンは政府を効率性の同義語とは考えていません。

しかし、私はその判断を尊重するようになったCem Kanerは、それを真剣に受け止めています。彼のブログで彼は次のように述べています。「SWEBOKが資格試験の基礎となる場合、SWEBOKの実践は医療過誤訴訟の基礎として扱われます。SWEBOKで良い実践と呼ばれていることを行う人々は、医療過誤で訴えられた場合でも、法廷で自分の実践を弁護することができます。はるかに優れた実践かもしれないが、SWEBOKと矛盾する実践を採用する人々は、法廷で厳しい批判を受けるリスクを負います。資格試験の基礎として、SWEBOKは、資格のある専門職が得ることができる、承認された実践の公式声明に非常に近くなります。」

では、Swebokはどの程度欠陥があるのでしょうか？今月は私にとって忙しい月なので、詳細に検討する時間はありませんでした。いくつかのセクションを読むだけでも、いくつかの危険信号が上がり、Swebokがアジャイルアプローチを排除する程度まで、計画駆動型開発に過度に重点を置いているという見解を確認するのに十分です。

私が最初に見たセクションは、設計に関するセクションでした。明らかにSwebokは、設計をプログラミングとは別の活動と考えています。これは、アジャイル運動の私たちのほとんどとは反対の見解です。コーディングとテストへの入力として、非常に詳細なレベルの設計が必要であることを示唆していますが、実際にはどの程度の詳細であるべきかを知ることは不可能です。

選ばれた書籍はひどいものではありませんでしたが、GangOfFour（デザインパターン）が推奨リストに載っていないことに驚きました。（二次的な「さらに読む」には掲載されていますが、主要な「推奨参考文献」セクションには掲載されていません。）

プロセスのセクションは、測定に基づく制御の概念に大きく依存していましたが、これは私が生産性を測定できないことを観察しているので、深刻な欠陥があります。明らかに科学的管理の原則に基づいており、そのようにしてプロセスにおける人々と人間の相互作用の問題の役割を完全に無視しています。再び、個人と相互作用がプロセスよりも重要であるため、これは知識体系における大きな欠陥です。

要件のセクションは、開発に着手する前に包括的なシステム要件仕様書を作成することに重点を置いています。これも非常にウォーターフォール的な考え方です。（興味深いことに、スパイラルモデルの絵を示していますが、要件文書を作成するためだけです！）要件におけるコストのトレードオフを探るという感覚はありません。私の見解では、これはあらゆる要件作業の重要な要素です。

簡単なスキャンではこれだけです。将来さらに詳しく調べてみるかもしれません。しかし基本的に、私はCem Kanerに同意します。私たちの業界はまだこの種の知識体系を生み出すには十分に成熟していません。私たちはまだソフトウェア開発について多くのことを学んでおり、現在、いくつかの考え方が存在します。ソフトウェアエンジニアリングコミュニティには独自の意見があり、ソフトウェア開発の一部には適切かもしれませんが、まだ広範なコンセンサスはありません。

(さらなる解説については、ロバート・レヴィを参照してください。)