処理の流れ図(フローチャート等)について、再考
先日、「フローチャート使用に、賛成?反対?」というタイトルで、記事を書きました。
それを見てくださった方から、twitter でこんな意見をもらいました。
『PS工程で使用する一つの手法としてフローチャートを使うのはありと思います。
PS工程で処理の流れを日本語で書いてPGではPSの内容を落とし込むだけです。その作業ができればどんな手法でもいいのかなと思います。』 (tweet原文を引用)
これについて、少し補足しておきましょう。
こちらの会社では、ソフトウェアの開発工程を次のような略称で呼んでいるようです。
・SS工程 : システム構造設計
・PS工程 : プログラム構造設計
・PG工程 : プログラミング
・PT工程 : プログラムテスト
・IT工程 : 結合テスト
・ST工程 : システムテスト
つまり、上記のtweetは、プログラム構造設計の工程で”処理の流れ”を設計書として作成するのには、フローチャートも有用ではないか。ということです。
なるほど、この方の仰る状況もわかります。
設計者と、コーディング以後を受け持つ担当者が異なる場合、しばしばこのような現場が見受けられます。
なぜ、このような現場では、処理の流れを設計書として渡す必要があるのか。
それは、次のようなケースだと考えられます。
case 1. コーディング以後担当者のスキルが心配
担当者が、まだアルゴリズムを自作する十分なスキルになっていないため、
そのままコーディングできるレベルの詳細な処理の流れを設計書として渡す
case 2. コーディングレビューがしやすいように
外部へ委託する場合など、コードレベルでの確認が必要な場合
依頼内容と、成果物(コード)が比較しやすいように、処理の流れを図式化する
しかし、いずれのケースでも、作成した設計書(流れ図)が使われるのは、PT工程まででしょう。その後の工程や、後の運用・保守においては、参照されることはないのではないでしょうか。
フローチャートなどで、詳細な設計書(処理の流れ図)を作成する場合、「それを作成する効果」 を、チーム内で共有しましょう。
それが使われる理由を知らずして、ただ決まりだから... で作成していては、作成する側は疲弊してしまい、受け取る側もコードへの変換者のままで成長が見られない、と思います。
今の組織の状況と、処理の流れ図を作成する意図を、皆で理解することが大切です。
そうすることで、組織として成長し、開発現場の改善への繋がることになるからです。
今回も最後に注意事項。
フローチャートのような処理の流れ図を使う場合でも、次のドキュメントは別途必要です。
(1) より広い範囲の構造が分かる設計図
その部分が、全体の中の何処に位置し、他とどのような関係を持つのか がわかるもの。
これは、設計を管理するうえで必須です。
トップダウンで設計する場合なら、本来こちらがあり、小さな範囲の流れ図が書かれるべきです。
(2) 担当範囲の仕様を示したもの
流れ図では、具体的なアルゴリズムしか示せず、その部分の仕様は表現できません。
何が入出力であり、どのような機能を実現するか。
その部分についての仕様を、明確に定義しておきましょう。
(前回からの繰り返しになりますが...)
フローチャートなどの処理の流れ図は、その性質をしり、適材・適所、適宜、使用して欲しいものです。
「社内の決まりだから...」という事だけで、ひたすら労力を使うようなことがないように、この点は節にお願いしたいものです。
※ 関連記事: Interface 2011年2月号