MicrosoftのクラウドOS「Windows Azure」

コメントは受け付けていません

投稿日:2008年10月28日 作成者:yasunaka

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

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

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

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

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

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

タグ 雑談

SEとは?

コメントは受け付けていません

投稿日:2008年10月20日 作成者:yasunaka

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

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

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

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

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

タグ 雑談

工事進行基準時代のプロジェクトマネジメント・セミナー終わりました

コメントは受け付けていません

投稿日:2008年10月17日 作成者:yasunaka

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

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

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

タグ 会社

IT業界の病根の深さ

コメントは受け付けていません

投稿日:2008年10月09日 作成者:yasunaka

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

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

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

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

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

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

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

タグ 雑談

crossnote ver 1.3.1リリースします

コメントは受け付けていません

投稿日:2008年10月07日 作成者:yasunaka

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

1.参照検索機能の強化

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

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

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

参照リンクの例

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

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

外部ファイルのコメントの例

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

外部ファイルにつけたコメントのリンク

2.外部ファイルの使い勝手の向上

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

3.戻る/進む機能

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

4.選択範囲の文字数の表示機能

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

文字列の選択

タグ crossnote

ミスを防ぐ方法

コメントは受け付けていません

投稿日:2008年10月02日 作成者:yasunaka

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

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

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

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

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

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

タグ システム