システムアーキテクト通訳案内士のブログ

　私の会社ですが、知っている人は知っているのですが海外旅行が専門の旅行会社になります。私はそこのシステムを開発、運営しております。 もっとも、零細なのでシステム担当者を一人抱えるのも厳く、糊口をしのぐ為に他社さんへ仕事をしたりしております。 このブログですが、少しは会社の売上に貢献しようという意図の元で、会社のリンクを張っていたりするのですが、思わぬ効果か最近ITエンジニアと思しき人からの問い合わせが増えたようです。 それ自体は良いことなのですが、弊社は個人旅行を専門に扱っており、つまりパソコンでいうところの自作専門店のような感じになります。ちょいと敷居が高く、つまりお客様に多少の知識というか作法が要求される訳です。 もっとも『客に向かって作法とは何ぞや!』とまでは思わなくても『なんか面倒だな～』と思った方は、オオフジのブログを見た！と言えば、親切にするように担当者には伝えておりますのでよろしくです。 お暇な方は、以下の説明を読んで頂ければと思います。

弊社の旅行部門の状況

• 旅行会社は薄利多売 　私も若かりし頃、いわゆるJ○Bが就職ランキングのNo1になっている様を見て、『旅行会社の社員って楽しそうやな～』とか思ていましたが、2010年現在、旅行会社というのは儲かりません。私はITエンジニアで良かったとつくづく思うぐらいに薄利多売です。例えば50万円の旅行の手配を行っても旅行会社には10%（つまり5万円）も手に入りません。ひどい時はマジで数千円の時があります。恐らく多くのITエンジニアは『そんなん簡単やん。数千円で充分やん』とか思われるかと思います。繰り返しになりますが、弊社の場合は単純に売れば終わりではなく、飛行機やらホテルやら鉄道やらをお客さんと相談しながらになります。つまりコンサルタントが入るわけですが、当然にコストがかかる事は理解していただけるかと思います。 多くのITエンジニアの方は、客先に常駐すると仕事があろうがなかろうが1万円は手元に入るかと思います。会社の売上で言えば1日、数万円になるかと思います。何故、日本のIT業界で人売りビジネスが横行するのかが良く解ります。マジで手間なく儲かるからです。 　
• ネットのお客は対面販売のお客と比べると厳しい 　もちろんこのブログを見ておられる方はそうでもないかと思いますが、ネットのお客は対面販売のお客と比べると厳しいです。大分前に『私の身近なモンスター』でも紹介しましたが、ここまでの人はマレなのですが、ネットのお客は合見積が当たり前で、色々やり取りをしていきなり音沙汰が無くなるということも日常茶飯事です。そのようなことが1日に何件もあると、担当者も学習し儲かりそうもないお客様が解るようになり、冷たくなるのですが、その判断というのは完全ではない為、素人のお客様には冷たくなりがちになります。で、ITエンジニアのお客様は結構この例外に該当したりします。 　 ITエンジニアの言葉を借りますと、 お客：「お宅のパソコンにCentOSを入れたら動かなくなった直してくれ!」 的な質問が来るとどうしても 担当者：「オープンソースは自己責任なので御自身で処理して下さい。それとも弊社のPCのハードが壊れましたか？」 お役：「いや、CentoOSを入れたらお宅のパソコンが動かなくなったんで！』 担当者：「・・・」 という噛み合わない話になりますとお客も担当者もストレスしか残りません。 　 当然に客商売であればそのようなことが無いようにしなければなりませんが、いかんせん人間がやることなので相性もあり、ネットというコミュニケーションにワンクッションある媒体を使うと齟齬が出てきます。 　

厳しいお客様の例

• 商売でやっていることを理解していないお客様 　当たり前ですが、弊社は商売で旅行会社をやっております。一部HP等で無料の情報提供を行っていますが、基本的にボランティアではありません。その部分を充分にご理解頂ければと思います。 希にですが利益を出す行為に関して『悪徳業者』のようなお叱りを受けることがあり、『サービスすれば良いやん』とご指導を頂くことがございますが、特定のお客様だけ優遇することはできません。それは他のお客のご迷惑になるからです。 　
• 値切り交渉を楽しまれるお客様 　特定の地域で、提示された価格をそのまま鵜呑みにせずに『そこから幾ら値切れるか？』というゲームを楽しまれる方がいらっしゃいますが、再度申し上げますとおり、弊社は薄利多売で値切り交渉を行うコストも厳しい状態にあります。値切り交渉を楽しまれたい方はあらかじめ、『俺は30%値切りたいからそれだけ値段を盛っておけ!』と申し出て下さい。 　
• 聞くだけ聞いたら終わりのお客様 　旅行の素人が恥を忍んで、専門家に色々聞きたいことがあるでしょう。そのような場合は、バラで購入するのではなくまとめて買って頂ければと思います。これも希にあることですが、一通り質問を聞いた後に『こっちの方がホテルが安いからこっちで買います』というのがあります。実はこのようなお客様が一番ご迷惑なのですが、お互いに気持ち良くお取引させて頂きたいものです。 　

実際は、多くのITエンジニアの方は上記のタイプに当てはまらない方の方が多いです。なので上記のお客様の例をみてもピンとこないかと思います。ただ、この様なお客様もいらっしゃるということを雑学程度に知識として入れておいて頂ければと思います。 なので、オオフジのブログを見た！と言えば、親切にするように担当者には伝えておりますのでよろしくです。

不覚にも風邪をひいてしまい先週から更新が滞ってましたです。 以前は何カ月も更新せずにほっておいたのですが、最近更新しないとアクセス数が減るのである種の脅迫観念にとらわれたりしますです。 風邪をひいていたのでネタもあまりなく先週に引き続き他の記事の引用で。以下の記事によりますと話題のプログラミング言語第一位はJavaらしい。 プログラミング人気ランキング、Smalltalkトップ50から消える はやくADPもランクインしたいのだが・・・というお約束は置いておいて、JavaとCで話題が二分しているらしいです。JavaとCであれば作るものに応じて住み分けができているかと思われます。つまり、JavaだとWEBアプリで、Cだとシステムよりのツール等という感じになるでしょうか。なのでこの２つの言語はそれぞれ順位を保っていくのではないでしょうか。またC++が3位というのが興味深かったりします。ちなみに私ですが、ここ10年程C++の仕事を受けたことがありません。もちろん使えはしますが、C++を使った最後の請負仕事は12年程前でMFCでGUIのプログラムの作成だったりします。もっともCの方はもっと前になりますが・・・。と思いきや最近、久しぶりにC++の仕事をしました。 もちろん自社で使うツールなどをC++やCを使ってというのはあるのですが・・・。Javaに関しては5年程前にある人に教えて以来ということになります。一時はJavaPressに記事を書いていたこともあったのですが・・・。 とまぁ私の仕事事情（体感）とちょっと違うのですが、2010年現在のITエンジニアがマスターすべき言語は、Java、C、C++ということのようです。ってホンマかどうかは置いておいてこのうちの１つはマスターしておいた方が良さそうです。 このブログですがC++ネタを上げているのですが、確かにC++を使う方の人口が多いみたいで、ちょいちょいアクセスがあます。ちなみにダントツの人気記事は、C++/STLでCSVファイルの読み込みだったりします。『21世紀も10年が過ぎ去ろうというところで、C++でCSVっているの？』と思わなくもないのですが、まぁ人気があります。ちなみに、『【求人募集】GIGAZINEのために働いてくれる記者・編集を募集します』を読んで思うこと。はさすがにGIGAZINE人気に乗っかって先週はアクセスを伸ばしたのですが、今週はぱったりとやんでしまいました。

先週、ADPのリリースを行ったので、ちょいと息抜きを。 GIGAZINEの求人募集が今の世相を反映していて面白いのでコメントしてみます。 　 http://gigazine.net/index.php?/news/comments/20100802_gigazine_job/ 「【求人募集】GIGAZINEのために働いてくれる記者・編集を募集します」 　 一言で言いますと今の従業員がダメダメなので、新しく募集するとのことです。何処でもダメな人はいるもので、私が14年程前に遭遇したダメな人Ａ（2年目のエンジニア）は、 　 私：「じゃ、こうやって、こうやって・・・1週間ぐらいで出来るよね」 Ａ：「私に残業しろってことですか！？」 私：「・・・・・」 　 それから一年後 私：「じゃ、これ、1週間ぐらいで出来るよね」 Ａ：「私に休日出勤しろってことですか！？」 私：「・・・・・」 　 私は教育係としてＡのめんどうを見ていたのですが、一連の発言を受けて、私はＡをリリースしました。と同時に自分の教育者としての能力の無さに落ち込んだりしました。 　 また、記事にある、『できる者はますますできるようになり、できない者はますますできなくなっていく』の発言ですが、私も若かりし頃（同様に14年程前）に上司に以下のような質問を真面目にしました。 　 私：「なんで出来ない奴の給料と私の給料が同じなんや!」 上司：「お前、知らんのか？、昔から『出来る奴は全体の2割でそいつらがその他の8割の奴を食わしとる』と言われているんや」 私：「・・・（妙に納得）」 　 その頃の日本社会では出来る人も出来ない人も同じように給料を貰えるということであり、20年程前に『日本は世界で最も成功した社会主義国』という事を聞いた記憶もありました。 　 当時、労働者が自身の稼ぎ以上に給料を貰える社会にある種の矛盾を感じていて何時か破たんすると思っていたので、現在の日本経済の低迷ぶりはある種、自然の成り行きと受け取っていたりしてました。 ただ、こうリストラや派遣社員の雇い止が進み、そうやって切られたとおぼしき人がコンビニや清掃員として働いている様をみるともう少しなんとかならんかとも思ったりします。一方的な成果主義や企業の論理を労働者に押し付けるのも如何なものかとも思いだし、そのあたりのバランスが、まぁ難しいところです。 　 で、会社という組織にあてはめるとその判断の責任を担っているのが経営者ということになるのでしょう。記事にある、『払われた金の分だけしか働かない、働きたくない』ですが、人として自然な感情なので編集長のお怒りについてはごもっともですが、経営者としてはこのような考えを持つ従業員も受け入れないといけないことでしょう。 もちろん、『記事を書くのは面倒くさい、そもそもできれば書きたくない』というような仕事をしたくない人は辞めて頂くほかありません。のでこちらについては毅然とした対応を取らなければならないかと思います。 経営者としてはこのあたりの対応の違いを明確にしないと従業員になめられるかと思います。 　 偉そうに言いましたが、では私自身はどうしているのかと言いますと、私は人を雇うということはない、ということで私自身も答えを持ち合わせておりませんです。 　 とうことで今回はADPの宣伝はなしでした。

最近ADP関連のブログの更新がありませんでしたが、久しぶりのADPの布教活動を。 今年も飛び交う「日本みたいになるぞ」報道に書かれていますが、日本の失われた10年は海外でも悪い見本と取られていますが、もっと驚くことに、引用しますと、
デフレというおなじみのお化けがアメリカ経済の懸念材料として再登場している。（中略）日本のデフレを10年以上も研究した結果、エコノミストたちは次第に、自分たちはデフレの仕組みを何も分かっていないと気づき始めている にありますとおり、デフレの仕組が解っていない事実に、なるほどと思うとともに『エコノミストは何をやっとんのじゃ！』というある種の憤りを感じたりする。特にソフトウェアエンジニアはコンピュータが動かないとお客からのある種のプレッシャーを感じるのだが、『エコノミストは、この日本の状況下である種の責任感とか使命感とかには駆られないのだろうか？』とか色々考える。 もっとも多くの人も何かおかしいということに気づいているかとは思うのですが、『ではどうやって解決するの？』と思われるでしょう。そ・こ・で、ADPの登場です！（ってかなり強引な宣伝です）。つまり、あ~だ、こ~だと議論ばかりに頼らずにもっと科学的にシミューレーションのような手法を使ってデフレのメカニズムの解明とかの研究をしませんか？という提案です。 ADPですが、Another Data Processorの名前のとおり、経済シミュレーションのようにややこしいシステム（真面目な言葉を使えば複雑系）を容易に記述できるようにというコンセプトで開発を行っています。 サンプルでちょっとした経済ゲームを作成してみました。 ソースも添付しましたので参照して頂ければ解るかと思いますが、様々な条件や計算を行うシステムでも比較的スッキリと記述できるかと思います。 ちなみに、ゲーム自体は興味本位で作成したのですが、作成したモデルですが、製品を無限に作成できる場合、人口は安定的に増える。ので上限を設けたら、今のところ安定的に人口増加するパラメータが見つかっていません。見つけた人は連絡を！

チョット野暮用が入りADPの開発（というかブログの更新が）滞ってます。自慢にもなっていない記事をそのままにしておくのも何なので、ちょっとしたネタをアップします。 他人が作ったソフトウェアにバグがあったり仕様変更で改修したりする場合、新規で作り直すか、改修するかが議論になったりすることがあります。 良く聞く意見に 　『バグバグでソースも汚いので新規で作り直しましょう』 というのがありますが、この『ソースが汚い』という意見ですが、往々にして主観が入っていることがあります。つまり、 その人のコーディングスタイルに合っていない→ソースが汚い ということを言っている場合があり、この意見を鵜呑みにして新規開発の道に行くのは危険だったりします。 良くあるミスが、既存のコードに入っていたノウハウ（エラー処理や例外的な処理など）が新規開発で消えてしまい、却ってバグバグになったり、実際にはそう見栄えも良くなっておらず結局、工数だけかけたということになったりします。 新規なのか改修なのかというのはケースバイケースの面があり、あまり一般論では語りにくいのですが、私の場合、以下のルールで新規開発を行います。

1. 既存のコードがある場合、基本は改修で行います。 バグがあるからとかソースが汚いという理由で新規開発を行いたくなりますが、その程度では新規開発はしません。
2. 改修に工数が掛る場合、仕様を完全に把握できかつコーディングテクニック上ではなくパラダイムだったりアルゴリズムが元のコードよりも有効なものが使える場合、先ずは関数レベルから置き換える。 オブジェクト指向を使っていないコードにオブジェクト指向を行ってみるとか、サーチアルゴリズムを別のものに入れ替えるとか、if文の条件が複雑だか良く見ると簡単にできる場合に簡単にするとか、コピーペーストしているコードで共通部分を関数にするとかです。
3. 出来ることならテストプログラムを書き、デグレードを防ぐ。
4. 徐々に改修するコードを広げてゆく。

とまぁこんな感じでやってます。 ちなみに、自分が過去に作ったコードは結構大胆に書き換えたりします。自分が作成したものの場合、1回目より2回目の方がソースが綺麗に書けるということと、『仕様を完全に把握している』という条件をクリアしやすい為です。