update it, Inc.社長のブログ

またまた「私の履歴書」ネタで恐縮なのですが、今朝(4/19)の日経新聞の私の履歴書（セブン＆アイ・ホールディングス会長の鈴木敏文さん）のなかで、創業以来、周囲からは「なんて非効率なことをしているんだ」とあきれられながらも、OFC（オペレーション・フィールド・カウンセラー=全国各地で一人７?８店舗を担当する）の会議を毎週、全員を東京に集めて行ってきた、という話が書いてあります。

これ、コストのことだけ考えるとえらく非効率のように思えるかもしれませんが、この会議を単なる情報伝達の場ではなく、互いの考え方や価値観を共有する場としてとらえ、フェイス・トゥ・フェイスのダイレクトコミュニケーションを貫いてきたと説明されています。

このface-to-faceのコミュニケーションって大事なんですよね。話している人の身振り手振り、アイコンタクトなどのような技術的な要素だけではなく、同じような境遇にある人達、仲間がすぐ隣にいて、互いにちょっとしたことでも気軽に話しかけることができて、互いにどんなことを悩んでいるのか、どんなことで成功したり失敗したりしたのか、などなど、いろんなことを共有できるってことがface-to-faceコミュニケーションの魅力だと思います。

セブン・イレブンの場合にはこのOFC会議を使って上から下まで同じ価値観を共有することに成功したわけです。

さて、システム開発の現場の話に戻りましょう。昔はタバコ部屋ってものがあって、そこでは仕事の合間にちょっと一服、タバコをふかしたり、コーヒーを飲んだりすることができました。最近は禁煙の高まりからこのタバコ部屋がなくなったところも多いと思うのですが、実はこのタバコ部屋でのface-to-faceコミュニケーションって重要だったな、と思います。（ちなみに私はずいぶん昔に禁煙しています）

昔、タバコ部屋で交わされる何気ない息抜きの会話の中で、なぜかいろんな仕事上のアイデアが湧き上がってくるのを何度も経験しました。

タバコの場合、吸う人、吸わない人の話があるので今タバコ部屋をそのまま復活させるというのも難しい面があると思いますが、何かこれに変わる新しいface-to-faceコミュニケーションの場を考えていく必要があるのではないでしょうか？

今までの話はいかに無駄を減らすか、という観点の話が主体でしたが、今日はリスク管理、つまり、どちらかというと無駄をしてでも失敗する可能性を減らすためにはどうすべきか、ということについて書いてみます。

開発プロセスは、このリスクを減らすために存在します。プロジェクトが失敗する可能性を減らすために、いろいろと手順や儀式を決めて、その通りに進めることによりプロジェクトが破綻するリスクを減らします。ですので優れた開発プロセスはリスクをコントロールすることができるはずです。

ただし本当に意味のある、効果的なリスク管理はもっと別なところにあると思います。タイトルにある「小さなリスク管理」です。プロジェクトにおいて日常発生するさまざまな細かいリスクをきちんと対処していけるかどうかということ、これに尽きます。例えば問題点をバグトラッキングシステムのようなものできちんと管理しているか、みんながそれを常に見ているか、きちんと対応しているか、そういった実行面がきちんと回っているかどうかが、本当のリスク管理ではないでしょうか？

少なくとも週1回の定例ミーティングを開いて「そのときだけ」リスク項目の消しこみを行う、みたいな形式的な運用ではリスクが管理されているとはいえないでしょう。

昨日の曖昧な仕様でプロジェクト・オーナーを1名決めて、その人が勘と度胸ですべての仕様を決めていく、というスタイルのほうが実は費用対効果が優れていることが多いと書いたのですが、これってちょっと誤解を招きやすい表現なので、もう少し説明します。

ここでいうプロジェクト・オーナーとは「ユーザ側の立場の代表」であり、「専門家」である必要があります。単に闇雲に仕様を決めてしまう人ということではなく、ユーザ側が何を欲しているのかが裏の裏までわかっていて、ユーザ側の意見を集約することのできる人、かつ実務にも詳しい人、ということになります。ちなみにユーザ側の立場の代表はユーザの団体・法人に所属していなければならないというわけではなく、本当にユーザ側の立場で思考できる人であれば良いのです。

このような人を設計・開発体制の中に入れ、権限を与えることができれば、おそらくもっとも効率が良くプロジェクトが進み、出来上がったプロダクトも現場のニーズにこたえたものになると思います。

こうやって指名されたプロジェクト・オーナーは権限もある代わりに非常に責任も重大です。この人の考え方次第でシステムがうまく稼動しなかったり、プロジェクトが頓挫するリスクもあります。プロジェクト・オーナーは説明責任を負いますし、かなり大変な仕事には間違いないのですが、特別なタイトルであり、成功報酬型にすることにより、非常に優秀な人にインセンティブを与えながら遂行してもらうことができるようになると思います。

アジャイルの手法の中にはこのようなプロジェクト・オーナーのような人（ユーザ側代表）にプロジェクトに入ってもらうということを薦めているものもあるようですが、まさにそれです。ただしできるだけ強い権限をその人に集中させるべきだと考えています。

日本の会社の中ではなかなかこのような体制に移行できるところはまだ少ないと思いますが、こういう体制でプロジェクトが進められる会社は非常に競争力の強い会社になると思います。

今日は曖昧な仕様書というテーマです。システムで実現すべきことが書いてあるのが仕様書なわけですが、この仕様書が曖昧で何を実現するのかがはっきりしないものって、結構あります。特に厄介なのはシステム開発の最初の期間で、「じゃあ何をやろうか」というスタイルのシステム開発をする場合です。

この「じゃあ何をやろうか」というのはシステムの概要設計フェーズに含まれている場合も多いのですが、これは設計ではなく分析です。本来設計の前に終わらせるべきことなのですが、事を複雑にしているのは、分析の精度をある程度求めると、投資対効果の費用を算出するためにシステム概要の前提を立てる、つまり設計しておく必要がでてくるということです。これはまさにシステムの概要設計にほかなりません。つまりどういうインフラを用い、どういう運用で、どういう技術やパッケージを使い、おおよそのシステム構成はどうで、などといったことがわからないことには費用の算出ができないということです。

分析フェーズの費用算出においてある程度システムの概要に見込みを立ててしまうと、今度はそれがいろいろな意味でシステム概要設計の足かせとなってしまいます。じゃあそれで問題がでないようにしようとすると、結果として「曖昧な仕様書」が出来上がってくることになります。つまり問題を先送りするわけです。

プロジェクトの運用スタイルの中にはわざと決定を先送りするやり方もあるようですが、そうは言っても基本的な事項を先送りされてしまうと、その先の検討が進まない場合が良くあります。例えばちょっと極端ですが、アプリケーション方式でやるか、Web方式でやるか、なんてレベルのことも決まっていないと、システム構成も決められません。それが連鎖して何から何まで曖昧模糊とした状態からぬけだせなくなる、なんてことも起きます。

これって、良心的な、頭のいい人達が集まってやると余計にこの状態に拍車がかかる傾向があります。ちゃんとやろうとしすぎて物事が運ばなくなる状態です。しかもこうなってしまうと分析期間がかかりすぎ、それだけで莫大なコストがかかったりします。プロジェクトを進めるためには、規模にもよるのでしょうが、むしろ1名のプロジェクト・オーナを決めて、その人が勘と度胸ですべての仕様を決めていく（もちろん裏づけは取った上でですが）、というスタイルのほうが実は費用対効果が優れていることが多いのではないかと、経験上私は思います。

少し前に紹介しましたが、日経新聞の今月の「私の履歴書」は鈴木敏文さん（セブン＆アイ・ホールディングス会長）です。今朝の内容ではアメリカでセブン・イレブンを見つけてきて、それを日本で展開しようとするが、その当時の日本では大型店が地元の小型店で成り立つ商店街を駆逐するという構図が出来上がっていて、そんな小型店がうまくいくわけがないと社内外から大反対される、という話が書いてあります。

これに対して鈴木さんは果敢に挑んでいくわけですが、闇雲に挑戦しているのではなく、根本的な部分、本質的な部分でそれまでの常識（小型店より大型店が有利）の「ウソ」を見抜いている点がすごいんですね。その当時の業界関係者や学者は単に売り場面積の大小で判断していたのに対し、鈴木さんは小型店より大型店が有利という「常識」は、それまでの小型店の労働生産性が低く、かつ顧客都合を無視していたという前提で成り立っている話しだということ、そしてマーケットに変化が現れ、それまでの安い商品を並べれば売れるという時代ではなくなってきたということ、この２つの「事実」を捉えていたので、果敢に挑戦することができた、というわけです。（詳しくは今朝（4月13日）の日経新聞朝刊を見てください）

物事のブレークスルーって、この常識を疑う「非常識力」から生まれると思います。でもこれっていきなり沸いて出てくるようなものではなく、普段の考え方、考える姿勢の問題なのでしょうね。　例えば上記のようなコンビニエンスストアーを日本で展開するという話も、その当時の常識にどっぷり漬かっていた業界関係者ではなかなか出てこなかった発想だと思うのです。流れに流されるのではなく、常に「？」と考える姿勢を貫いていることが重要なのだと思います。

昨日のブログ「重複を削ろう」で無駄を削ってアジャイルにいこうという話を書きましたが、重要なのはやはりそれまでの常識を疑うという気持ちなのだと思います。今、当たり前のようにやっていることは本当に必要なものなのか、逆に本当は必要なのにも関わらずやっていないことはないのか、常に自分に問いかけていきたいと思います。

昨日の?設計書に書くべき範囲と絡むテーマなのですが、設計書って同じようなことの重複が多いですよね。例えばDOAにしろオブジェクト指向分析・設計にしろ、最初に概念モデルを作って、それから物理モデルを作って…ってように、同じ対象に対して２度モデリングをしています。これって目的が違うし、出来上がりのものも違うものなので、厳密には重複ではないのかもしれませんが、なにか似たようなものを作っていますよね。

で、そもそも先に作った概念モデルってなんなの？　っていうのが今回の主題です。もしそれがシステムをデザインするためのものだったら意味がないんじゃないの？って思うんです。それが業務のモデリングだったら話はわかる。このシステムを導入したときに、あるべき業務をモデリングしたものが概念モデルだっていうんだったら書くべき内容がぜんぜん違うから存在意義があると思うんだけど、どうも本来はそういうものではないらしい。

で、似たような、さらにもっと詳しい物理モデルを後で作るんだけど、そうすると同じテーマで２つのバージョンのドキュメントが存在することになる。苦し紛れに概念モデルは最初の設計時に作って後はメンテナンスされないなんて説明がされたりするんだけど、それって重要な設計書類でないからメンテナンスできないだけじゃん、って思っちゃうんです。

別に設計者の頭の整理をするために勝手に概念モデルを作る作業をやめろとはいいません。が、重要でもないドキュメントは成果物ではない、単なる個人的なノートでしょ、ってのが言いたい。それなのにことさらそういったことの重要性を強調するプロセスを定義しちゃうもんだから、成果物として扱われ、無駄な作業が増えちゃうわけです。

最近あんまり聞かなくなった単語だけど、生粋のアジャイラー、安中です。

システム開発には「なんたら設計書」というのが多く伴います。通常のウォーターフォールによる開発では業務要件定義書に始まり、システム要件定義書、システム概要設計書、システム基本設計書、外部仕様書、テスト仕様書etc…が作られますね。

大量のドキュメントを作成しながら、実際には現場ではあまり有効活用されていないケースも見受けられます。なぜでしょうか？　そういう立場のプロジェクト・メンバーになったつもりで考えてみましょう。

１．量多すぎ。頭に入りきらない。
２．実際に作るとなると参考にならないことが多い。

一番の理由はおそらくこんなところではないでしょうか？　こんな理由から上流工程のドキュメントは下流工程のプログラマーが読んでいないことが多いと思いますし、それが当たり前のように思われているところもあるかもしれません。実際のところ「自分のやる範囲の仕様書だけ見てればいいや」っていうプログラマーも多いかもしれません。

でもこれってもったいないですよね。ちゃんとみんなが「使う」「使える」ドキュメントを作るべきだと思いませんか？

じゃあなぜ、量が多くなりすぎるのか。　そして実際に作るとなると参考にならないことが多いのか。　それは設計書に余計なことを書きすぎているからではないでしょうか？　設計書に一般論や誰でもわかることなど書く必要はなく、そのシステムが「他と違うこと」「特別なこと」を書くべきなのではないでしょうか？　何がエッセンス（本質）かということをきちんと捉えて、そこにフォーカスしたドキュメントであれば、それは量は少ないけど中身がとっても濃いもの、読みやすくてためになるものになると思います。

設計書を納品物として納める場合、設計書に「厚み」が要求されることも多いと思いますが、本来逆で、「お、こんなに薄くまとめられたの？　すごいね！」と、紙としての薄さと内容の濃さで勝負できるように変えていくべきだと私は思います。

プロジェクトを確実に破綻させる方法の第4弾は、「聞いていない」です。これ、プロジェクトの中ではよく起こりませんか？

聞き手が聞き漏らしていた場合もありますし、本当に聞かされていなかった、ということもあるでしょう。でもどちらにしろ、プロジェクトの中で、「聞いていない」ことが自分の知らないところでいつの間にか決まっていた、ということがたびたび起こった場合、相互に不信感が募ることになります。

「聞いていない」ことによる問題は、それによって何か大きな抜けが発生するといった直接的な面もありますが、それ以上に心理的にネガティブになってしまう問題のほうが大きいでしょう。自分が蚊帳の外に置かれたと一旦感じてしまうと、その人の積極性が失われてしまい、Aクラスのスタープレーヤーだった人がとたんにCクラスの他の人の足を引っ張る人になってしまったりします。

プロジェクトマネージャーやサブリーダーの人は、自分が担当するメンバーに対し、直接関係がないと思った情報でもなんらかの形で伝達するように努めるべきだと思います。プロジェクトマネージャやサブリーダーが知っていることと、プロジェクトメンバーの知っていることには何が特別な理由がない限り、差をつけるべきではありません。何が伝えられないことがある場合には、どういったことは伝達できて、逆にどういったことは伝達できないのかを予め明確に示しておくことも重要です。そうやってみんなに全部さらけ出しているんだよ、とプロジェクトメンバーにアピールすることで、各メンバー一人ひとりのプロジェクトへの帰属意識を高めることができるのではないでしょうか？

4月2日のブログプロジェクトを確実に破綻させる方法　その３として「曖昧プロセス」について書きましたが、では逆にうまく回すにはどうすべきなのか？　について述べます。

私はそのためにはプロセスの定義をできるだけシンプルにすべきと考えています。理由は簡単。人間そんなに複雑なものには対処できません。完璧な定義よりも、プロジェクトにかかわるチームメンバー全員が、きちっとを守り続けられることのほうが重要なのです。特定の人しか理解していないような複雑なプロセスは、結局オペレーションできません。一貫性をもって、同じ呪文を繰り返すことが品質を向上させるには重要なのです。定義の完璧さが重要なのではなく、きちっとオペレーションすることが大切だから、できるだけシンプルであるべきだと考えているのです。

ここででてくるのが、ブログ私の履歴書で書いたセブン・イレブン流の話です。私がセブン・イレブンの話を聞いたときに一番感銘を受けたのが、パートやアルバイトまで巻き込んで全社的に一貫して「仮説・検証」していてるという点でした。

シンプルだけと、一貫性のある、強力な呪文をみんなで唱えると強くなれるって、まるで何かのゲームみたいですが、if文の嵐のような大量のプロセス定義よりもよっぽど実効性があるのではないでしょうか？

プロジェクトを確実に破綻させる方法としてご紹介する３つ目は、「曖昧プロセス」です。システム開発の開発プロセスが定義されているというのはすばらしいことなのですが、きちんと運用されていない場合にはかえって弊害になるという話です。

最近ではユーザ企業側でも自社の開発プロセスがきちんと定義されているところが多いです。これ自体は悪いことではありません。そしてシステムを開発する人・チームが常に同じであれば、長年の付き合いの中でそれらのプロセスは自然に理解され、伝承されていくでしょう。しかし、人は入れ替わるものです。またパートナー会社が変わるということもあります。

問題はそうしたときにドキュメントに書かれた開発プロセスに具体性が無く、実際の運用においてどうすべきかが曖昧な場合に発生します。ドキュメントにはいいことが一杯書いてあるんです。でもじゃあ、このときには何をどうしなければならないのか、っていう具体的な進め方が曖昧だと、プロセスについての議論が沸騰して、実際のプロジェクトが進まなくなる、なんていう馬鹿馬鹿しい経験をした人って多くありませんか？

ある意味、プロジェクト推進者が「ものがわかる人」ならば柔軟な対応で問題にはならないのですが、逆に厳密さを追求するタイプの人だと最悪です。

そもそもユーザ会社の開発プロセスって、せいぜい１つか２つのタイプしか定義されていないことが多く、その中でさまざまなタイプの開発を網羅しようとしているので、プロジェクトの種類によっては意味を成さないような項目が並んでいることが多いと思うのです。でもそのような場合にどれは行ってどれは行わないっていうことが曖昧だと、開発者側がそれに右往左往される。先に述べた「伝承された」人達にはここのあたりのことは自明だと思い込んでいるのですが、それがさらに曖昧さの入り込む原因になっているのです。

盛り込みすぎたプロセスも曖昧になりやすいです。プロセス定義書だけで厚さ？センチなんてものは、おそらく運用不可能です。で、結局これはやる、これはやらないなんてことが現場で判断せざるを得ない。ところがこの判断のやり方に明確な基準が示されていないと、人によってやったり、やらなかったり、となるわけです。この状態で先に述べた、厳密さを追求するタイプのプロジェクト推進者がいたりすると、開発プロセスを守るためだけの作業に時間を食われ、プロジェクトは確実に破綻します。

本来開発プロセスはプロジェクトをうまくまわすためのツールであって、それ以上のものではないはずです。目的と手段を取り違えないよう気をつけていれば、この手の問題は起こらないはずなのですが、みなさんのところはどうでしょうか？