update it, Inc.社長のブログ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ぐー。

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

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

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

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

最近会社のお仲間になった熱帯魚君たちです。

癒されます。

昨日の「能力の応じた支払い」に関連するテーマなのですが、作る人と指示する人の違いについて書きます。

ある人から、本来のプロジェクト管理者が自分でプログラムを作っているためにプロジェクトが管理されていないことがあった、という話を聞きました。これは小さいチームでは仕方ない場合もあります（現に私の会社では人が少ないこともあって私自身がバリバリコーディングしています）。しかしプロジェクトがある一定の人数になったら、プロジェクト管理者はプログラムを作ってはなりません。プロジェクト管理者、つまり指示する人はプロジェクト・メンバーが少しでも作業がやりやすいように環境を整えてあげるのが仕事であって、自分が一緒になって作業者になってはいけないのです。

私の会社の場合でいうと、今は社長の私自身も一緒にプログラムを作っているのですが、これは７月末までと予め宣言してあります。本来の社長業（といっても零細企業の社長業ですけどね）を行うためです。（ということで、社員のみんな、よろしくね！）

さて本題に戻って、指示する人のやるべき仕事とは、プロジェクト・メンバが少しでも作業がやりやすいように環境を整えることだと書いたのですが、ここでいう環境には非常に広い範囲のことが含まれます。クライアントとの調整はもちろんのこと、仕事の優先順位付けやタスク管理、プロジェクト・メンバへのケアなどいろいろですが、こういった仕事はすべて、プロジェクト・メンバが作業をやりやすくするために行うことだと思います。考え方の問題だと思うのですが、決して仕事を「やらせる」のでなく、彼らが仕事がしやすいように手はずを整える、ということです。つまり指示する人、と書きながら、実際にやるべき事は、仕事を事細かに指示することではなく、中のプロジェクト・メンバに対するある種、奉仕のような仕事だと考えるべきではないかということです。

ただし、これはシステム開発の現場のプロジェクト・メンバがプロフェッショナル集団である場合に可能な話です。プロジェクト管理者はプロフェッショナルに対する奉仕者であるべきだ、ということです。この形態は非常に理想系なのですが、中のメンバーがすべてプロフェッショナルであるという前提条件が付いていることには注意してください。

システムの開発現場では今まではたいていの場合、経験年数に応じた支払い体系になっていることがほとんどです。これは日本の年功序列制度が根底にあるためだと思います。しかし実際にシステムの開発能力で見た場合、必ずしも経験年数と能力は比例関係ではないですよね。

プログラマー３５歳定年説がささやかれるのも、こういった背景があるからではないでしょうか？　つまり年齢が上がるに従って給与が上がることが暗黙の了解となっているために、給与を上げ続けることができないばかりにプログラマーを続けられなくなる、ということです。

プログラマーというのは特別な能力が求められる職業です。（プログラマーと単なるコーダーの区別がつかないような人はこのブログを読んでいる人にはいないでしょう）　従って能力が高ければそれだけ払う、低ければ安い、というのは非常に当たり前の話に思えます。本来は優秀なプログラマーなのに、年齢に応じて給与を上げ続けなければならないという呪縛のためにプログラマーを辞めなければならない場合があるとしたら、非常にもったいない話だと思いませんか？

技術の進歩は日進月歩なので付いていくのが大変だという面もありますが、大変なのは若い人でも同じはずです。新しい技術を吸収するスピードそのものがそんなに大差あるわけではないと思います。そして新しい技術の学習を開始するタイミングは若い人でも経験年数が多い人でも変わらないはずです。だからマスターするタイミングもそんなには変わらないことになるのですが、そこは経験年数が多い分、若い人よりもなんでもかんでも優れていなければならないという暗黙の了解、つまり新しい技術に対して若い人と同じ水準でいいのか、という「良心」が彼らを苦しめているのだと思うのです。

日進月歩の技術とは別に、システム開発に関するノウハウや知見というのもあります。これは基礎的な能力であり、短期的な技術の変化で評価が変わらない部分で、その人の本来の能力の大きな部分を占めているはずです。この本来の能力を正当に評価して支払うことこそ、能力に応じた支払いなのだと思います。

管理者に向かない、優秀なプログラマーがいるのは事実です。また全員が管理者になれるわけではないことも明白です。そういった人たちが気持ち良く働けるようにすることが、競争力の強い会社とする１つのポイントではないでしょうか？　「スーパープログラマー」と呼べるレベルの人たちに対し、管理者と同等か、もしくはそれ以上の給与を得られるチャンスを提供していくことも検討すべきでしょう。

以前曖昧な仕様や一人が仕様を決める、とはという内容で、1名のプロジェクト・オーナを決めて、その人が勘と度胸ですべての仕様を決めていく方式のほうが実は費用対効果が優れているという話を書いたのですが、今日はそれに類する話で、「ヘッドは誰か」というテーマです。

うまくプロジェクトを進めるためには、やはりユーザ側の意思決定者、つまりヘッドを１人に絞り込んでもらうべきだと思います。経験上、ユーザ側の意思決定者が不明確な状態でうまくいったプロジェクトはありません。（私自身、何度もこれでだいぶ痛い目にあってきました）　このヘッドとは形式的な話ではなく、実質的に、１名のヘッドが意思決定をしているかどうかという話です。もちろん組織的にその人が対象案件におけるヘッドであるという裏付けは必要です。

もしユーザ側に裏の意思決定者がいたり、誰も意思決定をしていなかったり、本来ヘッドであるべき人がその機能を遂行していない場合には、ユーザ側に対し「これではプロジェクトがうまくまわらない、改善しないことには手を引く」ぐらいの厳しい態度で臨むべきだと思います。

もちろんサブシステム毎に機能が分かれていて、そのサブシステム内に閉じた意思決定については、そのサブシステムのヘッドが判断すれば良いのです。ある事象を判断するのが誰か、ということが明確になっていて、その対象者がきちんと機能していればよいわけです。

プログラマーの間に一般に浸透してきたリファクタリングという言葉ですが、誤用が目立つという話を聞きました。プロジェクトのメンバーがいつまでたっても進捗が進まず、何をやっているのか聞いてみると、延々とリファクタリングをしていると言う。でもどう考えてもやっていることはリファクタリングではない。確かにこの手の話は私もたまに聞きます。

上記の例では作り直すことをリファクタリングと称していて、実際にやっていたのはリストラクチャリングだった、ということでした。確かにリファクタリングとは作り直すことの一種ではありますが、外から見たときの振る舞いを変えずに中身を洗練させる作業であり、振る舞いが変わってしまうような場合にはそれはリストラクチャリングと呼ぶべきです。しかしリストラクチャリングという言葉が一般化していないためか、もしくはリファクタリングという言葉がかっこよくて、ある種免罪符のように使えるからか、なんでもかんでもリファクタリングと称してしまう場合があるようです。

リファクタリングは常に推奨すべき行為だと思いますが、リストラクチャリングとなると通常時間、つまり工数がかかるので、実施すべきかどうかはプロジェクトの状態によって判断が分かれると思います。それが今後のシステムの開発を阻害するような問題を含んでいる場合にはリストラクチャリングすべきですが、そうではない場合には無理に行うべきものではありません。

行っている行為がリファクタリングなのか、それともリストラクチャリングなのかの判断は、厳密にやろうとするといろいろ議論があって難しいと思いますが、１?２時間以内、どんなに長くてもせいぜい半日以内に完了するレベルがリファクタリングであり、それを超えるレベルの場合にはおそらくリストラクチャリングになっていると思います。もし皆さんのプロジェクトのなかで何日間にも渡ってリファクタリングをしているという例があるのであれば、それは本当にリファクタリングなのか、もしリストラクチャリングであるならば、それは本当にいますべきリストラクチャリングなのかを判断させるべきだと思います。