update it, Inc.社長のブログ

公的機関や公共性の高い法人などがシステム開発を委託する場合、通常は競争入札が必要とされています。コストを下げるという観点ではとても重要な仕組みだと思いますが、私は果たしてシステム開発の委託に対してこの競争入札という仕組みは適切なのだろうか？　といつも疑問に感じてきました。

その理由は以下のような点です。

１．価格が安いところが本当に適切な委託先なのか？

２．ある程度の規模のシステムを委託開発する場合、「上流工程」と「下流工程」を分離発注せざるを得ないが、このことがかえって非効率性を生まないのか？

３．競争入札制度が成り立つには、「どこに発注しても結果は同じ」という前提が必要だと考えられるが、これは果たしてシステムの委託開発について成り立つのか？

価格については、確かに安いに越したことはないのですが、プロジェクト・マネージメントの基本原則であるQuality/Cost/Deliveryのバランスのことを考えた場合、CostとDeliveryが極端に抑えられた成果物のQualityはどう担保するのだろうか、と思います。つまり果たして委託する側はそのQualityをきちんと『事前に」評価することが出来るのだろうか、ということです。

もちろん受託側がオフショア開発などによって構造的に低コストで開発する能力を持っているのならば良いのですが、それでもQualityを確保するには相応のCostが本質的にかかるはずです。（ここでのQualityは単なるソフトウェアのバグの割合の話ではなく、そのソフトウェアがどれだけ「役に立つか」という観点の話です。）

上流工程と下流工程の分離発注と競争入札が組み合わさると、それぞれ違うベンダーが担当することになりますが、これは逆にコストアップ要因になってしまうのではないかと思えます。上流の設計する側がどう作りこむかという観点なしに勝手に設計を進めてしまっては、結局下流工程担当側が相当な修正を強いられることになり、結果として工期が余計にかかってしまうことになりかねないのではないでしょうか？

最後の「どこに頼んでも結果は同じ」というのは、恐らく皆さんも納得しない人が多いのではないでしょうか？　やっぱり受託する会社、もしくは担当するプロジェクトチームにより「できる」「できない」の能力差が大きく出るものと私は考えます。プロジェクトが成功した割合は100%を大きく下回っているという事実があります。受託する会社の能力によって、この割合というのは大きく変わると考えるのは自然ではないでしょうか？

世の中の報道は一方的に随意契約が悪い、ということしか取り上げませんが、そういったニュースを聞くたびに果たしてもう一方の競争入札制度が本当に正しい姿なのか、私はいつも疑問に感じています。

皆さんはスケジュールの管理をどうやっていますか？　手帳やカレンダーなどいろいろな方法があると思いますが、Outlookやサイボウズのような、会社が提供するグループウェアを利用する場合も多いのではないでしょうか？　会社としてグループウェアを使用している場合には、全員がそこにスケジュールを登録しないと効率的な運営ができません。従って強制的にそのグループウェアを利用することになります。

私もいままでそういった、会社が提供するグループウェアを利用してきましたが、いつも悩んでいたのがどうやってプライベートなスケジュールを管理するか、という観点でした。というのも、例えばある日はプライベートな用事で早帰りをしなければならないとして、それを会社のグループウェア上に登録すべきかどうか、という話です。

ひとつの考え方としては会社のインフラ上でプライベートなスケジュールも一緒に管理してしまう、という方法があります。もし他の人に公開したくないことであれば「公開しない」とすることにより、他の人からは内容は見られずに、その時間帯が空いていないということだけを公開することができます。ところがこの方法は次のような問題を抱えています。

１．そもそも会社のインフラを個人的に利用して良いものか

２．大部分の会社提供のグループウェアは会社外から参照できない場合が多く、会社の外でプライベートなスケジュールを参照できないのは困る。

３．いくら「公開しない」という選択肢があったとして、会社のインフラ上の場合、第3者にプライベートな情報が漏れるリスクがある。

こうして考えてみると、あまり妥当な方法だとは思えません。私の場合、上記のようなケースではグループウェアに「早帰り」という情報のみを載せ、それとは別に個人のスケジューラ（私の場合はCLIE）に再度登録するようにしていました。

しかしこの方法だと常に会社のグループウェアと個人のスケジューラの2つを同時にメンテナンスする必要があります。面倒くさいですし、メンテナンスし忘れて痛い目にあったこともあります。

個人の情報は会社に登録すべきものではないと思いますが、一方で個人のスケジュールと会社のスケジュールをセキュアに、互いに必要な情報だけ交換できるような仕組みはないものでしょうかね？

さて、引き続きcrossnoteのお披露目シリーズ、第５弾です。（すみません、そろそろワンパターンですね）
今日はアウトライン機能を使って、ドキュメントを編集するデモをお見せします。

上の図をクリックして、表示されたFlashのStartボタンを押してください。

crossnoteではドキュメントを直接ワープロのように修正することも出来ます。設計書や仕様書などを作る場合、今回デモしたようにドキュメント全体の構成をタイトルを考えることであらあら決めておき、後で中身を書くという使い方が多いと思います。そのような場合にはこのアウトライン機能は非常に強力な助っ人になると思います。

今週載せたFlashのデモですが、IEだと見れなかったようです。（FireFoxでしか確認せずに気づきませんでした。すみません）

今は直っていると思います。見れないと思ってあきらめた方、ぜひもう一度トライしてみてください…

さて、引き続きcrossnoteのお披露目シリーズ、第４弾です。
今日は大盤振る舞い（？）で、テキストの比較のデモと表の比較のデモの２つをお見せします。いずれも非常に短いデモですので、気軽に見てください。

まずはテキストの比較です。

上の図をクリックして、表示されたFlashのStartボタンを押してください。

テキスト枠が変更されたときの、中身同士の比較の例です。

次は表の比較のデモです。

このように、中身同士の比較を行うこともできます。

次回は、アウトライン機能を使うあたりについて説明したいと思います。

さて、引き続きcrossnoteのお披露目シリーズ、第３弾です。
今日はドキュメントの構成比較のデモをお見せします。

上の図をクリックして開いたFlash画面のStartボタンを押してください。

パラグラフが追加されてきた時の、構成比較の例です。crossnoteは通常のワープロとは若干異なり、ドキュメントはパラグラフやテキスト枠、図形枠、表枠などといった「部品」を組み立てて構成します。これらの「部品」がドキュメント上でどのような順序で配置しているかを表現したものが「構成」です。そしてupdateする前とした後でこの構成がどのように変化するかを比較する画面が、この構成比較です。

次回は、テキストの比較画面について説明します。

先日に引き続き、crossnoteのお披露目第２弾です。
今日はupdateボタンのデモをお見せします。

上の図をクリックして開いたFlash画面のStartボタンを押してください。

これはupdateボタンを押したときの動きを説明しています。自動的に同期Viewに切り替わり、他の人が変更した箇所が表示されます。また同時に開いているドキュメントも修正されています。

次回は、この先の比較画面について説明します。

今日はcrossnoteのスナップショットを、このブログを見ていただいている皆さんにだけ特別に、ちょっとだけ先行公開します。

こんな感じです。

（大きな画面でよく見たい人はこちらをどうぞ）

ま、見た目はワープロみたいなものでしょう。左側にプロジェクトを先頭にしたフォルダーやドキュメント、またそのドキュメントの中身がツリー上になって見えているのは通常のワープロとは違う点かもしれません。

大きな画面で見ないと良くわかりませんが、上のツールバーのところに、保存ボタンの隣の、左から２番目に表示されている矢印のボタンが、Collaborative Documentation Serviceを実現するためのもっとも重要なボタン「updateボタン」です。

また近日中に続きをお見せします。

昨日のブログではパッケージ化のためにはマーケット分析が重要だよ、と書きました。これって実は、普通の会社が普通にやっていることだと思いませんか？　つまり、自分のところで売るものを何にするか、マーケットを良く分析して決めるということです。でも受託開発をベースにしている会社の場合、マーケット分析をして売り物を定めるということをやっているところはどのくらいあるのでしょうか？　まずはこれから着手するだけでも他社との差別化が図れるのではないかと思います。

さて、パッケージ化を行う際に難しい問題として、そのパッケージのノウハウのアイデアは誰のものか、ということがあります。ノウハウは当然ただではありません。もしパッケージ化を行うにしても、肝心なノウハウの部分が他社から提供されている場合には、せっかくパッケージ化したとしても、おいしい部分を持っていかれ、自分はリスクだけを抱えるといったうれしくない状態になりがちです。これはできるだけ避けるべき事態です。

そうは言っても、これを避けるためには、実際に業務をしているお客様の会社よりもシステムを開発している側が商売のノウハウをより多く持っている必要があります。果たしてそんなことができるのでしょうか？　できるわけがない？　　いや、できるのです。

なぜならば、お客様の会社のほうは自分のところの業務ノウハウはありますが、同業他社のノウハウまでは知りません。システムをパッケージ展開できているところは、複数の会社に接しているので、その中から次のビジネスの種をいち早く察知して、それをサポートするためのパッケージを開発することが可能です。もちろんお客様側のノウハウをいろいろと頂くことになる部分もあると思いますが、一方で提供する側にもなるのです。このGive and Takeの関係ならば、一方的にノウハウ料を吸い取られることにはならないのです。

もしこのブログを見て、皆さんにとって何かのヒントになることがあれば、私は最高に幸せです。日本のソフトウェア会社が変わっていくことを切に願っています。

先週のブログで受託開発からの脱皮をテーマに３回ほど書きましたが、今回は脱<<受託開発>>を考える上での問題点として、「パッケージに向くもの、向かないもの」について触れておこうと思います。なおここでいうパッケージ化とはいわゆるパッケージソフトだけでなく、ASPやSaaSなど、広い意味で特定の業務をサポートするソフトウェアやサービスを提供することを意味するものと捉えてください。

いくらソフトウェアの世界はパッケージによる展開が魅力的だとしても、なんでもかんでもパッケージ化が可能なわけではないのは皆さん百も承知の事実です。パッケージ化が可能なのは同じものを複数のお客様に売る（もしくはサービスする）ことができる場合であって、そのような見込みのないものであればパッケージ化する意味はありません。

今まで日本のソフトウェア開発に受託開発が圧倒的に多かったのは、パッケージによる展開をやろうにも、個別のお客様専用のソフトウェアのためパッケージ化が出来なかった、というように主張される方もいらっしゃると思います。確かにこれはもっともな主張のように聞こえます。

でも実はこれも大部分のケースは、開発する側がお客様の業務を理解していないために必然的にそうなってしまっているに過ぎないのではないかと私は思っています。

お客様の業務を深い部分で理解していれば、お客様からの要求仕様をそのまま鵜呑みにするのではなく、より深いレベルでの抽象化が可能なはずです。つまり、業務を理解していないがために適切な抽象化ができないので、様々なお客様に対するニーズにこたえられるようなシステムとして設計できないのではないか、ということです。

パッケージ化を阻害するより現実的な問題としては、上記のような抽象化を適切に行えるようになるにはかなりのノウハウの蓄積が必要で、将来売上げの見込みが立つかわからないものに対してそのようなノウハウ蓄積のために必要なコストを現時点で払うことができない、ということがあります。また商売として考えたときに、たとえすばらしいパッケージソフトが出来たとしてもそれが売れるかどうかは別問題ということもあります。これらのビジネス的な要因でパッケージ化をあきらめるのは当然、正しい選択だと思います。

ということは、（当然のことですが）パッケージ化を行うためにはマーケット分析がとても重要です。今後、対象の業務についてのニーズがどれだけ増えるのか、正しく予測することが必要だということです。

業務がわかっていれば、対象業務領域についてのマーケット分析もより確実にできると思います。もしそれが将来的に有望な市場で対象業務について確実に拡大が望めるのであれば、パッケージ化をぜひ検討すべきだと思います。