誰かをスケープゴートにするよりも、問題解決することが先決だろ
「誰のせい」とかどうでもいい。
目の前にある問題を解決することに注力しろよと思う。
問題が解決した後も、「誰のせい」ってのは追及しなくていい。追及すべきは「なぜそうなったか」だ。
原因追及。
誰かが問題発生のトリガーを引いてしまったのだろうけど、その人を「お前が悪い」と責めるのは意味がない。むしろ原因追及が遅れ、同じ過ちが繰り返される。
そんなくだらないことより、どうやったら今後同じ過ちを繰り返さなくて済むのかを考えろよと思う。
同様に、自分がトリガーを引いてしまった場合でも、「私のせいです」とは言わなくていい。
他の人に「お前のせいだ」という認識を与えてしまって、原因追及の妨げになるから。
だいたい、たいていの問題は複合要因だから、誰かひとりのせいとかめったにない。
反省は大事だけれど、反省ってのは自分を責めることじゃない。
今後同じ過ちを繰り返さないためにはどうしたらいいかを考えることが反省だ。
業務ってなんだ。システムってなんだ。
SIerの世界で言われる「業務」って何だろう。
「SEはお客様の業務を熟知していなくてはならない」とか言われる、あれ。
自分は「業務＝仕事の手順」だと思う。
販売管理の手順、経費精算の手順、輸出入の手順、…。
この「業務」の中で、システム化できる部分は、データの記録や照会をするところ。
どういうデータを記録するか。そして、そのデータをどのようにDBに記録するのか、どのように画面に表示するか、DBと画面間の変換はどうするか、データのチェックはどうするか、…。
ちょっと考えると、これってルールの話だということに気づく。
記録・照会したいデータがあって、それをどういうルールで処理するか。
そのルールを定義すること＝基本設計。
で、そのルールを手続き的な言語に落とし込むのが詳細設計と製造。*1
今はこのルールを手続き型言語で書いているので効率が悪い。
処理フェーズを適切に分けて、各フェーズをルールベースで記述すると生産性は高くなる。
それこそ「コンサルタントがガリガリと設定を書く」という世界になる。製造不要。オフショア不要。短納期。低コスト。
「人間にわかる形」でルール設定を書いて、それを処理エンジンに食わせたら必要な処理をしてくれるという仕掛けがあればよい。
こうなると、テストフェーズの重要性が増す。設定ミスを防ぐにはテストしかないから。
「この設定でほんとうに予定通りの動きをするよね？」という確認が必要。
で、それはお客さん（ユーザ企業内の人）でもできるんじゃないか。むしろお客さんのほうが自社データの扱い方に慣れているから、チェックは確実なんじゃないか。
また、要件をお客さんと共有して、理解して、ルールに落としこめる人の存在が重要になる。今もそうだけど。
逆に、単純に「日本語で書かれたロジックをプログラム言語に翻訳するだけの人」は不要になる。集めてこなくてよくなる。そうしたら、コミュニケーションコストが下がるから生産性はその点でも向上する。
無論、一部に複雑なロジック（ルール設定できるようにあらかじめ作り込まれていない処理）ってのもあるだろうから、そこはプラガブルにしておく。そのロジックは優秀なエンジニアがさくっと書けばいい。難しくても物量は少ないから。これで解決。
なので、DSL、ルールベース、クエリ処理ってあたりは今後ますます重要になってくると思うなぁ。
こんなことを
3ヶ月前くらいまではよく考えてました。
いや、今でもこれはそう思ってるけどね。
でも、今は自分でコードを書けばいいだけなので、プログラム中にSQLを書くだけでだいたい解決できちゃってるんだよね。
上記のような考えって、大量にコードを書いたり、「標準化」の「標準」を低い位置にあわせなきゃいけない場合に役立つんじゃないかな。
*1:論理飛躍すると、だから詳細設計と製造は融合・一体化できる。工夫とスキル次第では。
意外なところでアクセス増加
ここ数日アクセス数が少し増加しています。
特に記事も書いてないのになんでだろ？と思って掘り下げて調べてみました＠Google Analytics
⇒ここ数日のトップキーワード「東京アメッシュ レーダー」
調べてみたら、なんとGoogle検索結果で2番目。
そりゃ増えるわけです。*1
◇
ちなみに、その記事はこちら。http://d.hatena.ne.jp/shozzy/20090227/1235702731
東京アメッシュのレーダー画像が特徴的な形になっていたのを記録した記事でした。
*1:増えたといっても、増分は30hit/日くらいだけどねｗ 所詮ネットの隅っこにあるしがない個人ブログなんで。
非同期画面
XMLHttpRequestとかの関連。
サーバ側で重い処理をするとき、リクエスト開始でひとまず画面を返す。
その後、ポーリングなりcometなりでステータス更新して、最終的に結果を画面に反映する。
これができるとユーザビリティはかなり向上する。
普通に画面遷移しようとして小さなステータスバーがにゅーっと伸びるだけじゃわかりにくい。
（ユーザ層をどこに絞るかにもよるけど）
ある意味当たり前なことなんだけど、Webの普通の仕組みだと難しかったり。
フレームワークが力を発揮できる場所。
もうあるのかな？あるよねきっと。
※作ればできるのはわかるんだけど、フレームワークでさくっとできるのかな？ってことで。
電気自動車は充電がネックだよね
7月に電気自動車が相次いで市販化されるようです。
将来は間違いなく電気自動車の時代になると思いますが、
当面のネックは価格と充電でしょう。
価格のほうは量産化でどうにかなると思うのですが、
充電は何かブレークスルーが必要そうです。
普通に充電したら、どうやっても数十分単位で時間がかかるので。
そこで考え付くのは次の２つ。
１．電池の共通化
２．燃料電池
電池を共通化すれば、充電スタンドでは空になった電池パックを
フル充電済みの電池パックと交換するだけで済みます。
（自動車用の電池は重いから、交換するのも大変そうですが…）
燃料電池はすでに実験している通り、メタノールとかを流し込む仕組みなので
ガソリンと同等の時間で補給できますね。
こう考えると、将来は燃料電池車が生き残るのかなぁ。
システムづくりの敷居を低くするには？
羽生章洋さんのブログを読んでいたら、こんな記述がありました。
「Excelみたいな感じで使っていたら、気がついたら全社最適されたシステムになってました」くらいのものが作れないといかんのではないか、あるいはそういうものが作れて初めてインハウス時代が開花するのではないか。
http://blog.livedoor.jp/habuakihiro/archives/65227419.html
これは確かにそうだと思います。
自分は非IT企業勤務なのですが、社内で周りの人と話をしていると、
「こんなシステムがほしいな」とイメージできる人は結構いて、
Excelの計算式レベルだったらそれを実際に作れる人も少しは居る。
でも、プログラムは組めない。マクロも組めない。
だから、ちょっと複雑な（Excelの計算式で処理できないレベルの）システムになると、
欲しいものを作れないか、外注することになっている。
そんなところに効く仕組みを作れたら、派手ではないけれど売れる商品になると思うんです。
◇
ここで、「そういう仕組みを作るには何が必要か」をちょっと考えてみました。漠然とですが。
１．目的をうまく手順に落とし込める仕掛け
「こんなことがしたい」というのを考えられても、「じゃぁどうやったらできる」と
いう点が皆目わからないという人は多いものです。そこをサポートする。
たとえば、「画面から何かを入力して、ボタンを押したら、処理された結果が出てくる」という
流れに従って「何を入力しますか」「どんな結果が出てきますか」「どういう処理をしますか」
という3ステップにするとか。
２．コンピュータの制約を意識させないか、逆に明示して回避させる仕掛け
詳しくない人が考えるロジックは、通常ありうる処理に目が向いてしまい、例外とか
「その他の場合どうするか」という点が抜けがちです。*1
そういうのを、「こういう場合も想定できますけど、どうします？」というのを
自動でサポートしたい。聞いてくるとか、デフォルトで「この条件のどれにも一致しませんよ」と
例外処理に回ってくれるとか。
３．上記の2点が、ぱっと見てわかる仕掛け
UI上の工夫。Excelだと、ワークシートやセルが常に目に見えていて、そこに直接計算式を
書き込めるからわかりやすいんですね。そのレベルのUIを作る必要がある。
ちょっとずつ進んでいけるようなUIを。
４．入門書
紙のマニュアルがないと理解できないって人も結構いるので。
５．教育コース
直接教えてもらえばわかるんだけど、って人も結構いるので。
◇
実現したとしても「できる人」から見たらおもちゃだし、たいしたシステムは作れない仕掛けに
とどまると思うけど、それで十分なシーンというのもたくさんあると感じています。
*1:プロでもそうか（汗）
