update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あらかじめ断っておきますが、以下の話は今当社が研究・開発しているものとはまったく関連がありません。純粋にこうしたらいいんじゃない？っていう話です。

今から１０年以上前の話なのですが、私は昔、当時勤めていた会社内で「コンポーネントウェア宣言」なる文章を書いたことがあります。コンピューターのハードウェアは最初は真空管に始まり、トランジスタ、ICと徐々に集積度があがり、最終的にはLSI（大規模集積回路）と呼ばれるまで集積度が上がったのだけれども、ソフトウェアも徐々にそのように集積度があがり、コンポーネント単位で扱われる時代に変わるでしょう、そこでどんな「コンポーネント」を用意したらビジネスになるのか考えてみませんか？という内容でした。

ま、正直なところ社内で相手にしてくれる人はあまりいなかったのですが、その後ERPソフトをベースにした商売を外資系システムコンサルティング会社がやっているという話を聞いたときに（ERPソフトがコンポーネントといえるか？という点は若干あるものの）、やっぱりそうなってきたな、という実感がありました。

さて現代。今までフレームワークというと、どちらかというとシステム的基盤として用意されることが多かったと思うのですが、私は今後、業務システム毎のフレームワークというものを作っていくべきだと考えています。そう、業務システムのコンポーネント化です。ERPソフトはその１形態に過ぎないと思っています。もちろん基盤とするシステム技術としては一般的なフレームワークを利用するのですが、その上にカスタマイズ可能な業務アプリケーションを作りましょう、という話です。

少し前のブログ拡張ポイントは計画的に その２において、一般の業務系のシステムでも拡張ポイントを予め設計しておくべきだという話を書いたのですが、この拡張ポイントを正しく設計するというのが業務システムのフレームワーク化だと考えます。

システム基盤としてのフレームワークは低レベル階層のものでしかありません。カスタマイズ可能な業務システムとして、業務に特化した高レベル階層のフレームワークが一旦構築できてしまえば圧倒的な強みとすることができるはずです。

以前大量のメールが飛び交うでプロジェクト内でのメールのやり取りの多さについて書いたのですが、今回はビジネスインフラとしてのEメールについて書いてみたいと思います。

Eメールは今やビジネスインフラとして完全に定着しているといって良いでしょう。仕事上のやり取りを行うには実に優れた仕組みです。BtoBの商売であれば、まずほとんどのケースでメールでのやり取りが可能だと思いますし、履歴も自動的に残るので、電話の場合のように言った、言わないの問題になることがありません。またPUSH型の仕組みでありながら、いつメールを読むかは読み手側の都合で決められるので、うまく使えば非常に効率的に仕事が進められるようになります。

ある意味でFAXが似たような情報伝達の仕組みだといえますが、送る手間、受け取る手間、整理する手間など、FAXはいろいろ手間がかかりますよね。私の場合、FAXとメール、どっちかを選択しろといわれたら何の躊躇もなくメールを取ります。とまあ、便利なことは間違いないメールですが、一方でスパムメールの多さに辟易している方も多いと思います。またスパムメールとはいえないものの、こちらがそれほど読みたいとは思わない広告メールを送り続けられる、というのもあまりうれしくない話です。

スパムメールに対してはスパムメールフィルタが便利なのですが、間違えて通常のメールがスパムメールとしてブロックされている場合が多く、ちょくちょくスパムメールのリストをチェックしなければならない点が難点です。またドメイン名でスパムメールを判別している場合、ちゃんとした会社のドメイン名がなぜかスパムメールのブラックリストに載ってしまって、そのお客様からのメールがいつの間にか受け取れなくなっていた、なんてこともありました。

スパムメールは送信にコストがかからないことに起因していると思います。そう考えると実現性は薄いのかもしれませんが、インターネットとは別の、送信するのにコストのかかる有料のビジネスEメールネットワークなんてのがあっても良いのかもしれませんね。

一般に会議って無駄って言われますよね。　って、言いすぎかもしれませんが、無駄な会議の多さを良く聞きます。私も今まで無駄だなって思う会議が数多くありました。こんなの皆を一同に出席させなくてもいいじゃん、ていう会議です。中でも自分がその会議にいる必要性が感じられない場合（当事者意識が感じられないテーマの会議のとき）には特に強く感じたものです。

一方で以前Face-to-faceでダイレクトコミュニケーションの重要性を書いたのですが、会議というのはうまく実施できればまさにこのダイレクトコミュニケーションの場として非常に有効になります。例えばドキュメントを読むよりも人に説明してもらったほうが早く内容が理解しやすいということがありますよね。会議の前に事前に各自ドキュメントを読んでおいて会議の時には質疑応答だけにしろ、なんていう堅苦しい会議運営が行われる場合もありますが、実は事前には何も時間を取らずに、会議の場で説明をしてもらった方が効率的な場合も多いかもしれません。

会議を無駄にしないために大切なことは、出席者を絞り込むことだと思います。本当に出る必要のある人だけに出席してもらい、内容を押さえておけばいいだけの人ならば冒頭でさっさと帰してあげるようにするか、内容を理解するためのプレゼンコーナーだけに出席してもらって後は帰してあげるとか、ちょっとした工夫で意義の高い会議運営ができるのではないでしょうか？

よく会社の前をたむろっているねこ達です。

ぐー。

昨日、ANAが予約や搭乗手続き、手荷物管理などを行うシステムでトラブルが発生し、予約や発券、搭乗手続きなどがしにくくなったため羽田空港を同日午後6時までに出発するすべての便を欠航にした、というニュースが流れていました。このニュースの詳細はまだよくわかりませんが、気になったことがあります。コンティンジェンシープランはどうしたの？ということです。

飛行機を制御するようなシステム、すなわち安全に直接関連するシステムの場合にはそもそもシステムトラブルが絶対に起こらないように二重三重の対策をする必要がありますが、今回トラブルを起こしたシステムはチェックインのためのシステムということで、業務の自動化システムであり、直接安全性に関わる部分ではないように思えます（実際のところはわかりませんが）。一般に業務を自動化するためのシステムの場合、万が一そのシステムが停止した場合に備えてコンティンジェンシープランを作って備えておき、いざとなったらマニュアルで運用して回避するのが普通だと思うのですが、今回の件はどうだったのでしょうか？　新聞を読む限りは職員が手作業で対応したが追いつかなくなり、朝の段階から遅延や欠航が出始めた、とありますので回避策は一応行ったのだと思いますが、準備が足りなかったのかもしれません。

システムを設計する際に、このようなシステムトラブルに対応するための仕組みを用意しておくことも重要です。例えば証券系の発注システムの場合、取引所へ発注するたびにそのログをラインプリンターに印字する場合があります（今どきラインプリンター？といわれてしまいそうですが、１件発注するたびに紙媒体上に１行記録するにはこれが一番良いのです）。　こうして紙に残しておけば、万が一その時点でコンピュータがダウンしたとしても、最低限のことはその紙を見ながらマニュアル対応でなんとか切り抜けられるようにするわけです。そして数が多い場合には人海戦術で対応できるように準備しておきます。

ハードウェアのトラブルの場合には交換することによって復旧できることが多いですが、ソフトウェアのトラブルの場合、そう簡単には復旧できない場合があります。その場合に備えて、可能であればマニュアルでなんとかなるように設計しておくことがコンティンジェンシープランへの第一歩だと思います。