update it, Inc.社長のブログ

最近＠ＩＴの自分戦略研究所で後藤和彦さんが書いているコラム下流から見たIT業界を興味深く読んでいます。コラムではプログラマという立ち位置からプロジェクトを見渡した時に見える数々の問題点を論じています。

上流工程担当者 v.s. 下流工程プログラマという構図も見え隠れしていて、上流工程担当者の人の中には読むと不快に思う人もいるかもしれませんが、違った立場・角度から物を見ることによって見えなかったことが見えてくる、という観点ではぜひとも読むべき内容だと思います。

このコラムで指摘していることとして、上流工程の設計に異常に時間がかかりすぎていないか？　ということがあります。プログラマの立場から見て、何でこんなにつまらないことに無駄に時間をかけているのか、という指摘があります。後藤さんのコラムでは無能な設計者への怒りが伝わってきます。

実は私も以前、1ベンダーの立場としてあるプロジェクトに参加していた際に、同じようなことを感じた時がありました。決めるべきことが決まらず、内容のないレビューを繰り返し、無駄にスケジュールがどんどん後ろにずれていく。でも1ベンダーとして参画している中でできることは限られ、その時はとてももどかしさを感じました。

このように確かにプロジェクトにおいて上流設計がうまくいっていないケースは多々あるのですが、上流工程には『政治的な要因』が絡みやすく、担当者が有能・無能にかかわらず構造的に前に進めにくくなりやすいものです。だからなかなか仕様書が完了しないというのも、必ずしもその人の責任とは言い難いのです。

上流工程の仕事は、実は仕様書を書くということではなく、仕様書を書けるようにコンセンサスを作り上げるということです。仕様書は結果であって、そこに至る過程の検討内容が重要なんです。コンセンサスがとれていれば実は仕様書を書くという仕事はそんなに難しいものではありません。でも現実問題として、そのコンセンサスを取るのに時間がかかり、その結果上流工程の設計全体がずるずると時間がかかることになってしまいます。

でも世の中には単に仕様書を書くことが上流工程の仕事だと思っている人も多いですね。本来上流工程では何をしなければならないのかを、みんなが理解する必要があるのだと思います。

現在最終テスト中ですが、crossnote ver 1.3.1をリリースします。今回のバージョンでは参照検索機能がさらに強化され、かつ外部ファイルの使い勝手を向上させました。

１．参照検索機能の強化

あるドキュメントを修正する場合、同時にメンテナンスしなければならない対象のドキュメントはどれか？　それを知るための便利なツールとして参照検索機能をさらに強化しました。

前回のver 1.3.0で参照コピーという仕組みを導入し、さらに「あるドキュメントを参照コピー元とするドキュメント」を検索する機能を用意しましたが、この機能をさらに強化し、参照リンクについても同様に検索できるようにしました。

参照リンクはドキュメントの文中に埋め込めますので、例えばドキュメント中に『ドキュメント「運用設計書の.5.1 HA構成について」を参照』のように参照リンクを入れておけば、「運用設計書」からこのドキュメントを検索するするができます。

さらにこの参照リンクは質問やコメントにも添付でき、さらには外部ファイルからもコメントなどとして参照リンクを指定できるため、外部ファイルも検索対象に含めることが可能です。

外部ファイルにコメントが付いている例です。

コメントをダブルクリックするとコメントの中身を見る画面が開きます。画面の一番下のドキュメントのアイコン（プロジェクト「crossnote」のドキュメント「crossnote導入手順書」）により、このテストExcel.xlsファイルがcrossnote導入手順書を参照していることを表しています。

２．外部ファイルの使い勝手の向上

外部ファイルを開いている状態で同じファイルをワークスペースから再度起動したときの振る舞いや、新規の外部ファイルはデフォルトで編集状態にするなど、細かな使い勝手を向上しています。

３．戻る/進む機能

[ALT + ←]および[ALT + →]でドキュメントを開いた順に戻ったり進んだりすることができるようになりました。参照リンクで他のドキュメントにジャンプした後、元のドキュメントに戻るには[ALT + ←]です。

４．選択範囲の文字数の表示機能

一番下の左端に、選択した文字列の文字数を表示するようにしました。

ITProに叱るより真因を追究、対策べからず集という記事が載っていますが、非常に良い内容です。ミスをした時に対する一般的な行動に対し、実はそれでは効果が出ないよ（場合によっては逆効果ですらある）というのを7項目にまとめて説明しています。

中でもこれは良いな、と思った項目は以下のようなものです。
（7項目中の4項目。コメントは私の独自の解釈です）

—-
×　ミスをしかる、罰する
○　ミスしない人をほめる
—-
ミスをしない人はいません。この当たり前の事実が、事実として受け入れられない人もいます。その場合、ミスをしかり、罰するという方向でしか考えられなくなってしまいますが、誰でもミスをするという事実を前提に考えると、ミスしない人をほめたほうがチームのやり気を増し、明らかに理にかなっています。

—-
×　恥ずかしいから隠す
○　積極的に全社公開
—-
これも上記と同じように、誰でもミスをする、という前提で考えれば、積極的に公開して他の人が同じミスをしないようにするのが賢いやり方です。

—-
×　ルールで縛る
○　絶対守れる最小限に抑える
—-
以前このブログで「シンプルなプロセス」ということを書いたことがありますが、とにかくみんながきちんと実行できることが重要です。たくさんのルールが満載されていても、ルールにがんじがらめになって結局有効に機能しなくなってしまいます。必要最低限に抑えて、みんながきちんと守れるようにすることのほうが実効性が高いと言えます。

—-
×　「チェック強化」で終わり
○　仕組みを見直す
—-
これが特に重要ですね。チェック強化と叫ぶのは簡単ですが、具体的な方法がありません。精神論だけで終わってしまい、現場の感じが悪くなる以外は特に得るところはありません。本当に改善するには「仕組みを見直す」のが最善の方法といえます。

昨日ズィット社の「SaaSの現状とPaaS環境でのソフト開発・適用について」というセミナーに参加してきました。まだあまり詳しくない人が現状についての概略をつかむにはとても良いセミナーだったと思います。

私は今までこのブログでPaaSはあまり取り上げてこなかったのですが、今回のセミナーで注目するきっかけを得ました。PaaS(Platform as a Service)とは、SaaS(Service as a Service)がいわば完成品としてのサービスの提供なのに対し、PaaSは未完成品の”Kit”としての提供だと考えるとわかりやすいと思います。

PaaSは活用の仕方によって、独自社内システム開発のために用いることもできますし、PaaSを使って完成させたアプリケーションをSaaSとして提供することも考えられます。

ちなみにPaaSとはSalesforce.comの造語なのでしょうか？　マイクロソフトなどでは最近Software plus Serviceなるものを推していますが、コンセプトは異なるものの、狙っているターゲット（企業内で利用するシステムのネットワーク・サービス化）が重なっているように思えます。

昨日のセミナーを聞いていてPaaSが少し厳しいと感じた点は、PaaSを選択するとそのPaaS独自の環境（データベースやコンポーネントなど）に取り込まれてしまい、他の環境へ移ることが難しいという点です。PaaS上でアプリケーションの展開をする場合、ある意味PaaS提供ベンダーというお釈迦様の手のひらの上でビジネスを行うことになります。このリスクをどう考えるかが１つのポイントといえそうです。

昨日のブログでは「なぜ上流工程を改善しようとしないのか？」というテーマで、開発プロジェクトを進める上で、みんなが最も改善すべきだと感じている課題は上流工程の問題なのに、それを改善しようと考えている人はあまり多くない、という話を書きました。そして今日は、上流工程を改善するにはどうすべきか、について考察してみます。

おそらく一番重要なのは、上流工程について「学ぶ」ことだと考えます。ここでいう「学ぶ」には２つの側面があると思います。

■システム開発というプロセスを学ぶこと

■ユーザの業務を学ぶこと

おそらく大部分の上流工程の設計者たちは、このどちらかに偏っているのではないでしょうか？　システム開発プロセスのプロです、という人はいます。またユーザ業務ならまかしておけ、という人もいます。でもその両方を十分理解して、最適な提案ができる人というのは非常に少ない、というのが私の実感です。

システム開発はバランス感覚が問われる、総合的な判断能力が必要な仕事です。システム開発プロセスを知っていても、ユーザの業務をきちんと理解していなければ必要な機能、不必要な機能の判断もできず、適切なリソース配分ができず、過剰な、もしくは使いにくいシステムとなってしまいます。一方でユーザ業務を知っていてもシステム開発プロセスを理解していなければ、度重なる仕様変更を繰り返し、プロジェクトを疲弊させ、最終的にはプロジェクトを失敗に導いてしまうことにもなりかねません。

この問題を避けるためには、まずは「学ぶ」ことが重要ではないでしょうか？　つまりユーザ業務を十分に知らないのであれば、それを徹底的に理解できるように学ぶこと、システム開発プロセスを知らないのであれば、それを徹底的に学ぶこと、何にも増して、まずは学ぶことが最も重要なのだと思います。

足りなかった部分を学ぶことにより、プロジェクトの様々な問題点・改善すべき点が徐々に見えてくると思います。その上で様々な方法論なりツールを活用すれば、鬼に金棒です。

私も何歳になっても、謙虚に学ぶ姿勢は大切にしていきたいと思っています。

TechTargetジャパンでプロジェクト管理ツール利用に関するアンケートを行った結果を公開しています。

これを見ると、開発プロジェクトを進める上で、最も改善すべきだと感じている課題は「不十分な要件定義(39.2%)」が突出して多く、続いて「頻発する仕様変更(18.1%)」となっています。

そうなのです。開発プロジェクトにおいて一番改善すべき工程は、要件定義や仕様変更を行う、いわゆる「上流工程」なのです。もちろんプログラミングやテストなどの工程で問題が出ることもありますが、でもそれも実は原因を分析してみると上流工程での結論に問題があった結果、それがプログラミングやテスト行程で問題が発覚した、というケースの割合が非常に多いのです。

でも不思議なことに、問題意識があるにも関わらず、その上流工程を改善しようと考える人はあまり多くありません。なぜなのでしょうか？

上流工程を別のチーム、もしくはベンダがやっていて、そこに対する不満がある、というケースも考えられます。この場合には不満を持つ人と実際に実施している人が異なるので、なかなか問題意識が実施している当人たちに伝わっていない、というケースもあるかもしれません。

もう一つの可能性としては、上流工程を改善するといっても具体的にどうしたらよいのかがわからない、ということも考えられます。いろいろな手法、ツールなどがあるのですが、どのような方法をとったら実際に良くなるのかがはっきりしない、ということです。

プロジェクト運営の方法はおそらく各社各様、同じ会社内でもチームごとにいろいろと特色があって異なるのが実情だと思います。そしてあるチームでうまくいったからといって、ほかのチームでそのまま同じように適用してうまくいくとは限りません。

こういったプロジェクト毎の違いにばかり目を向けていると、全体として上流工程を改善するやり方が見えてこない、というのが実情なのではないでしょうか？

じゃあどうすべきなのか、を明日考察することにしましょう。（できるかな？）

ライトスピード社との戦略的パートナー契約に関するプレスリリースを行いました。

詳しくはこちらをご覧ください。

「工事進行基準時代のプロジェクト・マネジメントセミナー」というセミナーを開催します。

【受講無料（事前登録制）】2008年10月16日(木曜日) 14:00?16:00
サン・マイクロシステムズ用賀本社内26F セミナールーム

受講予定者数 50名
受講料 無料（事前登録制）
主催 アップデイティット株式会社
協賛 株式会社アドライト,株式会社ＳＤアドバイザーズ,ライトスピード株式会社

工事進行基準のプロジェクトに発生する問題は何か？　どう対処すべきなのか、など、プロジェクト・マネジメントの現場に焦点をあてたセミナーを開催します。

「工事進行基準の初歩」から始め、プロジェクト・マネージャにとって気になる疑問点などを、ケーススタディなどを通して理解を深めることを目的とします。参加者の匿名形式でのアンケートを通して、業界動向の把握にも努めます。

また工事進行基準対策で活躍中で公認会計士でもある株式会社アドライトの木村忠昭氏にもオブザーバとして参加して頂き、財務会計と管理会計の観点からのアドバイスを頂きます。

気軽に参加していただけるセミナーです。奮ってご応募ください。

応募はこちらから

マイクロソフトは、コンシューマー向け「Windows」を再構築するという記事がITMediaのニュースに載っています。図を見て思ったのですが、これってマイクロソフト版のコンシューマ向けクラウドのイメージですね。（クラウドの先のクライアント側しか描かれていませんが）

1つ感じた点は、マイクロソフトのクラウドはすべてマイクロソフト製品で固められたモノリシック(monolithic)構造だ、ということです。今回の発表ではそれら全部まとめてWindowsという名前で呼びますよ、としています。

そして、「Life Without Walls」（壁のない世界へ）というメッセージ。

ある閉鎖的な環境の場合にはこのモノリシックな構造は管理上都合が良いと思います。しかしコンシューマ向けのクラウドとしてモノリシックな構造を望む人がどのぐらいいるのでしょうか？　確かにマイクロソフトの場合、それを主張できるだけのバックグラウンドがあると思いますが、新しいクラウドの世界においてもマイクロソフトがＰＣの世界と同様のポジションになることを望む人（会社）はあまり多くないんじゃないか？　と勝手な想像ですが、そう感じています。

そしてモノリシックさを強調すると、モノリシックなものとそうでないものの間に「Walls」ができてしまうのではないでしょうか？

そもそもクラウドの考え方の中では、その中の各デバイスが特定のＯＳなり、ミドルウェアなりに拘泥されない世界がイメージされていると思うのです。もちろんWindowsがその世界の中で重要なプレイヤーとしてある地位を占める、というのは当然の成り行きだと思いますが、クラウドの中ではWindowsも1つのプレイヤーに過ぎず、他の仕組みともWindows間のやり取りと同様にWebという仕組みでインターフェースできるんだよ、と伝えていくことが本来あるべき姿なのではないか、と感じました。

約1年前に、SaaSについて私のブログでこんなことを書いていました。

■ 技術者の立場から見たSaaS（および技術者の立場から見たSaaSその２）
■経営者の立場からみたSaaS

今回はその第3弾（1年ぶり…）として、ユーザの立場から見たSaaSというテーマを考えてみたいと思います。

ユーザから見たときのSaaSならではのメリットは、実は上記の２つでも同じことを言っているのですが、「継続的な改善」にあると思っています。

一般に、SaaSモデルでは継続的に行われるバージョンアップについて、特別な料金を取ることなしに最新のバージョンが利用できるようになっていると思います。勝手にどんどん機能向上していくということです。継続的に改善が行われていれば、システムが陳腐化するリスクが比較的小さいといえます。

パッケージ型の場合には導入した以降、期間がたつと必ずシステムが陳腐化してきて、いずれ新しいバージョンを導入するか、乗り換えるか、という話になります。この場合、新しいバージョンへの入れ替えにしたとしても、カスタマイズ部分の作りかえやテストなど、それなりのコストと期間を要します。このためになかなかバージョンアップができずに、導入してしばらくたった現在、塩漬け状態になっているというケースも多いのではないでしょうか？

SaaSを導入するという理由はもちろんこれだけではありません。他にも例えば
(1) ハードウェアなどを購入する必要がないこと
(2) 運用を自前で行う必要がないこと
(3) ソフトウェア費を経費化できること
など様々なメリットが考えられます。ただ(1)や(2)についてはアウトソーシングと言った観点でのメリットであり、(3)もリースにすれば同等の効果が得られるなど、必ずしもSaaSでなければ実現できない、というものではないです。しかしこういったメリットも含めて一括で恩恵を受けることができるというのは、やはりすぐれた方式であるといえると思います。

上記に加え、さらにシステムの陳腐化をできるだけ抑えるという観点でSaaS導入を考えるという時代がいずれ来るものと、私は考えています。