update it, Inc.社長のブログ

隣の公園で花が咲いていました。

暑さ寒さも彼岸までって言いますが、ちょっと和らいできましたね。

プロジェクトを確実に破綻させる方法ってのは穏やかでないタイトルですが、プロジェクトにおけるアンチパターンをいくつか紹介していきたいと思います。プロジェクト管理「手法」についてはPMPとかを勉強すればわかりますが、実際には手法をいくら勉強してもうまくいかないものはうまくいかない。じゃあなぜ？　ってあたりを掘り下げていきたいと思います。

まず最初は「プロジェクト関係者が一致協力していない」。って、小学生でもわかるような話ですが、実はプロジェクトが破綻したケースって、裏の（というか本当の）原因がここにあることが結構多いのではないでしょうか？　つまらないことでメンバー間で意地を張り合っているとか、相手を蹴落とすように競争をしあっているとか、信用していないとか、見下しているとか、そういったメンバーや関係者間のどこか親密ではない関係が、コミュニケーション不足や誤解を招き、プロジェクトへの不満が鬱積し、やる気が低下し…という負のスパイラルを発生させる最大の原因になっていることが多いのではないでしょうか。

逆に、一致協力しているプロジェクトは強いものです。大変な修羅場ですら乗り越える力を持っています。大変だけど、プロジェクトに参加していることが楽しいと感じられるプロジェクトは、おそらくそれだけで成功する確率が大きく高まると思います。

このアンチパターンから脱却するための一番のお勧めの方法は、「仲間意識の共有」です。プロジェクトメンバーや関係者はみんな仲間なんだって、特にリーダークラスの人たちが率先して意識し、発言する。同じプロジェクトを進めてくれるメンバーは、たとえパートナー会社の人であろうが派遣の方だろうが、みんな仲間なんだって、そういう気持ちを育み、一緒にやっていこうっていうちょっとアナクロなやり方が、実はいろんな「手法」を駆使するよりもよっぽど効果的でお勧めの方法です。

うーん、そろそろ換えなきゃ。

ダイソウの100円ポプリです…

システムを設計するときに気をつけていることを１つご紹介します。それはタイトルにある「具体的な検証」です。システムの仕様を設計する際にもっとも重要なこと、それは使う側の立場になって設計することだと思います。使う側のさまざまなシチュエーションを想定し、それに対してシステムがどう応じるのかを検証しておく、ということです。

通常、システム屋がシステムを設計すると、実現すべきことを要件定義としてまとめ、それを正しく実装するというアプローチをとると思います。これは当然正論で間違いではないのですが、いかんせん、要件として書き出された内容を深く理解しているわけではないために、使う側のほんのちょっとした「こだわり」にたいしてあまりに無配慮なことが多いのではないでしょうか？

もちろん不必要なこだわりをシステムに詰め込んでしまうと要件が膨らみすぎ、これはこれで破綻します。ですので「こだわり」をストレートに要件にしてしまうのではなく、なぜそれにこだわるのか、その背景ではどんなことを考えて、何を実現しようとしているのかをできるだけ「具体的に」理解します。この具体的に、ということがとても重要で、誰が、いつ、何を、どのように、何のために、をはっきりさせ、またその周りにある他の「具体的な事象」との整合性を検討していきます。そうやって考えていくと、「あ、こういうことなんだ、」と初めて顧客側の考え方がわかり、その上でより良い解を顧客に提示することができれば、信頼を得られますし、システムもより良いものになると思います。

会社の窓からの風景です。

この前を、よく猫たちがたむろしています。

変なタイトルですが、最近IT mediaの記事で、「字幕.in」を1人で作る…を見たときにふと、いまから10年ぐらい前のVisual Basicがでてきたときのことを思いだして、こんなことを考えてみました。

IT用語としてのマッシュアップとは、他から提供されたWebのサービス（API）を利用して、そこにアドオンする形で新しい付加価値を追加する行為です。元のコンテンツの部分についてはある意味で「パクリ」なのですが、コンテンツ提供者側も意図的にAPIを公開しているのであり、また元のWebのサービスにはない付加価値をそこにつけることに大きな意義があります。先の記事の「字幕.in」などは、一人でこんなものつくっちゃったんだ、て感嘆するぐらい、よくできていますよね。

この「他の人の成果物を利用して、そこに付加価値を追加する」というやり方は、コンピュータの世界では過去、コンポーネントという形で扱われることが多かったと思います。そこで思い出したのがタイトルにあるVB (=Visual Basic)です。VBが出た当時注目されたのは、もちろんグラフィカルに簡単に画面を作れたということもあるのですが、もしそれだけなら既にNextのInterface Builderなど、先行しているものもありました。それ以上に、その当時VBXと呼ばれた部品がいろいろ開発されて、日付をかっこよく入力できる部品とが、データベースとのやり取りが簡単にできるようにする部品とか、そういった部品をペタペタと自分のアプリケーションに張り込んで使うことができた、というのが実はVBが当たった大きな要因だったのではないかと私は考えます。この部品(=コンポーネント)とは、他の人（会社）が開発したものであり、この他の人の成果物をうまく利用することで簡単に本格的なアプリケーションと比較して遜色のないアプリケーションを開発できた、というのがVBが伸びだ大きな要因だったのではないか、ということです。

ただしVBのころと比較した場合、現在のマッシュアップと呼ばれているものは、コンポーネントの位置づけが主客逆転しているというか、利用するAPIのほうがむしろ主といえるぐらい、利用される側の存在（関与する度合い）が大きいという点がだいぶ異なっています。実際似たようなサービスを提供していたニワンゴの「にこにこ動画」がYouTube側の都合でサービスが中断したっていう件もありましたが、サービスとしての脆弱性の克服が今後の課題でしょう。逆にいうと提供する側もこのような不安感を払拭するための施策をとらないと、なかなか企業レベルで利用できるサービスとはならないのではないでしょうか？

会社のコンピュータはデュアルディスプレイ化してあります。１９インチの液晶を２台並べた構成です。これ、いいですよ。仕事の能率アップに寄与すること多大です。

仕事でEclipseを使っているのですが、右の画面で参考にするWebページを開いて左の画面でコーディングするといちいち画面を交互にポップさせたりするような手間がかかりません。またデバックする場合、右画面でプログラムを走らせておいて、左画面でスタックトレースの中身をチェック、なんて場合でも画面切り替えをしなくてすむから、フォーカス移動のイベントが起こらないですむ（おいおい、ナニを作っているだ？）、なんて感じで、とてもお勧めです。

弊社の社員が言っていた話なのですが、RSSフィードは便利だけどたくさん登録してしまうと、更新通知が一杯来すぎてチェックが大変だ、とくに総合的な話題を扱うサイトの場合、まったく興味のない話題についての更新通知がくるのがうざい、という内容の話をしていました。で、彼の思いつきは「RSSフィードにフィルター機能を付けられないか？」。なるほど。RSSフィードもやりすぎるとスパムメールと似たような状況になってしまうわけですね。（ま、メールに比べれば変な勧誘メールが来ない分、だいぶましだけど）

ちなみにグーグルってみるともう既にそんな機能をもったものもあるみたいですね。

実際RSSフィードにしろメールにしろ、人間って自分で情報を集めに行くPOP型よりも、人から情報を送りつけてもらうPUSH型のほうが好きみたいですね。これはおそらく注目したいテーマは決まっていて、情報を絞り込む手間を省きたいからなのでしょうか。私なども普段ごく決まったWEBページを見に行くことが多いというのは、自然に情報の絞込みを行っていることの表れなのでしょうね。ただPUSH型の情報配信が有効なのはPUSHされる量が少ない場合で、多くなってくると自然とPOP型にならざるを得ない。そこにジレンマがあるわけですね。

ってことは、フィルターされて抽出された結果だけをPUSHして、それ以外をPOP型にすればいいってことか。

どうでもいいですが、私の愛車（ルイガノくん）です。

毎日これで通っています。

以前の仕事（金融系）で、セルサイド（金融商品を売る側、例えば証券会社など）の顧客からバイサイド（金融商品を買う側、例えば資産運用会社）の顧客へ変わったことがありました。セルサイドというのはあの手この手でいろいろな商機を捕らえては儲ける、というスタイルなのですが、バイサイド側は基本的に他人のお金を預かって運用するので、言い方は悪いですが、いかに儲けるかという観点よりは、いかに言い訳するか、という観点のほうが重要視されています。つまり「これだけ儲かった」という言い方ではなく、「他の人に比べてこれだけ成績がよかった」という観点で考えます。この「他の人（=ベンチマーク）」とはマーケット全体の平均のことで、例えば日経平均とかいわれているやつが相当します。（ただし最近はこの「他の人との競争」を放棄してインデックス運用と呼ばれる「他の人並みの成績」を売りとする運用が増えています。）

最初にバイサイド側で仕事をしたときに最初に感じたのが、この「他の人」との比較で論じることへの違和感でした。だって、他の人が-5%だったときに、私は-3%で運用しました。だから2%も良かったんですって、そういう論法なのです。確かに論理的なのですが、これは運用者側の観点であって、お金を預けた側はやっぱり儲かってくれないと困ると思うんですけどね。

例えば会社の場合、こんなことは言ってられないわけです。マーケットが良くないから会社が減益になりましたって、株主に報告して納得する株主はいないわけです。株主は言います。「もっと努力せよ、」と。（一応資産運用会社の名誉のためにいっておきますが、彼らは決められたレギュレーション（投資手法）の中でのみ運用をまかされているのであって、儲けるためには何をやってもいいというわけではないので、会社とは単純には比較できません。どのようなレギュレーションの運用スタイルを選ぶかはお金を預ける側が選択するのです。でも、ということは預ける側もよく研究しないとだめってことですね。）

前置きが長くなったのですが、同じような考え方をソフトウェアの世界ではできないものなのか？　ってふと思いました。業界全体でのベンチマークです。例えばファンクションポイント（FP)はファンクションポイントの計算はできるものの、FPに対する実際の工数は各ベンダーによって異なるはずです。これの業界平均値を求めることができたら、ちょっと面白いかなって思います。

でも資産運用の世界では「ハイリスク・ハイリターン」「ローリスク・ローリターン」が成り立っており、あるときバーンと儲けるような運用をしているところは逆にあるときにはゲロッと損をするものなのです。じゃあソフトウェアの世界におけるリスクは何で見ればよいのか？　FPに対して出来上がりにかかった工数がやたら少ないと思ったら、中はバグだらけだった、とか、ちょっと負荷が高くなったら耐えられない構造だったとか、まあいろいろありそうですが、うーん、こちらは数値化が難しいな。あと中のコードの汚さはなかなか表に出ない「負債」ですね。（Martin Fowlerの話にもありますね。）　FP辺りの工数がやたらいいなと思ったら実は「負債だらけだった」というのもナニかな。一生表にでない負債ならいいけど。