update it, Inc.社長のブログ

最近、システムの開発期間がどんどん短縮されてきているという話を良く聞きます。技術的要因としてはシステムの基本要素のコンポーネント化やライブラリー化が進んだこと、優れた統合開発環境が誰でも手に入りやすくなったこと、非技術的要因としては昨今の一般マーケットにおける商品サイクルの短縮化などにより、儲けるためには時間がかけられなくなってきているということ、などが理由でしょうか？

システムの開発期間が短くなっている、というのはほとんどの場合、開発の期間のことを指していると思います。設計期間が短いというのはおそらく、同じようなものを過去何度も作ってきているので、いちいち設計しなおす必要がない場合など、特殊な場合のみで、大規模な受託案件だと設計期間が長く、かつそれは開発期間に比べ、あまり短くなっていないと思います。

開発期間はできるだけ短く、という話になるのに、設計期間が短くならないのは、1つにはその仕様決め作業にユーザ側自身が関わっているため、無茶なスケジュールになりにくいということ、もうひとつには「考える」時間は短縮できない、ということがあると思います。

で、工数という観点で考えると、昔は設計工数に比べ、開発工数のほうが圧倒的に大きかったのですが、今は開発工数が期間が圧縮されて少なくなった分、設計工数の割合が大きくなってきているように感じます。設計工数の中にユーザ側の参加者の工数まで含んでしまうと、実はかなり大きな数字になっていたりしますよね。

システム開発というと開発のほうにばかり目が行きがちですが、全体の最適化という観点ではもう少し設計工程の効率化も検討していくべきだと思います。

フロントオフィス・システム（省略して、フロント・システム）とは主に金融系のシステムにおいて、収益に直接結びつく業務をサポートする領域をカバーするシステムのことを言います。一方、勘定などお金の管理などを行うシステムをバックオフィス・システム、リスクやコンプライアンスなどを担当する部分を、その中間をとってミドルオフィス・システムと呼んで区分けすることがあります。

私は以前、金融系のシステム・エンジニアだったのですが、その中でも主にフロント・システムの領域を担当していました。（なおミドルオフィス・システムも若干やっています）

このフロント・システムの領域はまさに時間との戦いなんです。マーケットで儲かる業務をサポートするためのシステムを出すということは、儲かり始める前にシステムを提供しなければなりません。いくら立派なシステムを提供したとしても、マーケットで儲からなくなってからでは遅いんです。

しかし皆さんもご存知のとおり、一般にシステムとは開発に時間がかかるものです。それを創意工夫によって、出来る限りの短時間で目的の業務をサポートするシステムを作り上げることが、フロント・システムには求められます。

最近のWebシステム系においても、ある意味非常に似た状況だということを聞いています。最近は、そもそも全般的にシステムの開発期間が短くなっており、昔のフロントシステムの開発と似たような状況になってきているのかもしれません。

フロント系システムを担当していたときに出した１つの答えは、まずはExcelと計算用のDLLなどを駆使して、なんとか業務をまわせるものを予め提供しておき、少し時間を稼いでいる間にきちんとしたものを仕上げて置き換える、というやり方でした。商売はまずは儲かってなんぼ、の世界です。厳格さが要求されるバックオフィス業務はさておき、フロントオフィス業務をサポートするためには機動力が重要なので、できるだけ柔軟性が要求されたのです。そのためにはExcelはまさに最高の道具でした。

最近EUCというとマイナスのイメージが強く、Excelが悪者のように言われることが多いですが、まずは商売は儲けられるようにすることが重要です。業務にもよりますが、特に柔軟性が要求される分野では、まだまだExcel君が活躍すべきではないでしょうか？

ちょっと前の「言葉の大切さ」というテーマで書いたブログで、crossnoteを一言で表すと何？というのを書きました。そのときには「共同作業のためのワープロ」と書いていたのですが、いろいろ考えた挙句、「ネットワーク・ワープロ」というのはどうか、と思いつきました。略すと「ネット・ワープロ」でしょうか？

なんかわかったようで実は良くわからない説明ですが、何かネットワークを使って皆で使うワープロだっていう感じは出ているのではないでしょうか？　じゃあネット・ワープロをもうちょっと説明すると、「変更したところを教え合うワープロ」だよ、ということになります。

ネット・ワープロ = crossnote、よろしくお願いします。

昔、プロジェクト・マネージャーの研修を受けたときに、顧客と「握る」ことの重要性を習ったことがあります。「握る」とは、私なりに解釈するならば、

１．システムの目的（何のためにやるものなのか）をはっきりさせ、
２．目的に沿った形で要件の大枠を固め、
３．要件の範囲内で十分であることを顧客側の実質的なヘッドに納得させる

行為です。最初に握れるかどうかがシステムの成否を決める、と教わりました。

今ASP（今流に言えばSaaSか）を扱っていますが、この「握る」という行為はASPやSaaSの場合、存在しないんですね。握る場合にはお客様の代表がいなければならないのですが、ASPやSaaSの場合、当然そのような方はいらっしゃいません。お客様は皆、お客様なわけで、ある客様との間で「握った」としても、他のお客様がそれで満足するとは限りません。

ASPやSaaSの場合、そこから収益が得られているならばどんどん改善していくことができるということ、そして対応する要件の優先順位の決定権が、最終的には提供する側にあるということが「握れない」ことへの代償といえましょう。

とはいえ、お客様からの要望は最優先ですね…

今まで営業なんてぜんぜん経験のない私が、crossnoteを売るための営業をやり始めました。全然ないというのはうそかもしれません。一応今までも営業の人と一緒に客先へ出向くというのは何べんも経験しました。でも今までは隣に専門の営業マンがいたのですが、今はそのような人はいません。

何事も経験なのですが、そうは言っても事業は成功させなければなりません。事業を成功させるためには営業は必須です。お客様のところに出向くたびに、あー営業マンとしてのセンスがないなーと思いつつも、お会いする人のエネルギーやアイデアをもらい、何とかがんばっていこうと心に決めました。

営業というのは人と人とのつながりなんだ、ということを改めてかみ締めている今日この頃です。

ここのところ寝不足気味でちょっと眠いです。

帰るのが遅いのでさっさと寝てしまえばいいのに、毎晩ピアノを弾いています。秋はショパンが一番です。

CNET Japan上のブログ記事で、江島健太郎さんの日本IT業界絶望論を興味深く読みました。またその後に投稿している希望は突然やってくるもなかなか面白い内容です。

私自身はシステム開発会社もサービス業に変わっていくべきだ、という持論の持ち主なので、江島健太郎さんのいう顧客指向への批判については正直あまり同意してはいません。たとえどんな商売をやろうと、顧客の顔を思い浮かべながら商売をするというのは基本中の基本だと思うからです。またお客様に喜んでもらえることとは、他人からの評価を得るということであって、それこそが自信の源泉だと思います。お客様に喜んでもらえなければ結局は自己満足で終わってしまうのだといつも感じています。だから、やっぱり顧客指向は重要だと思うのです。

ただ、先のブログを読んでみて、ものすごい危機感については共有できた気がしています。実際、SIのシステム開発の現場にいて、技術ギークよりもリレーションシップ・マネジメント担当のほうが先に出世していくようなケースを目の当たりにして、何か違和感のようなものを覚えたのは事実です。

顧客とのリレーションシップは重要です。でももっと重要なのは、その顧客にどれだけの本質的価値を提供することができたのか、ということではないでしょうか？　もしリレーションシップだけが良くて提供する中身がない、なんてことになれば非常に恥ずかしいことだと思います。

日本も、もっと中身で勝負できるように変えて生きたい。本当にそう思います。

日本社会は裏・表というか、建前と本音が分かれているとよく言われています。みなさんも日常の中で、この建前と本音を使い分けていませんか？

システムについても、「建前のシステム」と「本音のシステム」の２つがあるのだと感じることがあります。建前のシステムというのはコンプライアンス上とか、監査上などの理由で「必要な」システムです。MUSTなので、ないとまずいのですが、導入する側としては「まああればいいじゃない」という感じで導入するものかもしれません。一方「本音のシステム」とは、それを導入していることによってビジネスがうまく回り、あー本当にこれはいいシステムだ、なければ困る、というシステムです。

ちなみに例えば監査系のシステムが本音のシステムになり得ないか、というと必ずしもそうではないと思います。システムによっては監査することがビジネスに直結していて、使う側が、あー本当にこれはいいシステムだ、なければ困る、と思っていてくれれば、それは本音のシステムだと思います。

システムを売る人からすると、実は建前のシステムのほうが売りやすいのかもしれません。なぜならばそれは必要なものであり、導入する側もそれほど熱を入れないので、後腐れのない売り方ができるでしょう。一方の本音のシステムは、導入する側としても力が入るので、いろいろと注文が出て大変です。

でも、システムとして意味のあるのはやはり本音のシステムでしょう。特に作る立場（技術者）からみたら、どうせやるならば本音のシステムを作って、使う人に満足してもらいたいと思うのではないでしょうか？

もうすぐあるお客様にcrossnoteのトライアルを開始します。その準備作業中です。通常の時間にはとても書けそうにないので、今書いています。

約１年かけて、ようやくここまで来ました。会社をスタートさせて開発を開始した（というか仕様設計をしていた）頃は、正直なところ、ものになるかどうか非常に不安でした。さんざん無駄金を使った上げく、何にも残らないのではないかと不安にさいなまれた日々もありました。

普通の会社は会社を設立すればそんなに間をおかずに営業を開始するところがほとんどだと思いますが、アップデイティットは１年間はひたすら引きこもって、crossnoteの開発に明け暮れなければなりませんでした。当初の計画通りではあるものの、こんなことをしていて、本当に大丈夫なのだろうかと、あせる気持ちを抑えるのに必死でした。

この１年間は、休みは正月の２日とゴールデンウィークにとった２日だけで、後は文字通り、働きづめでした。家族にもいろいろと迷惑をかけたと思います。

でも、ようやくですが、スタートラインに立つことができました。
いままで一緒に開発してくれてきてくれた社員の人たち、手伝ってくれたみんな、いろいろと意見をくれた方々、家族、トライアルで使ってみようといってくれたお客様、みなさんに最大限の感謝です。
ありがとう。

Webを使ったシステムで、検索する際のキーとして全角の数字での入力をさせるものが、たまにあります。例えば住所などを何気なく入力して、確認ボタンを押したら「全角で入力してください」と言われてちょっと「？」と悩む。あ、そうか、番地の番号などが半角だったのだ、とようやく気づく。そういうケースです。

ちなみに全角で日本語、英語が入り乱れていると、ハイフンがカナのーになってたりすることがあって、後で見ると恥ずかしくなります。できれば数字や英語などはやはり半角で入力したいもの。

まあ、作っている側の論理からすれば検索などのことを考えて、入力データを揃えるのは「当然」なのですが、使う側の論理では「ありえない」ことになります。システムを設計する側は普通この手の問題には気づいているものですが、全体の工数などを考えて、仕方なくそうなっているのだと思います。

根本的には、こういった問題に対処するためのライブラリを整備していくのが正解なのだと思います。（たぶん上記のような問題への対処するライブラリなら、すでにどこかにありそうですよね）　ぜひ積極的にそのようなライブラリ整備を進めていきたいものです。