設計飛翔？ ～Optional presence～

ちょっと久しぶりかもしれない、元ネタありのタイトルです。
今回は簡単すぎるので元ネタ当てクイズはなしで＾＾；

システム開発の現場では、一般的なイメージに反して文書作成や調査に多くの時間を割きます。
筆者の経験＆印象では、設計：製造：試験＝４：２：４（または５：２：３）であると思っているほど、プログラミングの時間（＝製造工程）は少ないのです。
プロジェクトの改善を考える際には、必然的に時間をかける部分の改善をまずは考えることになりますので、設計と試験の議論がよく行われます。
設計と試験では、設計のほうが先に行われ、又、試験項目の作成は設計書を元にするのが原則なので、試験の議論の前に設計の議論を行うのが良いのですが、今回は社内での設計に関する議論から思い浮かんだ話です。

前提として、システム開発によく用いられている開発手法の説明を。
開発は「要件定義」⇒「設計」⇒「製造」⇒「試験」⇒「納品」（⇒「運用」）　という流れで行います。
以前もちょっと書いた記憶がありますが、
　「要件定義」：システムで実現したいこと／やりたいことを整理する
　「設計」：要件定義を満たすために、どのような仕組みを作ればいいか考える
　「製造」：設計通りにシステムを作る
　「試験」：要件定義を満たしているかどうか、又、システムがちゃんと動くか確認する
　「納品」：システムを利用する人のもとに届ける
　（「運用」：システムが日々ちゃんと使えるように管理を行う）
と読み替えてもらえれば理解しやすくなるかもしれません。
実際にはそれぞれの工程で本や論文が山ほどあるのですが、そういうのは専門家にお任せで
…ＳＥは専門家じゃないのか？　専門家ですが、本とかに体系だてて書く気はありませんよ。

上記の４工程（納品は重要だけど開発工程というのも微妙なので除外です）のそれぞれで文書（ドキュメントと呼ぶことが多いです）を作るのですが、文書作成は時間も手間もかかるので営利企業にしてみれば最低限に抑えたいのがホンネです。
そこで、最低限必要な文書を整理しようという試みが社内で行われています。
筆者も参加していますが、建前論と現実とを行きつ戻りつする不思議空間となっています。
そこではあまり言うべきではない、小プロジェクトでの開発方法についてが今回の本題です。

設計は一番重要な工程です。
しかしながら、２，３人程度のプロジェクトにおいてはメモ書き程度の設計で製造を行ったほうがよいことがしばしばあります。
　・規模の小さいシステムであること
　・開発メンバーが固定されており、人数が３名程度であること
この条件を満たす場合、実は設計書作成がプロジェクトの大きな枷になります。
設計書は、要件の確認と製造の実現可能性の裏付けの意味がありますが、これは略式の設計書で十分に対応できます。
一般に言う設計書だとずいぶんといろいろ書き込む必要があるのですが、色々書く理由が多くのメンバーで設計を共有することとシステムに齟齬や矛盾がないようにすることなので、人数が少なくて規模の小さいシステムだと…　いらないんですよね＾＾；

ＰＤＣＡサイクルを回す場合はそうも言っていられませんが、設計工程をほとんど飛ばして製造に、なんて荒業も時には必要かなぁと思います。




※注
　筆者は設計を重視しています。
普段から設計をせずに製造などという手法を使うわけではないことを明記しておきます。
念のため＾＾；

＜ＰＤＣＡサイクル＞
　Plan Do Check Action　の４工程を繰り返し行うことで、問題点の早期発見ときめ細かい計画改善を実現しようとして提唱された手法　…　だと思っています。
　色々な場面に使えるので使い方・とらえ方は様々ですし、４工程ではなく３工程や５工程で行うこともできると思います。
　専門誌などでよく使われている言葉なので「ＰＤＣＡサイクルを回すことで品質向上を図りましょう」とか発言するとかっこよく見えます。
しかし、具合的な提案がないと評価が地に落ちるもろ刃の剣。ＰＤＣＡサイクル未経験者にはオススメできない。
　なんだか吉野家コピペ（これ）っぽくなってしまったので牛丼が食べたいなぁ（笑