インクリメンタルかウオータフォールか

どちらが優れているか、などと言う議論ではない。
杓子定規に、「どちらか」しかできないＳＥが、多いのは、困ったもんだ。

ウオターフォールを選択すべき時
・要求がかなり安定している
・設計が比較的単純、セオリーが確立されている。
・長期的な計画や予測が重要
・管理コストも含め、下流での変更が、極めて高くつく

インクリメンタルを選択すべき時
・要求が変化しやすい。要求を出す人さえ業務に精通していない。
・設計が複雑である、定型化されていない
・長期的な計画や予測は、プロジェクトにおいては重要ではない。
・下流での変更を吸収しやすいシカケがある。

プロジェクト推進の手法は、信念や宗教で選ぶべきではない。適切な手法を選ぶことも、ＰＭの腕のうちだ。

個人情報保護：郵便局で思ったこと

今年の初めに引越しをした。
距離にして数百メートルだが、イロイロ手続きをした中で、
郵便局にも転送願いを出した。
引越しの１週間ほど前、氏名、転送元と転送先を申込み用紙に書き、
窓口で提出した。

引越ししてみると、どうも転送されていない。
旧マンションのほうは、新しい入居者もきていないので、
管理人さんに相談してポストをあけさせてもらうと、
転送がされていないことが判明した。

これはマズイと転送願いを出した郵便局へ。
「いったいどうなっているの？書類受け取ったでしょ？」

申込み用紙はない。それは個人情報保護のため、
本局へ持っていってしまっている。と窓口で言われる。
ここには、控えもないのだ。

たしかに、個人情報は、存在するから守らねばならない。
存在しなければ、守る規則も組織も体制も省略できる。
窓口の局に置かず、本局に集中させるのが安心だ。効率がいい。
この郵便局のＰＭＳを決めた人は、いい方法と思ったことだろう・・。

顧客情報を営業マンが持ち歩けば、紛失のリスクがある。
守る立場からは、持たないことが望ましい。
でも、過去の自分の購入履歴や種々の情報を営業は知った上で、
自分に必要な、あるいは向いているサービスや商品を勧めて欲しい。
そうでなければ、ネットでたいていのものは手に入るわけで
営業という人間が介在する意味がなくなる。

勿論、企業の使命として、情報漏洩をさせないことは大事なことだが、
保護の名目で、顧客満足度を犠牲にする愚は避けたい。
先の郵便局の例でいえば、コピーとってファイリングして、
鍵のかかるロッカーなり金庫に保管しておく規則にしておけば
済むことだ。

個人情報を守ることは、企業として大事なことだが、
その企業・組織がが存在することの目的やサービスを
忘れちゃあ、どうしょもない。

PEPSIのバイラル手法

PEPSIコーラのサイトで、ゲームをクリアすると、コンプリートバナーがもらえる。
何となく、少しばかり得意になって、Blogに置いたりしたくなる。

広告費を払ってバナーを置いてもらうのではなくて、
一般の人に置いてみたいと思わせて、バナーを自己増殖させる。
バイラルマーケティングの実例として話に聞いたので、実物見てみたわけだが・・。
この際ですから、おれも、乗せられてみました。しっかりクリアしたので、バナーつけときます。
ゲームは単純なんだが、予想より奥が深く、楽しめた。バナーはわりと簡単にゲットできましたけどね。

でも・・俺はコーラは飲まないんだ。
そういう奴には、そもそも売り上げに効果のある広告ではないが、ジワリと認知度をあげる意味じゃあ、いいアプローチだよな。

個人情報保護と匿名性

個人情報を保護するということが世の流れで、その必要性を否定するつもりは、勿論ない。自分に関した情報が、ひとり歩きして、思わぬところで使われると思うと気持ちが悪い。もっとも、自分は、こうしてブログを書きつつ会社へのリンクも張っているわけで、やはりそれなりの決意のもと、個人情報に分類されることをさらし続けていて、気持悪いも何もないわけだが。。

P-MARKもちょっと前は、所持していなくても仕事になった。が、今ではそうはいかない。取引前に当たり前に確認される。ECサイトのサーバを預かるデータセンターなども、「個人情報を利用する」事業者ではないからP-MARKの必要性はないのかもしれないが、自分達が「このセンターを利用してはどうですか」と顧客に提案する際は具合が悪い。

守るが大事であることは論を待たないが、中途半端な解釈や理解で、行き過ぎた話も耳にするようになってきた。出すことが当然なのに、出せませんという例は、時々ニュースで聞いた。

話が少し飛ぶが、飛騨の有る村の家では、子供達が中学校にはいると表札にその旨が書き加えられる。例えば「ＸＸ中学校１年１組高橋太郎」と、ご主人、奥さんの左に書かれる。これのネタ元は、司馬遼太郎さんの「街道をゆく」の飛騨の話。連載は1986年だ。個人情報保護の観点からは、とんでもない話として、嘲りをうけそうな話だが、それなりの理由がある。

14才で元服・成人という時代があって、武士でなくても、14才は大人として扱われていた。武士は明治時代になってなくなったが、その精神は残った。
自分の名前、所属する組織（学校）を出してもらえることで、大人と見なすよと悟らせ、かつ、そこには、「名を惜しめ」「匿名でない自分の名前で責任をもって行動しろ」という意識が息づいている習慣だ。

保護という大義で担保される匿名性を前提に、無責任な言動をする人が本当に多いと思う。勿論、内部告発など、匿名ゆえに、言える事、書けることもあるだろうし、匿名すべてが悪いとは言わない。

バランスが大事なんだが、世のコモンセンスとして、どこが均衡点になるのかは、もう少し時間が必要だと思う。が、IT業界の真ん中の開発会社としては、世の中庸が定まるのは待ってられない。１００％の正解は誰にも出せないだろうが、「外さない」を担保するためには、やはり関心をもって学んでいきたいと思う。

LINUXとUNIXの思想2

UNIXの原点の思想について。覚書２

・ASCIIをもって尊しとする
　データの保存は、原則アスキーファイルする。そのＪＯＢに特化したバイナリデータは避ける。組み合わせることを前提とし、効率より移植性を大事にしていけば、出てくる結論は、ASCIIだ。　ここにはデータに対する哲学が含まれる。動かせない、再利用できないデータは死んでいる。特定の何か（人、アプリ）でしか扱えないデータであるとすれば、それはデータを人質にとられている。処理速度の問題？まあね、でも、それ、来年にはもっと早いマシンになってるんだぜ。


・使えるものは使う。作ったものは使い倒す。
　小さく、組み合わせのしやすさに重きをおいた。勿論、それは自分のコードだけではなく人のコードも、組み合わせて使う。自分のコードも使わせる。UNIXのソースコードは無料で配布されていた。秘密にしておく価値があるのか？

・データをしゃぶる、使いまわす。紙に出さない
　紙に出たデータはそこが終着だ。再利用には極めてコストがかかる。検索もできない、暗号化もできない。そのデータは死んでいる。紙に書くな、書くエネルギがあるならASCII入力してしまえ。
　
・１０％の努力で９０％の問題を解決する
　人の生き死にや、銀行口座のシステムで無い限り、９０％の問題に対応すれば十分なことが多い。残りの１０％を満たすためには、それまでの１０倍のリソース、コストを投入しなければならない。
　

LINUX UNIXの思想 １

言うまでもなくLAMP,LAPPの L は、Linuxだ。
若いエンジニアが 2w3w で訪れてくる時、あるは、社員採用に応募してくるサーバ￥ネットワーク系の技術者から、こんな話あった。「Linuxは自信あります。けどUNIXになるとちょっと・・」

おいおい。
勿論、/etcやらのconfig関係は、ずいぶん変わってきているのは事実だ。最近のSOLARIS10は、従来の定番の管理手法が通用しないという泣き言も聞いている（というか、俺も泣きたい）。
まあ事実ではあるな。

で、質問してみる。
「LINUXでも、HP-UXでもSOLARISでも、共通している考え方、原点の思想ってあるんだが、それはわかるかい？」「最初にUNIXを作った人の考え方とか、使いながら考えたり、体感したことあるかい？」
細かいパラメータの違いは各O/Sにあるのは事実だけど、そんなものをたくさん丸暗記したってしょうがない。いつか変わる。そうじゃなく、変わらない思想や考え方が身についているかなあと、たしかめてみている。何とかなりそうだなあと思える人は半分くらいかな。

いくつかのポイントを書いておく。
文中のUNIXはLINUXと読みかえても差し支えない。

・スモールイズビューティフル
　カーネルも、シェルも、各種コマンドも。小さいからわかりやすい、組み合わせしやすい。組み合わせなんて、今でこそコンポーネントが当たり前だけど、当時としては画期的。

・ひとつのことをキチンとやる
　組み合わせすることを前提とすれば、ひとつのことだけ、きちんとできればいい。ひとつのことのレスポンシビリティを保証すればいい。
　クラス設計をする時に避けるべきことに、何でもやっちゃうウルトラなクラスを作らない。先の小さいことはいいことだとあわせ、これは今でも設計開発に通用する原則だ。（不慣れだとついやっちゃうんだよな）

・さっさと試作する
　勿論、これは機能仕様や要求の整理の重要性を否定するものではない。しかし、聞いても、事前に調べても、埋められないことがある。その時には、ちゃっちゃとプロト・サンプコードを書いて、リスクを減らしてしまう。UNIXそのものには、設計書は存在しない。簡単な機能メモは作られたかもしれない。現在、書店に行けば、山ほどのUNIXの仕様について書かれた本がある。しかし、それらはできあがってから書かれたものだ。UNIXそのものの開発プロセスが、レガシーなウォターフォールを排斥して進められてきている。

・実行速度より移植性
　UNIXそのもの開発者の頃でも、「来年にはマシンの性能は、Ｘ倍になる」と言われていた。チューニングなんて意味がない。基本のアルゴリズムがダメダメで、あまりにムダなことをやっているコードや、腐ったSQLの話は別だが。繰り返し使われ、コールされる回数の多いサブルーチンは、チューンする価値はある。
　最も効率のよいコードは、移植性を犠牲にする。あるいは、もっとも、ユーザインターフェースに優れたコードは移植性を犠牲にする。後の話は最近の携帯電話での開発の余談だ。機種独自機能を使えば、１年後は大変だ。

まあ、HP-UXや今のSOLARISに、原点の思想がどこまで残っているの？は、議論の余地があるのは承知しております。
「変わり果てたからこそ、Linuxだけに原点が生きているんだ」という、よくわかっているグルやウイザードの方々には、私ごときは逆らいません。逆らいませんから色紙にサイン下さい。

PHPフレームワーク Ethna(エスナ)

PHP5用のフレームワーク。今回、初めて仕事に使用してみている。規模は２人月。暫定サービスインは、7/13で、その頃には、結論も出せるだろう。

他のフレムワークと比べて、勿論いいところもあるし、足りないところもあるが、メンテをする人が日本であることが嬉しい。サイトはここ->
画面系がsmartyを前提としているあたりも、敷居が低い。

strutsに構造が近く、Mojaviの人にも、似ていると受けとられている。何より、見通しがいいと思わせてくれている。

PHPフレームワーク phrameとMojavi

phrame は、Strutsの設計思想を継承していて、JAVA/Struts 環境から移行してきたプログラマには、習得の面では、非常に魅力的だと思う。開発する組織・会社で、JAVA/PHPのプログラマが兼務することが多いような場合であれば、教育コストを考えると、悪くない選だと思う。しかし、JAVAとPHPの言語仕様が違う現実の中、PHP用フレームワークとして「最適」と断言するには少し無理があると思う。
調査程度はやったが、実プロジェクトには使っていないので、このへんで。

Mojaviは、非常にシンプルなフレームワークだが、PHP用に作られたが故に、フレームワークのもつ共通のメリットの他に、いくつかの優れた特徴を持っている。

Mojaviを使っているチームや組織も多いでしょう。実際、うちの会社でも、ここ何年か、使ってきた。

PHP5を前提としたフレームワーク

「低コストで短い期間で・・」どのようなシステムでもそうだ。社会の要請といってもいい。
特に、Web・携帯アプリケーション開発に対する要望は、よりシビアな昨今だ。
答えのひとつがフレームワークの活用だが、現在MVCモデリングが主流となっている。
フレームワークのメリットは大きく２点ある。
・MVCに代表されるデザインとビジネスロジックの分離による保守性・生産性の向上
・フレームワークというルールに則って実装することによるコードの均一化、品質の向上
などなど、今となってはわかりきったことだが、Windows プラットフォームでは、.NET 、JAVAプラットフォームではStrutsが、事実上のスタンダートとなり、多くのプロジェクトで使われてきた。

その中で、PHPにはデファクトスタンダードと言い切れるフレームワークがない。
PHP4の成功による裾野の広がりから、その状況が変わってきているが、まだ試行錯誤と言えるだろう。
phrame 、Mojavi、 Ethna が気になるところだ。

PHPの歴史 PHP5の優位性

PHP5は、それ以前のバージョンとは、多くの点が改良されている。PHP4の基本的な文法は、Zend Engineと呼ばれるスクリプトエンジンだった。PHP5が多く使われ出している今となっては、異論も多いが、当時としては、洗練された構造かつ容易に拡張可能な言語エンジンとして優れていると言える。これはそれまで、*場当たり*的な拡張を繰り返してきたPHP3に対する反省と要望の賜物だろう。

Zend Engineは、PHP4を成功に導いた。そのため利用用途もより広範囲・大規模になり、エンタープライズ用途にPHPを利用する・・・という、ある意味冒険的な構築も行われた。（当時の僕なら、そんな選択はできなかったかもしれない。）

こういう利用は、Zend Engineの開発者達の想定を越えた広がりだったと思う。当たり前のことだが、大規模サイトを構築する際のコードの再利用性の悪さといった問題を呼んだ。
技術面か、最も問題視されたのは、PHP4のオブジェクト指向機能の弱さで、JavaやC++に慣れたプログラマからは、不満が多く寄せられ抵抗された。

もちろん、PHP4でもオブジェクト指向機能を徐々に加え改善され続けてきた。世の中にはオブジェクト指向COBOLだってあるんだ。付け加えることぐらいは、できるわな。
しかし、基本的なZend Engineの文法を大きく変更することまではできない。そうなると開発者達それぞれが、職人的努力と技量で、PHPなりの記述方法を新たに開拓し、目的を達成しようとした。
努力は涙ぐましい・・。でも、それに変わる処理系がなかったんだよなあ。
職人のような努力をすればするほど、（目的のシステムはできるけれど）、わかりにくコード群になるわなあ。保守性を切り捨てることになる。

さてPHP5は、これらの問題に、抜本的な解決を与えるために作成された。
各種extensionの対応やPEAR、クラスフレームワークの新機能への対応など、JAVA C++の経験者には、「便利」「再利用性高まった」と思える機能も、PHP3やPHP4*だけ*に慣れたプログラマにとっては、敷居が高くなったとも、考えるべき要素が増えたとも、いえる。

PHP5のもつヨサを生かすには、プログラマーやチームに、スキルが要求される。
僕は、2005-2006年、WEBとIP電話の交換機(PBX)の繋ぎこみゲートウエー構築プロジェクトに、PHP5を選択した。従来であればJAVAまたC++を選んでいただろうが。

他システムとのI/Fすりあわせ等、言語そのものとは無関係の苦労が多いプロジェクトではあったが、PHP5によるコンストラクションそのものや、その後の運用(かれこれ１年）には、何ら問題はなかった。

PHP5でやらせて

LAPP,LAMPの話の場合、つまりほとんどのWEB系開発の場合、特別の事情や制限が無い限りPHP5を使わせてもらいたいとお願いしている。

過去あった特別な事情とは、

・既存サイトがPHP3 PHP4 で作成されおり、プログラム資産の継承が重要な場合。
・利用しているIDCのサービスが、PHP4の利用しかできない場合。
・お客様が、Perlがどうしても好きな場合
・製品版のJVM を用意する予算が有る場合(tomcat はお勧めしない）
・既存のサーバがWINDOWSベースなので、.NetASPでの構築が自然な場合

LAMP LAPP

WEBや携帯サイトの構築において、LAMPあるいはLAPPでの開発のメリットは広く知られるようになり、問い合わせをいただく場合も、それを前提としていることが多い。
実際の受注も、バージョンの差異はあるものの、基本的にこの組み合わせで落ち着く。

LAMP Linux Apache Mysql Php
LAPP Linux Apache Postgresql Php

これは、無償ライセンスでありながら、
・Linux + Apacheの組み合わせの実績、
・大半のWebサイトには必要十分な機能を提供できるMysql Postgresqlの機能
・Java(Tomocat等)よりも軽く安定したPHPの実行エンジン
等が実績として評価されてきたことによるのだと思う。

重宝されているLAPP LAMP ではあるものの、APの規模が大きくなり開発に従事するメンバーが増えてくると、それなりに種々の課題・問題が産まれる。これは別に、LAPP,LAMPに限った話ではないが、LAPP,LAMPも、やはりそれらの課題からは免れない。すべての問題を解決する魔法の手法ではない。
小さな話であれば、品質には大きな影響はなく、やっつけてしまえるものの、規模がある際は、当たり前のシステム構築の手法を積み重ねていく必要がある。