複雑な処理の整理方法と見積り方法

Question

お世話になっております。

仕様検討や既存システムの仕様整理する際の話です。

複雑な処理が必要な場合、
例えば、インプットに応じてdb更新または登録しながらファイル出力するのを他領域システムと同期を取りながら行う、など、
皆さんはどのように仕様というか頭の中を整理しているのでしょうか？

図に起こすとよいと言われるのですが、
図やフローが苦手なので起こすのにも時間がかかり
結局実装を読んでしまいます。。

ただ、そういう時は頭の中で整理しきれていないことが多く、「ここの処理どうなってたっけ？」と聞かれてすぐに答えられないことも多いです。

設計～実装の作業見積りを出す際も、複雑な場合は正直実装してみないとどれくらいの修正量で実現出来るのかわからず、見積りするころにはほぼできている、または実装してから結果的にそれに合わせた設計書を起こしているということが多々あります。

正直慣れだと思うのですが、
上記のような場合、どのような図を起こすと整理しやすくなるでしょうか？
また、色々なインプット、アウトプットが入り乱れている場合、皆さんはどのように整理していますか？

Answer 1

こんにちは。

「複雑な処理」は複雑ですから、スルっと頭の中には入ってきません。最初は混乱しまくりです。その状態のまま設計すると良いものはできませんので、時間を掛けてでも整理するべきと思います。
なかなかその時間をとることが辛い場合もありますが、上流工程のミスは工数を大きく増大させます。上流工程に必要な時間をかけることはトータル工数の削減に有効です。

さて、頭の中を整理する手段はいくつかあると思いますが、やはり有効な手段は図と思います。

図に起こすとよいと言われるのですが、

図やフローが苦手なので起こすのにも時間がかかり
結局実装を読んでしまいます。。

既に実装があるのならそれを読んで図に起こせばよいのでは？
（あ、でもフローチャートは単に時間の無駄ですから止めましょう。高級言語が発達した現代ではフローチャートは素人さんにとっては複雑な流れを素人さんに分かりやすく説明するためのものと思います。）

そして、図を書くのが苦手ということですが、恐らく全ての人が最初は苦手です。みんなご自身で苦労して図を起こすスキルを身に着けているのが実態ではないでしょうか？　分かりやすい図を書く努力を継続しているとそのうち得意になりますよ。そして、最後は図に書かなくても図が頭の中にでてくるようになるので複雑な構造の整理自体が得意になるのです。

Comments

[lupus_dingo]

>なかなかその時間をとることが辛い場合もありますが、上流工程のミスは工数を大きく増大させます。
まさに今その状態で、進捗に遅れを出してます。
フローチャートをExcelでいちいち作成するの本当に面倒ですよね。。

Answer 2

実装してみないと、というのは、言い換えると「実装する前に手順を確立させていない」（＝設計できていない）のです。
手順が確立していなければ何をどれだけ作業するかが分かりませんから、見積もることもできないということになります。
そして図を書くというのは手順を整理することに他なりません。

スパイラル開発やアジャイル開発という、短期間で開発サイクルを回す（その代わり1サイクルでの開発は小規模なものが連続する）手法もありますが、これは設計を重視しないわけではありません。全体像を把握したうえで「小規模、あるいは最小限度の設計と開発」を繰り返す方法ですから、設計をしっかりできないと破綻します。

最近は図としては UML が標準的ですから、まずは UML のシーケンス図を書いてみるのも手ですよ。
※フローチャートと違い、それぞれの作用対象が図に出てくるので、「何が何に対していつ何を行うか」を明確にすることができます

Comments

[lupus_dingo]

uml検索してみましたが、色々な図があるんですね。
シーケンス図が自分が欲しい図に近いきがするので作ってみようかなと思います。

>「実装する前に手順を確立させていない」（＝設計できていない）のです。
そうなんですよねー。出来るのはわかるんですが、実は引数とか実装規約を考えると全体的に修正が必要とかを実装し始めないと気付かないことがよくあります。

Answer 3

図で書かないならせめて文章で書けばいいのでは？

1. 入力がされた
2. 他領域に情報発信（非同期処理開始）
3. DB更新または登録：失敗した場合は〜〜〜
4. ファイル出力：失敗した場合は〜〜〜
5. 他領域の完了を待つ
6. 画面更新（「完了」と表示）

例えばこんな感じで。

---

「いつ（入力可能タイミングや同期待ち等）」
「誰が（ユーザーが、メインスレッドが、サブスレッドが、DBが等）」
「何をしたら（送信ボタンを押したら、このメソッドが呼ばれたら等）」
「どうなる（返り値の有無、例外時処理等）」
これらを１つずつ考えていくだけでも大分変わるような気がします。

Comments

[lupus_dingo]

文章にはおこしています。
ただ、複雑な処理だとそれだけでは簡単には理解できなぃですよね？
そういうときに皆さんどうしているかという質問です。

[sakura_hana]

敢えて強い言葉を使いますが、その複雑な処理を理解するのを放棄するから、後で困るのではないでしょうか？

複雑な処理を紐解いて整理しておけば、後で実装する際にその通りに作ればいいので楽になります。
１回プログラムを日本語で書いておく的な感じでしょうか。（もちろん考えるまでもない、機能を見ただけですぐに頭にプログラムが浮かぶ内容は端折ってもいいと思います）

まぁそれでも「見落とし」はありますが、それはもう他の人にチェックしてもらうとか１回寝て起きてから見直すとか、出来るだけ減らすようにするしかないですね。

[lupus_dingo]

>敢えて強い言葉を使いますが、その複雑な処理を理解するのを放棄するから、後で困るのではないでしょうか？

放棄しているように受け止められたらすみませんでした。むしろ真逆で、どのようにしたら、理解しやすくなるか？というのが今回の質問です。

>複雑な処理を紐解いて整理しておけば、後で実装する際にその通りに作ればいいので楽になります。

その整理が、文章だけでは難しいような場合はないでしょうか？
複雑な仕様の場合特に、よく細かい文章だけ書いて、ユーザに全体が把握しにくいと言われるので皆さんはどうしているのかアドバイスをもらうのが目的でした。