セミナー
今日は朝からセミナーに参加。
リッチクライアントが主題のセミナーだったのですが、最近のAJAX(エイジャックス)人気が沸騰する中とあってかなり参加者が多かった。
大規模・中規模システムの殆んどがクライアン/サーバ型よりも管理がしやすいとか、コストが削減できるなどの理由で、総合的に見て良いとされWEBアプリケーションが構築されてきたが、入力系(会計等)などのシステムをWEBアプリケーションで行うと、どうしても操作性が悪いという弱点があった。それを克服しようと各ベンダーがActiveXというWEBブラウザープラグイン(AcrobatReaderやFlash等)を入れ込ん解決しようとしたが、ActiveXを使用するともともとWEBアプリケーションの利点だった「大多数のクライアント管理」に支障がでてくるので各ベンダーや顧客はヤキモキしていたのが現状だった。
そうした背景から生まれたのが「リッチクライアント」という概念で、WEBアプリケーションでプラグインなしでWindowsアプリケーションと同じような操作性が保てるようにしようというのが、、、、 前フリがながくなったのですが、リッチクライアントというセミナーに参加者が多い理由だと思われます。
また、AJAXとはそのリッチクライアントの中でも特にインパクトが強かった「グーグルマップ 」の広がりによってその開発手法が一気に有名になってしまった。(グーグルマップで地図がスクロールできるようになったのがAJAXの開発手法)
マイクロソソフト社が躍起になってグーグルとの差別化をしようとしているのも、グーグルに危機感を感じているのもわかる。マイクロソフトが一番の収入源としてるオフィス系のソフトもあと数年でWEBブラウザーで操作できる、ソフトではなく「サービス」に移るかもしれない。そうなるとマイクロソフトに残るのはOSのみとなってしまうのだが、WEBブラウザーから操作ができるとなれば、OSは何でもよくなってくるので、そのうちOSもWindowsでなくてもよくなってくる。。。 そう考えるとマイクロソフトもこれから大変だ。。。
ただし、、、、、
そう簡単にWEBアプリケーションサービスに世界中の全ユーザが移行するとも思えない。
理由は、、、
「過去の遺産をどうするの???」
ということ。
WEBアプリケーションは一からサービスを立ち上げるのは得意とするが、過去の遺産であるデータまで救ってあげて管理するのには不得意だからだ。
そう考えると、あと10年ぐらいは両社のしのぎあいになるのかな。
繋がっている。 「オブジェクト指向の世界」 と 「失敗学」
明後日提出するお客さんへの提案書を書いている途中なのですが、、、、
「あっ!!」
っと気づいたことがありました。
もう何度も読み返している本で、このブログでも2回ぐらい(確か。。)紹介した、
- 畑村 洋太郎
- 失敗学のすすめ
の本の中に、
「局所最適・全体最悪」
と言うフレーズがありました。
つまり、「局所だけにとらわれて改良や見直しをした結果は、全体から見ると全く持ってバランスが取れていないものになる」
ということです。平たく言えば、「木を見て、森を見ず」ですね。
つまりは、何事も全体を把握した上でシステムを改良していかなければならないということです。
これは、、、
先日の@ITの記事「オブジェクト指向の世界」 第5回目に、
「全体最適とアーキテクチャ」
これは、まさしく、、、 失敗学と同じではないか。。。。
もう、万物の心理が「全体最適」で考えると良いように運ぶ、、、、 というように思えてきました。
@IT から 本
前回は@ITと本でしたが、今回は逆です。
@ITで先日読んだ記事でまた特に良かったのが、
です。
その中で、やっぱり出てきました、、、「ピータードラッカー」!!
うぅ~ん。やっぱり超有名なのね。
「顧客創造」
が企業において一番考えなければならないことだというのです。
そして、@ITの記事の中でも「顧客創造→顧客満足→ソリューション→How(どのように)、what(何を)」というオブジェクト指向に結びつくということのようです。
というわけで、今週の本は
- P・F. ドラッカー, 上田 惇生
- マネジメント - 基本と原則 [エッセンシャル版]
本 対 @IT
最近読む本(新刊に限らず)には結論や著者が言いたい事に対し理由を述べているのが少ないように感じる。
なんか惰性で読んで、文字だけ追っ掛けている感じ。
フムフムと納得はするのだが、、、
調査報告や数字が現されているだけでその数値や結論に何故いたったのか?
数値を逆算するとこうなるという著者の理由がはっきりとわからない。
調査報告から「この結果からこうなる」といきなり結論!?になっている。
あと、同じことがダラダラと章が変わっても書かれている。
「それ、さっき書いてあっただろ!!」 と何回も突っ込みいれそうになる。
本と比較して、最近本当に良い情報がまとめられ的確に書かれているのが@IT の記事だ。
仕事がら良く@ITの特集を拝見するが、今週読んで特に良かったのが、「企業コミュニケーションにおける本当の課題」 という記事。
社内のコミュニケーションツールをどのように活用すればよいのか、それぞれのメリット、デメリットを「理由付き」で詳しく紹介している。
社内のコミュニケーションツールとは、「メール」、「グループウェア」、「電話」、「WEB会議」をそれぞれ、「一対一か他対他のコミュニケーション」という軸と「蓄積型(非同期型)かリアルタイム型(同期型)のコミュニケーション」という2つの軸で図に表されていて、それぞれの向き、不向き、または使い方を間違えると混乱を招く事例、その理由が詳しく述べられている。
是非、読んでみてください。
パスパル
パスパル というサイトがあります。
静岡の学習塾なのですが、そのサイトに
と言うのがあって、質問事項に答えると、なんと、、「社長になれる度」がパーセンテージで表示されるそうだ。
。。。。。。。。。
診断をしてみるか、してみないか、、、、 もし15%ぐらいだったらどうしよう。。。。
おそるおそる質問に答えて(本当に正直に)診断結果を待つ。
結果は、
「連想方展開タイプ」<Ca型>
だそうだ。(Caとか、BaとかAaとか色々な型があるらしい)
気になる社長になれる度数は。。。。。
「88%」!
ほっ。。。。。
とりあえず見込みはあるようでした。
相性判断では、(以下パスパルの診断抜粋)
連想方展開タイプ
◇あなたは今会社やグループの右腕または左腕になれる方でしょう。それとも実質的には社長さんや代表なのだけれども、一代目や誰か他の人が頑張っておられて少々目の上のたんこぶと感じておられるかも。そんなあなたをひと回り大きくしてくれるのはBa、Daの人達でBb、Bc、Db、Dcの人達も支えとなってくれるでしょう。
これから、Ba,Daタイプの人を弊社でも採用しよう。
皆さんも是非、パスパルをやってみてください。
新技術採用!
今回受注するプログラム開発の案件(JAVAによるWEBアプリケーション)から。。。
従来型の開発方法から、「新技術の導入」に踏み切ることにした。
新技術と言っても、自社で何か新しい技術を開発するのではなく、あるオープンソース系のコア技術を利用するのだが、それを使うと開発効率がUPするのと、開発で一番手間が掛かってしまうデータベース関係のところが解りやすくなるメリットがある。
ただし、新技術を採用する時のリスクも当然ある。
一応、十分な勉強と新技術を使用した場合のプロトタイプなどを作成してテストをしたが、完全に旧来のプログラム作成から新技術に移行できるかどうかはわからないからだ。
新技術でできると思ってその方向で開発していた途中で、
「やっぱり対応できない。。。。」
なんてことになる可能性もある。
新技術の勉強は、覚えるまで時間がかかるし、旧来のどの部分に適用できそうなのかなどの試行錯誤にはかなりの労力が必要になる。
もちろん、勉強時間や試行錯誤が長くなればなるほど弊社にかかる経費がかさんでくるし、これは初期投資になるので、ある程度の運転資金も必要になる。
できることならば避けたいし、いざ本番開発に踏み切ろうとなった場合でも不安と恐怖が頭を持ち上げてきて、「本当に大丈夫かな~。。。。。」と思ってしまう。
従業員のいち開発者の立場であれば、新しい技術を試せるチャンスをもらえるのだから喜んですると思うが。。。。
経営者の立場からすると、新技術導入によって「初期投資と後の回収とで本当に採算があうのか?」がどうしても基本の考え方になってしまう。
まあ、そればかり考えていてもしようがないので。。。。
ここは決断です!
新潟から来客
今日は、わざわざ新潟から弊社の東京事務所に来てくれた人と少しお話。
お客さんに出す「要求仕様書」をどのように書けばお客さんが納得するか、読んでもらえるか、またデータベースの設計や運用の仕方などの情報交換をしてなかなかいい話ができた。
(その人の同僚で、データベースのにカラム数が400個もあるテーブルのシステムを開発しようとして結局断念してしまった話にお互い爆笑)
そのあと、同じフロアの数人と一緒にご飯を食べに行った。
せっかく東京まで来てもらったのに、東京名物・・・といったお店ではなく某居酒屋チェーン店で申し訳なかった。
話もはずんで楽しい夜でした。
営業。。。
今日は夕方から御茶ノ水のお客さん、神田のお客さんのところへ。
御茶ノ水のお客さんのところにはシステム改良の見積書を提出。
一通り、開発の要求仕様書の内容説明をしたあとに、
「見積はこちらの方になります。。。。」
いつもながら見積書を出すときはドキドキするなぁ~
きちんと仕事をして得られる対価なのでドキドキする必要はないのに。。。
オレって営業には向いていないかな~ と、お客さんの所を出て自問自答。。。
その足で神田のお客さんのところに行って、今度はドキュメント管理システムの営業戦略の打ち合わせ。
弊社には今のところ「営業マン」としての人がいないのでそのお客さんの所の全国にいる営業マンは非常に魅力的だ。
お互いの利害関係が一致し、うまく協業できればそのお客さんにも喜んでもらえると思う。
さっきの自問自答を引きずっていたからか、なんか少ししどろもどろな状態。。。
神田のお客さんの所を出てからも、何か落ち着かない。。。
何かに追いまくられているような感じと、アルコールでも入れて忘れてしまいたい衝動に無性に刈られてしまった。。。
とりあえず、事務所に戻って、社内のレイアウト変更。(模様替え)
机やら、サーバ群の移動をして、配線して。。。
結構よい運動になったので、少し気分が落ち着いてきたのでほっと一息。
テニスの試合です。
今日は日曜日!
テニスの日です。
今日はインドア(室内:体育館)での団体戦でした。
うぅ~~~ん。 おしい。
どうしても勝ちたかったし、とても惜しい試合が1つ。
結果は1勝2敗。
もっとがんばらねば。。。 朝練でももっと「意識」をもって練習しよう。
ただ、自分でもなかなか良い感じになってきたと思う。
仕事もテニスも同じ部分はたくさんある。
テニスの試合では、自分の性格や考え方がよくわかる。
また、相手を戦略的に攻める、自分を守る、この繰り返しと相手との駆け引きは仕事においても共通する部分がたくさんある。
勉強になります!
要求仕様書お客様に提示2件目
今日は、要求仕様書提示の2件目。
こちらもスムーズに打ち合わせできた。
「オレの作った要求仕様書ってなかなか良い!?」
なんてね。。。 まだまだですよ。
今回のお客さんには、お客さんからの要求以外にこちらから「このようにすればもっとよいのでは?」という「提案」も少しさせてもらった。
要求仕様書は厳密にはそのような「提案」は普通記述するべきではないが、その提案によってまた話の展開も変わってくる。
また、「あのときあのように要求していれば。。。。」とお客さんに思わさないようにするためにも、システムを良くするための「開発側からの要求、提案」もたまには必要だとおもう。
昨日、今日のお客さんのシステムは、良いシステム開発になりそうな予感!(というより、絶対!)