自転車で通勤しましょ♪ブログ

利用者が不特定多数であるWebサイトの場合、利用者視点で考えるべきで、発注サイドと制作サイドの都合でわけのわからない仕様にするべきでない。仕様に対する明確な理由がなく、屁理屈やどちらサイドの都合であっても、その仕様をユーザが快と思わなければ失敗に終わる。

まぁなんでこんなことを書いているのかというと、制作サイドの都合（工数がないだの、改修が大き過ぎるだの）で屁理屈をいって現在の仕様でお客様をごまかしたとしても、利用者からの反応が返ってくるのはお客様なので、その時点でお客様の不信感を買ってしまうのではないかと思うからだ。ちゃんとやってくれないと思われてしまう(必要な費用を出してくれていないという点は大いにあるのだが)。もちろんやれる技術力はあるのだが、そこはコストとの相談になるので、ごまかすのではなく、やはり松竹梅的なプランを掲示してお客様主導で決定するプロセスがないとお客様は納得しないと思う。お客様が選択した結果、利用者の反応が芳しくなければ、プランをアップグレードするという方法をとらなければ、お客様も学習できないし、我々の掲示に納得してもらえない（その時点で判断材料が少ないからまともな判断ができないパターン？）。

下請けでいつも感じるのは、マネジメント層のコスト意識が強すぎて我々の提案を屁理屈に変えてしまい(必要経費すら無駄扱い？)、お客様との折衝が長期化して、いいものができないというジレンマだ。コストを最小化しようとした結果、要求が満たせず、折衝のみでコスト増大してしまうパターン。まぁ俺は常に富豪仕様にしろって言ってるつもりではない。ただ、不特定多数の利用者のサイトの場合、正しいのは利用者であってお客様でも制作サイドでもない。
お客様自身が利用者の場合は、富豪仕様でなくても運用でカバーすることが可能だが（マニュアルを作ったり）、そうでない場合はお客様にも納得してもらった上で、我々から見たら富豪仕様でも作らなければならないと思う。損して得取れ。というか、その損は損ではなく、得をとるためのコストであるので、コストかけて得取れと言いたいわけです。それと、明らかな損は、お客様が制作サイドを貶めている（ように感じる）ので明らかにモチベーションが下がります。まぁそこはマネジメント層の腕の問題かもしれない。

ネットにおいては、Win(お客様)-Win(制作サイド)では足りない。Win(利用者)-Win(お客様)-Win(制作サイド)の関係を築けるように、お客様と制作サイドで友好関係を築く努力のためにも、仕様決定プロセスの透明性を高めるべきではないかと思う。

それにしてもこの2ヶ月くらいで、WordPressのプラグイン開発の方法をほぼ掴んだ。大概のものは作れるという自信ができた。

企業・お店のサイトの構築であれば、WordPressで十分に作成可能だと思う。プラグインも豊富にあるし、イレギュラーな機能に関しては、プラグイン開発でまかなえるし、その部分の見積もりさえしっかりしていれば、お客さんにもある程度短納期でサイトを納入することができる。大体の開発がイレギュラーなものは必要ないレベルであると思う。

開発コストは落とさずに、開発期間を短くできるぶん、サイトの目的、コンセプト、ターゲッティングなどのウェブコンサルティングに力を入れて、他社との差別化を図るようにしたほうが、お客さんも我々もユーザ（お客さんのお客さん）も利益を享受できる、Win-Win-Winの形になるのではないかと思う。

しかし、ウェブコンサルティングに力を入れようとするとお客さんから見ると、そのコストが余計に見えるらしい…。俺からするとそこが一番重要なところであると思う。ウェブサイトの効果はウェブコンサルティングで決まる。都市部はどうかはわからないが、地方ではそこをないがしろにするお客さんがまだ多いようだ。そこに誘導できない我々にも問題があると思うのだが、説明しても盲目的にNOを突きつけられる場合が多々ある。目に見えないものの先にこそ、掴みたい明日があるというのに…。

まあ一言でいうと、『最も必要である箇所のコストをケチるな！』ということだ。我々もいいものを安く提供したいが、納得できない代物を格安で提供はしたくはないんだ！！それは利益が上がらないからとかじゃなく、『お客さんのためにならないもの』になっている可能性が高いからだ。それを提供し続けると、Lose-Lose-Loseになってしまう…。そんなことは絶対に避けなれければならない。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
	木下 史彦 オーム社 2007-12-22 売り上げランキング : 52268 おすすめ平均 まさに教科書だ さらばウォーターフォール 面白かったのは「コードレビューのパターン」。コード見直し模様。 Amazonで詳しく見る by G-Tools

アジャイルプラクティスを読んでて、腑に落ちた記事があった。

「設計は指針であって、指図ではない」

これは、設計者にも開発者にも、どちらにとってもいい言葉だと感じた。理由としては、設計者は指針を書くことに注力できること。いい意味で時間の短縮ができる。

詳細仕様書でフローチャートを書いていたときに、やりたいことはわかっているのだがフローチャートにして書こうするとすごく時間がかかった。しかも悲しいことに、この時間のかかったフローチャートは、「わかりにくい」と言われてしまった！！

フローチャートではなく、フローを箇条書き形式で書き直して見てもらったら、「これならわかる」と。

『詳細』なので、詳細にしなければならないという気負いがあるが、指図になるまで詳細にすると、仕様に問題がある場合に後戻りするのが難しい。しかも、詳細設計書を書くのに異常に時間がかかるようになる。これでは本末転倒だし、プログラマの仕事とやる気を奪う事になる。
機能仕様書に載っている機能は具体的にどんな処理をするかを設計する事が詳細設計であり、どのように実装するべきかはプログラマに任せたほうがいいと思う。アジャイルプラクティスに書かれているが、

「実際にその場所を通ってみるまでは、そこがどんな様子なのか確かなことはわからない」

のである。実装を詳細設計に書いたところで、実際に実装しようとするとどうしても無理が生じる場合はありうる。以前に、指針を示さずに指図になっていた詳細設計書を受け取ったのだが、フローとSQLが間違っていたことがあった。何がしたいのかがわかっていれば、間違っている場合は報告できるし、実装も可能なのだが、このときは駄目だった。詳細設計書の修正依頼をかけても修正に時間がかかり過ぎて工数がどんどん減っていき、待ちきれずに意図を判断して実装。そして詳細設計書と実装がどんどん乖離していく…という悪循環だった。

ドキュメントは指針。そして実装方法は、『実際にその場所にいる人』に委譲したほうがいいと思う。指針を共有できれば、プログラマから設計者へのフィードバックでまた素晴らしい設計が生まれる場合もある。

Manage It! 現場開発者のための達人式プロジェクトマネジメント
	でびあんぐる オーム社 2008-10-18 売り上げランキング : 79101 おすすめ平均 プロジェクトマネージャー必見 面白いけど読みにくい ITシステム開発のPMそしてそのスポンサー必読です Amazonで詳しく見る by G-Tools

Joel on Software
	青木 靖 オーム社 2005-12 売り上げランキング : 89514 おすすめ平均 会社のみんなに読ませたい お気に入りの本です 本当のソフト開発を本当の意味でわかってもらうのにいい本 Amazonで詳しく見る by G-Tools

ドキュメントを残す人でありたいと考え、それを模索している。Wordでテンプレートを作成してみたりとか。Webアプリの開発に携わっていると、低コストで厳しい工数を要求されるので作り出してから考えるみたいになってしまいがちだ（うちの会社では…）。工数を削減するためにドキュメント作成を省いたり、あまりに簡潔なものにしてしまうのは、逆に工数の増大を招く。

ドキュメントを書かないのか、書けないのか。最初は面倒臭がって書いてくれない！と思っていたのだが、最近になって、実は書けないんじゃないだろうか？と考えるようになった。ドキュメントは書けないけど、ソースコードは書けちゃうから書けるほうに安易に手を出して、修正依頼がきて、ブツブツと文句を言っているというような。自分はそんな人間にはなりたくないので、機能仕様書を作成してコーディングに入る前に確認を取るようにしている。これは当たり前のことのように思えるのだが、できていない人が多いんじゃないか？

機能仕様書、詳細設計書の書き方を学ぼうとネットで検索してみたりもしたが、しっくりとくるテンプレートが未だ見当たらない。機能仕様書に関しては、Joel on Softwareで書かれている方法で学習していて、なかなかいいなぁと思えるので、そちらを改良していこうと思う。問題は詳細設計書で、見ていてもしっくりくるのがない。感じたのは

• 一見わかりやすそうで、そうでもない
• Excelで作られているパターンが多い
• （主観的な意見だが）読みたいと思わせてくれない作り

という点。特に最後のが重要で、せっかく作っても読まれていないということが、往々にしてある。
ということで、Wordで作ることにした。
まぁあんまり変わらんやん！って言われる可能性も高いのであるけれど、Wordでやるほうが管理上楽だし、綺麗に作る事が出来る。ドキュメントには美が必要だと思う。ドキュメントの作成にしても、最初はなかなか上達はしないので、工数もかかるだろうが、そこをちゃんと経験しないと仕様をまともに考えることがないので（頭を使わないため）、エンジニアとして実力が向上しないんじゃないだろうか？

今思うと、ドキュメント書くのが下手な人の話って、わけわからんことが多いなぁ〜と思う。何がしたいのか、何が求められているのかがブレてて、言いっぱなしで、自分でドキュメントにして形にするということがないような気がする。ドキュメントを書くプロセスを経ると、まとめるというフィルターを通した上で出来上がるので、要件もまとまるし、情報共有もスムーズになるし、他人の時間を節約することができるので費用対効果は素晴らしいものがあると思う。いいドキュメントを作成すると信頼も得られるし。

ドキュメントを作るのを面倒臭がる人は、あまりに「自分の時間」にフォーカスを当て過ぎではないだろうか？他人の時間を節約するということは、自分の時間を節約することにも繋がるので、目先の時間に捕われず、ドキュメントに時間を「投資」したほうがいいと思う。得られるのはドキュメントだけではなく、「書く力・考える力」も手に入る。そういうことが、結果的にお客さんの期待に応えることに繋がると思う。

• どういうふうに書いたら他人に喜んでもらえるドキュメントになるだろうか？
• 手戻りの発生しにくいプロセスにするにはどうすればいいのか？
• このプロジェクトの目的、解決すべき本質は何か？

これを常に考えていきたい。

エンジニアのためのWord再入門講座 美しくメンテナンス性の高い開発ドキュメントの作り方
	翔泳社 2008-05-22 売り上げランキング : 7760 おすすめ平均 為になった すばらしいＷｏｒｄ入門書 数少ない、明確な視点・コンセプトのWORD本 Amazonで詳しく見る by G-Tools