情報システムの構築で作成する「設計書」が様変わりしている。業務フローやデータ定義書、画面遷移図といった従来の設計書の書き方では、業務部門を加えた多くの関係者が理解しにくい上に、頻繁に発生する変更にも対応しづらいからだ。
そんな中、現場の技術者が工夫して新たな設計書を作り上げる動きが出てきた。この特集では、その中から「すごい設計書」と呼べる事例を実際のサンプルとともに紹介しよう。
情報システムの構築で作成する「設計書」が様変わりしている。業務フローやデータ定義書、画面遷移図といった従来の設計書の書き方では、業務部門を加えた多くの関係者が理解しにくい上に、頻繁に発生する変更にも対応しづらいからだ。
そんな中、現場の技術者が工夫して新たな設計書を作り上げる動きが出てきた。この特集では、その中から「すごい設計書」と呼べる事例を実際のサンプルとともに紹介しよう。
富士通
合意した仕様通りにシステムを構築したにも関わらず、ユーザーに「思っていたのと違う」と突き返される。そんな失敗プロジェクトは枚挙にいとまがない。富士通の岡田一志氏(SI技術本部 技術戦略統括部)はその原因を「ユーザーの『価値基準』が抜け落ちてしまうからだ」と指摘する。
NTTデータ
NTTデータの村瀬全紀氏らはNoSQLデータベース製品「MarkLogic」を活用するにあたり、エクセルを駆使して設計書そのものを自動化ツールとした。NoSQLの特徴を生かしつつ、エンジニアにとって使い勝手の良い設計書を目指す。
豆蔵
システム開発は旅――。複数の企業や部署がかかわり、それぞれ異なる役割を果たしながら要件定義や設計、実装・テストといった工程が進んでいく様子を表した例えである。上流工程と下流工程、発注側と受注側が互いにプロジェクトの全体像を把握して共通認識を持つ。そんな開発は理想である。
ラック
セキュリティ対策を設計書に落とし込めている開発現場は少ない。個々の脅威への対策を記述してもシステム全体を守れているのか判断しにくいし、あらゆる脅威の対策を盛り込むと読みにくくなる。ラックの永井英徳氏は3つのドキュメントを組み合わせ、網羅性と分かりやすさを両立した。
楽天カード
楽天カードは2014年以降、開発スピードの向上やメンバーとのコミュニケーションを円滑にする狙いで、設計書の改良を重ねてきた。その結果、13カ国のメンバー全員に意図が伝わり、開発生産性を20倍に高めたビジュアル設計書を作り上げた。