システム刷新に失敗する理由のひとつが、ユーザ企業が業者の設計スキルを吟味せずに一括請負契約を結んでしまう点にある。彼らに委託すると、実際には下請業者が設計していたりする。多くの業者が多かれ少なかれゼネコン化しているため、設計スキルが空洞化しているためだ。下請業者に的確な設計が出来ないとは限らないが、起用される設計者のスキルレベルを発注者がコントロールできないという意味で、リスクが大き過ぎる。 そもそも「システム刷新に失敗した」とはどういうことか。ユーザ企業自身が想定するコスト感やスピード感でシステムを改善・発展させられなくなっているのであれば、失敗したと判断していい。少しばかり改修しようとしても、無駄に複雑な設計を掌握している開発業者の意向に振り回される。そんな業務システムの命運は業者に握られていて、これはもう経営権の一部を奪われているのと変わらない。そんな事例は少なくない。 なぜそういう

はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する