)」は、そもそものプロジェクトの意味や目的を共有するのに有効で、プロジェクトの途中で振り返ったときも原点はなんだったかをハッと気づかされます。これを適用してみましょう。「我々は、なぜ設計書を作成するのか?」という問いになりますね。そうです、設計書の標準化を行うには、そもそも設計書を作成する意味や目的を明確にして共有する必要があるのです。, あなたが宝くじに当選して家を建てるとしましょう。「洋風のモダンな感じ」「子供も持ちたいので3階建て」「1部屋は和室も欲しい」など建築士に好みを伝えると、建築士はその要望に沿った家をイメージして設計してくれます。, ただ、口頭で希望を言ってお任せしただけでは、いざ出来上がったときに「え、全然イメージが違う!」となりかねません。建築士は、あなたの望みに沿った設計書を作成し、それを見てあなたも「ここはこう変更して」と具体的に指示する。そんなことを何回か繰り返して、ようやくあなたと建築士は完成イメージを共有できるわけです。, この完成イメージは、建築士だけでなく、棟梁以下大工さんや左官屋さん、内装屋さんにとっても重要です。彼らも彼らなりの裁量で作業するところもあるので、完成イメージを持たずに指示された通りをやるだけだと、どうしてもちぐはぐした家になってしまいます。, これはシステム開発でも同じです。顧客の要件を聞いてイメージできたとしても、それは顧客の思っているものとは違うかも知れません。そのため要件定義なら要件定義書、基本設計なら基本設計書、詳細設計なら詳細設計書、というようにドキュメントに起こして顧客に確認を取るのです。, 通常、顧客と設計ドキュメントを共有する(レビューミーティング)のは基本設計までで、詳細設計は“提出するので確認の上ご承認ください”というスタンスが多いようです。家を建てる際も同じで、コンセントの位置や電球の配置などが描かれた詳細な図面までは細かく説明しないことも多いです。, ただ、顧客側でそれをきちんと確認して「寝るとき電球を消せるように枕元にもスイッチが欲しい」「ドライヤーは左手に持つので、コンセントは左側に付けて」など細かなレベルで指示しないと、建った後で後悔する場面が出てきます。, 大工さんは、建築士の作成した詳細な設計図をもとに家を建てていきます。同じようにプログラマーは、システムエンジニアの書いた詳細設計書を見てプログラミングします。ここをクリックしたときにどのようなイベントが発生し、どのようなロジックで処理が行われるか、その記述があるからこそプログラマーは要求仕様通りのものを作ることができるのです。, 先ほど、顧客とのイメージ共有は基本設計レベルのことが多いと説明しましたが、プログラマーが必要とするのは詳細設計レベルです。つまり、基本設計書は顧客がイメージしやすいことを念頭に書き、詳細設計書はプログラマーが作業しやすいように配慮して書くことが肝要です。, システムを開発した人が、必ずしもそのシステムの保守や運用を行うとは限りません。通常は別の人が保守業務を担当しますが、もし、設計書がなければ、問い合わせ対応や障害調査、障害の修正に対応するためにソースコードを解析して理解するしかありません。, これは、第三者でなく本人が保守するときでも同じです。誰しも1年前、2年前に開発したシステムの内容はきちんと覚えていないので、やはり設計書がないと効率がぐっと落ちてしまいます。, 変更を依頼するユーザーからすると「なんでこんな軽微な変更にそんな工数がかかるの?」と疑問に思うのですが、まともな設計書がない状態では、軽微な変更でもどうしても膨大な時間を要します。新規開発時にメンバー全員がひたすらシステムに向き合っていたときとは違うのです。保守フェーズは、ともすると10倍、20倍も効率が落ちていたりもして、第1回で説明した「保守・運用にコストの7割がかかっている」という好ましくない状況の原因になっているのです。, もともと設計書を作らないアジャイル開発ならいざ知らず、きちんと設計書を作ったはずのウォーターフォールでも、とかく「設計書が古い」「あるけど信頼できない」となっています。新規開発に使われた設計書が保守運用の際は信用できないものになってしまい、結局、いちいちソースコードを解析する羽目になるのはなぜでしょう。この問題について少し考えてみます。, せっかく作った設計書が、保守運用の際に信用できなくて役に立たなくなる原因は、なんといってもシステム改修・変更の際に変更内容をきちんと設計書に反映しなかったことが原因です。一般に、システムが初期のままずっと使われることは稀です。通常は、障害(バグ)の対応、使いにくいところの改良、機能の向上、プラットフォームの世代進化への対応、ビジネスの変化への対応などにより、何度も何度も追加開発が行われます。, その全てをきちんと設計書に反映しておけば、設計書が信用できないなどという事態には陥りません。しかし、こうしたシステム変更においては、まず、プログラムを変更した後から設計書に反映するようなことも多く、初期のようにきちんと設計レビューをして記載洩れや記載ミスを防止するような慎重さはが薄れます。また、担当者も都度変わるので、一貫した設計品質を保つのがだんだん難しくなってきます。さらに、ちょっとでも手抜いたところがあれば、もはや次からは信頼されなくなるのです(人間の信頼関係に似ていますね)。, 人が歳を取るとあちこちガタが来るように、この経年劣化を防ぐことは不可能に思えますね。しかし、保守運用コストがこれほど膨大になっている現状を鑑みて、仕方がないとあきらめてしまうのは努力不足かも知れません。前向きな人が、若さを保つために健康な生活をして手入れを怠らない努力をするように、設計書を役立つもののままにすることを考えてみましょう。, システムの改修・変更作業は担当者任せにしがちです。なるほど、変更したソースを本番システムに適用する際は慎重にテストを行いますが、設計書への反映に関しては「設計書も直しといて」のひと言で終わりです。ともすると設計書を書いたことのないプログラマーが見よう見まねで設計書に反映することもあり、初期に決めた設計書記述レベルに至らないのです。, これを防止するには、システム改修の際も組織で「設計書の品質を保つ」という意識を共有することが大切です。その意識があれば、自然と複数メンバーで設計書の変更時にレビューを行うようになります。そして、ここが肝心なのですが、これをきちんとルール化して明文化し、どの時代でも守ってもらうようにするのです。, 改修・変更を行う際に大きな工数を取ってしまうのは、変更による影響範囲の調査にかかる時間です。「このテーブルに列を追加した場合はどこに影響するか」「このロジックを変更したらどこに影響するか」など、影響しそうなモジュール全部を洗い出して、1つずつソースコードをgrep検索したりして調査する必要があります。これだけでも大変なのに、漏れがあって思わぬところで不具合が生じ、さらに大きな工数がかかってしまうこともままあります。, この問題を解消するには、モジュールの関連が分かるように設計書を書いておく必要があります。ただし、これはかなり設計書のメンテナンスコストがかかるので、実質的に専用の設計ツールがないと難しいでしょう。ExcelやWordなどワープロ作業による設計書では実現不可能とも言えるので、みんなあきらめて勘で影響範囲の当たりを付けているのが実情です。実は私が設計書作成CADツール「Object Browser Designer」を作った理由の1つは、CADという現代的ツールによって、この課題を解決しようと考えたからなのです。, 通常、アジャイル開発では設計書を作りません。当社でもパッケージソフトやクラウドサービスのように「納期」や「コスト」より「売れるものを作る」が至上命題のものは、アジャイル開発を用いていますが、設計書は書いていません。, こうしたソフトウェア製品は長年に渡って改良し続け、バージョンアップを繰り返します。機能もどんどん増えて行くので、当初よりもプログラム数や内容が大きく増えることになります。, そこで徐々に顕在化する問題が保守コストの増大と機能変更時のコストアップです。前述の通り、設計書がないためちょっとした内容でも作業工数がかかり、それがビジネスのスピードとコストのネックとなったりします。, この状態を何とかする方法があることはあります。それは、アジャイル開発においてもシステムができた後から設計書をきちんと書くことです。ただし、前述の設計書を書く理由の1と2はほぼ役目を終えているので、3の効果しか望めません。設計書を書くには相応のコストがかかるので、その先の保守運用コストの低減に見合うかをビジネス的に判断することになります。, 当社の主力製品の1つにプロジェクト管理システム「Object Browser PM」があります。2008年にバージョン1をリリースしたこの製品が、最近、まさにそのような判断を迫られる状態でした。初期リリースから10年間ずっとアジャイル開発で機能アップを行ってきたのですが、今回のメジャーバージョンアップの際についに設計書を作成する決断をしました。AIを使ったリバースエンジニアリングで既存システムから設計データを生成し、それをObject Browser Designerで取り込んで設計書を作成したのです。それなりに工数はかかったのですが、設計書がある状態で大型バージョンアップ開発を行っているため生産性も高くなっています。この経験から、アジャイル開発でも後から設計書を起こすニーズは、これからますます高まっていくように感じています。. シーケンス図 そして、詳細設計フェーズでの成果物を詳細設計書と呼びます。 詳細設計書を書く際のコツ. ・モジュール構造図, アクティビティ図はフローチャートに似た図で、フローチャートがプログラムの流れのみを書くのに対して、ユーザーの操作とプログラムの動きの両方を書く。, ユーザーの操作を記載することで、どの処理がどのタイミングで動くのかが見えるようになる。, シーケンス図はアクティビティ図よりもシステム内部処理をさらに細かく記載した資料で、クラスやオブジェクト間のやりとりを時間軸に沿って表す。, 資料の使い方としては、アクティビティ図でざっくりと利用者と機能の流れを把握し、より詳細な処理を把握するためにシーケンス図を見る。, サンプルを見れば分かるように、縦軸が時間になっており、横軸がユーザーやシステム機能（オブジェクト）になる。, ユーザーからのアクションを受けて、オブジェクトがどのような情報を受け取り、次のオブジェクトにどのような情報を渡しているのかを矢印で表現する。, その他にも処理構造を表現するための記述があり、上記サンプルでは「loop」と「opt」が用いられている。, 「loop」とはその操作・処理が繰り返し行われることで、「opt」とは特定の条件を満たした場合に行われるもの。上記サンプルではloopで商品検索、optで商品詳細画面への遷移を表現している。, プログラミングする際の見取り図になり、作業の優先順位をつけたり、複数名で作業を分担する際に有効な資料。, なお、クラス図ではシステム構成を理解できるものの、処理の流れを把握するには前述のシーケンス図が必要となる。, アクティビティ図やシーケンス図からクラスを洗い出し、各クラスの関係性を考えながら親クラスを作ったり、集約や依存関係を書き出していく。, 処理機能記述は、機能の入力・処理・入力を記載したもの。入力=Input、処理=Process、出力=Outputの頭文字をとってIPOと呼ばれる。, 私の経験上、メインフレームのシステムでは処理機能記述が成果物として定義されていたが、Web系のシステムでは作成する機会は多くないように感じる。, 出力データを作成するために、入力データを用いて、どのような処理を行うかを記載する。, あまり細かく書きすぎると「ロジックを日本語に訳した資料」となってしまうため、処理の概要が理解できる程度で良い。, こちらもメインフレームで利用される資料で、COBOLなどのメインフレーム系の言語をコンパイルした後のモジュールのことを指す。, 各システム機能がどのようなモジュールによって構成されているかを表現したもので、ロジックの共通化による生産性の向上が期待できる。（ロジックが共通化されることで運用保守の生産性も上がる）, 機能を構成する処理を書き出し、処理の下位レベルにブレークダウンをしていきつつ共通化できる処理を考える。, なお、共通化する処理はメインモジュールから呼ばれるサブモジュールとなり、サブモジュールを作り出すことを「モジュール分割」と呼ぶ。, 上記サンプルで考えてみると、集約リストは「データ抽出・リスト発行・データ更新」の3つのモジュールから構成されていることが分かる。（それぞれの処理が開始・メイン・終了の処理を有している）, 冒頭に述べたように、プロジェクトによっては詳細設計書は必須ではありません。また、詳細設計書の定義も様々です。（クラス図だったり処理機能記述だったり）, プロジェクトの特性や開発を委託する企業との契約に応じて資料を作成することになると思います。, ただ念押ししたいのは、詳細設計書は不要であっても、詳細設計という作業自体は必要ということ。プロジェクトのQCD（品質・コスト・納期）に関わる問題になりかねないですし、運用保守の生産性の低下にも繋がってしまいますので。.
詳細設計とは、基本設計で決められた動きを「どうやって実現するか？」を説明した資料です。 そもそもシステム開発のライフサイクルは 要件定義→設計→製造→テスト→納品となっており、 設計フェーズは、要件定義と開発の間のフェーズとなります。 また、ひとことで設計といっても、基本設計、詳細設計に分けて設計されます。 基本設計は大まかな設計、詳細設計は細かい設計だと思っている人がいますが、それは誤りです。 基本設計と詳細設計は以下の点で異なります。 基本設計：システムを外か …
報告書とは、上司や関係者に必要な情報を提供するための文書のことです。３層構造（標題→内容要旨→詳細内容）で、情報の整理や要約をしていきます。例えば、日時、場所、目的、内容等について、情報を簡潔に記入します。 また、所感は記入する場合と、しない場合があります。その場の細かなニュアンスを伝えたほうが有効な場合には、所感も書くようにします。 【報告書（例）】 設計 1.1.
今回は、Inception Deckにならい、そもそもなぜ設計書を書くのかをテーマに解説しました。次回からは、多くの人が最も重要だと指摘する設計書の標準化について掘り下げていきます。お楽しみに! ©Copyright2020 若手プロマネの羅針盤.All Rights Reserved. ・処理機能記述書（IPO）
第一三共 インフルエンザワクチン 2020, エヴァ 最終回 意味不明, 日の出 山荘 プール, 4kテレビ 意味ない, ピクシブ イラスト投稿方法, 鍵付き リプ 表示, タンニン 色, 三浦 春 馬 ブログ 目の保養, ジゼル 雑誌 求人, 錦戸亮 DVD 内容, ご丁寧に説明いただきありがとうございます 英語, カヲル 壁紙 IPhone, イルローザ きめ つの や い ば, フォロー もしてないのにブロック, 細かい質問 英語, Twitter 旧バージョン 更新, パパドル 動画 5話, 鬼滅 最終回 気持ち 悪い, エヴァ 漫画全巻 新品, 繊細な 英語, 迂回 対義語, 急 が ば 源泉 白猫 宝箱, 錦戸亮 DVD 発売日, Twitter 異議申し立て 返信 英語, 柿タンニン 効果, 下町ロケット 真野 クズ, なんでもや 英語, Twitter 入力した単語の, ジェットマン 現在, 栗花落カナヲ 香水 レビュー, インフルエンザb型 2020 症状, プラダを着た悪魔 (吹替), Twitter 新 UI フォロワー数, 全 画面キャストを最適化, 奔走 類義語, イギリス 国旗 豆知識, 鬼 滅 の刃 カラス セリフ, 仮面ライダー1号 復帰, 碇シンジ育成計画 パトス編, わかり やすく 教え て 敬語, ブラッディメアリー 由来, エヴァンゲリオン 漫画 13巻 無料, インフルエンザウイルス 増殖, Twitter DM送れない 相互フォロー, インフルエンザ検査 綿棒 長さ, プラダを着た悪魔 ダウンロード, 相手のフォローに自分が いない, サイモンコーウェル ワンダイレクション, 錦戸亮 会見, 冨岡義勇フィギュア一番くじ メルカリ, 啄木鳥探偵處 岩手, Auひかり 繋がらない, 鬼滅の刃 お館様 声優, エクセル マッチング 並び替え, 遷移可能 英語, 質する 意味, 第二東京大学 エヴァ, 解説書 英語, アセトアミノフェン 市販薬, 応急対策 意味, スダジイ 実, 無理をする 意味, きさん児 意味, コナラ 冬芽, Weblio Extent, オーク 家具 色, 碇シンジ できるわけないよ, 声優 宮田幸季 ハイキュー, 克明 対義語, 詳細にありがとうございます 英語, マテバシイ 葉っぱ, コールドケース 最終回 解説, Safari ページを開けません セキュリティ保護された接続を確立できません, エヴァ 2話 セリフ, きめつのやいば 192, 沼津 市民 ラブライブ, 中曽根弘文 派閥, 辛党 類義語, フォローチェック 一括ブロック, 商品提案募集 雑貨, エンベロープ アルコール, 1リットルの涙 病気, 仮面ライダー 食玩 シークレット, どんぐり アクセサリー 幼児, 鬼滅の刃 風の道しるべ ネタバレ, 対義語 寛容, シンエヴァンゲリオン 冒頭 公式, Twitter 制限解除, 対照的に 英語, 黒歴史クリーナー メンテ, 他 18件洋菓子専門店桔梗屋, 冨久家 沼津ケーキ店など, 葛城ミサト 最後, 松田詩野 事務所, エヴァンゲリオン 旧劇場版, 松田詩野 ハーフ, エアガン市場 ジャンク袋, 沢田研二 TOKIO 意味, ご教示ありがとうございます 英語, 旧字体 変換 スマホ, Twitter リプ 非表示 できない,
