結局、システムの設計書って何書けば良いの？っていう件

僕はいくつかシステムやチームに参加させてもらいましたが、驚くほど、

設計書がコスパ悪い。。。

個人的にはで、ドキュメントとして成立してないことも往々にしてあると思ってます。

そこそこ工数とってやってる訳ですから、情報資産としてイケてる設計書を作りたいのです。

という訳で、今回はそもそもなぜシステムの設計書は得てして微妙なのか考えてみました。

【微妙だと思うところ①　実装と整合性が取れていない】

これ出来てないと意味無いと思うんですけど、ちゃんとするの難しいし、もはや違ってて正常な空気すらあります。

内部設計が微妙な場合はたぶん、こういう状況でしょう。

外部設計作る→内部設計作る→内部設計間違っとるぞと思いながら正しいだろう実装をする→修正の時間ないOR忘れるOR製造終わったし放置でよくね？OR運用さん宜しく

僕は根本原因はWBSにあると思うんですよね。

実装が遅れるとか、仕様が変わるとかはリスク高いので考慮してますけど、

ユーザーへの資料でもないし実装できちゃうし、考慮してないですよね。

WBSになければ、時間ないし忘れちゃうでしょう。

内部設計が間違ってるのが分かるのは製造や単体テストのフェーズなんで、ウォーターフォール自体が失敗してるというのもWBSに書きにくい理由ですかね。

運用さん宜しくってのは、どのチームでも出来ることじゃ無いですよね。ソース読めない人もいますし。属人化やらしてるレベルだと優先順位は最下位でしょうね。

【微妙だと思うところ②　資料多すぎ。しかも断片的】

システムが大きくなれば、資料が増えるのは分かりますけど、必要以上に多くなってませんかね。例えば、プロジェクトごとに資料を新規作成している場合。

特に、システムの変更箇所のみ設計書作るとか。

2003年　[基本設計書]リンゴ画面表示対応.xls

                詳細画面の中央にリンゴを表示する。

2004年　[基本設計書]リンゴ画面表示個数変更対応.xls

                詳細画面の中央にリンゴを５個表示する。

2005年　[基本設計書]オレンジ画面表示対応.xls

                詳細画面にオレンジを２個表示する。　※リンゴ画面表示個数変更対応.xls参照

2007年　[基本設計書]画面表示切替対応.xls

                詳細画面に表示する果物をラジオボタンで切替可能にする。

2010年　[基本設計書]詳細画面改修対応.xls

                詳細画面のラジオボタンをプルダウンに変更し、管理者はバナナを選択可能にする。

2011年　[外部設計書]果物管理システムリプレース対応.xls

                果物管理画面の下部に備考欄を追加する。※要件定義書を参照

2015年　[外部設計書]みかん個数入力欄追加対応.xls

                果物管理画面の上部にみかんを表示し、個数入力欄を追加する。

。。。で、結局全体としてはどうなっちゃったの？よくわからんから、システム触ってみよ。

となるパターン。

上記の場合だと、画面名や果物名もしれっと変わってるし、バナナがどこに書いてあるのか調べるのは大変でしょう。過去の資料を参照にすると、陳腐化して使い物にならん資料も大事にとっとかないといけない。それと資料間の境目的な仕様の記載が漏れがち。実は2007年時点で果物の表示は全て１個でした。とか色々出てくる。

そして将来は、みかんの個数だけインサートするテーブルが多いとかベテランしか知らない状況が生まれるんでしょうね。

【微妙だと思うところ③　肝心なところがスカスカ】

詳細設計書に一生懸命ロジックを書くと、保守が大変なのか手を抜いてることがありますね。文章にしにくいときもあるのでこれも難しいところ。

詳細設計書曰く、

　詳細リスト取得・・・リンゴ、バナナ、オレンジについて詳細マスタからデータを取得する。

ソースコードは、

public class L001001 extends BusinessLogic {

    public void getDetailList(String userId, InfoTable info){

        switch(info.fruitsId) {

            case Const.APPLE:

                addApple();

                break;

            case Const.ORANGE:

                if(SystemUtil.getServiceID(SystemConst.S01).equals(info.serviceId)) {

                    if(!CommonUtil.isEmpty(SystemUtil.getCustomData("REMARK", "S01"))){

                        try {

                            getRemark();

                        } catch(BLException e) {

                             exceptionHander.add(e);

                        }

                    }

                }

                addOrange();

                break;

            case Const.BANANA:

                addBanana();

                break;

        }
        addRemark();
    }

}

適当だけど、こんな風になってたりする。

あれ、オレンジの時だけなんかやってるじゃん。リンゴはしなくていいの？

みたいな。嫌ですね。経験上、設計書がザルすぎるところは単体テストも適当。

かといって、１０Kステップあったら設計書に１０K行書くのも嫌です。

設計書とか関係ないけど、個人的には何でもかんでもメソッドの型がvoidなのは本当に見る気失せます。

ということで、努力目標程度ならまだしも、設計書とプログラムをバッチリ辻褄合わせるのって、本当に難しいし、そこに時間やら人やらつぎ込むのは、たぶん無理というか無駄。資金が潤沢にあればいいレベルまで持ってこれるでしょうが、UI設計とかテストとかに時間使った方が、ユーザは喜ぶと思うんですよね。

この件について、私なりの結論は、

詳細設計だか内部設計だか知らないが、ソースコードに吸収されてしまえ。

です。

詳細の記載場所はJavadocとかコメントとかにして、概要とか全体像は資料にしておく方がいいと思うので、基本設計書はしっかり作るべきです。

アムウェイのおばさんとの会話のまとめ その３

アムウェイに勧誘されました。
今回ので４度目。まぁ、さすがに慣れてきました。
ただ、今回は私が無視しなかったせいで、３日間という長期戦となったのでした。

アムウェイが合法なのも儲かっている人がいるのも分かりますが、私にはご縁がないようです。

ということで、前回に続き、アムウェイのおばさん（Aさん）と私の会話を紹介します。
これが最終回です。


【３日目：１６時〜１９時（雨）】
参加者：アムウェイのおばさん（Aさん）、私（I）
場所：おばさんの活動拠点


改札での待ち合わせにやっぱり遅れたというか来てもないAさん。
今回は、買い物してたらめっちゃ並んだから遅くなったとのこと。
で、近所にはいるからこっちまで来いとか言い出す始末。
雀の涙ほどの僕の給料からさらに上前を撥ねようとしてんのに何言ってるんだ。
今回のでわざと遅れているのではという疑惑はほぼ確信となりました。
あのね、私はあなたより大分遠いところから来てますよ。


A：「あ、こんにちはー。ごめんねー。すごい雨だねー。」

I：「。。。そうですね。」

A：「もう少しで、うちのメンバーがいるところに着くよ。」


５階ぐらいの建物に到着。最寄駅からは５分程度、場所は結構良い所。
ただ、建物がボロいよね。
エレベーターで３階に到着。女性が多いのか、入口は飾りが色々あって、おしゃれ？というか塾の教室っぽい。
案内されて中に入ると、個室になっているところが３つぐらいあって、白板やら椅子やらあって３０人ぐらいは入れそう。
塾に通ってた頃を思い出す。とは言うものの、塾よりは整理されていなくて、何がごちゃごちゃしてる。


A：「席空いてるか確認して来るから待ってて。」

部屋には１５人ぐらい。僕以外にも何人か勧誘されていました。

A：「今日はね、Iさんのために、私も勉強して来たんだー。」


前回も聞いたような、内容を話し始める。アムウェイはメーカーでCMを使っていないから、安く良いものが買えるとかなんとか。全部アムウェイでやってんだとか言ってる。
その流れで、アムウェイが売り上げ１位とかいいながら、本社の写真を見せる。いや、前も見たし。


I：「まぁ、立派な建物だと思いますよ。でもね、ジャンルも技術も違う製品を大量に生産した上に出荷までやるとか規模が足らないと思いますよ。在庫の保管場所も足らないでしょうね。工場とか言ってますけど、レイアウトから判断すると一部の物流加工がメインってとこじゃないですかね。だから本当は大半はOEMじゃないですか。今の説明は嘘ですよ。」


まあまあ知ったようなこと言ってみた。
写真１枚だと判断できないようなことも無理して主張。


A：「うーん、確かにOEMの製品はあるね。」

I：「ですよね。都合の悪いところは、いつも僕が言ってから言いますよね。」


Aさん、今度はビデオ見て欲しいとか言い出したので見てみる。
なんか聞いたことある話だった。
登場人物は２人。川の水を街に運ぶ仕事をどうやってやるかって話。
１人は一所懸命水を汲んで運ぶ。もう１人はどうするのか。


I：「これ、パイプライン作るやつですよね。」

A：「。。。」


予想通りパイプラインを作って、権利収入を得ることができました。
めでたし。めでたし。
要するに、賢い人は上手に大金を稼ぐという内容で、一理あるかもしれないが、アムウェイのビジネスモデルとはまるで違うと思うのは私だけかな？
と言うか、小学生向けのビデオ。


A：「すごいでしょ、権利収入ってどう言うものか分かった？　権利が欲しくなって来たでしょ？」

I：「この話とアムウェイの共通点がよくわかりませんね。どこが作ったビデオですか？」

A：「どこが作ったとかそう言う話はいらないの！（怒）」


理解力のない私に苛立ちを隠せないAさん。
さらに私がネットに書いてあったアムウェイの悪口についてどう思うか聞いて見たところ。


「それは、悪いグループに入ってしまった運の悪かった人の話で、私たちには関係ないよ。それに前にも言ったけど、うちは成功者の下にいるし、ノウハウが伝わってるから大丈夫。」


マルチで上の人が成功者でないパターンがあるのかどうか甚だ疑問。
そして、すべての悪口に対して運が悪かっただけとか。そんなの通らんでしょ。やっぱアムウェイって普通じゃないよね。
だんだん空気が悪くなって来たので、Aさんは考えました。


A：「そうだ！　自分の夢を１００個書いて来てよ。」


めっちゃ話飛んだぞ。そしてマニュアル通り。ずっとめんどくさい事ばっかり言ってる私を相手に、このやり方で落とせると思ってるのでしょうか。


I：「いやー、そういうのいらんっすわ。マニュアル通りで共感してたらもう入会してますよ。今の感じだと１００％入会しないと思いますよ。」


困って涙目のAさん。
Aさんは近くの中年男性に助けを求めました。
その男性はきっとそのグループでは幹部的な存在なのでしょう。
多分、私の会話も聞いていたのでしょう。
男性はスマホで遊んでたクセに、「忙しい」とか言ってAさんを見殺しにしました。
良いグループですね。


A：「詳しい人に説明をお願いしようと思ったんだけど、今は無理みたいだからまた今度にしよ。」


帰り道、最寄り駅まで一緒に帰りました。
アムウェイに忠誠を誓ったAさんは人混みの中でアムウェイの良さを大きな声で語ります。
また来週会おうとか言うAさん。いや、もう結構です。

その後、しばらくラインで連絡されましたが、面倒なので無視しました。


【まとめ】
アムウェイは細かいところでよく計算されていると思います。
心理学なんかはかなり研究されてそうです。
グループ内で売上を共有し、高め合うのか監視するのかよく分からんシステムもあるようですし、IT投資もしっかりですね。
今回はネットであるような高圧的な感じには遭遇しませんでした。
が、普通に異様な空気ですよね。

アムウェイの設立者、設立年月日など事細かに記憶して、かなり訓練されたAさん。
税金を安くするとかはやけに詳しいAさん。
なのになんで、

「勧誘は本能だ！！」

とか言っちゃうんですか。
そういうところです。普通の人とは相入れない感じになっているのは。
Aさんは悪い人ではないです。でも、アムウェイ以外で人間関係はないでしょうね。
なんだか、気の毒な気持ちになりました。