update it, Inc.社長のブログ

セキュリティは重要だ、ということはみなさん頭ではわかっていると思います。でも実際にセキュリティに縛られる立場になると、あれはだめ、これもだめと、窮屈で、自由をうばられるもの、というイメージがありませんか？

一般にセキュリティを高めると自由度が奪われる方向にあるのは事実だと思います。ただし、場合によってはセキュリティを高めることによって逆に、いままで出来なかったことが出来るようになる場合もあるのではないかと最近気づきました。つまり、セキュリティ上の理由からあることが出来なかった場合、そのリスクを払拭するセキュリティの仕組みを実現できれば、今まで出来なかったことが出来るようになる、という話です。

例えば、ノートPCを持ち歩くことができるのは、セキュリティの仕組みをきちんと備えているから、とは考えられないでしょうか？　いいや、昔はハードディスク・パスワードも掛けずにノートPCを持ち歩いていたよ、という意見もあると思いますが、それは本来認識すべきリスクに対して目をつぶっていた、というだけだと思います。

裸の王様は、一度自分が裸であるということを知ってしまった後は、もう裸のまま外を歩けませんよね。でもちゃんと着衣という一種のセキュリティを身にまとうことによって、また外出できるようになるのです。

セキュリティというと、どうも窮屈なイメージでしか捉えられない場合には、ぜひこのように、セキュリティによって逆に出来ないことが出来るようになっているのだ、と考えてみると良いのではないでしょうか？　受身（パッシブ）のセキュリティではなく、能動的（アクティブ）なセキュリティの考え方が、世の中を変えていくのだと私は思います。

先日、会社と社員の関係ってどんなものなんだろう、と考えさせられる体験をしました。あまり詳しくは述べませんが、ある商品を買う際に感じたことです。

個人用のある商品を購入した際、その商品の営業マンの不手際のために、ちょっとしたドタバタがあったんです。その営業マンの方自身は良くやってくださっていたのですが、如何せん、手際が悪かったのですね。その上、基本的な部分で間違いをしていて、そのために何度も契約しなおす羽目になったり、あちこちに確認の電話を入れる羽目になったり、時間を食われたり、となってしまったのです。

ちなみにその営業マンはまだ新人さんのようでした。

結果としてはその営業マンを責める話かもしれないのですが、そこでふと思ったのは、そういう事態をその会社は、会社として予めリスクとして認識し、うまくコントロールすべきだったのではないか？　ということです。

その営業マンの人は自分のミスをなんとか自分の中だけで処理しようとしていたようなのです。しかし、やっぱりミスは個人の責任ではなく、会社の責任として処理するような仕組みにしておかなければならないはずです。

つまり、こういう事態が発生したら必ずエスカレーションすること、などといった規則を予め決めておいて、問題が発生したら必ず上司に連絡を入れ、皆で問題をシェアし、解決策を確認する。非常に当たり前のことなのですが、この教育がきちんと出来ていないことが問題だと思ったのです。

昔はビジネスマンになったら最初に「ホウレンソウ（報告、連絡、相談）」の原則を習ったと思うのですが、今はどうなんでしょうか？　今一度、噛み締めてみると良い言葉ではないでしょうか？

いまや誰でも当たり前のようにネットでお買い物する時代になってきました。Webでお買い物をする場合、個人情報やクレジットカード番号などの重要な情報をやり取りする場面ではSSLの仕組みを使って暗号化していますが、この仕組みが利用しているサーバ証明書ってどの程度信用できるものなのでしょうか？

つまり、Webブラウザ上でお金を振り込もうとしている相手が、本当に自分が想定している相手と同一であるということが、果たしてサーバ証明書で証明できるものなのでしょうか？

サーバ証明書を発行する場合でもいろいろとやり方があるようで、厳格に審査を経た上で発行されるものもあるようですが、あまり厳格なチェックを経ずに発行されるやり方もあるようです。商法が改正されて商号が比較的自由になった現在、相手を認証するための仕組みとしてはあまり信用してはいけない情報になっているように思えます。

一方で、一般のユーザは、とりあえずURLがhttps://で始まっていれば安心と思い込んでいる人が多いのではないでしょうか？　https://で始まっているということは、通信がSSLにより暗号化されているため、第3者に盗み見されないということは言えます。でも通信している相手が本当に想定している相手かどうかを保障しているとは言い難い、というわけです。でも、このことを理解しているユーザは少ないのではないでしょうか？

どの会社の発行した、どのようなタイプの証明書だから信頼できる、なんてことを一般のユーザは理解していないと思いますし、インフラなのにも関わらず、いちいちそんなことをチェックしないと使えない仕組みというのも何か変です。

こういった部分にこそ、公的機関が監査できるような法整備がなされるべきだと思うのですが…　皆さんどう思いますか？

私のもっとも嫌いなものの１つ、それがこの「権威主義」です。なぜならば、私自身が今まで、だいぶこれでいやな思いをしてきたからです。

権威主義の元では、ベンチャーは活躍する場がありません。（権威のあるベンチャーがいれば話は別ですが）　どんなに技術的な、もしくは専門的な能力では負けないと自負があったとしても、この権威主義の前では何のアドバンテージにもならないからです。

でも世の中には意外と権威主義的な人って多いですよね。例えば、超有名メーカーから派遣されてきた人達のいうことはホイホイ聞くのに、そうでない立場の人に対してはやたら懐疑的・否定的な人。私はいままでそういう経験をしたことが何度かあります。ちなみにそういうケースに限って、その超有名メーカーから派遣されてきた人達が明らかに勉強不足で、トンチンカンなことを言っていたりする場合があって、あぜんとすることがありました。

私自身が以前は大手企業（？）側で働いていた人間だったのですが、そこから逆にベンチャー側に移ったときに、ああ、こういう風に人のことを見ている人がいるんだ、と強く感じたものです。

権威主義の人というは、中の人を見ずに看板を見て判断していることが問題なのですが、当の本人からすると、それで「自分はリスク回避できた」つもりでいます。つまり何の疑いもなく、「○○という看板を背負った人達が判断した結果」だから正しいとすることによって、自分自身に降りかかるリスクを回避しているつもりになっている、ということです。

でも、それって、単に思考を停止しているだけなのに気づいていないんです。その結果、被害を受けるのは、実は自分の所属している組織自身だってことは忘れないで欲しいものです。

レイト・マジョリティとはマーケティングの世界で有名なイノベーター理論の中に出てくる分類の１つです。これは1962年に米のスタンフォード大のロジャース教授が発表した理論で、知っている人も多いのではないでしょうか？　イノベーター理論とは新商品購入に対する態度を、購入の早い順に分類すると、以下のようになるよ、という理論です。

１．イノベーター　目新しい物好き。全体の2.5%

２．アーリーアダプター　新しい価値を見出す人々。オピニオンリーダー。全体の13.5%

３．アーリーマジョリティ　慎重だけど、皆よりは取り入れるのが早い人々。全体の34.0%

４．レイトマジョリティ　懐疑的な人。皆がやっていないと取り入れない。全体の34.0%

５．ラガード　最も保守的で、伝統になるまでは動かない。全体の16.0%

企業間取引のケースで考えた場合、企業のサイズが変わってもこの割合って変わらないのでしょうか？　なんとなくですが、経験的に、大きな企業になるに従って下のほうの割合が増えてくるように思えます。つまり大企業になるほど、レイトマジョリティの割合が増すのではないかと。

同じような話で、プロジェクトにおいても、そのヒエラルキー構造の中で上の立場になるほど、上記の分類におけるレイトマジョリティ側の人が増えるように思えます。

つまり、大きな企業とか、偉い立場になるほど、一般的に新しいものに対して慎重になる傾向があるのではないかと。あくまで私の主観的な話なのですが。

私自身は、仕事においてはアーリーアダプターでありたいと思っています。（仕事以外の部分は結構レイト・マジョリティの部分が多いかもしれませんが）

皆さんはどうですか？

物事はシンプルなほうが良い。これは昔から、いろいろなことに対して言われていることだと思います。システムにしてもそうです。同じことを実現するのであれば複雑であるよりはシンプルなほうが良い。そのほうがバグを減らしやすいし、メンテナンスも楽です。なぜならば、理解しやすいから、です。

文章にしてもそうです。シンプルな文章のほうがわかりやすいですし、相手に伝わります。

シンプルさは、コミュニケーションや相互理解のための基本原則といえるのかもしれません。

しかし、シンプルであるというのは、実に難しい。本当にそう思います。何が難しいのかというと、「何を残し、何を削るべきか」という判断です。シンプルにするためには、余計なものを一切そぎ落とし、中の一番重要な、本質的なことだけを残すようにしなければなりません。

つまり、雑多な物事の中で本質的な部分とそうでない部分を分類する能力が問われるのだと思います。物事をシンプルにする能力というのは、この分類する能力と非常に近いのかもしれません。

crossnoteを使うとドキュメントを修正後、コミットするだけで、どこをどう変えたのかをプロジェクト関係者に通知することができます。この仕組みはオフショア開発に非常に向いていることがわかりました。（まあ、前からわかっていたことではあるのですが、いろいろな方にヒアリングを重ねるにつれ、その思いを強くした次第です）

実際、crossnoteのセキュリティ管理の仕組みも、まさにオフショア開発向きだといえると思います。まあ、正確には分散拠点開発向きで、国内でも同じことで、複数に分かれて開発している場合には非常に威力を発揮すると思います。

このブログを見ている方で、ご自身のところでオフショア開発を手がけていて、興味のある方はぜひご連絡いただけないでしょうか？　まずはマーケティングといいますか、今現在オフショア開発をしているところではどのようなことをしていて、どんなニーズがあるのかをもっと良く知りたいのです。

ご希望であれば、その場で実物のデモをお見せいたします。

（とはいっても、私としてはオフショア開発以外の部分でもぜひ使ってもらいたいと思っています。オフショア開発はやっていないけど、実物のデモを見てみたいという方がいらっしゃいましたら、ぜひご連絡ください。）

連絡先はinfoまで。（後ろに @updateit.co.jp を付けてください）
よろしくお願いします。

crossnoteはコンカレント性（同じドキュメントを複数人で同時に編集することが出来るようにすること）を確保するために、内部のデータ形式として独自フォーマット（というか、正確には独自データ形式）を採用しています。ところが正直なところ、セールス的な観点でいえばこの独自フォーマットであることはマイナス要因になります。

つまり独自フォーマットの場合、通常のワープロソフトではそのままではドキュメントを編集できないことがネックになる場合がある、ということです。例えば委託者側から、納品物を別のベンダーにメンテナンスさせる可能性を考えて、編集可能なドキュメント形式での納品を要求される場合があります。現在crossnoteについて、ヒアリングを進めているのですが、実際にそういう意見を頂きました。

これについては内部フォーマットは変えようがないのですが、通常のワープロソフトなどで編集できる形式で出力できるようにコンバータを用意しようと考えています。

皆さんもご存知かもしれませんが、WordやExcelにはファイルの中に履歴データが含まれています。それに気付かずにユーザに渡してしまい、隠しておいたはずのデータがユーザに見えてしまい、大変なことになった、という話を聞いたことがあるのではないでしょうか。お客様にWordやExcelの形式でデータを出す場合には、たとえ元のドキュメントと同じ形式であれ、クレンジングというか、中の見られてはまずいデータを削除する作業が必要です。crossnoteの場合にはコンバートして出力するので、そのようなデータが裏に入る危険性がない分、実はこのやり方のほうが望ましいのではないかと考えています。

残念ながら最初のバージョンでは間に合わないのですが、遅くとも来年の3月末までには、製品に組み込む予定です。

これとは別に、今までのプロジェクトのドキュメント類はどうしたらよいのか、という話もいろいろなところから頂いております。例えば通常のWordやExcelなどで作成された、既存資産です。

これらについてはバイナリデータとして、セキュアに、かつ履歴管理を行いつつやり取りするための仕組みとして、crossnote上でやり取りできるように機能追加していく予定です。ただしバイナリデータについては残念ながらコンカレント性はありません。（誰かが編集中の場合には他の人は編集できなくなります）　またバイナリとしての塊の単位で変更履歴管理を行いますので、中身について、どこをどのように変更したのかまでは追えません。

このように制約事項はありますが、できるだけ既存資産についてもシームレスに扱っていけるよう、サービスを改善していきたいと考えております。

近年、システム開発の世界ではITアーキテクトの必要性が叫ばれています。現実問題として、プロジェクトの中でITアーキテクトという職種が実際に存在しているチームはまだ少数派なのかもしれませんが、様々なシステムの仕組みを熟知し、要求仕様に対して適切なアーキテクチャを提案・実現する能力を持ったスーパーSEは、みんなから待ち望まれているのだと思います。

最近はプログラマのキャリアアップの１つの目標としてITアーキテクトの存在は大きくなってきているようです。スペシャリストとしての頂点という意味合いが強いのでしょう。

ITアーキテクトは対象のシステムの、アーキテクチャの全体像を設計する役割を持ちます。ITアーキテクトが決めた方向性に従ってシステムが設計されることになり、その大方針はそのシステムのライフサイクルにおいて大きな意味を持つことになります。

私はこの「システムのライフサイクル」という部分がポイントだと思います。つまり、ITアーキテクトは対象のシステムのライフサイクルを見据えて全体像を設計する責任を負う、ということです。しかし、昨今のシステムを取り巻く状況を考えると、これはとてつもなく大変な仕事であることがわかります。

システムを取り巻く環境は非常に早いサイクルでどんどん変わっています。従って採用したアーキテクチャが非常に早いタイミングで廃れてしまうことも十分考えられます。もしそうなってしまうと、エンハンスやハードウェアの載せ変えもできなくなってしまい、早々にシステムの「死」を迎えることになってしまいます。そのためにシステムのライフサイクルが不用意に短くなってしまい、作り変えのための余計なコストが必要になったとしたら、それはITアーキテクトの責任である、ということなのです。

つまりITアーキテクトは、一時の流行にとらわれることなく、少なくとも対象システムのライフサイクルの期間内は十分に使い続けることができるような、信頼のおけるアーキテクチャを選択する義務があるということになります。そしてもっとも重要で、難しいのは、採用する技術について未来を見通す力を持たなければならない、ということです。

ということで、私はITアーキテクトは予言者、それも客観的な予言者であれ、と考えています。できるだけ客観的に、技術動向を予言できる能力が必要だ、ということです。

昨日ご紹介した渡邉美樹さんが書いた、「もう、国には頼らない。」（日経BP社）の中に、学校の先生を360度評価するという話が載っています。先生にも切磋琢磨してもらうために、その評価基準として自分および上司だけでなく、同僚、部下、PTAの親、さらには生徒にもアンケートを取り、評価を行うということです。（ちなみに本人評価は自分に甘くなりがちであること、および校長を除く上司や部下による評価は結局年功序列的な結果となってしまうということで、途中から評価基準から外すように「改善」したそうです）

生徒からの評価というと、生徒に媚びる先生が高評価になるのではないかという疑問が出ると思いますが、生徒側が選ぶのは結局は尊敬できる先生を選ぶようです。先生は生徒から尊敬されるようにがんばる、ということになります。これは非常に自然なことだと思いました。

生徒というのは学校から見た場合の「お客様」に相当します。もちろん一般のサービス業における「お客様」の定義とはだいぶ異なるのですが、やはり学校というサービスとして考えた場合のお客様であることには間違いはありません。生徒からの評価を聞くというのは、エンドユーザにアンケートを行うというのと同じ話なのですよね。

さて、システムの開発現場でこの360度評価を取り入れるとしたら、どんな感じになるのでしょうか？　つまり上司だけでなく、同僚や部下、さらにはユーザや協力会社の社員など、プロジェクトの関係者に幅広く評価に参加してもらうということです。

プロジェクトが営業的にはうまくいったものの、プロジェクト・メンバーは疲弊しまくり、結局は大量の退職者を出してしまった、なんてことを避けるためには非常に良い方法かもしれません。また影に隠れて、ユーザからの評価に寄与していた人物が浮かび上がるかもしれません。プロジェクト内のコミュニケーションに大きく寄与していた人物がはっきりするかもしれません。

少しでも客観的な評価に近づくためには非常に有用な手法ではないでしょうか？