基本設計のあれこれを教えてください

Question

わからない事！
現在、既存システムを.netからPHPに移行する新規システムのコーダーを一人でしています。

もともと、インフラ要員(業界1.5年目...転職組)のため、コーディング補助でPM(PL)をしている方の下に就く予定だったのが、その方が、別件にて、当方の作業が０工数になってしまいました。
仕方がないので、わたくしが、一人プロジェクトをする事になりました。

自社内先輩方にも質問は、投げたのですが、いまいち具体的な内容に落とせなかったので、
知恵を貸していただきたいです。

質問1
画面定義書とは、画面の一覧と各画面毎の機能が記載された資料の認識であっておりますか？
質問2
画面定義書は、具体的な資料として、どう言った感じの資料になるのでしょうか？
※可能であれば、こんなフォーマットって言うのを教えてもらえると幸いです。

質問3
機能一覧とは、画面単位ではなく、業務フローに合わせて、各工程で使用するビジネスロジックを網羅した資料である。
質問4
機能一覧を作成する際に記述しなければならない(説明しなければならない)箇所は、どの様な内容でしょうか？
※こちらもフォーマットなどで御説明いただけると幸いです。

補足：作成しているシステムは、webシステムです。
※google先生に問い合わせをして、色々なサイトは見たのですが、
有識者向けの説明が多く、具体的な内容に落とし込めていないです

以上、よろしくお願い致します。
質問場所がここじゃないってことでしたら、削除とかしますので、教えてください

Answer 1

社内（社外に提示する目的も含む）で必要とされるドキュメントは固有名詞になりがちで、
一般的なフォーマットや書式では情報の過不足が必ず発生します。

それぞれのドキュメントが業務として求められているのであれば、
責任者に対して同様の質問を行い、回答を求める「必要」があります。
*その結果回、「自分で定義しろ」という業務なのであればそれはそれでOKです。

以下はその前提での個人的にこれくらいは必要だろうと思う回答です。

質問1
画面定義書とは、画面の一覧と各画面毎の機能が記載された資料の認識であっておりますか？

webのシステムであれば、それに加えてフォームや機能の具体的な仕様まで記載されたもの（デザイン的な要素以外は全て分かる状態）が欲しいと思います。
また、どこでどの画面が使われているかわからないと用をなさないので、機能単位での画面遷移図とセットで扱うことになります。

質問2
画面定義書は、具体的な資料として、どう言った感じの資料になるのでしょうか？
※可能であれば、こんなフォーマットって言うのを教えてもらえると幸いです。

スクリーンショットやワイヤーフレームで画面をメインの項目にして、
「画面名」
「主な要素とその機能」
「フォームの仕様（遷移先、バリデーションルールとそのエラー等も）」
「URL」
あたりを記載します。

質問3
機能一覧とは、画面単位ではなく、業務フローに合わせて、各工程で使用するビジネスロジックを網羅した資料である。
質問4
機能一覧を作成する際に記述しなければならない(説明しなければならない)箇所は、どの様な内容でしょうか？
※こちらもフォーマットなどで御説明いただけると幸いです。

「各工程」の定義がわかりませんが、ユーザがそのシステムによって実現可能な機能が「ユーザ目線で」記載された資料だと考えます。
機能仕様書としてまとめるのがいいかと思います。
機能仕様書

Comments

[tama_yn0815]

おお！？大変、御丁寧な回答をありがとうございます。
珠玉の回答だと思います。
ご回答を読んだ後にリンク先の説明をみると、リンク先の内容が理解できます！
本当にありがとうございます。

[tanat]

お役に立てれば何よりです。

とりあえず増員者がどんなものか確認して、その後どうハンドリングするか決めるための資料なのであれば、質問内でやり取りされている内容で問題無いように思います。

そうでは無く、本当に「その資料を基に実装を始める」という事であれば、ここを失敗するとても簡単にデスマーチになりそうな案件に見えます。（私の勝手な思い込みの可能性も高いです）

> 新規システムに移行する際に追加要望なるものが、出てきまして、
というのはよくある話なのですが、
「本当に欲しい」のか「ついでなので欲しい」
や
「既存機能の完全コピー＋αが欲しい」のか、「業務フローに影響が無ければ多少の変更はOK」なのか「既存機能の要求を満たせばいいのか」
あたりが曖昧だったり、
「基本設計はあるのでそんなにコストかかんないよね？」などがあったりするとかなり危険です。

また、クライアントから見ると、既存システムを作り直したところで新しい価値が生まれるわけでは無いので、不満が出やすいです。（実際にはリバースエンジニアリングを伴なう作り直しでとても苦労するのに。。）

増員者が作るものを理解するためのドキュメントという事は、
その時点でクライアントの要求が確定している必要があるため、
時間をかけて（現時点で完璧だと思われる）機能仕様書を完成させるよりは、
「本当にクライアントが求めているものは何か、どういう方針なのか？」という
最上流部分を出来るだけ早く明確にして、クライアントと共通認識を作り、
そこから開発のための資料を作るという流れにならざるを得ないようにも思います。

*このあたりはプロジェクトを固めた人が既に固めていて、クライアントとの信頼関係も十分！あとは作るだけ！という状態ならあんまり心配ないと思います。

不安を煽るようなコメントで申し訳ありませんが、ご参考まで。。。

[tama_yn0815]

既にデスマーチ....ファイヤージョブになっているのです(T_T)

流れとしては、御説明いただいた通りで、今回作成しなければならない資料は、増員者がシステムを理解するため+今後のハンドリングを決めるための資料になります。

クライアントとの信頼関係は問題ない(競合他社いないため)のですが、1月12日リリース1月18日環境切り替えとなっているので、そこまでには、要求システムを完成させないといけない状態になっているです。

今回、既にコーディングが始まっていまして、上流工程すっぽかしで、製造指示が出たため、自分の中で疑問があっても、「社長や担当Aさんが、仰っているのだ、問題ないのだろう」って思い、実装をしていたのですが、なかなか、終りが見えなく、Aさん、社長と会議の場を設けたところ...

担当Aさんの認識は「Aさんの代わりに僕が、フル製造、Aさんはオブザーバ的ポジションで僕からのPHPに関するQAに回答すること」
社長の認識「Aさんが、メインでコーディング、共通化されたメソッドや画面を僕が、横展開」
僕の認識「Aさんの補助で、作業指示はAさんから降りてくるため、その指示に従い作業をすること」
と、それぞれがそれぞれの認識で食い違い、「なあなあ」な状態で、口頭での打ち合わせが多く、エビデンスと言えば、私がメモしたテキストくらいなため、このままじゃ完成しないって事が発覚。
しかし、システムは11/25日にデモリリースってなっていたため、機能と画面を制限して、リリースしたが、12月末までにSTを完了させてリリース(1/12)は絶望的なため、APP事業部_部長に相談(インフラのため、基盤事業部_部長経由)したところ、先輩6人を土日と業後を返上して、作業補助をしていただけることになりました。

問題は、部長含め先輩方が、僕と同程度でもシステムを理解しようと思うと日数がかかる為、部長から、「作り方が分らないことは、判っているから、完成度は求めない、ただ、○○君がわかる範囲で、画面定義書と機能一覧を12/01の第一回打ち合わせまでに作ってください」と指示されたのが、今回の質問の始まりになります。

的確なご回答、本当に感謝いたします。
アドバイスをいただいた以上、炎上していようが、いまいが、何としても完成させて見せます。
本当にありがとうございます。

p.s.今回のPJは、社長以外はクライアントと会話が出来ないため、要件なるものは、すべて社長が聞いた内容で、社長はエンジニアではないため、画面のレイアウトにばかり気がいっていて、重要な機能的な部分が不明瞭な状態です。
こちらも、なんとしても、要求を聞く会議の場を設けないとだめですね...

[tanat]

そういった事情なのですね。
大変な状況ではありますが、
現時点での問題となる部分は整理されている&社内の認識+協力体制も整いつつあるようにお見受けします。

クライアントへのヒアリングさえうまく行けばあとは工数をどれだけ投入出来るかというステージに持っていけると思います。

無責任な発言ではありますが、頑張って下さい。

Answer 2

設計書の定義や用途は貴社内の先輩にこういうとらえ方で良いか確認しますし、会社によってそれなりの書式の雛形があるだろうから、それをもらうようにしましょう。雛形さえなければ、
画面定義書 Excel download
などとググって探し、先輩にこの書式で良いかと確認します。

.netのコードを読んでPHPに落とし込むだけの能力も必要ですから、わたしなら上司にきちんとお金を払ってそれなりの経験者を調達してOJTで教えてもらいながら作業できるように、依頼じゃなくて、用意するよう要求します。
無免許なのに新車のポルシェを運転してコーナーを曲がりきれず30メーター下の谷に転落・即死しそうに思えます。能力や経験を無視して頭数だけ集めて崩壊したシステムを何度も見ていますが、それでは会社の信用も将来もありません。

Comments

[tama_yn0815]

おお！なんと、目から鱗です。
ポルシェの例え、具体的で納得の行くご説明でした。

以下、回答
実は、.netのコードは既にコンパイルされており、.dllファイルになっているため、逆コンパイルなることを実施しないとサーバー側の処理を確認できないそうです。
そのため、既存システムをユーザーベースで触り、その挙動と同じものをPHPで作成する事が主目的でしたが、新規システムに移行する際に追加要望なるものが、出てきまして、DB定義の変更や一部業務ロジックの変更を余儀なくされたため、到底私一人では、完成させられなくなったので、先輩を増員することになったのです。
しかし、その先輩から基本設計書を作成するように指示があり、その中でも上記の二つを先ずは、って話だったのですが、どうも、自分の脳味噌がポンコツな所為か、具体的な作業(作成物の形)が、理解できていない次第です。

自社、雛型ですが、設立1年目で殆どが自社外へ出ている為、自社での請負は初案件なんで、そう言ったのが、全くない状態でした。

書式、これかな？って言うのがいくつかあったので、そちらをポストして、解答を待つことにいたします。
御教示、ありがとうございます！

Answer 3

参考になるかどうか・・・。政府系システムの場合では
総務省の電子政府のサイトに、政府共通ルールの策定(標準ガイドライン等)「政府情報システムの整備及び管理に関する標準ガイドライン実務手引書」の第7章 設計・開発（PDF資料）のP4０当たりに発注者目線での要件定義の内容との整合性に係る、画面定義書、機能一覧の位置付けが書かれています。
また、「ipaシステム開発」でググるといろいろ出てきますよ。

Comments

[tama_yn0815]

なるほど、大変参考になりました。
このあたりの内容理解が足りていないのも原因なんですね

[blackonyx]

大変そうですが頑張ってください！

[tama_yn0815]

がんばるです(*^_^*)

Answer 4

まったくこの手の作業をやったことがなく、どんなドキュメントを作ればよいのかも分からないというのであれば、以下のURLにフリーで使えるドキュメントのテンプレートがあるので、参考にしてみてはいかがでしょうか？
もちろん、すべてを作る必要はなく、これから作成するシステムで必要なものだけを作ればよいと思います。

PocketDOC - PocketDOCとは？

Comments

[tama_yn0815]

ありがとうございます！確認してみます

[trick]

KatsumiTanakaさんが言うように全て作成していたらとても大変なので
必要なものだけを作成したほうが良いと思います。
この当たりが参考になれば幸いです。
https://thinkit.co.jp/free/project/4/3/1.html

[tama_yn0815]

katsumiさん、trickさん
フォーマットありがとうございます。
フォーマットは、こちらのものを利用させていただきます。
また、全部ではなく、一部とのことですが、もう一度、先輩に必要な資料を精査依頼いします！

Answer 5

これでなければならないという正解はないでしょう。どういう目的でドキュメントを作るかによって異なってきます。画面定義書といっても、それを元にしてお客様とレイアウトについて検討するのか、画面を作る人に渡してその通りに作ってもらうためなのか、保守のために記録として残すためなのか等、様々な目的があるかと思います。まずは、その点を確認してみないと色々なサンプルが出てきて、どれを使ってよいのかわからないという状況になります。

Comments

[tama_yn0815]

そうなのですね....具体的な説明はISMS的に危ういので、抽象的な説明になりますが、
一人プロジェクトでは、プロジェクトそのものが空中分解する恐れがある為、要員を追加する事(開発経験者を投入し、プロジェクトの立て直しをする事)になりました。

増員にあたり、増員者が「何を作れば良いのか」を具体的に理解するための資料(仕様書や設計書ベース)を作成してほしいと依頼を受けたのですが、実際に出来上がる資料の完成形がわからないため、質問したのが、背景になります。

システムは、画面遷移と比較的簡単な業務ロジック(計算ボタンで入力値をもとに料金計算やSQL(CRUD)の発行など)、セッション上で値の保持のみで、外部APIを利用するような部分や一時保存機能などはないです。