update it, Inc.社長のブログ

昔、同じ年金問題とシステムというタイトルでブログを書きました。そのとき、「裏付けのないまま事を運んだ場合のリスクを考えていない」ことを述べました。「一年以内の突合を公言したために、期限を守ることが絶対条件になってしまった、と考えると、この後、悲喜こもごもとしたことがいっぱい起きそうだ」とも書きました。

昨日の年金の「年金　年度内解決を撤回」ニュースを見ていると、やっぱりね、という感じを受けました。そもそも名寄せって、とんでもなく大変な作業であることは、やったことのある人ならわかると思います。「ここまでずさんであるこということは想定外」というコメントがありましたが、この発言者の方にとっては本当に想定外かもしれませんが、実際に関わっている当事者の人はどうなのでしょうか？

もし、本人達は無理だと気づいていても、それを言い出せないような状況になってしまっていて、切り出せなかったとしたら、やはりリスク管理に大きな問題があったことになるのではないでしょうか？

以前私は、システム開発が失敗する原因は要件定義段階に問題があるケースが多い、ということを言っていますが、今回のケースもおよそ同じような話だと思っています。そして、プロジェクトのメンバの中にはその失敗の芽に気づいている人もいるはずです。でもその声が反映されない「仕組み」に問題があるのだと思います。

こういうのって、ITガバナンス的な考えで解決すべきテーマなのかもしれませんね。

最近内部統制まわりの勉強中です。『これでわかる会社の「見える化」と攻めの内部統制 – 平松　徹著　週間住宅新聞社』という本を読んでいたら、ISOのマネジメントシステム関連の認証を取るケースで、良いISOと悪いISOがあるという話が載っていました。

この悪いISOのケースとして、ISO認証を取るためにドキュメントを2重管理している例を挙げています。ISO認証を取るためには業務プロセスのドキュメント化が必須ですが、その際に実際に使っているドキュメントとは別に、ISO認証を取るための別のドキュメント類を構築して両方を維持している場合がある。そうするとドキュメントの2重管理となってしまいコストが余計にかかってしまい、ISO認証は負担が大きいということで認証を返上するケースが相次いでいる、という話です。

業務設計する際に、システムによりデータを一元化するのは基本中の基本だと思うのですが、この手の作業を現場に任せてしまうとなかなか徹底されず、結局例外だらけで効率の悪い体系になってしまう場合があります。といって、外部コンサルタントに丸投げしてしまっては、結局現場では使い物にならないISO認証専用のドキュメントが出来上がり、現場で使い続けられるドキュメントとISO認証のためのドキュメントの2重管理になってしまう場合がある、ということなのでしょう。

いずれにせよ、実際に業務をしている人達が、自分達でその業務を効率的にまわすにはどうすべきなのかを一生懸命考え、その結果を１つのドキュメントとして反映させていくのが正しい姿なのだと思います。そして重要なのは、そういった、現場サイドにおける細かな改善をどんどんドキュメントに反映させていき、より良いプロセスに改善していくということではないでしょうか？

ドキュメントは一元化、そして現場での改善を吸い上げることが出来る仕組み、こういったあたりが成功へのキーワードではないかと思いました。

私はどうも日々の業務に忙殺されがちです。なんせ小さな会社なので、なんでも自分でこなさなければなりません。でもそんなことばかりやっていると、一番重要な、大切なことが抜け落ちてしまいます。そこで会社の関係者の方のアドバイスに基づき、中期アクションプランを作成することにしました。

要はプロジェクト・マネジメントと同じで、WBSに落とし込んでスケジュール化する、というだけなのですが、難しいのは比較的プロセスが明確なシステム開発プロジェクトとは異なり、状況に応じていろいろな「パス」が発生しうるという点です。その都度書き換えていけばよいのだと思いますが、そうは言っても想定しうるパスについては書いておきたいもの。

そうなると、ガンチャート的なスケジュールには不向き？のように思えます。何か良い方法はないものでしょうか？

ここのところ、crossnoteをWeeklyでバージョンアップしています。WeeklyでReleaseを繰り返すというのはかなり大変なのですが、少しでも早く改善したものを届けたく、しばらくはこのWeekly releaseを続けてみようと思っています。

Releaseの際には膨大なテスト項目を毎回テストしなければなりません。crossnoteは操作できる部分が多いため、たとえ基本的なテストだけに絞ってもかなり膨大な数になってしまうのです。前にも言ったことがありますが、RCPベースのアプリケーションの自動化ツールとして適当なものを知らないので、メンバー全員で1日がかりの手作業で回帰テストを毎回実施しています。いや、これは大変ですし、時間もかかります。いずれ自動化が必要です。

こんなことならSWTUnit(RCPUnit?)作っておくんだった、って思います。  😀

ちなみにcrossnoteは一番最初はインストールが必要ですが、それ以降のバージョンアップは自動更新されるようになっています。ログイン後、バージョンアップされているとそれを自動的に検知して、ユーザにダイアログを表示します。後は指示に従って操作すると、変更された部分が更新される仕組みです。(RCPの自動更新の仕組みをそのまま使っています）　バージョンアップそのものは割とあっという間に終わってしまいますよ。

最近家でもcrossnoteを使っています。crossnoteはご存知（？）ネットワークワープロなのですが、Eclipse Rich Client Platformという技術をベースに開発しているので、たとえネットワークがつながっていなくても利用することが可能です。またインターネットさえ使えれば、サーバにドキュメントを保存できるだけでなく、他の人とドキュメントを共有し、他の人が行った修正内容を確認したり、履歴管理したり、などといったことができます。

なので、crossnoteを使うと家からでも問題なく使えます。ノートPCでの利用にも便利です。

１つ制約事項として、会社のPCと自分の家のPCなどのように、異なるPCにおいて同じユーザIDで共有することは「お勧めしていません」。サーバとクライアントPC内では常に同期が取れた状態を維持する必要があり、同期がずれている状態だと自動的にその同期を合わせる機能があります。別のPCで修正して、修正点をアップデートしないまま同じユーザIDを使って他のPCでログインしてしまうと、元のPCに戻ってログインした直後に同期処理が実行され、アップデートしていなかった修正内容が消えてしまうことになります。（ただし、明示的に終了前にアップデートしておけば、修正内容は消えません）

ということで、会社と家で、別々のPCでドキュメント共有を実現したい場合には、別々のユーザIDを利用してください。

Googleなどには自動翻訳してくれる仕組みがあります。私もよくお世話になっているのですが、実にすごい仕組みですね。

以前SwingUnitの開発でブログを書いていたときに、外国人の方でその日本語で書かれたブログを読んでいたという人がいました。なんとGoogleで自動翻訳して読んでいたそうです。今の人にとっては当たり前に近いことなのかもしれませんが、私は非常に驚いた記憶があります。

本来、言葉の壁というのは非常に大きいものです。日本のIT産業は見えざる参入障壁に守られている、という話がありますが、まさにこの「言葉の壁」に守られているということなのだと思います。（それ以外にも文化的な違いから起こる壁もありますが…）　自動翻訳はその壁を突き崩す可能性を持っているのだと思います。

自動翻訳は精度といった面でいうと、未だに変な結果になりがちですが、意味を理解するという観点でいうと、十分なレベルになってきているのではないでしょうか？　Googleは自動翻訳のAPIを公開しているという話を聞いたことがあります。可能であればそのうちcrossnoteにも自動翻訳機能を入れてみたいな、と密かに思っています。

（ついでに言うと、crossnoteは最初からオフショア開発での利用を前提に、プロジェクト内のメタ情報を2ヶ国語で保持する仕組みを持っています。）

以前、crossnoteはネットワーク・ワープロという言い方でどうでしょうか？というのを書きましたが、似たような言葉にオンライン・ワープロというのがあります。こちらは既にある程度一般化している言葉で、相当するものに例えばGoogle Docs & SpreadsheetsやZoho Writer, Think Free Officeなどといった、Web2.0系のオフィスソフトがその代表格となっています。

crossnoteもSaaS的に利用するという観点でオンライン・ワープロの一種と言えると思います。一方で、ネットワーク・ワープロという名前は「通信機能の付いたワープロのように聞こえる（弊社関係者）」という声もあり、オンライン・ワープロと名乗ってしまったほうが良いのか、ちょっと悩みどころです。

ただ、crossnoteは上記のようなオンライン・ワープロとはだいぶ性格が異なっています。どのように違うのかをまとめてみましょう。

１．表現力の違い
オンライン・ワープロの場合、要素技術としてAjaxを使っています。このためと考えられますが、図形編集の機能が弱く、貼り付けることはできるものの、ワープロ上で直接図を編集することはできないものが多いようです。
crossnoteはRich Client技術(RCP)を用いているので、例えばシステムの設計書などで必要なレベルの、そこそこの図であれば十分に書くことができます。また紙に印刷したときにも十分な品質のドキュメントとして利用できるように、表紙や目次を付け、ヘッダやフッダなどがきちんとセットされた、ページを意識したドキュメントを書くことができます。

２．オフラインではどうか？
やはりAjaxをベースとしているための制約ですが、オンライン・ワープロというだけのことはあり、オフラインでは使えません。（ただしGoogle Docsなどは今後オフラインでも使えるようになっていくようですが）
オフラインで使えない場合、例えばネットワーク障害があったり、サーバ側のトラブルがあるときには一切利用できなくなってしまうのですが、crossnoteの場合、オフラインモードがあり、かつドキュメントは手元にあるので、ネットワーク障害があっても、またサーバ側でトラブルがあっても、ドキュメントを読んだり修正したりすることができます。

３．プロジェクト向けか？
オンライン・ワープロの場合、個人でアカウントを取得して、みんなで利用する場合には個別に招待する、という方式をとっているところが多いようです。プロジェクトという単位での管理手段は提供されていません。
crossnoteははじめからプロジェクト内での利用を前提とした仕組みとなっており、プロジェクト内の管理者がユーザIDやプロジェクトの管理を行い、プロジェクト内のメタ情報などを一元的に管理する仕組みとなっています。

４．ドキュメント共有の方法の違い
オンライン・ワープロもcrossnoteもドキュメント共有が可能ですが、crossnoteは、変更差分管理の機能が特に強化されています。前回アップデートしてからの変更点が通知されるのはもちろんののこと、その単位で履歴管理されますので、過去にさかのぼってバージョン間の比較が可能になっています。このため、ある部分を誰がいつ、何のために、どのように変更したのか、といったことが簡単にわかるようになっています。

会社を起業するときとか、他の人に自分のビジネスモデルを説明する際には、事業計画書が必要になります。金融機関からお金を借りる場合には当然ですが、そうではない場合でも事業計画書を作っておけば、自分の考えを整理し、事前にビジネスのリスクを分析しておき、早め早めに手を打つことが可能になります。

そして、会社を起こした後でも事業計画書は適宜更新していくと良いようです。そうすることで当初の予定と現在の状態を比較し、見直すいい機会になります。

実は今、まさにその事業計画書を現状に合わせてアップデート中なのですが、当初の事業計画と比較すると、リリース予定が1ヶ月半延びたのを再度認識しました。

見積もりが甘い、ということなのですが、そもそもやろうとしていることが大きすぎて、通常のやり方では現状のupdate it, Inc.の陣容では出来る内容ではありませんでした。crossnoteを作り上げるというのはProject X的なプロジェクトだったので、はじめからこのようなブレは想定済で、良くここまでたどり着けたな、と思っています。

なんとか「もの」は出来てきたのですが、この事業計画書のストーリーの中では、これはちょうど折り返し点に来たに過ぎません。気を引き締めて、後半戦に臨みたいと思います。