使える設計書・使えない設計書

ＣＯＰ１０が始まりました。

愛知万博の時は東京に居たのですが・・・

なんとなく「やっている」程度の情報しか入ってこなかったのを覚えています。

今回のＣＯＰ１０も同じ感じなのかなぁ？　と思ってみたり。

中京圏はローカルでの広報が多い気がするのですが、気のせいでしょうか？

今日のお題は　設計よもやま、という感じです。
といっても、設計の方法などについて論ずるわけではなく、設計書と製造の距離を埋める一つの方策を考えてみようと思います。

設計書というものはシステム開発に必須の文書です。
料理に例えるなら、レシピのような位置づけになります。
特定の相手に読ませるなら相手に合わせたレベルで、一般向けならそこそこ細かく、というあたりは共通してきます。
しかし、どのような相手であれ設計の次は製造作業があります。
設計書に書いてある内容を、製造者がコードに置き換えていく作業・・・
必要な事ですが、労力がもったいないケースもあります。
当然、途中で設計が変更されればやり直しが大変です。
設計変更に連動して製造も変更されれば、と思ったＳＥは数知れず、でしょう。
料理と違って、設計も製造もＰＣの中で行っているのですから。

そこで、製造のなかで定形化出来る部分を設計書に記載しておけば？
というベタなことを考えています。
実際に一部の設計書に対して私的に実験を始めていますが、評価はまだ先になりそうです。
項目名を書きかえると関連するソースコードが変更される。
ただこれだけなのですが、設計書をＯｆｆｉｃｅ（主にExcel）で記述している現状では色々な工夫を要求されます。
さすがにＩＤＥなどで記述したスケルトンなどを設計書と言うわけにはいきませんし、ＵＭＬは悪くないけどツール頼みなのが怖い。

結局のところ、自前で、多くの人が理解可能な作りで作るのがＢｅｓtなのかな？　と思い、ちまちまと工夫をしていこうかという感じです。




・・・具体的な事を伏せたら余りにも短くなってしまった。

設計飛翔？ ～Optional presence～

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

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

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

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

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

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

goo mail 騒動 ～『フリー』ってなに？～

先日（5/7）、多少触れましたが、goo mailのリニューアルが大問題に発展しているのをご存知でしょうか？

まとめwikiからの情報となりますが、ITmadiaNewsに5/10に取り上げられてから、大手新聞社も後追いで取り上げ始めています。
状況の推移によっては各マスコミが取り上げるかもしれないですね。
特にgooの運営は「NTTレゾナント」が行っているのですが、ここの株主を見てみると…
　エヌ・ティ・ティ・コミュニケーションズ株式会社 66.6%

　株式会社エヌ・ティ・ティ・ドコモ 33.4%
とあります。ＮＴＴレゾナントのＨＰの企業情報からコピペしましたので（現時点では）間違いない情報です。
どちらの株主もシステム開発を生業とする人の多くが知っている／仕事をしたことがある大手です。
goo mailの広告出稿者やドコモの携帯の不買程度で済めば良いのですが、ＮＴＴ系列すべてへの叩きが始まると困りますね。

goo mailのお知らせページというものがありますが、goo mailからのお知らせなどはここに出てくる様子です。
ちょくちょくチェックしていたのですが…　ブログ（コメント可能）形式なので報道され始めてからのコメント数がちょっと恐ろしいことになっています。
5/13～5/14で概算４００～５００コメントとか。
流し読みをしてみると、だんだん2ちゃんねる化しているのがわかって鬱になりましたが「無料」であることに対する言い合い（議論じゃないです。あれは議論と言えるレベルじゃないです）を見ていて「フリー」についてちょっと考えてしまいました。

言い合いの主な考え方は２つ
　Ａ：『無料なんだから提供する側のすることに従え』
　Ｂ：『無料とはいえ今まで使えていたものが使えなくなるのは問題』
マスコミに露出して以来、Ａの書き込みが増えてきたあたりが面白いですね。
それぞれの考え方について考察してみると…

　＜Ａ＞
　極端な表現をすると「使わせてやっている」考え方。
ある程度の独断専行ができないと何もできない状態に陥ってしまうので、提供側の都合で物事が進むのは当然と言えば当然。
しかし、提供側は無料とはいえボランティアをしているわけではないのを忘れている気がする。

　＜Ｂ＞
　ＳＥ的にはこの考え方は基本中の基本。
以前のシステムで実現できていたことを、リニューアル後のシステムで実現できないというのはよほどの理由が必要。

Ａに全く理がないわけではありませんが、人として（少なくとも日本人として）道義とか何とかを考えると最低でもＢの考え方でないとダメちゃう？　と思えます。
「フリー」だからと言って、使えないものを提供してよいということにはならないということですね。
尚、使えないと一言で言っても色々ありますが、この場合は旧システムが使えた環境では新システムも使えること、が最低限になります。
メールは継続して使用してなんぼですので。

まとまらないですねぇ…
やはり自身が当事者の一人（筆者のフリーメールはgoo。学生時代から使っています）だと整理しきれないか……

「全体」と「個別」の境目

タイトルを書いてから、なんて抽象的なんだろうと思ったのですが後悔も反省もせずに進めます。

私はＳＥなわけで、仕事と言えばシステム開発なり保守なりその他システム関連のよしなしごとをそこはかとなくやるわけで。
現在担当しているプロジェクトがＡＳＰであることからこんなタイトルが浮かんだわけです。

ＡＳＰはその性質上、１つのアプリケーションを複数名（複数企業）でそれぞれ利用します。
わかりやすい例としてはフリーメールがあげられます。
（Ｗｅｂサービスと混同している？　SaaSはどうした？？　まぁ、そこらへんは置いておいて＾＾；）
フリーメールにログインすると自分のメールボックスを利用できるのですが、そのメールボックスは自分のためだけに「個別」に作られたのではなく、アカウントさえ作れば誰でも使える代物です。
しかし、他の人のメールボックスを見ることはできないし、自分のメールボックスが見られることも（恐らく）ありません。

使う側としては便利なのですが…　作る側としてはなかなかに大変でもあります。
　「全体」　即ちそのアプリケーションの利用者のほとんどが使うであろう部分と、
　「個別」　即ち利用者によって　使う／使わない　が割れる部分の切り分けが必要です。
個人ユーザ向けならば「個別」部分はオプションで選択可能（ブログのレイアウトなどがいい例です）にしておけば問題ありませんが、企業ユーザ向けだとそうもいかないことがあります。
個人だとシステムに合わせられるのに、集団（企業）だと合わせられない傾向にあるようで…　システムを集団（企業）に合わせてほしいとなることが多いのです。
この要望に沿ってシステムを合わせて大変なことになったのが独ＳＡＰです。詳細は雑誌の記事（googleで「ＳＡＰ　アドオン　バージョンアップ　サポート」で検索するといくつか出てきます）を見てみてください。業界誌（？）では有名なので。

酷過ぎて例にもならないのですが、タイムリーな話題ですので取り上げると、goo　mail　なんかは「個別」にすべき仕様を「全体」に適用して大失敗をしつつある状況ですね。
３行でまとめると
　　リッチ過ぎる画面にリニューアルし
　　操作性やレスポンス・通信負荷を最悪に
　　「全体」で喜ばれた機能は消え去った
ですね。
wikiまで作られている（新gooメール不具合まとめwiki）のですが、そこを見てみると、不具合以前にログインできない／画面が表示されない　という素敵な状況です。
リッチ過ぎる画面は「個別」で欲しがる人がいる程度の代物で、「全体」に組み込むべきではなかったのかなぁ、と。
え？　これの何処が『システムを集団（企業）に合わせてほしい』と繋がるのか？
実はgoo mailのリニューアルはNTTdocomoの携帯メールとの連携が大きな目的の一つだとか…
gooの運営はNTTレゾナントなので…
ちなみに、このgoo mail（リニューアル後）、リッチな画面はAjaxで実現しているとか…
Ajax＝非同期通信JavaScript　です。盛りだくさんで使うとこんなに酷くなるのか、と反面教師にしております。
Googleも盛りだくさんで使っている？　いえいえ、通信が発生する頻度が全く違う様子です。
と、脱線が激しくなってきたのでここらで打ちきりです＾＾；

誰がためにドキュメントを書く

あからさまなタイトルですが、解りやすいので採用。

ドキュメント、という言葉もある種専門用語なのですが、ＳＥはパソコンに向かってプログラムを書いている時間よりも、ドキュメントを書いている時間のほうが遥かに長いということをご存知でしょうか？
ドキュメントとは、簡単に言うと仕様書や設計書のことです。
　こんなものを作りたい⇒仕様書
　こういう手順で作りたい⇒設計書
誤解を恐れずに簡略化するとこんな感じです。

やりたいことは簡単なのですが、間違いなく・漏れなくドキュメントを書くのはじつに難しかったりします。
仕様書や設計書はいろいろな種類のドキュメントに細分化されるのですが…　細分化し過ぎて何のためのドキュメントか解らないこともしばしば。
　「このドキュメントは何のために書いているのか？」
　「このドキュメントは誰が読むためのものか？」
こんな基本も考えられないほど追いつめられるプロジェクトも存在します。
存在するというか、ＳＥなら誰しも経験しています。
推測でなく断定してもかまいません。それくらい追いつめられているプロジェクトは…　話がずれるので割愛＾＾；

ドキュメントの意義について認識が合っていないと無駄な作業だけが増えるので、必要なドキュメントに絞って作業を進めるのが理想です。
しかし、現実にはそうもいかない（発注元の流儀で形だけでも必要・納品物として必要（←こういうのは大抵読まない））ので、なかなか難しいですが、一般的なドキュメントの意義を知ることで多少は理想に近づけるかな？　と思っています。