update it, Inc.社長のブログ

ついに来た、という感じでしょうか？

Microsoft、クラウドOS「Windows Azure」を発表

Amazon EC2のように、Microsoft自身がデータセンターを運用し、Windows Serverのクラウド版とでもいうべきAzure Service Platformを提供する、ということのようです。

Microsoftの開発環境(Visual Stadio)などを使って開発ができるという点で、プロプライエタリ とはいえ、業界標準ともいえる開発環境なので、以前PaaS(Platform as a Service)で書いたように「独自の環境」に取り込まれてしまい、他の環境へ移ることが難しいという問題を実質的にクリアできそうだと思います。

最初はインターネット向けのサービス基盤としての利用が多いと思いますが、私はこれは社内システムの構築基盤として有力な候補になってくる可能性があるように思えます。つまり社内システムをWindows Azure上で構築するということです。

ある意味、データセンター業務に相当する分野に本格的にMicrosoftが乗り出してきたということになります。利用する側から見ればチャンスであり、逆に今までの提供する側にとっては、かなり脅威に感じるところも多いのではないでしょうか？

相変わらず＠ＩＴ自分戦略研究所の後藤和彦さんのコラム下流から見たIT業界「SEとPG、どっちが頭がいい？（1）」が面白いです。少し攻撃的な内容ですが、とても共感を呼びますし、ためになります。ぜひ読んでみてください。

ただし、私はSEという職種は必要だと考えていて、そういった観点では後藤さんとはちょっと意見が異なります。

そもそもSE v.s. PGのような職種間での上下関係という考え方そのものが間違っている、と考えています。（参考システムエンジニアとプログラマー）　本来やる仕事の内容がぜんぜん異なるものであり、どっちが偉いとかいう話ではないはずです。でも今までの日本のシステム開発の現場では、PGの上がSEという固定観念が出来上がっています。これは悲しい事実だとしか言いようがありません。

そもそもSEとPGではやるべきことが異なります。顧客の要求仕様（機能要件、非機能要件）をまとめ、仕様を確定させたり、出来上がったものがその要求仕様に合致したものかどうかを検証したりするのがSEです。また複数のPG間のコーディネイト役としてモジュールやインターフェースを設計する場合もあります。要求仕様を満たすためのデータ設計も必要です。しかしSEがやるべき仕事とはそこまでであって、中身を創り上げる実装はPGの仕事です。

ある程度の規模のプロジェクトの場合、SEの仕事はPGの仕事の片手間にやるようなものではないはずです。世の中にはPGとやることがあまり変わらないSEがはびこっているとすれば、それはおそらく上記のシステムエンジニアとプログラマーに書いた「自称SE」なのではないでしょうか？

昨日、サン・マイクロシステムズ用賀本社のセミナールームをお借りして「工事進行基準時代のプロジェクト・マネジメントセミナー」を行いました。ご出席していただいた方、誠にありがとうございました。

前半は工事進行基準の初歩として、基本的な概念の説明、後半は実際に工事進行基準で今までプロジェクトを行ってきたところの例を元にケーススタディを行いました。少しは役にたつ情報をお伝えできましたでしょうか？

今後も随時、皆さんのお役に立てるような情報を、様々な形で発信していきたいと考えております。今後もよろしくお願いいたします。

最近＠ＩＴの自分戦略研究所で後藤和彦さんが書いているコラム下流から見た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%)」となっています。

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

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

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

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

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

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

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

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

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