更新停止

当分、このブログは更新しません。

内容的には、All About に書いていきますので、
そちらを見てやって下さいませ。

フォトコンテスト実績

会社の実績として明らかにしていいお客様というのは、そんなに多くない。
なかなか、ブログにも書けないのだが、今回は、大丈夫なので。

pbSTUDIOという、携帯とPCから写真応募を受け付け、審査や事務局の管理機能も提供するASPサービスをやっている。

http://www.atlas.jp/service/pbstudio/index.html

今回は、ノバルティス ファーマ（株）様に、お使いいただくことになった。

http://www.novartis.co.jp/campaign/photo2007/index.html

ASPとしての提供するので、システムはコンテスト期間中のみ、使っていただく。
同時に、システム運用や、システムでお預かりする個人情報のセキュリティの確保も含め、自分達の責任にて行う。実際、かなり気を使う。

葬儀の時の故人の撮影

pbSTUDIOについて、セッセとコラムを書いている。( AllAbout 向け)
カメラ付携帯で、簡単に応募できる写真コンテストのシステムなんだが。
実績やら想定事例やら、10/20から連続で１週間ほど出していく予定。

そのコラムを書きながらフト思い出した。東京の西のほうにある葬儀屋さんに行った時のこと。
サイト構築の話で行ったが、会社案内の時に、pbSTUDIOの話もしたら・・。
「最近の若いのは、葬式で、写メ、ってのとるんだよね、故人の・・。」
「そりゃあ、遺族の方は、いい気持ちされないですよねえ」
「難しいねえ」
「・・その写真コンテストって、やっぱまずいですよねえ」
「この業界（葬儀）も、どんどん変わってきて、新しい考え方も取り入れるべきとは思うんだがねえ、さすがに、まだ時代が早すぎるなあ。」
「いやあ・・時代が変わっても、そりゃ、ないでしょう」
「あんた、あいてい　とか仕事してるわりに、古い奴だね」

まだ、バカ話続いたが、このへんで。以上、葬儀社の専務さんとのお話。

５年後の未来

そんな未来でもないけどね。

今日の売り上げも大事だけどさ、５年後、みなと、笑っていたいわな。

自分の名前をググる

今までも時々やっていたのだが、上位に出てくるのは、千葉と奈良の造園の会社の同名の人でした。
コラム公開から半月、しっかりＴＯＰに出てくるようにはなった。

まあ実名と顔さらして・・・。誰かが言ってたなあ、「この業界、2chで、実名さらされて、一人前だよ。」う～ん、きっとうれしくないと思う。

AllAboutのコラム掲載開始->アクセス集計５日分

ソースにダンスを躍らせて: AllAboutのコラム掲載開始

8/30にOPEN、9/3 までのアクセス集計結果が出た。
５日間で、露出は670で500PV 。一日100PVか・・。
露出からＰＶへのつながりもそんなに悪くはないな。

９月で3000PVになるって感じかなあ。
立ち上がりとしては、上出来じゃないかしらん。

AllAboutのコラムはここ->

一応、毎日更新してます。

このサイトの値段は！ 2

如月乃庵: このサイトの値段は！で、2,400円だったけど、今日、3200円になった。（サイドメニューの右下）

800円単位であがっているなあ。
なぜ、800円？

更新できんぞ

AllAboutのコラムで、エネルギーとられてる。ブログまで、力がまわっておらん。

PMARKの更新申請も、バタバタで、今日やっとこさ。

AllAboutのコラム掲載開始

先ほど、AllAboutのコラムの公開を開始。
公開予定機能があるので、１週間分は、公開をスクジューリングした。

http://profile.allabout.co.jp/pf/terutakahashi/column/list/

さて、どうなることや。

セキュアプログラミング

WEB セキュアプログラミング

古くからEDPやシステム運用や開発をなされて来た方なら、驚かずに読んでいただけるでしょう。WEBシステム、携帯サイトのシステムというのは、本質的にかなりの危険を含んでいます。不特定多数の人間にＤＢの更新を伴うオペレーションを当たり前のように許可していますが、一昔前のシステムであれば、DBの更新などは、少なくともその組織の中の人間しかありえないと特定できましたが、今はそんなご時世ではありません。

セキィリティの問題は、運用するネットワークやサーバの管理者だけで解決できるものではありません。実は開発者サイドで留意しておくべきことがいくつかあります。ある程度の規模をもつシステム会社さんだと、ちゃんと意識して開発していらっしゃいますが、時々、社内の若い担当者が少しCGIの勉強をして作ったんじゃないだろうかと思えるようなサイトも見受けられます。
もしこれを読んでいる方の中に、サーバ運用担当、システム導入担当の方がいらっしゃいましたら、現在、管理しているサイトのプログラムについて、一度確認をされることをお勧めします。以下の項目は、言語に依存しない事項で、ソースを見なければわからないこともありますが、ブラウザからわかることもあります。

・入力データのチェックをクライアント側スクリプトに頼っていない。
　　　-->ユーザの利便性を求め、JavaScriptを多用するサイトで見受けます。
・全ての入力データからHTMLタグとなりうる文字「<」「>」を取り除いている。
　　　-->100% NGではありませんが、許可する場合は、
　　　　　相当な例外コードが必要です。
　　　　　意識して十分な予算と開発期間をとりましたか？
・HTMLにデータを埋め込む際には必ずHTMLエンコーディング
　　（「<」「>」「&」「"」「'」→「<」「>」「&」「"」「'」の置き換え）
　　　をしている。
　　　-->詳細仕様の議論の際に話題になければ
　　　　　省略されている可能性があります。
・保護が必要な全てのページにユーザ認証機構を組み込んでいる。
　　 -->WEBに不慣れなシステム会社が時々やります。
・事前に推定可能なセッションIDを用いていない。
　　　-->やはりWEBに不慣れなシステム会社が時々やります。
　　　　　また逆にWEBしか経験のないSOHO系のエンジニアが時々やります。
・重要なデータのキーをURLのクエリストリングで受け渡していない。
　　　-->100% NGではありませんが、やる場合は熟慮が必要です。
　　　　　弊社でも、他サイトのシステムとのI/Fのため
　　　　　（先方のミドルウエアの仕様）でやむを得ずやったことがありますが、
　　　　　最低限キーをジャミングする必要があります。
・hiddenフィールドでデータを受け渡していない。
　　　-->100% NGではありませんが、やむを得ずやる場合は、
　　　　　クライアントからの値を信用しないことを前提としたサーバサイドの
　　　　　コーディングが必要です。

このコラムでは割愛しますが、チェックすべき項目は、その他、ＤＢ周りのコーディング、それぞれの言語に依存した項目にも、重要な事柄があります。
IPAのガイドライン等には、一度は目を通し、開発パートナの選択や社内開発に際に、留意いただくべきかと思います。

サイト構築：ゴールのページはどこですか？

Google Ａnalytics をご存知の方は多いでしょう。無料で提供されているアクセス解析、トラッキング解析ツールです。もしご存知なければ、Google Ａnalyticsで、検索してみて下さい。
万能ではありませんが、なかなか優れものです。
これが無料で公開されるまで、私たちもアクセス解析の仕掛をお客様に提案してきていたのですが、実際に自分達で使ってみて、これだけのAPの構築と維持を続ける予算をお客様からいただくなら、サイトの他のこと（機能やサービス）に使ってもらったほうがメリットがあると考えています。利用するためには、各ページにJavaScriptを入れておく必要がありますが、WEB系の開発を行っている会社であれば技術的なハードルになりません。既存サイトのHTMLに入れていくとなると、ページの数だけ手間はかかりますが、リニューアルの際にあわせて行えば、わずかな費用で実現可能です。
Googleに統計情報でも把握させたくない、Googleを信用しきってはいけない社会的立場がある、というクリティカルな会社様や組織でない限り、お勧めしています。

そのGoogle Analitics の機能の中に、「コンヴァージョンの達成」の測定があります。サイトを訪れた方が、最期に何をして欲しいのか、最期にどこのページを見て欲しいのか、そこに至ることがコンヴァージョンの達成です。

サイトを構築する際、あるいはリニューアルの際、意識しておきたいのは、そのゴールページです。ゴールは、ひとつである必要はありません。
ECサイトであれば、商品の購入でしょう。販売サイトでなければ、資料請求やメルマガの購読申込、お問い合わせフォームで見込み客の情報登録をしてもらう・・などでしょう。すでに自社製品を購入された方に商品のメンテナンス情報をPDFで提供するからPDFのダウンロードをしてもらえればいい、という場合もあるでしょう。

ゴールが決まるといろいろなことが検討しやすくなります。
サイトのすべてのページは、そのゴールページへ行きやすくなっているでしょうか？
あるいは、PDFは単純なダウンロードだけでいいのでしょうか？　誰がダウンロードしてくれたかは、その後の営業フォローに役に立ちませんでしょうか？メールアドレスだけでも所得したほうがいいのではないでしょうか？

サイトの目的が販売であれば、売り上げ＝効果で、単純な効果測定ができます。しかしそうでない場合でも、サイトや投入したコンテンツは効果測定を行っていくことが重要です。
効果測定をしておかないと、次に投資するべき事柄、予算を使うべき優先順位は見えてきません。

一番ゴールにつながったページはどんなページだったでしょうか？
一番効果のないページはどんなページだったでしょうか？

今までの広告は、数、露出度が重要な要素でした。ＴＶでも電車の広告でも、あまりターゲットを絞れず、インプレッション（露出）の数や、絶対的刺激度で勝負してきたかと思います。広告を見る人は、自分に必要かどうかを選ぶことができず、とにかく興味があろうがなかろうが、目や耳に入るようになっています。
しかしWEBの場合、ユーザは、必要な情報を選択（検索）して閲覧します。必要でないことは目にふれさせることさえできませんが、必要としている・興味を持ってくれたユーザは、整理された見やすい情報であれば、ＴＶのＣＭ以上に熱心に見てもらえます。

WEBサイトをビジネスに役立たせるためには、いくつか持つべき手段がありますが、そのひとつがアクセス解析です。統計を得る手段は無料で使えるようになりました。解析の入口は、ゴールの確認と、そこに至るための効果的なページの認識です。

もっとも、アクセスや数値データで測れない事柄も存在します。
「社長挨拶」や「会社概要」がこれにあたりますが、仮に、どんなにアクセス数が少ないという結果が出ても、例外はありますが多くの企業の場合、省くべきでないのは自明かと思います。

AllAbout

AllAbout プロファイルにコラムを出すことになった。７月から話があって、ぼちぼち準備をしてきたが、9/1からいよいよ。

このブログは書きなぐり ^^;;だったが、AllAboutは、少しは丁寧に書かないとなあ。

AllAbout用の下書きも、このブログに一度UPすると思います。

OpenしたらURL貼っておきます。

携帯サイトを構築したい

携帯サイトを自らのビジネスに生かしたい。最近、地に足の着いた会社さんからも、そのようなお話をいただくことが多くなってきました。
１,２年前ですと、「これからは携帯だ」と、ハッキリしたビジネスの地盤、勝算やプランもないままで、携帯によって新しいビジネスにトライする、あるいは、新しいモノにすぐにチャレンジする体質の会社さんが多かったと思います。
ひどい話だと「今、サラリーマンなんだけど、辞めて携帯で儲けたいんだけど、何かいいアイデアない？」というような個人の方からの問い合わせもありました。

現在、そういった有る意味軽薄な騒ぎは終息しています。いよいよ本当にビジネスのツールとして、本業の強みをちゃんと持っている会社さんが、携帯サイトを手段として、地道ながら真剣に考えるようになってこられたと思います。

WEBでも携帯でも同じで、私たちが最初にお話をいただいた時に考えるのは、その会社様にとってサイトの構築の目的や目標は何だろうという点です。
ECの販売サイトであれば、比較的簡単な話で、集客し、商品を購入してもらうことがゴールです。その商品を買ってくれそうなターゲットについての仮説をたて、それにあわせたプロモーション、マーケティングの仕掛を実現するシステムにしていけばいいわけです。サラっと書きましたが、勿論、ケースバイケースでイロイロ課題はあります。

携帯サイトはＷＥＢサイトに比べ、いくつかの特質があります。
情報量の少なさ、文字入力の操作性の悪さ、にも関わらず、若年層に有効なアプローチ方法であるということなどです。
お客様のターゲットの年齢層が高い場合、あるいは個人を対象としていない会社である場合ですと、携帯サイトで何をするのかハッキリさせておかないと、無駄なシステム投資になりかねません。おそらくそういった会社ですと、携帯サイトの構築がそのまま売り上げに直結するかどうかは、疑問が残るでしょう。
しかし、そのような会社でも、若い世代へのリクルーティング、あるいは企業のイメージ戦略の一環として用いるのなら、有効な手段となるでしょう。

携帯サイト構築の重要性や、そこに期待する役割は、会社様によって様々です。
国内の自動車メーカのWEBの統括責任者のお話を伺ったことがあるのですが、
「WEBサイトのアクセスに比べ携帯でのアクセスは１０％に過ぎない」
「車を購入するため情報を欲しがる人にとっては、携帯の表現力では不足している。」
「今現在だけで言えば、携帯からのユーザはまったく重視していない。販売にはほとんど繋がっていない。」
「が、中期的には無視できない。携帯で企業のメッセージ、イメージを伝える努力はこれから重要になってくる。WEBの情報を携帯で出すのではなく、携帯を使うユーザに特化した別の情報を提供することで、効果がある。」
その一方、海外から若い女性向けの商品を並行輸入し販売している会社様ですと、
「携帯で売るのが一番大事。」
「WEBより携帯、ことに深夜のアクセスが非常に多い。」
と、携帯サイトには、積極的に投資をしておられます。

漠然とでも携帯サイトの構築をお考えでしたら、企画・検討段階でも一度お話させていただければと思います。場合によっては、「携帯サイトは、現段階では構築する価値が無い」というアドバイスになるかもしれません。携帯サイト構築の売り上げの多い会社としては、商売として困った話なのですが、「代わりに、こういったことをやりましょう。」というご提案ができるかもしれません。

WEBや携帯に限らず、システム構築の仕事は初期構築だけでは終わりません。長いお付き合いがすることが大事だと思っています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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も、やはりそれらの課題からは免れない。すべての問題を解決する魔法の手法ではない。
小さな話であれば、品質には大きな影響はなく、やっつけてしまえるものの、規模がある際は、当たり前のシステム構築の手法を積み重ねていく必要がある。

オブジェクト指向 のメリット まとめ

ユーザー・クライアントは、何らかの問題・課題を解決したいが故に、システムを構築する。
オブジェクト指向は、その問題領域の要望・要求の構造と振る舞いを、オブジェクト群とそれらの連携（協調）で、モデル化することができる。
システムのデザイン・設計とそのアーキテクチャも、オブジェクトとそれらの連携
コンストラクションの単位もオブジェクト
再利用・部品化・共通化の単位もオブジェクト。
ユーザの業務から実装まで、オブジェクトという考え方で、トレース可能なものにできる。

ユーザ・クライアントの基本的な考え（コンセプト・ビジネスモデル・ワークフロー）を、抽象化して計算機に入れてしまう。ユーザ・クライアントの心、気持ちを、忠実にシステムに反映させる。

オブジェクトは、極めてカプセル化され自立している。そのオブジェクトに機能が不足している場合、継承で新しいオブジェクトを作る、隣に別のオブジェクトを作りメッセージで繋ぐなどができる。

カプセル化により、中をどうしようと、システム全体としては、問題にならない。オブジェクトの外側のI/Fはそのままにしておき、アルゴリズムを変える、チューンする。I/Fが一緒の別のオブジェクトと入れ替える。

業務から実装までトレース可能なオブジェクト指向だか、その記述に使われるのがUML。

クラス図だけとは言わず、入り口から使用しないと、ありがたみが減ずる。

コンストラクション（設計・プログラミング）の準備

顧客に言われて、いきなりコーディングをするような仕事は、まあ、ほとんどない。コンストラクションにかかる前に、準備がどうしても必要だ。いわゆる上流工程だ。
イテレート、インクリメンタルの開発手法をとるにしても、この上流の重要度は変わらない。
今の仕事の情況では、20-80 が目安だと思っている。すなわち、プロジェクトに関わる総エネルギーの20%を費やして、80%の要求を洗い出し確定させる。
少なくとも、PMが「要求と設計は、かなり精査した。コーディングやデバックで致命的な問題は出ないだろう」と確信できるまで、コンストラクションにかかるべきではない。

もっともこれは、それまでに１行のソースも１個のクラスも作らないと言っているのではない。特に新しい技術要素を利用する場合は、準備段階での、サンプル・プロトによる評価は必須となる。

WEBブラズザベースの構築では、要求を確認するため、HTMLで紙芝居をつくり、クライアントと画面遷移を握っておくと、ほとんどの問題は潰れる。
他システムとのI/Fがあるなら、何より、実際のデータ（サンプル）を求める。設計だけでは、わからないことがある。

順番としては
課題・問題の定義(ゴール設定) ->要求仕様 ->アーキテクチャ確立->コンストラクションとなる。

関連する参考書としては、PMBOKガイドは一読しておきたい。2005年版は2000年版の１．５倍だが、書棚に持っておくべき。

アマゾン->プロジェクトマネジメント知識体系ガイド第3版 A Guide To The Project Management Body Of Knowledge

開発手法・プロジェクト管理手法

いくつかの本を読んではきたが、大半の手法が、排他的な姿勢だ。
つまり、この手法以外じゃ、失敗しますよ、これが絶対普遍の真理ですよ、あなたは神を信じなさい。

ハッキリ例外だったのは、XPだった。「使うべきではない」ケースをしっかりうたっている。

腕のいい大工は、その仕事にふさわしい道具を知っている。
腕のいいプログラマは、その案件にふさわしい言語を選ぶ。

官公庁相手の仕事であれば、仕事をしたことを証明するために、多くのドキュメントが必要だ。しかし、３ヶ月のキャンペーンで、使い捨てにするWEBサイトであれば、ドキュメント云々より、その間、動向を見ながら、走りながら治していくことが大事だ。

チームのあり方、プロジェクトの進め方を、一律のモノサシで測ることはできない。

プログラミングの例え4 システムを構築する

システムを構築する。建設をイメージできると思うが、このメタファが一番自然に思える。

小さい工事、それこそ、家の壁に、棚をつけろと女房に言われたなら、ちょっとした採寸とメモで、材料を買って、製造に取り掛かれる。
けれど、セルフビルドでも、家を建てましょうとなると、綿密な計画、プランが必要になる。
ましてや、ビルでも建てるとなれば、家の比ではない。

システム構築は、その規模や目的によって、採用するべき手法が異なる。

情報を見せるだけのWEBサイトと、決済、取引を伴うサイトを同列に扱うことはできない。
２０ページの企業情報を乗せたいサイト構築と１０万ページのコンテンツをもつサイト構築を進めるのに、同じ手法は使えない。

プログラミングの例え 3 アクリエーションする

システムをアクリエーションする。

こういうメタファも使われだしているようだ。

ほんと、メタファ好きだよな

真珠養殖ということなんだが・・。

母の貝が、じわじわと真珠を大きくしていく姿は、イテレート、インクリメント開発に、イメージが近い・・そうだ。

チームの構成員が真珠養殖を良く知らないと、このメタファの使用は無理がある。

プログラミングの例え2 システムを育てる

クライアントさんのシステム担当が、愛情をもっている場合、「育てる」といいたい気持ちもわかる。
いきなり最終目的に行こうとあせるクライアントに「システムは育てるもんですよ」と言ったことも確かにある。

新しい処理系をモノにしようとする場合、hellow worldから、コードを増やしていく。

インクリメンタル、イテレートのプロジェクトにも、当てはまりそうだ。

しかし、まあ、「育てる」と最初に言い出した本人（例のごとくメタファ好きの西洋人だが）は、農場をイメージしていたらしい。秋になるとコードを収穫する・・。う～ん。そうなるとちょっとね。

プログラミングの例え 1 コード（ソース）を書く

コード（ソース）を書く
　ひとつ捨てるつもりで。どうせ書き直すことになる。（Fred Brooks)
ひとつ捨てるつもりだったら２つ捨てることになる(Craig Zerouni)

　書くという比喩、メタファは、プログラムに合っているのか？

　自分ひとりでできる分量をプログラミングして、稼動させるなら違和感はない。
　ひとりの作品として、書く、著述するで、いいかもしれない。

書くとは、オリジナリティが伴う。ソフトウエアは完全にオリジナルだろうか？フレームワークに乗って、クラスライブラリを組み合わせて、他のサイトのサービスを利用して、目的を達するシステムを作ることを、書くというには、無理があるんじゃないかなあ。

　ないものは全て作る、すべて書くという、古の伝説のプログラマ達であれば、「書く」もいいだろう。

　だいち、もう、１人でやる仕事なんて、ほとんどない。

メタファ好き

チームでプロジェクトを進めるとき、メタファの良し悪しが、システム分析やデザインを共有する際、大事だったりする。問題領域を共有するような時にも有効なテクだ。

XPでも、重視してるし、CodeComlete なんかでも。

そういや、新約聖書のキリストの話は、例え話が多く、考えようによっては、メタファだよな。
釈尊は、「こんなことがあった」式だったと思う。（すこし記憶あいまい）

西洋人は、メタファが好きなのか？
抽象化、モデル化って、彼らの民族的なバックエンドにあるのかなあ。
日本人の「恥」の文化みたいに、彼らは子供の頃から、無意識にモデリングをやってるのかしらん。

別に、洋物の技術書を、「舶来物」ありがたく拝する世代ではないつもりだが、けっこう名著、古典って、日本人の書いたもの、少ないよなあ。

支払いサイト

うちの支払いサイトは、月末で締めて、翌月末に現金振込みにしている。
個人事業主、あるいは、一人会社さんを相手にしていると、時々、いろいろな相談がある。
このあたりは、社長が苦労人？で、資金繰りの切ない時代もあって理解があり、事情に応じて、できるだけの融通はお願いしやすい。
とはいえ、頼まれてもダメな例、断る例もある。

ＯＫした例
「今回の請求分*だけ*、３０日後ではなく、早めにお願いできないか。」
毎回のことじゃないし、もうすでに、その月の成果物収めてるし、たいていの場合、ＯＫしてます。

ＮＧの例
「毎月の支払いサイトを３０日ではなく、１５日でやって欲しい」
これは、ダメ。取引条件は、原則一律だし、例外的にその時だけのイレギュラー対応ならともかく、常態にするわけにはいかない。

常連と一見 エステサロンの噂話

お茶を飲みながら、隣の女性二人から、聞くともなく聞いてしまった話。

「ＸＸＸＸってさ、最近、雑誌だかに、でちゃったらしくてえ、な～んか変な客増えたのよね」
「そうそう、それがもう、偉そうでさあ、何様だと思ってるのよ」
「あたしなんか、怒られちゃったわよ。うるさいです、とか。なんで、初めてきた子供に、そんなこと言われなきゃいけないのよ。店員に言ってやったわよ、怒られちゃったんですけどおって。そしたら次行った時、オーナが出てきて、すいませ～ん、って。」
「まあ、そのうちまた静かになるといいんだけど」
「静かにならなかったら、回数券がなくなった、もう行かないわよ」

さて・・。
来客が増えれば、とりあえずに売り上げが増えて、店はうれしいわな。
でも、それだけじゃ、割り切れないこともある。

老舗の食料品を扱う店が、全国展開をして、売り上げは伸びたけど、味が落ちて、常連が離れる。
味が落ちないまでも、希少性が薄れ、誇りを失う。
職人は辞めていき、生産ラインの工員は残る。
モノの維持はなんとかできても、次の発展のコアは、もうない。

de マーケティング。
ブランドだと、製品そのものの工業的価値より高い値段をつける。
単体の利益より、その値段でもいいという人レイヤーの人しか客になって欲しくない。
夢？虚栄心？満足感？そういったものを売るわけだし。

銀座の飲み屋も高いよなあ（笑

業態、業種、そしてターゲットによって、価格設定、ＰＲの範囲、適正な業務規模ってあるんだろうな。
商売をする以上、拡大、成長することを否定するわけじゃない。
だが不自然なことは、自分たちの強みを捨て、成長の原動力を損なうことを、忘れずにいたい。

ディズニーランド

楽しませつつ何かを見せる手本として、ディズニーランドは優秀だ。
１０年以上前、美術館の学芸員さんから聞いた。
当時は、美術品をヨク見せるという観点からの見識で、それは留意してみていた。

WEBの導線、プラニングの立場から、やはりディズニーランドは参考になると、最近聞いた。
人の誘導の仕方、待っている間も楽しみに変える工夫。
インタラクティブなWEBプラニングするなら、ぜひ、その視点から見ておくべき、と。

おじさん一人で行くのも、職場の野郎どもと一緒にいくのもイヤなので、家内と行ってこよう。

会社法の改正

昨年、会社法が、改正・施行されている。

一人でも、資本金が少なくても、株式会社を作ることができる。
まあ、内容的には、有限会社とか合名会社と同等なんだが。

個人事業主を、主に対象としていたが、そういう法人さんからの問い合わせも出てきている。
「法人でもいいですか。」

勿論、かまわない。
自立して、独立して、社長になるってのも、ひとつの夢として悪くないことだし。

だけど、会社にした以上は、資金繰りでの泣き言、タマにはいいけど、毎月はしないでね。
一応、うちは、当月末締め、翌月末、現金振込みで、そんなに悪い取引条件じゃないんだから。

ヤン・アルチュス=ベルトラン写真展 空から見た地球

展覧会・美術館・独り言: ヤン・アルチュス=ベルトラン写真展 空から見た地球

フジフィルムのやっている、ショールムでの展示会。
１訪問者として楽しめました。

WEBで、B2Cのモデルを考えたとき、企業が伝えたいメッセージを、そのまま出したんじゃ、カスタマーには拒否される。

今回で言えば、「写真すごいでしょ、富士フィルムの技術は優秀です。」
でも、それを書いた、コンテンツなり展示なりしたところで、面白くないと、メッセージを伝える前に、来てくれない、立ち去ってしまう。

苦い薬・メッセージを飲ませるため、非常に楽しい展覧会、コンテンツを用意して、メッセージをすべりこませる。

WEBの企画を考えるとき、企業側のゴールのメッセージ、あるいはアクションを規定して、それを達するためのコンテンツを考えるアプローチは、有効だなあと思わせる展覧会だった。

NOVA コムスン

おさがわせ中の２社の社長
事業をする人間として、持っている才覚、嗅覚、エネルギー。
僕などよりも、１段も、２段も優れた人たちなんだろうと思う。

何かを間違えた。
たまたま運が悪く失敗したではなく、何かを勘違いしている。

その何かを、うまく説明できないんだが、誠実とか正直とか、まっとうとか。
法律には触れないけど・・で儲けるなんてことは、もしかしたらバブルの頃は、それでも良かったのかもしれない。
だが、これだけネットが使われ、バズ・コミュが無視できない以上、最後にモノを言うのは、本物かどうか、そして、本物であることを知ってもらう健全な努力だと思う。

年金問い合わせのフリーダイヤル

朝日新聞から。
問い合わせが殺到し、派遣会社からオペレータを増員して対応しているが、ロクに訓練もできず、「すいません、数日経ってから、おかけ直しください。」と、答えさせているそうな。

まあ訓練、教育のできたオペレータを、急に大量に用意できない現実はわかる。
回答するためのコンピュターの端末も足りないから、調べることもできないってのも、たしかに現実だろう。

けどね、ＣＳからいやあ、最悪だよ。

せめてさ、連絡先を聞き出して、「担当からあらためてご連絡させていただきます。混雑しておりますので、ご連絡に１週間ほど、かかるかもしれませんが、ご容赦ください」とか言えよ。
受付番号をお伝えして、紙でもいいじゃん、記録して、本当の職員が、順番に電話していけよ。
とりあえず、あやまっておけばいいから、みたいな人の使い方は、どうしょもないなあ。

客商売だったら、当たり前のことが、どうしてできないんだろうなあ。

B2B2C Valueエクスチェンジ

B2B2CのWEBサイト。

2w3wもサイトだけでとらえると、そう分類できるかもしれない。

B2B2Cの場合、企業と個人とで求めるものが違い。そこをうまく変換することが、サービス提供者のモデルやプラン作成になってくるわけだが。

2w3wの場合はどうだろうと振り返る。
技術者の要望と、企業のニーズと、本質的は相容れないものかもしれない。
サービスを提供する僕たちは、そこをうまく変換できないといけない。だが、事実や現実を不自然に捻じ曲げるのではなく、事実を正視し、現実の「おとしどころ」、「にぎれる」ところを模索する。

エクスチェンジというより、ネゴシエートで、本質はWEBやテクノロジーの枠内で納まることではない。

いろいろな事情

こないだ来た人の話。

ネットワークやサーバーのキッティング・セットアップができる。
家には１０台のＰＣを持ち、３台のサーバで遊んでいる。

ずっと、この業界で仕事をしてきた。が、家の事情もあり、いよいよ医者にならなきゃいけない。単価はどうでもいい。ただ、勉強する時間がとれる仕事を探している。

自社の受託案件では、マッチする業務はない。
開発だと、どうしても期限・納期が迫ると、稼動は長時間になるからなあ。

オーバスキルだけど、単価について妥協の余地があるということなので、ヘルプデスク、オペレーション、サーバーキッティングの業務を中心に探してみることに。

納豆チョコレート

今年に入ってからだが、身近な人、客先現場にいる人の誕生日に本を贈ることにしている。
大半が、技術書。
Code Complete とか、ソフトウエア職人気質とか。以前書いた古典的技術書にリストされているような本。
相手によっては、ビジネス書だったりもする。

客先に行っている人にメールした。
「誕生日おめでとう。プレゼントに、ＸＸＸＸという本を贈ろうと思うんだが、読んだことあるかい？」
返事
「覚えていてくれてありがとうございます。もらえるもんは、何でももらいます。珍しいお菓子とか・・あと、珍しいお菓子とか。ジンギスカンキャラメルは駄目です。」

どうやら、技術書より、珍しいお菓子がほしいらしい・・。

わかったよ、技術書も送るけど、珍しいお菓子も用意するよ。
で、水戸に行く用事があったので、常磐道の友部ＳＡで、「納豆チョコレート クローブ風味」をＧＥＴした。

人には、勧めません。

年間８５万台

どうでも、いいっちゃあ、どうでもいいが。
イギリスでは、年間８５万台の携帯電話がトイレに落ちているそうだ。

ちょっと信じがたい数字ではあるが、人口に対してだと、1.5%。
１００人の会社なり組織なら、１人ないし２人か。
そう考えるとそれぐらいは、いるような気がしてきた。

僕は一度落として以降、首にかけてるし、アドレスデータも対応するようにした。
アドレスは、ＰＣが正で携帯がサブセット。機種変でも、それほど苦労しなくていい。

どうでも、いいっちゃあ、どうでもいいけど、８５万件がインパクトあったので。

モバイルサイト

ある上場企業（製造業）の話。

毎月100万人のユニークユーザが企業サイトを訪れる。コンテンツは10万ページ。
今は、90%がPCで、モバイルは10%に満たない。
だが、この状況は、２,３年で変わるだろう。
今は、「モバイルサイトを作らねば」ではない。しかし、もう無視できない時が、確実に来る。

コンテンツの質も大事なことだが、まず量も、企業サイトにとって重要な問題となる。
必要とされる情報はロングテールまで。維持のインフラコストは、問題にならないのだから。

あとは、コンテンツを効率よく増やしていく仕掛け。システムと体制。
今から、これを準備しておくか否かは、大きな差になるだろう。

一方、その時に、現在の３キャリア別のタグなんてシカケが残っているだろうか？
流れは、フルブラウザと思っているのだが。

WEB・ネットのパイ

例えば、yahooでも、昨年ぐらいから、サイトを利用するユニークユーザの数は3800万程度と推定され、頭打ちになっているという。
もうネットを使う人そのものの増加は多くは望めず、パイの取り合いになった。
ま、人口自体が減っていくわけで、無理からぬ話ではあると思う。

企業のWEBサイトそのものの意味・意義が変わってきている。ある一定以上のアクセスのあるサイトであれば、それこそ、リサーチ会社を不要としてしまう。そのサイトそのものが、マスメディアに近い力を持つ。
自らがメディア足りうる時代になった。宣伝・広報の媒体の利用方法が変わる。

僕らの提案や営業が、顧客のビジンスの成功を意識した時、ともに考えるべき事柄として避けて通れない。
また、そこに営業的な勝機を感じている。

WEB広告営業職セミナー

株式会社宣伝会議のやっているWEB広告営業職セミナーに行くことにした。

自分の経歴からすれば、異分野ではあるが、ここ数年、必要性を感じていた。

システム構築の話で、顧客と話をしている中で、サイトを知ってもらう、収益をあげることについて、ちゃんと話を理解して、それなりの話ができないといけないなあと。また、広告も含めて提案できれば、顧客にとっての利便も図れだろうし、ビジネス拡大のチャンスにもなる。

ただ「プログラムが書ける会社です」だけじゃあ、生きていくのが難しくなるかもしれない(笑　という危機感もあるしね。
６月６日から１０回。水曜日の夕方からミッチリと。
まあ、基本的に、「知らないことを知る」喜びってのは、エンジニア出自の特質かもしれないので、楽しみにはしてるけどね。

会社は誰のもの

日経新聞のネタ。

内部統制が需要になってきたが、内部統制を進めるのは何のため？そりゃあ、会社のためだ、と。じゃあその会社って、誰のモノなのかしらん。そいつを考えましょうや、考えとかないと、内部統制進めようとしたところで、うまくはいきやせんぜ、と。

法学と経済学と経営学の立場からのコメント

法律、商法等では、会社は、株主のもの・・になる。そりゃそうだ、と。
経済学の立場から、資本の有効な活用、経済発展の寄与等から、株主のものと考えるのが妥当・・だそうだ。（オレは専門家じゃないので、コメントできん）
経営学の立場からは、上記を踏まえて、会社の存続には、それ以上の意義を経営者は持たねばならないとする。株主だけのもの・・とはいえない。
その日の記事は、そこまで（続く）

日々の日銭稼ぎに追われているけど、考えておかないとなあ。

ベッカー「人的資本」

経済学の名著だそうだが、それはおいといて。
企業が社員を教育する時、そこにはコストがかかる。そのコストの負担を、どこに求めるのかという洞察が面白い。
会社がもつの？個人がもつの？

これを考えるときに、汎用性のある教育と特殊性（その企業特有の）教育とをベッカーさんは、別けて考えている。

汎用性のある訓練、教育によって人的資本の価値をあげる際、教育投資とそれを回収する期間を考えれば、長期雇用できることが、企業側として必須条件となる。要するに教育に使った金の分、働いてね、と。

逆に、特殊なその企業でしか通用しない知識の場合、ヨソでは通用しない知識であれば、従業員にとっては、長期間働けるという保証がないなら、特殊な教育を受けるべきではない。従業員にとっては、ヨソにも行けないデッドロック。

さて・・。
SOX のセミナー無料でやるから、２年は契約して働いてね、という会社がある。
組み込み・制御系、未経験でもいいから、３年は契約してね、という会社がある。
SOXは、当分需要があるだろうし、組み込みは、特定の処理系に依存しない考え方が身につけば、悪い話じゃないと思う。
が、オレも一緒だけど、常に、その次・・を意識していないと、食い詰めるだろうなあ。

三角関数

２０代のころ、文学部出身の僕は、理系出身のプログラマーにかなりコンプレックスを持っていた。プロッターでグラフを描画するのに、座標を求める必要があるとき、サイン、コサイン、タンジェントが必要だった。

僕が苦労していると、理系出身のＴ君は、当たり前ジャン、常識ジャンと、ちょこちょこと、１ー２行書いて、ホイと渡してくれた。ああ、オレは、この先ＰＧとしてやっていけるだろうか、向いてないんじゃない？とか、けっこう悩んだわ。

だけど、仕事やってく上で、文学部ですからあ、なんていい訳できんしねえ。知らんかったら、調べりゃいいじゃん、以上。

今でも、三角関数は、調べないと思い出せない ^^;;
けれど、調べる方法は、インターネットをはじめとして、ものすごく豊富になってきて、困らない環境ができている。

ＰＧ・ＳＥで、ずっとやってきて、今、営業のような？仕事をしている。
最初は、言い訳してたかもしれない。「おれは、技術者だ、営業は素人だ」
でもね、何年もやってたら、「営業は素人」だなんて、言ってられないんだ。
やらなきゃいけないとなれば、それでメシ食おうとする以上、プロになんなきゃ。

三角関数を覚えてなくても、なんとかなった。
今も、立派じゃないけど、何とか、何かの間違いで、幸運と周囲の人に支えられて・・・何とかなってる。

10年生き延びた本（古典的技術書２）

古典的技術書の続き。

IT、ソフトウエア関連の本は、巷にあふれている。中には、その製品のマニュアルの引き写しそのままだったりする。

そうでないまでも、特定の言語、特定の処理系、特定の技術エンティティに特化した内容のものが多いよなあ。もちろん、そういう詳細を説いた書物って、実用性という意味では優れていて、「高いなあ」と思いつつ、けっこう購入してきたし、たぶん、これからも、昔ほどではないにしろ、必要に迫られて少しは買うんだろうなあと思う。
でも、そういう本って、寿命が短いよね。それらが良書か悪書かという議論じゃなくて、流行の旬の技術要素って、どんどん変わっていくし、そういう本は、その流れにあわせて、どうしても消えていく。十分に実用性があってもね。

そんな中で、１０年以上という歳月、生き延びてきた技術書は、時代を越えて通用する概念や考え方があると思う。
製品やプロダクト、処理系、フレームワークは、これからもどんどん変わるだろう。この業界で仕事していく決心をしているなら、それらの本ににある時間を越えて通用する概念・知識こそ、身につけていきたいし、部下、後輩、仲間に、身につけてほしいと願う。

だけど、これがけっこう大変なんだ。俺は最近は、技術書に限れば毎月１冊だわな。他の分野の本も読まなきゃいけない立場だし。
だけど、月１冊でも、継続していくと、けっこうな力になると思ってます。
１０年で１２０冊。流れやハヤリで消えていく知識の積み重ねではなく、時代を越えて残るＩＴの概念・哲学・思想の蓄積。差が出ると思うよ。


部下・後輩に読ませたい本のアマゾンのリストマニアはこれ

言語の歴史 4 オブジェクト指向

構造化言語も頑張った。が、やはり時代が許さない。

今まで、コンピューターは、本質的に「計算機」として使われてきた。ＸＸシステムとかＸＸアプリ。外装の機能は変わっても、やってることは計算機。

が今は、ネットの携帯、メール等、独立した個々の間ののメッセージツール、コミュニケーションツールになってきた。計算、演算の処理であれば、構造化言語でも十分対応できた。しかし、巨大なネット空間、トポロジー、メッセージ伝送を、モデルとしてとらえようとすると、手続き型や構造化の考え方では、表現が非常に困難。できないといってもいい。
web2.0のシステム概念など、オブジェクト指向そのものだ。

世の中でおきていること、シカケ、ビジネスの仕組み。問題領域、システム化対象領域の多くは、オブジェクト指向で表現するほうが、無理が無い。できないと言ってもいいかもしれない。
オブジェクト指向は、エンジニア、プログラマのニーズや好みで生まれたものじゃない。

C++より後発の、Java PHP5 Ruby などは、ネットを意識して、マシンをまたいでのメッセージ連携、プロセス間通信が、最初からできる。ネットに関係するコンストラクションの際に、今はそれらを選択することが妥当だろう。勿論、次に何が来るかはわからない。

今、ＰＧとしてするべきは、オブジェクト指向を理解したうえで、それらの処理系を使いたい。
JAVAのクラスメソッドをたくさん覚えても、オブジュクト指向を理解したことにはならないんで。

C++ JAVA PHP5 Ruby,Squeak
本稿では、いつもの言語の説明はしない。馴染みは十分あるだろうし。

古典的技術書

久しぶりの更新だ・・。

先日後輩２人と飲んだ。年は１０歳も違う。

だいたいサラリーマンが飲めば、大企業であれば上司、中小であれば社長の批判か、あるいは顧客とのやりとりの愚痴と相場が決まってる。１０歳違おうが、ＩＴ会社であろうが、まあ話題は一緒だったりする。

が、今回は、インフラ対ＡＰの技術論・実装論などで、やたら熱くなった。店に出入り禁止にならないか心配になるくらい。そのうち、攻撃の矛先が、先輩であるオレにむいてくる。

「だいたい、高橋さんなんて、はっきり言ってロートルですよね。（ぐはあ）　でもいいじゃないですか。僕らはそんなこと期待しない。Apacheのconfig のパタメータやら、PHPのクラスのメソッドの細かい仕様やら、oracle のチューニングパラメータを、あんたに教えてもらおうなんて思ってないですよ。
でもね、そういう細かいことは、僕らはいくらでも、必要なこと自分で調べていけるんですけど、常識というか、経験に裏打ちされたノウハウとか、年食った人は、そういうことこそ、教える責任あるでしょ。」

あいたた、痛い、痛い。そんなもんOJTだろと開き直るのも何だかなあ、「じゃあ」と、オレが読んで感銘・影響を受けたいくつかの書名をあげた。いまどきのハウツー、解説じゃなくて、哲学・思想がある時代を超えて通用しそうな本。
「すでに古典だけどな。これは、こういうとこが今でも通用すると思うぞ、ＥＴＣ」

その時の本＋アルファ　アマゾンのリストマニアにまとめた。

いいか悪いかしらんが、少なくともオレは、これらの本からは、かなり影響受けてる。マジ読んで欲しいなあ。

話題にした本のアマゾンのリストマニアはこれ

まあ、ほんと、オレは、いい後輩に恵まれていると思うよ。

言語の歴史 3 モジュール指向

言語の中*で* プログラムすることと、言語の中*へ*プログラムすることは、大きく異なる。(Gries 1981)
別に稿を書き起こす予定だが、ひとつの言語しか知らないと、その言語の仕様に限定された発想、思考しかできない。いくつかの言語を知っていれば、問題を解決するための最適な処理系の選択ができる。これは堅牢なアーキテクチャの確立のひとつの要素だ。

と、ぶち上げて、モジュール指向の言語の話だが、これ日本で全然、流行らなかった。好きな人の間で、「いいよねえ」「よさげだよねえ」と言ってたんだが、ビジネスベースでは、ほとんど使われてない。それだけ、cのインパクトでかかった。

モジュール=名前空間　として、抽象化されたデータ型を作る。

Ada やっぱりアメリカ国防省がからむ。データ抽象化と情報の隠蔽、パブリック、プライベートの考えなどをもつ。ちなみに、Adaさんという人は数学者で、世界で最初のプログラマと言われる。コンストラクションが難しい時、祈るといいことがあるかもしれない。

Mudula2 ごめんなさい、ほとんど知りません。ライフボード社で扱っていて、処理系売ってたんだけど・・・お小遣いじゃ買えませんでした。

撤退すべき時

もう時効なので。

付き合いの長い会社なんだけど、いかんせん組織が巨大で、セクションた担当によって、「アタリ」が異なり、トラブルこともある。

現場に来てやって欲しいという業務で、一人行ってもらった。
長期続くはなしだが、まずは契約１ヶ月でやって欲しい、と。

営業・収支上のPMはいるが、技術面のPMの働きまで、踏み込んでほしいとの希望で、たしかに、マッチしないと、プロジェクト自体が頓挫する重要なポジション。
慎重になるお客さんの気持ちもわかるし、行ってもらう本人にも納得してもらい、現場に入った。

１ヶ月が過ぎる、少し前。次も、1ヶ月で契約してくれ。
ゴタゴタするのもイヤなので、呑む。

そして、次、また１ヶ月と言い出した。
今まで、そんな話はしたことのないお客さんだったのだが、担当が不慣れだった。ダメならダメでいい、ミスマッチなら、早めに結論出して、次を考えるのが、お互いのためだろうに。
行っている本人がキレ、契約、更新やめましょう。と言い出した。
ごもっとも。オレも、この進め方おかしいと思う。フェアじゃない。

さて、それを言い出すと、
「いや、そんなことないんだ、残ってくれないと、困る」

だが、ここは、やはり引き上げるのが妥当と判断。
この行き違いそのものに、近い将来の問題の種を内包しているように思えた。
その会社全体とのツキアイはまだ続いているが、このセクション？この担当者は、ダメかも・・。

引継ぎやらなんやらで、けして、波風たてることは本意ではなかったし、いたずらにプロジェクトを困らせたいとも思わない。交代がくるまで、その後、２ヶ月は、やった。

バランスが、時に悩ましい。

言語の歴史 2 手続き型 構造化

オブジェクト思考の背景として歴史を知ることの他にも、コンストラクションの重要な決断をするためには、言語の種類、特色は理解しておくべき。どうしてこのシステム構築にあたって、PHP5を選択しているのだろう。いつまで、半人前のＰＧでいいなら知らなくても、考えなくてもいいけど。

COBOL アメリカ国防省向けに作られた。今でも大量に資産がある。
手続き型から進歩も続けていて、構造化COBOLや、最近では、オブジェクト指向の機能を持つCOBOLまである。不勉強で、オブジェクト指向COBOLの詳細は知らない。

Fortan 手続き型でスタートだが、Fortran77では、ブロック構造のIfが追加され、構造化への歩みもしている。

C 低水準に移植性の高いアセンブラとしても使えるし、構造化された制御、マシンからの独立（一応は）など、高級言語としての機能も。1980-1990年代、オープン系開発では、事実上の標準ともいえる。

手続き・構造化は、ずいぶん、がんばってイロイロなことを試みる人たちがいた。
同じようなところを、まとめて、サブルーチンとして使いましょうよ。
アセンブラまでは職人だけだったが、この頃から、プログラムが大衆化して、それこそ、ぐちゃぐちゃになって、コードの書き方何とかしましょうや。で構造化。

ちゃんとやれば、それなりに理解しやすいプログラムになる。でも、再利用できるのはあくまでも、コードのレベル。それ以前の、分析・設計の再利用性は、ない。勿論、コードと業務のつながりは直接的にはなく、ドキュメントのみが頼りになる・・が、このドキュメントが十分であることは・・マレだ。

言語の歴史 1 機械に優しい

オブジェクト指向の必然性を理解する上で、言語や処理系の歴史を、背景として知っておくことは有効だ。

まず、機械語やアセンブラの時代。
当時は、マシンもメモリも高かった。人が、機械様にスリスリしていく必要があった。人間はコンピュータの気持ちになって、0と1の羅列をする。（16進でもいいけど）
アセンブラのニーモニック。ちょっとだけ人にとって意味を持った。でも ADD はマシン語の010011だよね、とマッピング、紐付けしただけ。

長所は、マシンと環境と地球に優しい。エコだったんだな。早いし。
少しでも便利にしようと、歩み寄りもあって、マクロアセンブラとかも出たな。でも本質的には、普通の人には焼け石に水。もう職人芸の世界。
どうしても実行速度を負う、コードサイズを小さくする必要性があれば、今でも使われる。

そして欠点は、勿論、ふつ～の人は見てもわかんねえ。

化け物はいるもんで、16進をみてニーモニックに直せる人間逆アセンブラーとかいたなあ。尊敬されてた。でも俺はできません。

ソフトウエアクライシス対応 5 I/F重視

システムデザイン、アーキテクチャを確立する時、I/Fを重視した設計を進める。コンポーネントに分けることで、並行開発ができる。場合によってはアウトソーシングもできる。
疎結合であれば、依存度も低く、問題の切り分けがしやすい。

この発想がないと、web2.0的な外部システムのサービスを取り入れたシステムデザインは難しい。一応つながってはいるけどね、キレイじゃないよね。って、システムデザインになる。あとで誰かが苦労する。

オブジェクト指向は、現在のソフトウエアクライシスに対応する中心的な要素になり得る。が、オブジェクト指向でやれば、すべてうまくいくというような、魔法の薬ではない。
この問題を考えていくと、ソフト会社って何？ソフトウエア開発って何？　さらには、ソフトウエアエンジニアリングそのものの議論になっていく。
そのあたりは、きっとアジャイルのメンバーのお歴々が、やっていかれると思うので、お任せしておきたい。

オブジェクト指向の背景として、現代のソフトウエアクライシスに、文字を費やしたが、次は、オブジェクト指向の背景の２つ目として、言語、処理系の歴史を押さえておく。

ソフトウエアクライシス対応 4 フレームワーク

JavaでもPHP5 でも、いいフレームワークが揃ってきている。c++の時代とはずいぶん違う。
使用実績のあるフレームワークを会社に作っておく。蓄積していく。繰り替えし利用することで、毎回テストされ信頼性があがる。
昔でいえば、サブルーチン、プロシージャ、関数の共通化だったが、いわば局所的なパーツの蓄積。その意味では、ずいぶん進歩はしている。

オブジェクト指向の再利用性は、コードにとどまらず、分析、設計にまで及ぶ。経験も必要だが。

新技術は毎日のように出ていて、クライアントは新しいものが魅力的に見える。だか最新ということは、実運用を踏まえた安定性に欠けるということ。バグがあるに違いない。
だが、取り入れなければ、ジリ貧だ。そのリスクを回避しながら、開発することになるが、やはりインクリメンタル開発となる。とにかく、細くてもいいから、ガイドロープを向こう岸にかける。一番最初に、アーキテクチャーのプロト、サンプルコードを書く。
妥当性の検証はしっかりと。
これで、新しいものを取り入れたフレームワークが作れる。

ソフトウエアクライシス対応 3 アーキテクチャー

サービスインまでの仕様変更。そして勿論、サービスインして運用がはじまってからの機能追加。当然、あるべきものと考えておく。
システムは生きていれば成長する。成長の止まっているシステムは、使われない死んだシステムだ。言い過ぎかもしれないが、１００歩譲っても、世の中やビジネスが変わるのだから、それにあわせていかないシステムやサービスは、いずれ死ぬ。

おたおたするな、ガタガタするな。仕様変更や追加はある。そう割り切っておこう。費用などの点は営業的な話なので、今回は省略するが、問題は、それに耐えられるベースのアーキテクチャか否かだ。

オタオタしないための仕込み。それが安定したアーキテクチャだ。レガシーでいえば「方式設計」だが、オブジュクト思考でやるときには、インフラやベースラインのアーキテクチャ。機能を実現するレイヤ、ビジュアル（プレゼン）を担当するレイヤ。それぞれ独立してメンテできるようにしておく。MVCのフレームワークはいくつもある。その採用もいいだろう。

アーキテクチャがしっかりしていても、オタオタしないためには、条件がある。開発者が信頼に足り、物事の決定の場に立ち会えること。コミュニケーションが十分にとれていること。などなど、オブジェクト指向以外の要素があるが、XP(Extreme programming)について書くときにあらためて。

アーキテクチャの確立については、別途書き起こすが、ここでハッキリ書いておきたいのは、サービスイン前にクライアントからアーキテクチャの変更まで求められるような要望が出た場合、PM,PLは断固とした姿勢で挑むべき。なぜなら、それはプロジェクトのゴールが変更されたと同等のことで、このまま進めても、クライアントは満足するわけがない。もっとハッキリ言えば、必ず失敗する。ならば、プロジェクトの中止、仕切りなおしをするのが、誠意だと考えたい。

アジャイル宣言
契約交渉よりも、ユーザとの協調により価値をおく
計画に従うよりも変化に対応することにより価値をおく

ソフトウエアクライシス対応 2 見積もり

これをちゃんとやらないと、ソフト会社なんてすぐに潰れる。当たり前のことだが。いろいろな方法もあるから、一例を挙げるに留める。

機能の細分化。コードとUTは人日単位まで落とし込む。コード UT以外のやるべきタスクの洗い出し。それを積み上げる。
スケジューリングは、細分化された機能等を、タスクまたはwbs としてカレンダーにマッピング。優先順位もつける。

機能の細分化の際、オブジェクト指向でやる。すなわちオブジェクトや、それに含まれるメソッドが、ビジネスの要素にマッピングされるので、クライアントにも理解されやすい項目となり得る。同時にその見積もりの項目は、必要なクラス一覧にマッピングされる。

要求は変化する。要望は追加される。その要望を実現するために、どうして追加のリソースや工数が必要になるのか、クラス・メソッド一覧にマッピングできる見積もりは、クライアントへ、十分な説明が可能になる。

もっとも、開発論、技術論ではないところで、大枠の金額や納期は圧縮されるんだけど、オブジェクト指向とは関係ないので省略・・。

ソフトウエアクライシス対応 1 クライアントと握る

クライアントの考えていることをシステムデザインにキチンと反映する。当たり前のことなんだが、現実はキチンと決まらない。クライアントとの定例会議の最初の頃は、クライアント自身が考えが至らなかった事柄もある。要望は段階的に出てくる。

ダイナミック、インクリメンタルな開発は世の流れとして必要となる。そのためには、UMLなどを用いて、対クライアント、対内部のコミュニケーションコストを下げておく。オブジェクト指向はビジネスをモデル化することがキモであるから、うまく機能していれば、従来の設計レビューより、クライアントと握りやすい。

リリースは段階的に行う。一気に作るのは、このご時世では危険。小刻みにプロトを出す。外部仕様だけでも早い時期に見せていく。html紙芝居も有効な技。

クライアントの考えていることとは、「要求仕様」とは異なる。ここは大きなポイントだ。
今まで、システム開発の目的は、「要求通りの構築」だった。しかし時代のニーズは、システム開発の目的を「満足とビジネスの成功」にしてしまっている。
要求とは「確定させるよう吸い上げるもの」から「変化するもの、随時対応するもの」になっている。

ゴールとその効果測定（定量）まで、初期にヒアリングし、握っておく必要がある。

ソフトウエアクライシス3 ネット WEB2.0

ネットを前提としたシステムは、不特定多数の利用者を持つ。ネットを前提としていなければ、有る意味閉じたシステムともいえる。有る程度、ユーザが決まっていた。しかし、ネットにUIを持つ・開放するということは、データ更新を伴うオペレーション・操作を不特定多数の人間が行うことを意味している。ネットの前の時代なら、そんなこと怖くてやらなかった。

ネットやWeb2.0になって、ハードやソフトやAPまでも、IPリーチャブルなどこかに置かれている。そういうシステム連携をキチンとデザインできなきゃいけない。少なくとも、それを理解しイメージできてないと、コードもちゃんと書けない。

さあ、ラッピングだ。APIだけ覚えりゃいいにしちゃいましょう。
例えば、オープン系からキャリアスタートの俺が何だかんだ言おうと、ホスト、基幹、汎用には、既存のソフトウエア資産が大量に積まれているのは事実だ。その資産を利用することも必要とされる。だから外側に皮を被せる。ゲートウエイと言ってもいいかもしれない。外からみれば、オブジェクト志向で作られたAPIだけだ。中（裏）では昔のままのレガシーアプリが動いている。中は皮とメッセージ連携、イベントドリブで連動させる。

amazon でも、googleMaps でも、中で、何が動いているかなんて、どーでもよい。
APIで何が提供されているかだけが問題になる。

ブラックボックス化、API化によって、ネットが社会のインフラとして重要度はさらに増してきている。ちょっと前まで、ブラウジング、情報得る、見るだけのお手軽システムだった。せいぜい、ちょいとCGI。

ecサイト。B2B B2C。取引、決済が、ネットをインフラとして電子化されている。それは閉じた世界じゃない。ネットというオープンな世界のテクノロジを使う。xmlを使って、取引の区別をなくそうともしている。（標準化委員会の結論はどうなったかな）
従来のクローズされた世界のシステム以上に、堅牢であり、信頼できることを要求されている。そいつを２ヶ月でやれと求められる。泣いても許してもらえない。

さあ、どうしましょう。

だからこそ、十分テストされた信頼性の高いコンポーネントを使う。それは自分のシステム外でもいい。信頼できれば。
I/F重視、徹底したコンポーネント・モジュール化。

そのシステムデザインをステークホルダが共有する。共有するというのは、単にファイルを共有するということではなく、仕様や設計レベルも含めて共有する。それがないと、前節のインクリメンタル開発は実施が困難になる。そのシカケ、方法のひとつとしてUMLがある。それをチーム開発のリファレンスとする。しかし、UMLで表現すれば、問題が解決するわけじゃない。モデリングが大事であることは論を待たない。モデリングのコアは、アーキテクチャ確立で、これがブレることはプロジェクトのゴールが変わったことを意味する。

ソフトウエアクライシス2 さっさとやらんと他社に負ける

計算機は神様で、電算室、EDP室という神殿があり、技術者は神官であり神主だった。帳票１種類追加してよとお願いすると、完成は１年後ですというご託宣が下ったりした。企画し要求をまとめ仕様を決め、設計、製造、テストまで、２年とか３年でよかった。今でも、インターネットバンキングだと、ページの文言を変更するのに１ヶ月は必要だ。

大半のネットの世界には、そんな幸せはない。
ECサイトを作りたい、というクライアントがいる。
３年前だとカットオーバに３ヶ月もらえた。今じゃあ２ヶ月だ。

さあ、その２ヶ月で、クライアントのビジネスモデルを理解し、時には一緒にモデルを作りつつ、デザインして、コード書いてテストして。
その間に、そのクライアントのライバル・競合会社が、新しい機能をつけたりすると、すぐにつけろ、となる。
携帯のコンテンツをサーブするシステムだと、企画責任者が「ピンクのハートと黄色いハートじゃあ、集客力が違うのよ！」と、直前に言われたりする。PGの「どっちでもいいじゃん」みたいな話は通用しない。それはユーザの嗜好性に基づいたプロジェクトの成否をわける話だから。
画像の差し替えじゃなく、機種依存の絵文字の話だから、かなりややこしい。

開発サイドは、かなり苦しく負荷が高くなる。近々そうなるという話じゃない。もう、そうなっている。

さて、じゃあ、どうするか、だ。

ひとつは、０から作るのはやめましょう、と。
業務・業種で、こういうワークフロがありますね、と。それに対応するフレームワークを作りましょう。コンポーネントの組み合わせを想定しておいて、クライアントの要望をコンポーネントにしてプラグインしていく。
昔からあるパッケージソフトとか、ライブラリー群との違いわかるかな？
コンポーネントとしてプラグインするってところが、オブジェクト指向風。
そして、コードの再利用だけじゃなく、分析・設計の再利用も。
いい悪いというより、そういうスタイルにしなきゃしょうがない。

もうひとつは、仕様変更・追加は必ずあるとリスク管理しちゃう。
リスクといっても、昔のレガシーのころからの工数を大目にするって話ではない。
クライアントとシステムアナリストが、仕様まで落とし込み、コード化がはじまった。しかし、最終は、マーケット、ビジネスを、クライアントとアナリストが読みきったかどうかが大事で、読みが甘いとそこで仕様は変更される。
費用は別として、仮に対応しきれないと、クライアントは満足しないし、クライアントのビジネスは成功しないし、次の仕事はこないし、会社は生き残れない。
最初にいったけど、技術サイドの話じゃない。世の中にニーズの話だ。
アプリの仕様の変更、追加は、クライアントのビジネスの成功のためには、当然のことだ。それが世の中のニーズで、ソフトウエア開発者にとっては、生きていくのがイヤになる時代になった。
だから、インクリメンタル開発。プロトを提示し、早期に確認し、繰り替えし、積み上げの開発が、世の現実のニーズに近い動き方といえる。

以上、webのビジネスサイトを中心に書いたが、組み込みの世界でも、期間圧縮のプレッシャーはかなり強いとのこと。
携帯電話のバグで回収騒ぎがあるが、中身の８０％以上がソフトウエアで、２,３ヶ月のスケジュールで、テストも全てこなせず、品質としては問題があるのはわかっていても、生き残るためには、ヤムナシと市場に投下せざる得ない・・ということも、聞いたことがある。