【EC開発体験記-否定-】 常識を疑え

将棋の世界では今、格言や定跡を覆す新手ラッシュが起こっているそうだ。アマチュアが指したら稚拙と笑われるか常識知らずと起こられそうな指し手がプロの将棋で続出している。よくよく研究してみると理にかなった有力な手順だったという。これはまさに「コロンブスの卵」のような話。「コロンブスの卵」を発見するにはまず疑ってみる。これまで培ってきた常識を否定することから始める。これはITでも同じことがいえると思う。自分の感性に合わないものや、理屈では分かるけど納得できないものはまず疑問をもつように心がけるべきだろう。（声に出すと反感を買うのであまりおすすめではない）
　今回のプロジェクトでは開発生産性と品質という２つの重要なポイントは押さえつつ常識はずれのことにもTryしてみた。結果うまくいったものもあったが、酷く痛いことになったものもあった（約2:8）。いずれにしても、今はモヤモヤしていたことが自分なりに整理できて大変満足している。

１．受注番号等のキーを採番しない
２．テーブルは第3正規形まで設計しない
３．各サブシステムで共通のエンティティを使用（最小単位は1品1葉1レコード）
４．更新履歴は部分的に取らず1レコード分をコピーする大福帳方式とする
５．トランザクション処理は厳密にしない
６．オブジェクト設計をしない
７．サブシステム間を密に結合させない（サービスだけで繋ぐ）
８．外部システムとの連携はすべてを自動化しない（SVNを介した手運用を残す）
９．データ交換で全銀を廃止。XMLかJSONを採用して固定長データやCSVは廃止。
１０．Web受注はブラウザからのプロバイダ通信だけで完結させる
１１．文字コードを混在させない(Linux,MySQL,PHP,Java すべてUTF-8)
１２．すべてCoolURI
１３．チームでコード記法を統一させない（しなくてよい）
１４．ドキュメントは起こさない。(開発途中のtracの記述とテーブル・プロバイダ仕様のみ)
１５．商用パッケージを使わない（すべて手作り）
１６．入力は寛大に受け付け、出力は厳しくせよ（参考にすべきでないより）
１７．赤黒処理でレコードを２つ作成しない
１８．検索エンジンを自作しない（Googleを使う）

【メモ】Bloggerにはてなスターをつけてみた

一応、はてなスターをブログに設置するにはを参考にやってみたが、Bloggerのテンプレートが違うせいか、そのままだとできなかった。以下のようにやったらできた。

１）Tokenの下にheaderTagAndClassNameを追加

<script type="text/javascript" src="http://s.hatena.ne.jp/js/HatenaStar.js"></script>
<script type="text/javascript">
Hatena.Star.Token = 'xxxxxx';
Hatena.Star.EntryLoader.headerTagAndClassName = ['h3','post-title'];
</script>

２）post-titleを以下のように修正

<h3 class="post-title">
<a href="http://www.blogger.com/<$BlogItemPermalinkUrl$>" title="permanent link"><$BlogItemTitle$></a>
</h3>

３）.post-titleにdisplay: inline;を追加

.post-title a, .post-title a:visited, .post-title strong {
display:block;
text-decoration:none;
color:#c60;
font-weight:normal;
display: inline;
}

【EC開発体験記-開発-】命題を共有し開発者から提案する

「作っては壊す」過程があってこそ良いものが作れる

ゲーム開発者の話を聞くと作り直しはあたりまえだという。そもそも、多くの人に面白いと感じてもらうことが要件だったりするので納得のいくまで何回でも作り直す。いわゆるアジャイル開発なのだがこれが一般企業のシステム開発に採用されるにはいくつかの障壁がある。まず、一度作ったものを壊すことは心理的になかなかできないという点。開発者の立場からすれば過去に費やした時間と労力をすべて捨てさるような気分になるだろうし、発注者の立場からすれば、そんな無駄なことにお金を払いたくないと思うかもしれない。また納期が短くサービスインの日から逆算してスケジュールが組まれることが多いのも「作り直し」ができない理由の一つだろう。そこでよく陥るのは、要件定義や設計にしっかり時間をかけてやればいいとか、テストを十分にやればいいとか、一見正しそうで間違った意見に流されることだ。作りなおしてもいいがイテレーションの回数を先に決めようとか変な話になったりもする。たしかに、開発効率が悪いのは要件定義や設計をちゃんとやってないからだし、不具合が多いのはテストを十分にやってないからなのだが、そもそもこの「ちゃんとやる」ことが非常に難しいから困るのだ。ウォーターフォール型の開発の問題点はまさにここにある。次にこの記事を読んでもらいたい。

デスマーチがなくなる？
下請けは労働生産性が低い

　私は工事進行基準で解決できる話とは思わない。「ユーザーの要件定義があいまいで・・・・」とあるように、デスマーチはよく客のせいにされる。要件が決まらないとか、仕様がコロコロ変更になるのが諸悪の原因であるかのようにいう。たしかに客は何かお願いしたいことがあるから開発を依頼するのだが、要件定義や仕様をしっかり決められる客はまずいない。できるのであれば要件定義にお金を払うことはしない。一方の開発者は、客の意図・目的を積極的に理解しようとしない。彼らは意図に関係なく指示されたことだけを淡々とこなす。リスクを背負いたくないとか、いろいろ面倒なことを考えたくないので、客にそういった部分を引き受けてもらうか、元受けにマネージメントを要求する。多少単価が高くても元受けにはならず、すすんで孫受けになりたがる人さえいる。客は曖昧な命題だけをいい、開発者は具体的な指示がないと引き受けない。こうしてデスマーチの土壌が生まれる。間に入るPMが、安請け合いする場合や、マネージメント能力がない場合にデスマーチとなる。
　マネージメントは、まず要件定義をしっかりやることから始まる。私が考える要件定義とは、客のかかえている問題、悩みを解決するソリューションとして、まず開発者が提案し、それを客が受けいれて定義していく作業である。（ここでの開発者はPMを含むプロジェクト全員を指す）要件を決めるのは客だけだと思っている人は第一段階でつまずくことになるので要注意だ。要件定義も開発の１工程なので開発者が責任もってやらないといけない。それには提案型であることが重要である。積極的に提案すれば開発の範囲を明確にしながら前に進めることができる。
　これは客によるかもしれないが、開発者は提案に自分のやりたいこと、例えば、新しい技術習得であったり、フレームワークであったり、何か自分の目的を含めてしまって構わないと私は思う。それで開発者はモチベーションが上がって提案しやすくなるだろうし、客はそういうやる気のある開発者に任せてみたいと思うものである。
　作っては壊すアジャイル開発手法は品質のいいものを生み出すが、どうしたらそれを一般企業のシステム開発に採用できるのだろうか。命題を客と開発者が共有し、開発者から提案できるような文化をつくること・・・これがとりあえずの私の結論だ。