設計について思うこと
台風一過の影響で、都内の満員電車っぷりが半端ないことになっていました。日頃それほど満員電車には乗りませんが、あんなんが毎日だとそりゃ死にたくもなるなぁ、となんとなく思ってしまいます。
簡単に自殺したくもないので、満員電車は避けるようにします（？）・・・って大分タイトルと関係ないですね。
今回は、４年ちょっとこの業界で働いてみて、特に設計について思ったことをつらつらと書いていきます。
ウォーターフォール型の設計
私は幸か不幸か（多分不幸な方なんでしょう）、ウォーターフォール型の開発をしているような現場にしか行ったことがありません。アジャイル？なにそれおいしいの？みたいな旧態依然とした現場です。
そんな現場では、皆様よくご存知の通り、下のような段階を踏んで開発がすすめられます。ちなみに↓の略称は、私が経験した略称です。他にもあるのかもしれませんが・・・。
ちなみに、「あれ、ユニットテストとかないの？」と言われると、「無いです」と答えられるくらいの古い形態です。えぇ、業務でまともに書いたことなんてありゃーしません。よく"V字モデル"とか言われる、一方通行の開発手法ですね。私が見聞した記憶だと、たしかウォーターフォールは元々ハードとかの開発で用いられていた手法を、ソフトウェア開発に持ち込んだものだ、となっていたと思います。
私が経験した中で、工程の重要度としては、
> UI, ST >= RD, OM > SS,IT > PS > PT > PG
の順でした。あくまで私の感覚で、他の人は違ったかもしれません。
まぁ、極々一般的なウォーターフォールです。特に奇をてらったものはありませんでしたし、誰もこの工程に疑問を持っていないようでした。
SS、PSの意義
勉強不足で、アジャイル型の開発でRD・UIに相当する工程がどんなものになっているかがいまいちわかっていませんが、それでもそれに相当するものはあると思っています。無くても最終的にはあるものだと。
ウォーターフォール型とアジャイル型で一番違うところは、これも散々いろんなところで触れられていますが、まず実装する、という点だと思っています。ウォーターフォールで、SS/PSを書かずに実装したことありません。
ただ、SSとかPSとかを書いたことがある方には賛同頂けると（多分）思いますが、特にPSについて、書くことの意義が無いように思えて仕方ありません。SSの領域も大分怪しいですが、それでも全体で利用するようなメッセージ設計書とかはまだ書く価値が（多少は）あると思います。
バリバリアジャイルでやられている方々でもそうでない方（私含む）でも、ぶっちゃけ設計書書くよりもまず実装を開始した方が、よっぽど正確だし早い、というのが実感だと思います。特にウォーターフォールでは、プログラムを修正すると、それとほぼ言行一致する形で、ExcelとかWordとかを修正しなきゃなりません。今時ExcelとかWordで設計書とかないわー、と言える方は、それだけで大分恵まれているなぁ、と感じてしまいます（泣）
実際、最終的に大事なのはソースコードですし、そこからJavaDocとかDoxygenやらで自動的に生成してやれば済む話です。なのになぜSS/PSが必要だというと、「SEが最終的に見るから」だそうです。えーと、見たところで結局修正するのは別の人ですよね？最終的にソースコード見るんだから、そっちの可読性を高くするようにした方が合理的じゃない？という言葉は効きません。なんでかというと、SEがそのプログラミング言語を使えるかどうかなんてわからないからです。
ちょっと話は変わりますが、SE＝システムエンジニアという言葉は、ほとんど日本でしか使われていないと聞きます。他の国では、もっと細分化されたエンジニアだったりアーキテクトだったりする、と（これぐらい調べればいいのに）。
なんでこれほどまでにSESE連呼されるようになったかと考えると、日本人が大好きな"統合職"みたいなもんだからじゃないか、というのが私の考えです。プログラマーとかまで全部ひっくるめてSEということにしておけば、細かい雑務も含めて押し付けられる、と。どうでもいいですけどSEって聞くと最近は「Sound Effect」と反応するようになってしまいました。
話を戻すと、つまりは「ソースコードが読めない人のために作る」のがPS、ということだと思っています。ま、ひどいところだと、PSとPGを完全に一致させることが求められる、とかいうのもあるようですが・・・。それはさすがに論外すぎるので・・・。仕事をしているといろいろな人と出会いますが、プログラムの詳細を見るときにはまずソースコードを見る、じゃなくて、PS/SSを見る、という人が非常に多いと感じますね。
RD/UIが一番？
工程を表す時によく、「上流工程」「下流工程」と言われます。今でも求人とかで「上流工程を〜」とかは決まり文句のように登場します。上流、つまりウォーターフォールの上流なので、RD/UIの部分ですね。ここを任せられる、というのは上級エンジニアということらしいです。
個人的にはPS〜PG辺りの方がよっぽど頭も使う必要があるし、よほど高等なことがやっているので、そっちの方が上級じゃまいか、と思うのですが、お客様至上主義の日本企業では、客先に近いRD/UIをやる人が一番偉いみたいですね。
もちろん、要件とか外部のインターフェースとかをきっちり決めることは大事だと思います。最終的に言った言わないの世界になっているのも何回か見ているので、証拠とかも合わせて作っておくのは大事ですし、大体の顧客が見るのもこの辺の資料です。
ただ、この業界で日夜頑張っている方々はよーく身に染みていることでしょうが、要件とか外部のインターフェースとかは常に流動します。でもって顧客の方が強いのがほとんどで、よほど理不尽でも体感的には99.9%くらいの確立で捻じ込まれます。もちろん大抵の場合、期間が延びるなんてこともありません。
そうなると大変です。RD/UIの修正から始まり、SS/PS/PG/PT・・・と、順々に修正していく必要があります。ウォーターフォールは上流で決められたことが基本になるので、上流の設計書が修正されないと下流は修正できないからです。小さいのが一回二回とかならまだ可愛いですが、機能がまるごとひとつ追加、とかまったく想定されていないケースも対応することになった、とかが連続で入ってくると、デスマーチ突入確率が一気に跳ね上がります。
つまり、RD/UIが良く変化する＝顧客の要望が皆無であることがほぼ無い、という点を見ると、少なくとも実装側からみると、RD/UIの価値はかなり落ちてきます。それよりだったら、（プログラム内部の）設計をより柔軟に対応できるように時間をかけた方がよっぽど有益ですし、そういう考えで進められたのがオブジェクト指向であったりアジャイル方式であったりする、と思います。
結論としては
RD/UIで顧客要望なんてありえない、なんていう妄言を吐く人は無視しておいて、基本的な要望が移り変わることがほとんどであるソフトウェア開発において、設計書作成が大きなウェイトを占めるウォーターフォールはかなり効率が悪いです。ただ、今でも人命に関わるようなミッションクリティカルなプロダクトであったり、極めて強固なセキュリティが必要なプロダクトでは使われていると聞いたことがあります。本当に使われているのか、使われているとしてそこはデスマーチになったことがないのか、とかは気になりますが。
そういう意味では、アジャイル型の開発方式は、ハードウェアの延長線上という認識だったソフトウェアを、ハードウェアとソフトウェアは別物だと認識した上で作られた、よりソフトウェアに適応した開発手法なんだなぁ、と思います。（まーこれもいろいろな方が色々な表現で語られていることと思いますが）
ただ、現実として私がいるような底辺付近は、いまだにウォーターフォールが幅を利かせています。そういう中にあって、どうやったらアジャイル開発を行えるような環境にできるか、などを考えていた中での、ウォーターフォールの（というか上流工程の）問題点を改めて自分の言葉としてまとめたものがこの文章です。
自分の頭でまとめたものなので、ところどころ論理が破綻していたりおかしいところも散見されますが、思いとしては大体現在のウォーターフォールに対する批判と一緒、ということです。
ま、正社員という名の派遣社員（？）という立場である自分にそんなことをする権限があるはずもなく、出来る場所に転職をした方が早いんでしょう。というかいい加減転職しないと、ワーキングプアが目の前に迫ってきそうです。
