ひろゆき)Tweetはじめに前回、セミナーで「設計の効率化&品質向上のために3つのうちどれが一番大切か?」と質問をしたところ、圧倒的に「設計の標準化」に手を上げる人が多かったとお伝えしました。Deckを用いて、そもそも「なぜ標準化が必要なのか」というところから入ってみましょう。設計書の標準化が必要なのかこれ、逆に考えてみると分かりやすいようです。設計書が標準化されてないとどうなるでしょうか。システムエンジニアは、いちいち「どのような設計書が良いのか」を考えながら仕様を書き込む必要が生じます。場合によってはプログラマーがプログラミングをするのに必要な情報が漏れていることもあるでしょう。設計書を資産として捉えたとしても、システムごとにバラバラの設計書だったら、保守・運用の担当者が読み解くのも大変です。考えると、設計書を標準化することで図1のような効果があることが分かります。標準化するのは設計書だけとは限りません。目を少し遠ざけてシステム開発全体の標準化を考えてみましょう。すると、標準化すべきドキュメントとして図2のような対象が浮かび上がってきます。これらの資料を目的別に整理すると、大きく「プロセスの標準化」と「ドキュメント(成果物)の標準化」に分けられます。Structure)の標準や見積基準など、主にプロジェクト管理関連です。当社では第2回で紹介した「PYRAMID」という標準テンプレートを経て、現在は統合型プロジェクト管理システム(OBPM)を使うことで標準化を実現しています。ドキュメント(成果物)の標準化は、設計書やテスト仕様書、コーディング規約などが対象です。当社では「DUNGEON」という標準テンプレートを経て、システム開発用CADツール(OBDZ)を使うことで、機能設計書などの標準化を実現しています。図2:システム開発の標準化対象システム開発のドキュメントフローここではプロジェクト管理関連は対象外として、ドキュメント(成果物)の標準化を取り上げてみましょう。おけるドキュメントフローです。この図を基に、どのようなドキュメントが必要とされるかを説明します。要件定義書これを読めば、どのような目的でどのようなシステムを作ろうとしているのかがひと目でわかるものです。be)を作るか、それに必要なコストとスケジュール、得られる効果など、プロジェクトのゴーサインを出すために必要な情報がまとまっています。ユースケース図システムを利用する人(アクター)が、どのようにシステムに関わるか(ユースケース)をシンプルに図示したものです。図4は当社のプログラミングスキル判定サービス「TOPSIC」を用いて、中途採用のスキル判定を行うユースケース図です。当社(SI)の管理者が問題を作成し、ユーザー企業の管理者が問題を選んで、応募者を登録すれば準備OK。あとは応募者が受験して、ユーザー管理者がその結果を確認する。いうようにシステム利用者の役割と関わりがひと目で分かります。図4:ユースケース図(TOPSICの採用スクリーニング)(3)業務フローユースケース図は、基本的に時間の流れを表現しにくいので、複数の部門にまたがって業務処理を行う基幹業務システムなどでは業務フローを作成します。図5は見積・受注の業務フローを表したものですが、この図を上から下に読むだけでユーザーから見積依頼を受けて受注に至るまでの業務処理の流れがぱっと理解できます。図5:業務フロー図<<麻里ちゃんの設計奮闘記>>UMLって何?麻里:先輩、UMLって知っていますか?先輩:もちろん。Languageのことで、日本語だと統一モデリング言語などと訳されている。麻里:それってどういうものなんですか?先輩:システムをモデリング(モデル化)するためのドキュメント標準かな。ドキュメントの種類(ダイアグラム:図法)が13種類もあるんだけど、通常、目的に応じて使い分けているよ。麻里:全部、使うってわけじゃないのね。先輩:よく使うのは、ユースケース図とクラス図かな。時間の流れを表現できる図法としてシーケンス図なんかもわりと使われているよ。麻里:うちの会社ではあまり見かけませんね。ひと言でいうと文化かな。専門的な記述になるから、お客様が記述ルールを覚えて理解するのがちょっと難しい。お客様が直感的に理解しやすい業務フローや画面遷移図などを使う人が多いみたいだね。麻里:部門によっても文化の違いがあるみたいですね。ERP部は複数部門に処理がまたがる基幹業務システムだから業務フローを非常に重要視しているけど、画面遷移図は書いてないことが多い。eコマース部はECサイトを作るときに画面遷移図を重要視しているけど、業務フローはそれほどでもないみたいだよ。麻里:構築するシステムの特性によって、作成するドキュメントの優先順位が変わるのね。先輩:ま、誰と食事するかによって、レストランのチョイスを変えるのと一緒かな。麻里:そんなこと言って、先輩は誰と一緒でも、いつも同じ居酒屋ですよね。先輩:「誰とでも平等に接する」を旨としているからね(実は下心をカモフラージュする戦略なんだけど)!(4)画面遷移図どの画面からどの画面へ切り替わるかをビジュアル化したものです。図6はゲームをしながら花の名前を覚えてゆく無料アプリ「花の名前ダウト」の画面遷移図です。Web系のシステムでは、このような画面遷移図を作ることにより、ユーザーを迷子にさせない導線、セキュアな画面とオープンな画面の境界を理解するなどの目的に役立てることが多いです。Approach)」があります。これ、実は概念が流行らなくなったわけではなく、ただ単に当たり前過ぎて今さら言うまでもなくなっただけなのです。今も重要性は全く変わらないのですが、ふと「ひょっとして若いエンジニアは知らないかも」と老婆心が芽生えたので、コラムで取り上げてみます。Approach)です。いう単位でシステム化を図るアプローチです。業務ごとに考えれば良いので分かりやすい手法ですが、業務ごとに別個のシステムとなりやすく、データの重複や不必要なデータのやり取りが増えるといった問題がありました。一方で、データ中心設計(DOA)は、まず、データをどのように持つかを考えることを重視します。)するかという観点で捉えられます。通常の業務フローではデータの図は含みませんが、私は図5ように見積データや注文データなどのデータも書き込んでいます。この方がデータを意識したシステム設計がしやすいと感じているからです。業務フローを書いてからデータベース設計を行うのが一般的ですが、私の場合は業務フローと並行してERツールを使い、データベース設計も同時に行っています。データ構造はシステムの骨組みとも言えます。一般に業務は変更になることが多いですが、骨組みさえしっかり作っておけば、システム全体を大きく変更させる必要は生じません。データ中心設計できれいな骨組みを作ることで、業務の変更にも強いシステムを作ることができるのです。おわりに今回は、システム開発で作成されるドキュメントの中から、要件定義書、ユースケース図、業務フロー、画面遷移図など、主に要件定義工程で必要となるドキュメントについて説明しました。次回はデータ中心設計(DOA)に基づいたデータモデリングについて解説します。Browser」を開発・リリース。Designer」など、独創的なアイデアの製品を次々とリリース。最近は、AIを利用したサービスに取り組んでいる。ITの連載をまとめた「これからのSIerの話をしよう」「エンジニアなら知っておきたいAIのキホン」を刊行。「日本のITの近代化」と「日本のITを世界に」の2つのテーマをライフワークに掲げている。ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。VeloCloudが選ばれる理由SD-WANとはなにか。Linuxエンジニア育成への思いF5とNGINXの組み合わせで、サービス公開をよりセキュアに。ITがお届けするポッドキャストです。