わんくま同盟勉強会に、多数の方々に参加していただき、ありがとうございました。いただいたご意見をもとに、補足させていただきます。

まず、反省点。「質問」を、最初に持ってきたのはまずかった。やっぱり、警戒しますよね。最後の Q & A での発現率と比べると、かなり違います。で、ここであわてて金曜日に見たブログで思ったことを口にしたのが、さらに悪かった。これで、かなり混乱させてしまったようです。

また、対象とする人を明確にしていませんでした。タイトルに「設計」と持ってきたので、いわゆる「システム・エンジニア」とか、リーダ クラスの方々を対象にしたようになってしまいましたが、私が意図していたのはプログラマでした。この違いも、大きく響いてしまったのではないかと思います。

あと、「ここ、直したいなぁ」と思っていたことを、直せなかったのが最大のミス。なぜって、それが要だもの。はい、「まとめ」に持って行く直前です。ここ、プッツリ切れているんですね。はじめを削れば、時間的余裕も出てきたろうになぁ。詰めが甘いのが、私の弱みです。勉強します。。。

では、いただいたご意見の紹介と、補足です。

勉強会として一方的なレクチャーになるのかと、少し不安に思っていたのですが、対話としてのもので、非常に興味深く話を聞くことができました。

いろいろな方の視点で話が進む部分はとてもおもしろかった。

参加者からいろいろなツッコミが出てくるのはとてもおもしろいです。

ありがとうございます。私が Japan MVP Summit に出席して感じたのが、「確かにそういう場合もある。でも、それが適用できない場合があるんだ。頼む、しゃべらせてくれ。」ってことでした。これを、解決できないかな？ということで考えたのが、あのような形です。

はじめに出した抽象的な定義に対して、最後で戻ることが無く、思いの理由がわからなかった

ちょっと内容が抽象的だったかなと思う。

主題ながんなのか、わかりませんでした。

すみません。はじめに、「技術者は、話を振ったらしゃべり出す」と考えていました。そのため、最初の質問で何も出てこなかったので、焦りました。そして、まだ咀嚼していないことを話してしまったのがまずかったです。これは、話の組み立て方に問題がありました。本当にごめんなさい。

対象としている方々にずれがあった

はい、そうですね。親睦会でいただいた名刺の肩書きを見て、ビビってしまいました。

確かに、勉強会自体、対象とする人、レベルについては全くふれていませんでした。これは、必要ですね。また、私も、特にどんな人が来てくださるのか、どのような知識をお持ちの方々を対象とするのか、考えていませんでした。次回は、明確にしたいと思います。

私の方は、結果的に、０～２年程度の経験のあるプログラマが対象になっています。しかし、いただいた名刺のほとんどが、「リーダ」以上でした。。。

そもそも設計という言葉の定義がわからない。SWEBOK でいう設計とは、かなり違う気がする。「どのように」「どこまで」が、明確にならなかった。

設計には、いろいろな段階があると思います。今回、私が取り上げたかったのは、プログラミングに入る直前、「こういうのを作って」と仕様書を渡されて、実際に開発環境に向かう人が行う設計です。

これも確かに、主題として明確にはせず、話の中でさらっとさわった程度でした。申し訳ありません。

また、「どの様に」「どこまで」も、対象とする工程によって変わってくると思います。今回の対象は「プログラム直前」でしたので、次のことが私としての答えです。

• 使うものの詳細を知っていますか？

  すべてのクラスやメソッドを憶えろとはいいません。むしろ、そんな必要はありません。そうではなく、体系として、どの名前空間に、どの様なことが出来るものが集まっているのかということは、調べておく必要があると思います。

  実際、この過程が省略されていることが多いのではないかと感じています。私は @IT Insider.NET 会議室で、投稿をカテゴリわけしています。３月は週に２０程度の新規投稿しかなかったのですが、４月の終わりから週に７０程度に増えています。

  また、季節的に見ると、４月～９月にされる内容と、１０月～３月にされる内容とで、微妙に違いがあります。年度の前半には、基礎的なこと、メソッドの使い方やどの様なクラスを使用すればいいかという質問が、比較的多いです。後半には、少々込み入った内容、特定の条件のときに思った結果にならないとか、環境をかえたら動かなくなったという質問が、比較的多くなります。

  さらに、「msdn ライブラリは { 読みにくい | 読んでも意味が分からない | どこに何が書いてあるのか分からない } 」というご意見を散見します。

  このことから、「実は、わけも分からず、上からの指令 | 組織の方針で、使うものの調査をせずにプログラム製造を開始しているのではないか」と、思っています。この意見は、こうしたことを背景にしたものです。

• 仕様が決まった過程を記録していますか？

  仕様は、作る対象です。作る対象が明確になっていないのに、ものを作ることは出来ないと思います。もっとも、絵画や織物、彫刻などでは、できあがっていく過程で対象が変わることもあります。同じように、ソフトウェアも、できあがっていく過程で、様々な要因により、変わることがほとんどです。ただ、芸術作品と違って、それぞれの変更ポイントで、ゴールが明確になっていると思います。

  このとき、変わった過程を記録しておかないで、「こう決まった」という結果だけを記録していると、また同じことを繰り返すことになると思います。

  例えば、UI を考えます。古いシステムでは、リターン キーで入力項目を切り替えます。これを、Windows の UI である、TAB キーによる移動に修正したとします。このとき、「変更した」という記録しかなければ、会議に出席していなかった人、最悪の場合、会議に出席していた人からも、「なぜこんな仕様にするのか。リターン キーで移動になれているんだからそうしてくれ」といわれるでしょう。また同じ説明を繰り返すのでしょうか。しかし、決定後の要求ですから、結局、変更したことが無効になるでしょう。

  過程を記録するとは、こういう無駄を省くことが狙いです。どういう議論がされたのかを記録しておくことで、会議に出席しなかった人、時間が経ってから見直した人にも、決定の理由が分かり、「なぜこうなの？これじゃ困る」と言われにくくなるでしょう。

• ドキュメントはメンテナンスされていますか？

  ここで、何時、正式にメンテナンスするかについては触れませんでした。「少なくとも、手書きの修正が、手元にある仕様書に入っているべき」と言うに止めました。

  また、どの様にドキュメントを残すかについても、あえて触れませんでした。「最新版であるべき」とは言いましたが、「紙として残せ」とは、一言も言っていません。これについては、Insider.NET の記事、「連載 開発をもっと楽にする NAgile の基本思想 第1回 アジャイル開発ではドキュメントを書かないって本当？」を、あわせて読んでいただければと思います。この中で、「ソースコードで説明する」ということが言われています。このようなドキュメント化の方法もあるのではないでしょうか。

  これについて、他にもご意見をいただいていますので、そこにまとめます。

• 仕様の詳細化は足りていますか？

  「どこまで」というのを、もう一度出しただけですね。すみません。

  私はここで、コードと１対１とは言わないまでも、それに近いところまで落とす必要があると思っています。特に、駆け出しプログラマでは必須だと思います。それは、後々のデバッグのためでもあります。

  しかし、プログラムを作ることになれてくると、最初にブロックにたとえましたが、使えるブロックの種類が増えてきますから、だんだんおおざっぱで良くなってくるでしょう。決まった流れが見えてくるので、その流れが表現できる程度でよい、ということです。

  これも、関連するご意見をいただいていますので、そこでもう一度触れます。

• 例外的な状況が考慮されていますか？

  これも、他のスライドで「例外的な状況」というのを出しており、そこでの対象と違うため、良くないですね。

  ここでの「例外的な状況」とは、業務処理が続けられないような、正常処理から外れた状況を意図しています。

  別の言い方をすると、これはテスト ケースを先に作りましょう、ということなのです。中さんのデモの方で、「足し算」メソッドのテスト ケースとして、Int32.MaxValue + 1 の計算をさせていました。このような、オペレーション中に発生し得る例外的な状況を早期に見つけておきましょう、ということです。

  なぜか？後になって仕様を追加するのがどんなにしんどいことか、皆さんご存じなのではないでしょうか？

「設計とは何？」というものを再確認する意味ではメリットはあると思いますが、設計手法やその背景が千差万別であることを考えると、一般論の域を出ず（以下略）

確かに。私の背景を説明せずに、私の意見を「押しつける」ことは出来ません。今回、私の背景の説明を、まったくしていませんでした。ありがとうございます。

「全員が設計者」となるのは、難しいのかな

処理フローを設計者として残せるのは理想ですが、現実には難しいのではないかと感じました。（中略）作業量が２倍になってしまうのではないかと思うからです。

社内で行うことは出来ないかな、と思いました。口頭設計書と社内で言われていますが、画面のハードコピーがあればよい方です。

システム開発のプロジェクトの中で、それらを実践するには、時間的、技術的、精神的な制約が多すぎるかと思います。ともすると、いきなりコードを書いた方が早いという事態にもなりかねません。

「ドキュメントはメンテナンスされていますか？」を兼ねます。

確かに、そうなんです。ドキュメントを書く時間を、コードを書いたりテストする時間に回したい。その方が効率が良いんじゃないの？

では、お尋ねします。一度でも、ドキュメントを整備して、コードを書いたことがありますか？実際に、比較したことがありますか？

もっとも、「残すもの」の取捨選択を間違えると、ほぼ確実に失敗します。この加減が難しい。

しかし、私のところでは、Q & A の時間にお答えしたように、トータルな時間は変わりませんが、後ろの工程にかかる時間は減りました。それは、「どうしてだっけ？」「こっちの方が良いんじゃない？」と後戻りしたり、「どうするんだった？」と再度尋ねたりすることが減るからです。

このような、他の人を巻き込んだ時間のかけ方が減るので、一人一人の作業時間が若干増えても、プロジェクト全体にかかる時間が減るのです。例えば、会議で決まったことを誰かが仕様書に反映して、それから印刷して配る。こうすると、配られるのを待っていなければなりません。しかし、みんなが仕様書を持ち込んで、会議中に決定事項を書き込む。そうすれば、会議が終わった時点で、みんなが平行して仕事を再開できます。手元にある仕様書は、最新の仕様が反映されています。とりあえず、こういうところから始めてみてはいかがでしょうか。

“今”時間をかけることを惜しんだことで、“後”でそれ以上の時間が必要になるのではないか？

そんなふうに考えてみてはいかがでしょう？

メンテするのは、確かに手間がかかります。しかし、共通で使うクラスの説明がメンテされていなかったとします。そして、実際に使ってみると、書いてあることと違う動きをしたら？これを修正することにかける手間と、ドキュメントを修正しておく手間と、どちらが大変でしょう？メンテされていなければ、「どうなってるの？」と、聞きに行くため、使う人と供給する人の両方の時間を消費します。メンテされていれば、供給する人の時間だけが消費されます。

私はアンチ詳細設計！アンチ処理フロー派だ！！処理フローを決めると、処理フローにしたがった流れしか処理しなくなる。ユーザにも要求するようになっていく。

「仕様の詳細化は足りていますか？」を含みます。

すみません、これ、ちょっと意味が分かりませんでした。「何をしなければならないかを突き詰め、しなければならないことを達成する手順を明らかにする。」これが詳細設計であると思います。

また、「処理フローにしたがった流れしか処理しなくなる」が、「正常系の処理しかしなくなる」という意味であれば、「例外的な状況が考慮されていますか？」という提案をしていることも、あわせてご考慮いただきたい。

例えば、ファイルから設定を読み込むという作業について。これをするためには、まず、ファイルの場所を特定しなければなりません。次に、そのファイルの有無を調べます。有るならば、今度は読む権限があるか、確認します。それから FileStream なり、TextReader なりに開かせます。こういった処理の流れを定義せずに、どうやってプログラム化できるのでしょう？少なくともベテランの方々は、頭の中でそういう処理過程を設計しているのではないでしょうか。またここで、「ファイルの有無」と「権限の有無」について確認するという処理が出てきました。これにより、「無」という例外的状況がはっきりしました。

また、「逆設計」という話をしました。これは「設計」ではなく、「デバッグ」のことになります。

“バグ”といわれるものには、様々な種類があります。単にスペルを間違っているような（たいてい、コンパイラや IDE が教えてくれる）簡単なものから、処理の手順を間違えている（実行して初めて分かる）ものまで、様々です。ここで、処理の手順が間違っていたとき。どこが間違っているのでしょうか？「こうしたい。その為にこうするんだ」ということが定義されているから、それと実装を比較することで、「バグ」の場所を特定できるのではないでしょうか。

また、「ユーザにも要求するようになっていく」が、「ユーザの言うことは絶対。その通りに作れ」ということであれば、それに対しては絶対反対します。

できあがったシステムに、「ソリューション」という言葉を使うことがあります。「ソリューション」には、「解決」という意味があります。システム開発のどこに携わるかで意識も変わってきますが、最終的に納めるシステムは、ユーザが抱える問題を解決するものであるはずです。そうであるなら、システム開発に関わる人間は、相談者でもあると思います。他の人に相談するのは、その人に、より優れたところがあることを認めるからではないでしょうか。たとえ相手が素人だとしても、素人なりの考え方、取り組み方に一考する価値があるからではないでしょうか。そういった「価値」を提供するのが、ソリューションだと思います。また、その「価値」を「価値」として認められないなら、最初からシステム導入を考えない方が良いと思います。

もっとも、手順は複数あるからひとつに縛られない、という意味では賛成です。また、「処理フロー」をお客さんが実際に行う業務の流れと定義しても、賛成します。お客さん自身が行うことは、お客さん自身に決定権を持たせるべきです。しかし、システムとしての整合性、セキュリティ、技術的な制約を元に、開発者からお願い（あるいは要求）できる余地はあると思います。

矢印形のレーザー ポインタが欲しいな

すみません、親父から巻き上げたものなので、どこで買ったのか、いくらで買ったのか、不明です。なお、ヘッドを付け替えると、矢印だけでなく、SOS, I Love You などのマークも表示でき、「レジャーやデートにも最適」と、説明書には書いてあります。。。

特定の人向けリンク：Microsoft シェアード ソース CLI 実装
シェアード ソース CLI 実装は、CLR（Windows OS における、CLI の実装）とは違います。CLI がそのまま CLR だと判断しないでください（マイクロソフト社員さん談）。