update it, Inc.社長のブログ

エンタープライズ・アーキテクチャ（Enterprise Architecture、以下EA）が叫ばれるようになって久しいですが、あなたのところでもEAしていますか？　ユーザにとってメリットが大きいはずのEAですが、正直なところ、（ちょっと不謹慎ですが）システムを作る側からすると邪魔に思える存在だったりします。それはEAは技術の標準化を求めるものであり、技術革新とは相容れない要素があるからだと思います。今回の案件にはこの技術がぴったりのはずなのに、EAから外れるから使えない！　なんて経験、ありませんか？

私が一般に言われるところのEAについて疑問に感じているのは、果たしてドックイヤーと呼ばれるシステムの世界において、技術革新を無視して社内標準を採用し続けることが正しい戦略なのか、という点です。もちろん何でもかんでも新しいものに飛びつけ、と言っているのではありません。しかし適切に技術評価を行ったものであれば、むしろ積極的に新しい優れた技術を採用したほうが長期的には正しい戦略ではないのか、と思うのです。

EAの中でも、例えばデータモデル、コード体系の統合やアプリケーション間のインターフェースの共通化などはぜひ進めるべき課題だと思うのですが、一方、運用管理コストの低減という観点で、対象のハードウェアやOS、ミドルウェアに縛りを付けてしまうというのはいかがなものかと思います。もちろんあまりにバラエティーに富みすぎては管理できなくなってしまいますが、単一のハードウェア、OS、ミドルウェアに統一した場合の、システム・ポートフォリオのライフサイクル全体にかかるコスト・効果と、２，３のハードウェア、OS、ミドルウェアに分散「投資」するコスト・効果を比較した場合、むしろ後者のほうが優れている場合が多いのではないかと私は思うのです。

今の運用管理者では管理できないから、という理由で実現できていないとすると、厳しい言い方をすれば、それはその運用管理者をただ甘やかしているだけにしか思えません。もちろん新しいOSやハードウェアに対応するには、教育コストも余計にかかることになりますが、それを加味してでも将来の技術標準に対するリスクヘッジという観点で十分にペイできるのではないか、と私は考えます。

会社の隣がケーキ屋なんですが、その前で犬がお行儀良くご主人を待っていました。

年金記録漏れの問題が世間を騒がせています。年金記録5000万件が過去のシステム切り替え時などでうまくリンクがとれずに宙に浮いたままになっている件です。この件でＣＳＫホールディングスの有賀貞一さんがNIKKEI NETのIT+PLUSに寄稿している記事業務・システムの視点が欠落した「年金記録漏れ」問題の与野党議論を読み、大変面白いとおもいました。

「いかに政治家や官僚が社会インフラである情報システムと、それにまつわる業務処理に無知であるかが明解になった」
さすがシステムの専門家だけあって、業務的な観点、システム的な観点、コスト的な観点から、今回の決定が如何に「何も考えずに」行われているかを指摘しています。

読んでいて感じたのは、著者の有賀さんは「政治家や官僚」に特有なこととして指摘しているのですが、果たしてそうなんだろうか？　という点です。実はシステムの開発に絡んで世間一般によるある話ではないだろうか？と思ったからです。

つまり業務的な観点やシステム的な制約事項などが考慮されずに先に予算や期限ありきで物事が決まってしまって、あとからシステム担当者がそれにあわせるために四苦八苦、というのは良く聞く話だからです。もちろん今回の決定は1年という短い期間に区切ることにより、不安感を払拭するという戦略的な意味があるのは間違いなく、戦略を重視してそれにあわせて現実を変えていくという考え方そのものは正しいと思います。これは一般の企業でも同じような話であり、先に予算が決まるのも、対象の業務に対する投資対効果をベースに枠を決めていると考えれば正しい行動だといえます。

ただし問題なのは、いくらそれが戦略だとしても裏付けのないまま事を運んだ場合のリスクを考えていないことにあるでしょう。一年以内の突合を公言したために、期限を守ることが絶対条件になってしまった、と考えると、この後、悲喜こもごもとしたことがいっぱい起きそうだな、と勝手に想像してしまいました。

プロジェクトマネージャの重要な業務のひとつとして、プロジェクトメンバに対する評価があります。これは単にそのメンバへの支払いを決めるということではなく（そもそも普通のプロジェクトマネージャの場合、そこまで権限をもっていないことが多いですね）、プロジェクトメンバのやる気を高めるための1手段として評価を行うという側面が多いのではないでしょうか。

あるプロジェクトマネージャの人から聞いたのですが、その人はできるだけプロジェクトメンバーが日常で話した、何を目指しているのかとか、どんなことがしたいとか、そんなことををノートなどに記録するようにしているそうです。そして評価のフィードバックのときなどで、以前こんなことを言っていたけど、こうだったね、みたいに伝えてあげるようにしているそうです。

プロジェクトメンバからすると、ああ、この人は私のことをちゃんと見ていてくれているのだな、と感じることになります。この『見守っているよ』感がうまく伝えられればチーム運営上、大きなアドバンテージとなるに違いありません。プロジェクトマネージャからはプロジェクトメンバは1対多の関係なのですが、プロジェクトメンバからみれば1対1の関係だと考えてあげることが重要なのだと思いました。

ある人から、こんな問題をもらいました。「今あなたは新しく人を採用しようとしています。候補として次の2タイプの人しかいない場合、どちらを採用しますか？」

１．協調性が良いが技術的には平凡なタイプ
２．協調性が低いが技術的に非常に優れたタイプ

これって実際良くある話かもしれません。協調性が良く、かつ技術的に非常に優れたタイプであれば即採用なわけですが、そんなスーパーマンはそんなにいるわけではありません。

私の予想では、通常は１のタイプを取る人が多いのではないでしょうか？　特にチームワークを重視するプロジェクト運営を目指しているならば、絶対１の人を取るのだと思います。一方、短期間にアウトプットを出すことを求められているプロジェクトの場合、２のタイプを取るのではないかと考えました。

ただいずれのタイプにせよ、長期間プロジェクトメンバとして一緒に仕事をするのであれば、その人の足りない部分が補われるように育てていくことが重要なのだと思います。そういった意味では技術力が平凡なメンバーは、優れた技術力の持ち主の人の下に付けて技術力を育てるべきだと思いますし、逆に協調性が低いメンバーであれば、優れたプロジェクト・リーダーの下に付けてリーダーシップを身に付けさせるというのもいいのかもしれません。

働くことが好きな人ってどの程度いるのでしょうか？　私の場合はやりがいのある仕事の場合には、どんなに多く残業しても苦になりません。（やりがいの感じられる仕事の場合には、という条件付ですよ。）　いろいろ周りの話を聞くと、この業界には同じような考えの人も多いのかな、と思います。

私の場合は今は労働者としては扱ってくれないので、働き過ぎでくたばったとしても誰も文句を言ってはくれないのですが、通常、会社のプロジェクトの場合、そのプロジェクトメンバがどんなに仕事好きで、がんばって残業したくても会社としての労務管理上、それが認められない場合があります。またコストを圧縮したいという経営からの要求のために、できるだけ残業をしないようにコントロールしているという話も聞くことがあります。現場でプロジェクト管理をしている人であれば、プロジェクトメンバがもっと仕事をしたいと思う気持ちと、さっさと帰さなければならないという立場の板ばさみに苦しんでいる人も多いのではないでしょうか？

働きすぎで健康的を害するというのは絶対回避すべきことなのですが、おそらくそれは単に時間が長いということが問題なのではなく、長時間強いプレッシャーを受けながら仕事をしていることが問題のような気がしています。逆に上記で書いたような、自分から好き好んで残業仕事をしているプロジェクトメンバというのは、おそらく少なくともその仕事に関しては、プレッシャーの強さよりも仕事を楽しむことのほうが勝っているから、進んでやっているように思えます。

そのようなケースで少し問題なのは、プロジェクト管理者側がなぜそのメンバが残る必要があるのかが把握しきれない場合があることです。メンバ側も、いまやっていることがなぜ必要なのかを、管理者側にきちんと理解してもらうよう、説明責任があるといえます。

いずれにせよ、楽しんで仕事ができるというのはまさに理想的な状況だと思います。もしそのような状況が実現できているのであれば、度を越さない範囲で好きなだけやってもいいよっ、というような選択権を与えることはできないものでしょうかね？

もし顧客から、まだ内容が明確になっていない新しいシステムについての概算見積もりが欲しいといわれたら、あなたはどうしますか？　リスクを回避するために、システムの設計フェーズと実装フェーズを分けて、最初はシステムの設計フェーズのみを確定金額で受注し、実装フェーズは別途見積もりを行う、というのが教科書的な答えになるのですが、問題なのは上記のような手続きになるにせよ、顧客側では最初の概算見積もりに基づいてシステムに必要な予算を立てるため、結局その最初の概算見積もりが上限になってしまうことが多い、ということです。私も今までなんども、これで痛い目にあってきました。

概算見積もりの難しさの主因は、情報の少なさにあります。見積もり精度の良い手法というのがいろいろと編み出されていますが、結局その手の手法は何を作るのかがかなり具体化していないと適用できないものがほとんどで、概算見積もりが必要な段階では用を成さない場合がほとんどです。何を作るのかが確定していないのに正確な見積もりなどできるわけがありません。以前、概算見積もりの段階でソースコードの行数をベースに費用を見積もったベンダーを見たことがあるのですが、その思い切りの良さにある意味すげーっ（褒めたわけではないですよ）と思いました。

知人のプロジェクトマネージャの話では、「いろいろ考えて積み上げて算出した数字を、最後に3倍する」と答えてくれました。この最後の3倍というのが味噌で、そうすると経験的に収支トントンになる場合が多い、ということです。最後の倍率は状況によってはいろいろ異なるのかもしれませんが、少なくとも概算時に積み上げた数字というのは、まだ内容が見えてない分、大きな穴が開いている場合が多いので、かなり余裕度を見ておかないと痛い目に合うよ、ということを物語っているのだと思います。

日本ではシステム開発の現場でシステムエンジニア(SE)とプログラマー(PG)を分けている場合が多いですが、この違いって何なのでしょうか？　経済産業省の平成１７年特定サービス産業実態調査という資料において、情報サービス業の概況には、平成１７年のシステムエンジニアが242,098人、プログラマが101,986人となっており、情報サービス業全体に関わる割合はそれぞれ42.2%、17.8%となっています。つまりSEのほうがPGの倍以上いることになります。さらに平成１６年との比較で見ると、この数値はSEは0.3%増えているのですが、PGは-3.6%と大幅ダウンしていることがわかります。これは何を物語っているのでしょうか？

システムエンジニアの定義をWikipediaで見てみると、『情報システムの要求定義、設計、構築、運用に従事する職』となっており、『日本では企業情報システムの開発に携わる者に対して主に使われる用語』という説明があります。一方のプログラマは『設計に基づいて実装を行う人』という意味で使われることが多いと思います。では上記の統計によると、日本では情報システムの要求定義などを行う人が増えて、実装を専門に行う人は減っている、ということになるのですが、本当でしょうか？

上記の特定サービス産業実態調査においてどのような区分けでシステムエンジニアとプログラマを分けたのかはわかりません。Wikipediaにはプログラミング環境が進化した現代のシステム構築ではシステムエンジニアがプログラマを兼任することも多い、という記述が見られるのですが、プログラミング環境が進化した（？）から兼任が増え、プログラマの数が減ったというのは実感が伴ないません。あくまで仮説なのですが、おそらくシステムエンジニアとプログラマの区分けは自己申告制でありそもそも区分けがはっきりしないこと、そしてプログラマよりも上級のイメージを持つ「自称」システムエンジニアが増えたためと考えたほうがより自然な気がします。

もしこの仮定が正しいとして、みんながプログラマよりもシステムエンジニアのほうが偉いんだ、とか上級なのだ、と考えているとしたら、それは嘆かわしい事実のように思えます。おそらく派遣業において、プログラマというタイトルよりもシステムエンジニアというタイトルのほうが単価が高くなっている、という事実からきているのでしょう。でも仕事の職種の違いは必ずしもその人の能力差を表しているわけではなく、例えばバリバリ仕事ができるスーパープログラマのような人たちもいることを考えても、システムエンジニアがプログラマよりもランクが上だ、なんてそもそも間違っているとしか思えません。

生涯プログラマというのもカッコいいと思いませんか？　システムエンジニアとは本来異なる職種ということで、プログラマという職種をもっと肯定的に捉えられるようにイメージを変えていきたいと、私は願っています。

物の本には、プログラムを作る際にはパフォーマンス・チューニングは最後にやるものだ、と書いてあります。これ、ウソだと思います。

もちろん最初からプログラム上の小細工をしてパフォーマンスの良いプログラムを書け、ということではありません。が、システムの基本的な処理フロー、基本的なアルゴリズムの部分が根本的に間違っているときには、いくら最後に小細工してもどうしようにもない場合があります。もしそうなってしまうとデータモデルも含めて大幅な修正が必要になってしまうことだってあるのです。

だからシステムを作る際には、まず粗々の処理フローを組み上げたときに最初にパフォーマンステストを実施すべきです。その時点で既に問題があったら最初に戻って再設計が必要ということになります。

この手の問題は、例えばネットワーク上に分散されたオブジェクトを扱っていると特に良く遭遇します。オブジェクトのやり取りの粒度を間違えるとパフォーマンスに大きな影響がでますが、この修正はいろいろと影響がでやすく、最後に行うにはあまりにもでかいものです。これからSOAやろうという人は気をつけてくださいね。

予めパフォーマンステストを早い段階で実施しておけば、その後機能追加によって徐々に遅くなった場合の許容度を見積もることもできるようになります。最後になってあたふたしないためにも、プロジェクトのリスク管理の一環として早めのパフォーマンス・テストの実施をお勧めします。

今日は気温こそ低めですが、雨上がりのせいか少し蒸し蒸ししますね。

もうすぐ梅雨に入りますが、自転車が使えなくなるのが悲しいです。