コタツモデル・アンチパターンズ(1)

■はじめに
2008年3月の要求開発アライアンス定例会で「コタツモデル再考」という発表をしたのですが、予想外に好評だったので調子に乗って、発表内容をベースに「コタツモデル・アンチパターンズ」という標題で詳しい内容を書いてみようと思います。週1回ペースくらいで書いていこうと思いますので、興味のある方はRSSリーダ等に当ブログを登録お願いします。

■コタツモデル
システム開発プロジェクトは沢山の人によって進められます。特にシステムそのものの目的や方向性そして仕様を決めるプロセスは重要で、ここで失敗するとシステム開発プロジェクト自体が失敗するといっても過言ではありません(実際に、システム開発プロジェクトの7割は失敗しているという調査もあります)。

失敗する要因には様々なものがありますが、特に次の3種類のプロジェクト参加者が、システムの目的や方向性について合意形成していることがプロジェクトを失敗させない為には重要です。

• ビジネスオーナー (ビジネスの方向性や方針を決めるが、システム開発や現場業務には詳しくない)
• 現場担当者 (実際に業務を担当している現場担当者)
• システム担当者 (システム部門の担当者または開発ベンダ)

この３者が「コタツに一緒に入るように」ひとつのテーブルで議論を行い合意形成することを、コタツモデルと呼んでいます。

ソフトウェアはコミュニケーションで出来ている

とはチェンジビジョンの平鍋さんの言葉ですが、特にシステムの目的や方向性の決定、要件定義について、コタツモデルを形成することが、システム開発の成功確率を高める一つのポイントではないでしょうか。

■コタツモデルとアンチパターン

ソフトウェア開発において「こうあるべきだ」という典型例を集めたものデザインパターンであるのに対し、「こうあってはならない」という典型例を集めたテンプレート集がアンチパターン。
はてなダイアリー：アンチパターンとは

デザインパターンと言うと、設計やプログラムコードのお手本として捉えられることが多いのですが、これに対してアンチパターンは組織やプロジェクトマネジメントまで非常に幅広く取扱うことができます。書籍「アンチパターン -ソフトウェア既得患者の救出-」や、Wikipedia(英)のAnti-Patternには様々なレベルのアンチパターンが言及されています。

さて、コタツモデルは人間関係のメタファーであるため、次のような難しさがあります。

• 容易に修正したり、制御することは出来ない
• コタツモデルではない事はすぐにわかるが、簡単には是正できない
• 対症療法をとるしかない。

コタツモデルのようなアンコントローラブルな問題に対しては、HOWTOを語る事は困難です。しかし、アンチパターンのように「こうあってはならない」典型を示し、改善のためのアイデアを提示することは可能だと考えています。

■コタツモデルの良いところ
要求開発では、そもそも「要求はあるものではなく，開発するものである」という前提をおいています。過去のシステム開発プロジェクトの焦点は電子化や自動化が多く、既存の業務の仕組みを調査分析をすることでシステムの目的や仕様を決定することができました。しかし現在においては、システム化の対象範囲は広がり、人間系とシステム系が複雑に入り組み混在化したビジネス系そのものを扱う事もしばしあります。こういったシステムの要求は調査分析をしても見つけることはできず、プロジェクトメンバーによって検討(開発)しなければならない、ということです。

限られた期間、限られたメンバーで要求を検討(開発)する際に重要となるのはバランスです。

• 視野のバランス ・・・ 複数の視点から見て、合理的かつ効果的な検討を行うため
• 権威のバランス ・・・ 特定の発案者の意見に従うのではなく、参加者がフラットに意見交換を行う為

えてしてシステム開発においては、「発注者 vs 受注者」「要求を出す人 vs 作る人」といった形の上下関係になりがちで、これが原因で前向きな議論や関係が築きにくい。また、仕様を決めるユーザも人間ですから間違えることもあるわけで、そこから端を発した仕様変更の泥沼なども、権威のバランスを欠いた結果なのではないでしょうか。

コタツモデルでは、ここで(実現可能かは別にして)ビジネスオーナー、現場担当者、システム担当者が対等な立場で議論を行い合意する関係性を提示しています。これは、単なる絵的なもの以上の価値があるのではないか、と考える今日この頃です。

長くなってしまいましたが、次回からはさっそくアンチパターンについて紹介していきたいと思います。興味のある方は引続きおつきあいくださいませ。

メモを取らないとハイパフォーマーになれないよ

いつか書こうと思っていたんですが、ひがさんのBlogで言及されていたので反応的にエントリ。

なぜメモを取るのか。
* 記憶は頼りにならない
* メモを取ることで、脳を「考えること」に使える
* 記憶は共有できないが、メモは共有できる。メモを書くことは、他人と情報を共有することになる。
などです。メモを取ることは、一手間かかるようで、実は非常に効率的なのです。
2008-03-14 - reponの日記

メモを取ることで、満足しちゃうんだよね。頭を使わなくなる。だから、相手の話を聞くときには、その話に集中し、メモなんか取らないほうが良い。
メモを取ったほうが良いのか - ひがやすを blog

ちなみに私はちょっとしたメモさえあれば、台本のような詳細議事録を書ける特技を持っています。なんでできるかというとよくわかりませんが、学生時代に芝居の勉強をしているときに身についたような気がします。芝居だと自分と相手のセリフだけではなく動きも含めて記憶しないと演技が成立しないことがあるので、そのときに短期記憶が発達したのかもしれないと思う今日この頃です。

さて、個人的にはメモは取るべきだと思っています。以下理由。

• 目上の人と話をするときには、マナーとして
• 相手の貴重な時間を浪費しているのですから、「きちんと話を聞いて記録する」という立場で望むべきだと思います。ちなみにこれは私が社会人のキャリアを始めたときに先輩から教えてもらったことだったりします。
• 重要な事は忘れない、と自分を過信せず、トラブル防止の観点で
• プライベートであれば話は別ですが、特に仕事であれば、トラブルを防止しようとするのはあたりまえのことです。絶対に忘れない、と断言できない場合はメモを取るべきだと思います。

オーバーアチーブという、組織のハイパフォーマーを生かす／活用することについて書かれた本があるのですが、その中で「ハイ・パフォーマーのひよこを見極める」という章では、組織で働く基本として以下の3点が出来ていることが重要と書かれています。

• 呼ばれたら飛んでいく
• 大きな声で返事する
• きちんとメモをとる

前時代的なことかもしれませんが、少なくとも私はこれらが出来ない人とは、あまり仕事はしたくないなぁと思います。

Blogged with the Flock Browser

要求開発アライアンス3月定例会発表資料

私が運営にも参加している要求開発アライアンスの2008年3月定例会で、ちょっとした発表をしてきました。
詳しい話は別途近いうちに書きますが、とりあえず資料を公開します。

| View | Upload your own

(SlideShareがなかなか表示されなかったり、エラーとなる場合は、こちらからPDF版を取得してください)

以下簡単なふりかえりです。

• よかったこと
• たくさんの人に「気づき」を持ち帰ってもらえたようで嬉しかったです。
• 発表したことによって、皆さんから新たなアイデアをたくさんいただけました。知の連鎖を引き起こすことができたような気がしています。
  
• 反省点
• リハーサル不足だったので、スムーズに喋ることができませんでした。リハーサルは重要ですね。そもそも、人前でスライド発表すること自体かなり久しぶりだったので、焦ってしまいました。
• 時間配分に失敗して、自分の予測より15分くらい超過してしまいました。もうすこしスライドに対して説明する内容をシンプルにすべきだった。
• マイクを使わずに発表したのですが、後ろの人まで聞こえるかのチェックを忘れていました。聞き取りにくかった人がいたらごめんなさい。
  
• 今後に向けて
• 皆さんにいただいたアイデアを再整理して、ブラッシュアップします。
• 次に発表する時には、絶対に練習してから望む。

発表をご覧になった皆さん、どうもありがとうございました。

Blogged with Flock

デスマーチの誤用や誤認について

某所でデスマーチについて議論しました。その時点ではいくつか私の誤認もあったので、改めてデスマーチについて考えてみます。
個人的な意見としては、みんな「デスマーチ(ﾟ∀ﾟ)」と言いすぎると思っています。
なお、このエントリのBGMはマイ・ケミカル・ロマンスの「ザ・ブラック・パレード」で・・・

■個人的なデスマーチの定義（注：これはマチガイです）
デスマーチとは、ソフトウェア開発における悲惨なプロジェクトのメタファーです。メンバーに極度な負担を強い、かつ成功する確率が低い状況を、「死の行進（デスマーチ）」と呼びます。

後で調べて間違いだと気づいたのですが、個人的にはデスマーチの定義を次のように考えていました。

• これはデスマーチである
• 仕様が発散し、プロジェクトが収束する可能性が無い。仕様変更が多発し、つくれどもつくれども楽にならり。
• 品質が発散し、やはりプロジェクトが収束する可能性が無い。バグがバグを呼び、治せども治せども楽にならざり。
• これはデスマーチではない
• 単に、見積り・計画・メンバー・設計などに大きな間違いがあるため、期間内・コスト内に目標としたシステムを完成する可能性が低い為、ハードな労働を強いられている状態。
• プロジェクトの後期に大幅なメンバーの追加などを行った結果、コミュニケーションパス数が爆発し、混乱が発生し、結果として非常にハードな労働を強いられる状態。

要は、完全に何かのパラメータが発散する(際限なく増えていく)状況はデスマといえますが、単なる突貫プロジェクトや失敗を含むプロジェクトをデスマーチと呼ぶのは、不適切な不幸自慢なのではないかと思っていたわけです。

■真デスマーチの定義
改めて調べると、デスマーチの定義はこんな感じです(Wikipediaより)

• 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
• 与えられた期間が、常識的な期間の半分以下である
• エンジニアが通常必要な人数の半分以下である
• 予算やその他のリソースが必要分に対して半分である
• 機能や性能などの要求が倍以上である

これを見ると私の定義も別に誤っているわけではないと思うのですが、再考してみました。

• これはデスマーチである
  
• 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
• かつ、上記の状況に対して適切な対策を実施する前の状態
• これはデスマーチではない
• プロジェクトを成功させるために、不適切な労働を強いる状況 ( それは組織としてはダメですが、デスマというわけではない )
• よくわからないが、うまくいっていないプロジェクト

■要は何をいいたいかというと
みんな「デスマ」「デスマ」と言いすぎだと思っています。
「お前らに本当のデスマーチを思い知らせてやる！」
これはうそです。私もこんなデスマーチには参加したことはありません。キツイプロジェクトはありますけどね。

Blogged with Flock

システム開発上流工程における権威勾配

■権威勾配について

権威勾配とは、正確には「操縦室内権威勾配(Trans-cockpit Authority Gradient)」のことで、航空業界におけるクルーリソースマネジメント(CRM)に出てくる概念です。

CRMとは航空機パイロット(クルー)向けの学習プログラムで、『利用可能なすべてのリソースを、最適な方法で最も有効に活用することにより、クルーの トータルパフォーマンスを高め、より安全で効率的な運航を実現することを目的とする考えかた』という定義です。ITプロジェクトにおいても、チームのトー タルパフォーマンスを高める事は大きな課題なので、いろいろと参考になりそうなアイデアが詰まっているようです。詳細は下記の本などを参照ください。



で、権威勾配は何かと言うと、(飛行機が)安全な運行を確保するための操縦室内での権威の力関係のことになります。

• キャプテン（機長）、コーパイ（副操縦士）及びフライトエンジニア（航空機関士）間の勾配は大きくても小さくてもいけない。
• 適当な勾配を保てば、クルー間の自由なコミュニケーションが保たれ、航空機の運航もモニターも改善される。
• 勾配が急すぎると、コミュニケーションは減り、相互チェックが減じる。
• 勾配が浅すぎると、キャプテン（機長）が権利を行使できなくなる。

■システム開発上流工程における権威勾配

システム開発の上流工程(要求開発とか、要件定義など)においても、この権威勾配が重要なファクターではないだろうかと、最近考えています。主要な登場人物としての「ビジネスオーナー」「ユーザー(業務担当者)」「エンジニア（開発担当者）」の権威勾配が適切でない状態でシステムを開発すると、「使えないシステム」や「ビジネスに効かないシステム」が出来上がってしまうのではないか。

私も参加している要求開発のコミュニティでは、コタツモデルというメタファーを使って「ビジネスオーナー」「ユーザー(業務担当者)」「エンジニア（開発担当者）」の適切な関係を定義していますが、これをいかにして形成していくのか、について権威勾配の概念がピタっとはまるのではないか？



過去のシステム開発プロジェクトは、既存業務の自動化や情報化であり、比較的にシステム開発の着地点も見えやすかったのですが、これからのシステム開発は、より人間系を含め(技術的ではなく業務的に)複雑化していくと思います。

その中で成功確率を高めるためには、適切な権威勾配をステークホルダー間で構築し、コミュニケーションと相互チェックを実現していくべき、というのが私の意見です。

※蛇足
ちなみに、次回の要求開発アライアンス定例勉強会で「コタツモデル再考」というタイトルでお話させていただくことになりました。発表資料は本Blog等にもあとで掲載しますので、興味のある方はよろしくどうぞ。

Jolg Awardsで気になる本「Manage It!」

Jolt Awardsから。洋書だけど、ちょっと気になっています。

Manage It!: Your Guide to Modern, Pragmatic Project Management

posted with amazlet on 08.03.07

Johanna Rothman
Pragmatic Bookshelf (2007/06/15)
売り上げランキング: 1092

Amazon.co.jp で詳細を見る

というわけで、ちょっと調べてみました。

• The Pragmatic Bookshelfで少しだけ立ち読みできる。またPDF版を安く購入できる。
• モトDECで、現在YahooでDirectorをしている人が書いている。
• リスクベースで、ソフトウェア開発において意思決定をするためのガイドブック(と序文にある)。
• 実践的であることに注力しているっぽい。サンプルが読めるChap.4だと、ローテクツールでのスケジュール管理と題して、付箋を使ったスケジュール管理について書かれていたりする。

翻訳がすぐに出るのであれば待ってもよいのですが、今のところそんな情報も無いのでいっそ原書で読んでもいいかなぁと思う今日この頃です。今風に読書会などを開いてもよいのかも(でも、主体的になれる余裕は現在ナッシング)。

Blogged with Flock

Googleドキュメントのプレゼンテーションで文字欠け

このあいだ、梅田望夫さんの「ウェブ時代をゆく」を読んだのですが、その中に出てくる「第5章 手ぶらの知的生産」が気に入っています。梅田望夫さんの言う「手ぶらの知的生産」とは、

• 物理的に「手ぶら」でも、情報にたどりつくことができるようになったということ
• 知的生活を送るために、膨大な蔵書などの物理資産を持たなくてもよくなった

というお話です。興味のある人は「ウェブ時代をゆく」をお読み下さい。

さて、この本に感化されたわけではありませんが、最近個人的なノートや資料などは、自宅のローカルPCなどに保存するのではなく、Googleドキュメントで書き溜めるようにしています。これは「手ぶらの知的生産」ではありませんが、PCを持ち歩かずとも、随時自分の外部脳を取り出せるようにしておきたいためです。Googleドキュメントでは現在、ドキュメント・スプレッドシート・プレゼンテーションの3種類がサポートされているので個人的な書き物には不自由することはありません。

と、そのはずなんですが、どうやらプレゼンテーションには文字化けの問題が残っているみたいです。
回避策をいろいろと考えたのですが、どうやら無さそうな模様。
その問題とは、

• 特定の文字コード(具体的には、Unicodeの特定の文字(20592～20950)が、PDFには出力されない。
• おそらく、Google側のサーバにフォントが無い orz...

下記のスライドショーでは問題なく表示されると思いますが、PDFにエクスポートすると、Sample4の漢字はほとんど消えちゃいます。



現在プレゼンテーションは、PDFかテキストファイルにしかエクスポートできないので困っちゃいますね。特に発表資料などを作成して、オフラインな会場に持ち出せないのが苦しいところ。
HTMLに書き出す等の裏技も探しましたが、今のところはなさそうです。

というわけで、とりあえずはGoogleのサポートにバグ報告しておきましたとさ。

Blogged with Flock

ITシステムの導入で失われる知力について

前回のエントリでマインドマップまで書いて挫折してしまっていますが、ITシステムの導入で失われる知力に関する文章です。
ITシステムの導入は、その価値や生み出すものばかりに目がいってしまいがちですが、逆に失われるものもある、ということをよく考える必要があります。

■Google前後の世界
梅田望夫さんの有名な著書「Web進化論」を引くまでもないですが、Googleの出現によってわたしたちの知識に関する考え方は一変してしまいました。現在のわたしたちは、わからない事があれば考える前に検索するのです。結果として知識習得のためのコストが大きく下がった事はとても良いですが、逆に書籍などを読み、自分で考えるという力は低下しているような気がしています(これは個人的な主観です)。

■ITシステムとナレッジのトレードオフ
ITシステムを導入すれば、基本的には利用者はそのシステムによって処理能力を引き上げられ、今まで人間ではできなかったほど高度な分析や処理ができるようになります。システムにチェックロジックなどを組み込むことにより作業は平準化され、ミスが防止されるようになります。しかし、こういったメリットを享受した場合、同時に失っているものもあるのではないでしょうか？

• 遂行能力の引き上げ vs 能力そのものの低下
  今までは、行うべきこと(たとえば、見積り書の作成)のために、たくさんの物事(考え方やルール)を知る必要がありました。しかし、システム化してしまうことにより、そういった知識が無くてもそれなりの処理ができるようになります。結果として、利用者の能力そのものは下がってしまう事があります。

• 処理の平準化 vs 工夫力の低下
  システムを導入すれば、たくさんの仕事をシステムを活用して(何も考えずに！)処理できるようになったりします。また、処理は定型化/汎用化されているので、システムが示すとおりに入力すればすむようになったりします。今までは「能力の高い人は精度高く、能力の低い人は精度低く」だったのが平準化されます。しかし、これは、能力の高い人についても平均的な作業レベルまでしかさせない、という事にもなります。結果として、個々人が工夫をしたりする力が減ることがあります。

• 処理の高度化 vs ブラックボックス化
  今までは想像もできないような非常に複雑な処理も、システム化することによってできるようになります。しかし、逆に業務の一部がブラックボックス化してしまい、誰にも理解できないという事になりがちです。ちなみに構築当初は精通していた人がいても、その後担当者が異動してしまいシステムが変更できないというのも、よくはる話です。

• 処理スピードアップ vs コミュニケーションの減少
  システム導入により、今までは人間系でおこなっていた作業がスムーズに、スピードアップしてできるようになります。しかし、当然のことながら、コミュニケーション量も減っていきます。いままではコミュニケーションによって防止されていた作業の落とし穴が露呈したり、全体的な利用者のモチベーションが下がるということも発生する可能性があります。
  

■失うものは何かを意識し、議論する
得てしてITシステムの導入は、その正の価値ばかりばピックアップされます。なんといっても人は新しいものに期待をしてしまいがちです。しかしITシステムは企業やビジネスのインフラでもあります。上記のような観点で、負の影響についても(前向きに)意識し、議論をすることによって、防止したり縮小することができるのではないでしょうか？

Blogged with Flock