日経ITProに記事書きました(2)

前回に引き続き、こんな記事を書いてみました。
要求開発とコタツモデル(2)－－アンチパターンを活用する：ITpro

モトネタは要求開発アライアンスの3月定例勉強会で発表したネタだったんですが、なかなかちゃんとした記事風にするのは難しいものですね。良い思考トレーニングになりました。

日経ITProに記事書きました

こんな記事を書いてみました。

要求開発とコタツモデル(1)－－失敗パターンに陥らないために：ITpro

要求開発アライアンスではいろいろな議論や発表がされています。これを、もうすこしわかりやすく、ていねいに紹介したら良いのではないか？ と常々思っていたのです。というわけで、今年はこんな内容で何回か記事を寄稿してみようと思っています。

ちなみに、書くにあたっては『「超」文章法』をかなり参考にしました。個人的にはちょっとブームです。

「超」文章法 (中公新書)

posted with amazlet at 08.05.30

野口 悠紀雄
中央公論新社
売り上げランキング: 2064

Amazon.co.jp で詳細を見る

Blogged with the Flock Browser

IT複合汚染

ひょんなことから、有吉佐和子さんの有名な小説(?)『複合汚染 (新潮文庫) 』を読んでいます。本作は、ちょうど私が生まれた年の朝日新聞に連載された環境汚染問題をテーマとした文芸作品です。興味があるかたはWikipediaなどもあわせてご参照ください。

複合汚染 (新潮文庫)

posted with amazlet at 08.05.28

有吉 佐和子
新潮社
売り上げランキング: 35671

Amazon.co.jp で詳細を見る

本作を読んで、ふと気づいたのが昭和40年代の複合汚染の状況と、現状のITを取り巻く環境の類似性です。

例えば農業の近代化というと、耕作機械の導入、化学肥料の導入、農薬の使用なのだそうです。そして近代化した結果、農家は高価な耕作機械の購入にあえぎ、化学肥料と農薬によって荒れた土地で耕作を続ける為にさらなる化学肥料と農薬を投入し、最終的には複合的な農薬汚染によって病気となったり自殺してしまったりする(30年前の話ですが)。

特に本作で取り上げられている「複合汚染」では、農薬や化学肥料などが複合的に組み合わさった場合の副作用を検証せずに、それぞれ単品では「害が無い」と判断してドンドン投入した結果、結果として公害病や生産者の健康被害に至っている。

最近、ITを取り巻く環境についても様々な問題が取りざたされています。

• メンタルヘルスの問題
• 多重請負構造の問題や受託開発の問題
• 開発リスクや、システム開発の成功確率の問題

さまざまな現場で、プロジェクトや現場を良くするために様々な工夫がされています。また、開発ツールを始めとして日々新しいテクノロジが発表され続けています。しかし、それでも「よいシステム」「役に立つシステム」が次々と開発されているわけではないと思うのです。

利用者の役に立つシステムを適切な価格で提供する。これを目標にスタートしているはずなのに、みんなうまくいっていない。歯車が噛み合っていない。

というところで、『IT複合汚染』という単語を思いついたんですが・・・

Blogged with the Flock Browser

読書強制システム

またまたBlogの更新が滞ってます。連載宣言(?)をしたコタツモデルの話の続きも書けていないのですが、続ける気はもちろんありますので、もし万が一にも興味を持っている方は気長にお待ちください。

で、今回は私の読書強制システムについてのご紹介です。読書強制システムとは、スパルタンに大量の本を読まざるをえないようにするシステムの事です。この記事を読んでて思いつきました。

本は「欲しい」という前に買え。そう思います。

よく本が読めないとかいう人がいますが、そういう人に共通してるのはまず読めないという前に、読む本をもってないでしょ、ってこと。
そりゃ、持ってなければ読めません。読むためにはまず読むべきものを所有することです。そこからです。しかも、１つじゃなくて常に複数読みたいものを所有しておくこと。それもできるだけいろんな種類のものであった方がいい。
本は「欲しい」という前に買え：DESIGN IT! w/LOVE

私も同じように考えていますが、より自分に読書プレッシャーがかかるような仕組みにしています。
具体的には・・・

• 読むべき本は、とりあえずAmazonの「ほしい物リスト」に入れる。このリストをゼロにするのがゴール。
• 週次にただちに限度いっぱいまで、市立図書館で予約する(私の住んでいる自治体では6冊)
• 予約した本はランダムに貸出可能になる。貸出後2週間以内に読まなければいけない。
• 図書館で予約した本以外に、常に手元に数冊あるようにする。
• 図書館で借りた本が切れた時に読む。
• ただし、せっかく買ったのに読まないと旬が過ぎてしまうので1ヶ月以内には読み終わりたい。
• オプションとして、上司や会社の偉い人の本棚から本を借りる
• これはかなり早めに読み終わらないといけない。
• 会うたびに「どう、読んだ？」と言われてプレッシャーをかけてもらえる。
• もう一つのオプションとして、本の著者に会う機会を作ってしまう。(勉強会などで講演を頼んだり)
• 事前に読了することは必須。
  

これくらいやれば、きっと誰でもたくさんの本を読めるようになると思います。
ちなみに現在の未読数は227冊です・・・

Blogged with the Flock Browser

svn switch --relocateではUUIDが異なるリポジトリのSwitchはできない

今日ちょっとハマったのでメモ。Subversionという構成管理ツールのお話です。

Subversionのリポジトリを格納するサーバですが、当然のことながら永遠に同じマシンの上で運用するわけにはいかないので、移行をする必要があります。で、移行した際にはローカルのWorkSpaceを、古いリポジトリから新しいリポジトリに切り替えてあげる必要があります。

この操作は、Subversionのswitchコマンドで行うのですが、、、
実は、UUIDが異なるリポジトリへの切り替えは、現在のバージョン(1.4.x)ではできません。
UUIDのチェックロジックが埋め込まれており、回避は不可能です。
(ここまで調べるのにけっこう疲れた)

次期バージョンでは--ForceオプションによるUUIDチェックの回避ロジックが検討されているようですが、リポジトリを移行する際には留意する必要があるようです。

うへぇ。

Blogged with the Flock Browser

FlockにGoogleGearをインストールする方法

最近のお気に入りのブラウザはFlockです。ベースはFirefoxで、これにいろいろなSNS的ツールを追加したものですが、便利に使っています。日本語版はありませんが、基本的にはFirefoxなので特に利用に支障はありません。

ちなみにFlockの詳細はWikipediaが詳しいのであわせてどうぞ。

さて、FlockはFirefoxベースなので基本的にはFirefox向けの拡張機能はすべてインストールすることができます。ですが、なぜかWindows版ではGoogle Gearだけは簡単にインストールできないので注意が必要です。
Windows向けのGoogle Gearですが、利便性を重視して専用のインストーラが配布されます。このインストーラがFlockを検知してくれないために、Flockへのインストールはうまくいかないようです。(ちなみにMac OS Xではこの問題はないようです)

ではどうやってインストールするかというと、次のような方法で手動インストールができます。

1. まずはGoogle Gearをインストールする。(インストーラを実行する)
2. C:\Program Files\Google\Google Gears\Firefox にあるinstall.rdfをテキストエディタ等で開き、次の記述を追加する。場所は既に記載されている<em:targetApplication>～</em:targetApplication> の次の行が良いです。
       <!-- Flock -->
       <em:targetApplication>
           <Description>
               <em:id>{a463f10c-3994-11da-9945-000d60ca027b}</em:id>
               <em:maxVersion>6.02</em:maxVersion>
               <em:minVersion>0.2</em:minVersion>
           </Description>
       </em:targetApplication>
   
3. 最後に、このフォルダにあるすべてのファイルを1つのアーカイブにZIPする。
4. ZIPファイルの拡張子を、xpiに変更する
5. Flockを立ち上げて、ToolsメニューからAdd-onsを選択し、拡張マネージャを立ち上げる
6. xpiファイルを拡張マネージャにドラッグ

これでFlockでもGoogleドキュメント等をオフラインで使えるようになります。

Blogged with the Flock Browser

Doingリスト

ライフハック交差点：第10回　未来を引き寄せる ToDoリストの作り方 ｜gihyo.jp
で紹介されている、ToDoリストならず、Doingリスト。これ、オススメです。ひとことでいえば、「今なにをやっているかをメモなどに書くということ」です。Doingリストを作成すれば、割込みの作業や電話などがあっても、何をやっていたか、次に何をやるべきかについて見失う事はなくなります。

個人的なコツはこんな感じ。最近はRHODIA#13(文庫本サイズのRHODIA)を使っています。

• 仕事の種類や公私などでリストを分けずに、単に上から順に書いていく。
• 仕事中は常に手元に開いておいて、すぐに閲覧と更新ができるようにしていく。
  
• アクションリストで書く。「～の件」ではなく「～の件をメールする」という感じ。
• 終わったら気持ちよく斜線を引いて消す。
  

全てのアクションリストに斜線が入って一日が終わると気持ちがいいですし、残ったものはスケジュールに入れたり、翌日の早い段階でクリアするようにしています。

参考：
ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp

Blogged with the Flock Browser

svnsyncの使い方

svnsyncというのは、プログラムのソースコードなどを管理するバージョン管理システムSubversionのコマンドの一つです。ちょっと最近ハマったので調べた事をここにまとめてみます。

■svnsyncとは
svnsyncとは、Subversionのリポジトリを同期・複製するためのコマンドです。Subversion 1.4から追加されたらしい。リポジトリを同期・複製するための選択肢としては他にSVKというものがありますが、これはSubvesionには含まれずサードパーティ製ツールという扱いになります。主な違いは次のような感じです。

• svnsync
• Subversion 1.4以降に含まれる
• 基本的に「ターゲットと同期する」ことしかできない。
• SVK
• サードパーティ製のツールである(Subversionのインストールには含まれていない)
• Perlでできているらしい
• svnsyncより出来る事は多い。特定のリビジョンをスキップしたり、特定のリビジョンまで同期するというようなオプションが用意されている。
• 個人的な印象ですが、svnsyncほどの完成度ではない気がします(実際に今回ハマった部分はSVKでは回避できず、svnsyncでは回避できた)

■svnsync覚え書き
というわけでsvnsyncの覚え書きです。

• 基本
• リポジトリを作成する svn create hoge
• 作成したリポジトリのフォルダを開き、hooks/pre-revprop-change.tmpl をコピーしてhooks/pre-revprop-change.bat に変更する(Windowsの場合)
• hooks/pre-revprop-change.bat の2行目にexit 0 と記入する。
• 作成したリポジトリに、複製元の情報をコピーする。svnsync init file://hoge http://target
• これを実行すると、hogeのリビジョン0の属性として、次の3つの情報が書き込まれる。
• svn:sync-from-uuid：複製元のリポジトリのuuid
• 複製元リポジトリをsvn infoで見ると表示されるuuidと一緒のものが入力される。
• svn:sync-last-merged-rev：同期した最終リビジョン
• svn:sync-from-url：複製元リポジトリのパス (上記例ならhttp://target)
• あとは同期をする。svnsync sync hoge
  
• 基本的に最終リビジョンまで延々と処理を続ける。
• これだけ。
  
• メモ・調べたこと
• sync-last-merged-rev、sync-from-urlなどを変更すればある程度svnsyncの状態をコントロールできます。ただし、sync-last-merged-revを変更した場合、リポジトリのリビジョンと不一致があると、syncを実施する際にエラーとなります。
• sync-last-merged-revを変更するには、以下のコマンドを打ちます
  svn propedit svn:sync-last-merged-rev --revprop -r 0 --editor-cmd notepad file://hoge
• もしもリビジョンを変更したら、それに合わせてリポジトリのリビジョンもインクリメントさせる必要があります。うまい方法が見つからなかったので、私はプログラム以外のテキストファイルをちょっとだけ修正してコミットして調整しました。

今回のハマリポイントは、移行元のリポジトリで破損したチェックインがある(おそらく文字コードの処理に失敗し、文字化けした変更がコミットされてしまっている)ため、どうしてもあるリビジョンの修正にアクセスできず、syncが出来ないというトラブルでした。このリビジョンにはいかなる方法でも(svn infoですら)アクセスできないため、これをすっ飛ばす事が必要というわけでした。

■参考資料
とにかくこれが一番だと思ってます。しょっちゅう開いています。

Subversion実践入門—達人プログラマに学ぶバージョン管理

posted with amazlet at 08.04.09

Mike Mason
オーム社
売り上げランキング: 170542

Amazon.co.jp で詳細を見る

他に今回の作業をするに当たっては、以下のページを参考にしました。

• Subversionリポジトリのバックアップ( svnsync )
• Subversionによるバージョン管理
  

Blogged with the Flock Browser

メモシステムの変更

久しぶりにメモ/手帳システムを変更してみました。というのでメモ/手帳のお話です。

ここ数年は基本的に、いわゆるスケジュールを記入する手帳は持たずに手帳サイズのノートを使っていました。
人によって手帳のニーズは違うと思うのですが、個人的には、

• 会議や外出する予定は、会社で提供されるスケジュールサービスで管理せざるをえない。
• スケジュールをいちいち紙に転記するのは面倒だし、あまり意味がない。
• 記入するのは、基本的にはToDo(アクションアイテム)と作業メモが中心である。特に私は机の上が付箋紙でゴチャゴチャするのが嫌いなので、作業メモは一元的に管理をしたい。
• 仕事中はずっと開いた状態で机の上に置き、常に見る/書くことができる状態にしたい。
• 罫線はあっても無くても良い。方眼でも良い。
• メモ魔なので、必ず1日平均2ページを消化してしまいます。
  
• 年齢的にあまり貧相なのはイヤ。フォーマルな打合せでも使えるルックスが必要。
• かさばるのはイヤ(なので、システム手帳は嫌い)。
  

というのが私の手帳ニーズです。

ここ数年来は定番のMoleskinを使ってました。Moleskinは最近はとても入手しやすくなっていますし、開いた状態がキープできる(180度開く)ので愛用してきたのですが、最近は製造が中国になったり品質が落ちたという噂もあるらしいので、類似のノートもいろいろ試しています。

• RHODIAのePure
• 180度開いて使うという点で少し難あり。あと、開いた状態でずっと使っているとかなりクセがついてしまうのがイマイチ
• 能率手帳の能率手帳ポケット4
• 本当は2008年はこれで決定！というくらいに素晴らしい商品だったのですが、季節商品なので、年の始まり以外では入手が困難になってしまうという問題があります。補給性が低いのが凄いデメリット。
• 商品としては、最初に数ページだけマンスリースケジュールがあり、それ以降は全部メモという商品でした。Moleskinほど180度オープンをサポートしているわけではありませんが、耐久性についても申し分なし。

というわけで、やっぱりMoleskin中心で行こうかと思っていたのですが、ここ最近一つの大きな問題が出てきました。
それは、過去のノートが増えてきて邪魔というものです。

私のペースだと、Moleskin換算でだいたい3ヶ月で1冊使い切ってしまうのです。1年で4冊。最初のころは使い終わったMoleskinが増えていくのが嬉しかったりもしたのですが、10冊を越えるとだんだん苦しくなってくる。各ノートには思い出もあるので捨てるのもしのびないというわけです。

というわけで、2008年度版の能率手帳の能率手帳ポケット4を(やっぱり)3ヶ月で使い切ってしまった後、少し奮発してBRIT HOUSEのTHEMEという「スケジュール手帳」＋「RHODIAの#13」が両方使える皮手帳に変更してみました。イメージはAll About Japanのレビュー記事が参考になります。今のところなかなかに良い感じです。

• 左側が手帳、右側が文庫サイズのRHODIAの配置の手帳カバー。
  
• 基本的にはメモカバーなので、当然のことながら180度開いた状態で使うことができる。
• メモ部分はRHODIAなのでどんどん使える。また使った分は切り取って保管/廃棄できる。。現在は1週間単位で切り取って、クリップ止めしてデスクに保管するようにしています。
• 長期的なメモやスケジュールなどは手帳サイドに記入し、作業ログはRHODIA側に記入するという使い分けが可能。
• ちょっとオシャレ

これを作っているBRIT HOUSEさんはけっこうこだわりのあるメーカーみたいで、質感も非常に良い感じです。
というわけで、特にトラブルが無ければ当面はこのメモシステムでいってみようかなぁと。

Blogged with the Flock Browser

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

システム開発の要求開発・要求定義フェーズにおける人間関係のメタファー「コタツモデル」。そのアンチパターンについて考えるエントリの第2回です。


■オーナー不在(Owner Absence)
別名：誤った現場主義
挿話証拠：「トップは現場(業務)をわかっていないから」

ア ンチパターンの一つ目は、「オーナー不在(Owner Absence)」パターンを取り扱います。
図にあるように、「E(Engineer)：システム担当者」と「U(User):ユーザ、つまり業務担当 者」がコタツに入って、仕様を検討しています。ここで重要なのは、ビジネスオーナーが不在である、ということです。 ただしい コタツモデルでは、「E(Engineer)：システム担当者」「U(User):ユーザ、つまり業務担当者」「O(Owner):ビジネスオーナー」が 一つのコタツに入って合意形成をすることが良いとしています。それでは、ビジネスオーナーが不在の場合には、どのような問題が発生するのでしょうか。

■症状と結果
ビジネスオーナーは、次のような視点を持っています。

• 俯瞰的な業務構造やあるべき姿についてのイメージ
• 現場担当者や、システム担当者が知らない社内外の動き
• 実施事項がどのようにビジネスに影響するか

オーナー不在パターンでは、これらの視点が欠如する、または不足することによって次のような結果を引き起こします。

(1)現状業務にあわせてシステム化をしてしまい、業務の効率化や標準化、最適化がされない。

業 務担当者は通常、現在の業務を適切に遂行することが主な仕事となっています。その中で発見した課題や問題を中心にシステムの要求や仕様を検討するため、個 別の問題の解決は達成できます。しかし、あくまで現状の業務を中心に考えてしまうために根本的な(真の)改善点について、意識せずに回避してしまったり、 見落とす可能性があります。
たとえば、製造業の業務改善として有名なトヨタ生産方式(かんばん)では、商品の欠品を無くす為 に在庫を無くすという逆転の発想から生まれました。しかし、もしこの「欠品を無くす方法」の検討が、生産管理担当者によって行われたら、本当に「在庫を無 くす」という発想が出来たでしょうか。「欠品を無くす為に在庫を持つ」という常識に捉われてしまい、おそらく異なった結論に達するでしょう。
(参考：職場の「かんばん」方式)

(2)あまり重要ではない、些末な機能に大きく労力とコストを割いてしまう。

システム要求や仕様の検討は、必ず優先順位と取捨選択を伴います。この際に、ビジネス上の効果の視点が不足すると、本質的ではない機能について長い時間を割いて検討や開発をする事になりかねません。

• 特定の担当者しか利用しない機能に、非常にいろいろな使用頻度の低い付加機能を作ってしまう。
• 先進的だが実験的で、長期的に利用するかわからない機能に注力し、普遍的かつ長期的に利用する機能についての検討が不足する。
• 画像、アイコン、レイアウト、配色、その他ビジネスの本質とは関係の無い要求を多数盛り込んでしまう。

このような検討のムラとムダが、オーナー不在の場合に発生します。

(3)中途半端なシステムを作ってしまい、すぐに再修正が必要となってしまう。

中 途半端というのは2つの意味があります。一つはビジネス環境の変化に対する追従性です。業務担当者が知らない、または知らされていないビジネス環境の変化 というのは存在します。例えば法規制やビジネス戦略の方向性などは、内容によってはビジネスオーナーだけが知っている場合があります。また、業務の合併や 統廃合などについても同様です。
もう一つは、現場目線の検討によって、自社内の他のシステムと目的や機能が重複するシステム を、もう一つつくってしまうという問題です。特にユーザー部門が主導してシステムを構築する場合に、他の部門で検討中のシステムや、既に構築済みだが情報 共有されていないシステムと重複する場合があります。全社的なシステム部門の担当者が参加していれば防止する事もできますが、システム部門の参画も限定的 で、ユーザー部門と社外ベンダがシステムを構築する際にこういった問題が引き起こされることがあります
(参考：シャドーITって何？)

(4)開発プロジェクトメンバーのモチベーション低下

ビ ジネスオーナー不在のシステム開発プロジェクトでは、ビジネスとシステムの関係が明確でないままに進められてしまいます。システム開発メンバーも、自分の 開発するシステムが「何のために」作られ、結果として「どんなビジネス効果が出る」のかわからずに作業を行うこととなります。厳しいコストやスケジュール の制約の中で、自分達の参加するプロジェクトが、ビジネスオーナーから認識もされず、目的も不明確であればモチベーションも下がってしまうでしょう。

■典型的な原因

• ビジネスオーナーが、システムを単なる道具として捉え「ビジネスの屋台骨」ととらえていない
• ビジネスオーナーが、ITを苦手なもの、理解しにくいものとして避けている
• 業務担当者、システム担当者がビジネスオーナーの参画を面倒ごととして避けている

■解決策
システム開発プロジェクトへの、ビジネスオーナーの巻き込みは組織文化なども関係するため容易ではありません。しかしこの「オーナ不在」パターンにあるような問題が発生する懸念があれば、次のような方法を実施することを検討すべきです。

(i)儀式的イベントを活用する

プ ロジェクトのキックオフや開発フェーズの終了のタイミングは、ビジネスオーナーの参画を促せる絶好のタイミングです。特にキックオフについては次のような 視点でビジネスオーナーに発表をしてもらうことによって、検討期間中にビジネスオーナーが参加できなくとも、オーナー不在の不利益をかなり軽減できます。

• 検討するシステムのビジネス上の意義
• 検討の中で大いに検討してもらいたいこと、期待すること
• 望まない結果は何か

こういったイントロダクションの進め方については、GEが行う組織変革の手法「ワークアウト」が参考になります。ワークアウトでは組織横断的なチームが一 定期間のうちに問題解決のための議論を行います。その際には最初と最後だけ、ビジネスオーナーが参加を行い目的の明確化と、検討結果の是非の即決を行いま す。これはシステム開発の要求開発・要求定義フェーズにも適用できる考え方です。
(参考：GE式ワークアウト)

(ii)ビジネスオーナーへのインタビューをスケジュールに組み込む

キックオフやエンドポイントミーティングの実施の実績が無く、文化的にも受け入れられない場合は少なくともシステム開発の要求開発・要求定義フェーズで複 数回ビジネスオーナーへのインタビューを行えば良いでしょう。目的は、オーナー不在モデルで抜け落ちる「ビジネスオーナーの視点」を補うことです。なお、 ビジネスオーナーは忙しく、なかなか時間の確保をすることも難しいかもしれません。コンサルティングファームの技法の一つに「3分で行うエレベータープレ ゼンテーション」というものがあります。これはエレベータで移動する間の3分間で役員にプレゼンをすることなのですが、極端な話3分でも十分に確認や意見 を得ることは可能です。

■小話
ビジネスオーナーをプロジェクトに巻き込むのは最初はかなり躊躇します。ビジネスオーナーは、悪く言えば丸投げ、よく言えば権限を担当者に委譲しプロジェクトからは距離を置くのが一般的です。しかし、最終的に「ビジネス価値の高いシステム」を構築する上で、ビジネスオーナーは避けるわけにはいかない重要なプロジェクトメンバーの一人なのです。

プロジェクトは3ヶ月ほどの短期のものもあれば、数年間に渡る長期のものもあります。その期間たくさんのメンバーがシステムのために作業を行います。途中に苦しい時期もあるでしょう。そうやって作るシステムが「使えない」「使いにくい」「ポイントを外している」というのは、非常に悲しいことです。

オーナー不在プロジェクトに安住せずに、勇気をもってプロジェクトからアクションをするのが、大切ではないかと私は考えるのです。

コタツモデル・アンチパターンズ(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

ITシステム導入のポジティブな影響とネガティブな影響

仕事がらITシステムの導入に関係することが多いのですが、ITシステムの導入はビジネスにポジティブな影響を与えるだけではなく、同時にネガティブな影響も与えます。システム構築に際してはポジティブな影響(例「1日3000件の処理を可能とする」)をゴールとする事が多いのですが、ネガティブな影響についてはあまり論じられないような気がしています。

というわけで、ちょっと考えてみたのですが･･･図まで作って力尽きたので、次回につづく。




ちなみに今週の月曜日は、PFP関東ワークショップに参加してきました。今回もいろいろな気づきがあったのですが、ワークショップの内容はpapandaさんのBlogが詳しいので省略します。

SHELLモデル

前回のエントリに引続き、クルーリソースマネジメント(CRM)の話題です。



本書の中で紹介されているSHELLモデルが個人的にはとても気に入っています。というわけで、今回はSHELLモデルに関する話です。
SHELLモデルとは、KLMオランダ航空のパイロットであるHawkinsさんが提唱したもののようです。分野としては、人間工学(ヒューマンファクター工学)で論じられるものらしい。

• 中心のL = Liveware すなわち人間
• S = Software 作業手順や規則、規定のたぐい等
• H = Hardware 関連する機械、設備、使用機器、道具等
• E = Enviroment 物理的環境(空調、照明、騒音等)だけではなく、気象現象や社会環境など、仕事や行動に影響を与えるすべての環境を含めて考える
• L = Liveware あなたが接しなければならない、あなた以外の人。対人関係
• それぞれの要素が噛みあっていない箇所では、ヒューマンエラーが発生する。
  

クルーリソースマネジメント(CRM)では、このモデルを用いて中心にある人間のパフォーマンスの最大化を試みるものです。
このSHELLモデルは出自の関係からか、航空分野を中心にしか利用されていないようです。

ITシステム開発では、関連する話題として、次のようなものが個別にありますが、現時点では統合的な捉え方がされていないように考えています。

• アジャイル開発のプラクティスでは、人と人および、人と道具(SHELLにおけるHardware)の関係を中心に論じている (ex.「プロセスやツールよりも、人と人との交流を」「アジャイルツール(Wiki,バージョン管理,ユニットテスト,ビルドの自動化)の活用」)。
• プロジェクトファシリテーションでは、人と人(プロジェクトチーム)の生産性の最大化を中心に論じている。
• 開発プロセス論やテスト方法論では、規約(SHELLにおけるSoftware)による作業管理や品質保証について論じている。
• ピープルウェアといった書籍等は、物理的環境(SHELLにおけるE)と、人との関係について論じている。

最終的なゴールとしては、SHELLの各要素を統合した上で生産性の向上や最大化について論じるべき、というのは直感的にも非常にわかりやすいと考えています。

というわけで、次にプロジェクトを立ち上げる時には、SHELLモデルを中心に計画を行おうと考える今日この頃です。

マリン・コンセプト 正しく確実に伝える

最近ちょっとクルー・リソース・マネジメント(CRM)に興味があり、「機長のマネジメント」という本を読みました。

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



さて、CRMそのものも大変に興味深いのですが、今回は本書で知った『マリン・コンセプト』がとても便利だったのでこれを紹介してみようと思います。

マリン・コンセプト

• 海軍において、確実に指示を行い、誤謬なく伝達するための手法です。
• 基本ステップは次の通り
• 発信者が「指示」を出す (ex.全速前進！)
• 受信者は指示を「復唱」する (ex.全速前進！)
• 発信者は復唱内容を確認し、誤謬無く伝達されたことを確認する。
• 受信者は指示を実行し、変更を加えた場合はそれを合わせて報告する (ex.全速前進 よし！)
• 双方向(2ウェイ コミュニケーション)で確実性が高い。
• 迅速である。
  

非常にシンプルかつ、あたりまえな内容ですが、個人的にはハッとしてしまいました。
最近はメールやメッセンジャー、チャットなど多種多彩なコミュニケーション手段が多彩になっていますが、その割に「正しく誤謬なく指示を伝える」こともしばしです。
特に、テキストベースの電子メールなどでは、コピー・ペーストによって(理解できていないのに)返信されてしまい、結果として指示が失敗するということも考えられます。

というわけで、個人的には重要な指示は、

• メール または 電話で連絡する (ex. AとBを操作して結果CがDかを確認してください)
  
• 誤謬無く伝わったか、電話などで確認する (ex. AとBを操作して結果CがDかを確認します、と言ってもらう)
• 実施結果を、電話などで確認する (ex. AとBを操作しました。結果はC'でDと一致しました。OKでした。と報告してもらう)

となるように心がけている今日この頃です。

参考
操舵號令及針路呼稱法

Blogged with Flock

仕様変更を受け入れる話

先日某所で行われた合宿勉強会で盛り上がったネタを整理してみるものです。

さて、ここで言う仕様変更とはITシステムの開発期間における「仕様(設計)の変更(修正)」の事を指しています。
一般的には仕様変更が発生すると、手戻り作業が発生し、スケジュールやコストが変化します。というわけで、ITシステム開発では忌み嫌われるのが普通ではないでしょうか。
(このへんのニュアンスが分かりにくければ、404 Blog Not Found : 惰訳 - 建築士がプログラマーのごとく働かねばならぬとしたら をご覧になることをお勧めします。全プログラマーが泣いた。私も泣いた。)

特に日本では多いウォーターフォール型の開発では、中盤から終盤にかけてこの「仕様変更」の扱いが非常に重要な問題となっています。特に日本型開発ではシステム開発プロジェクトの序盤で予算が確定(固定)しており、話がややこしくなります。

立場別に、言いたい事を整理してみます。

• ユーザ / 発注者
• 今の設計(仕様)では使えない。使いにくい。IT化の効果がでない。
• その設計(仕様)は誤っている。誤りの原因は開発者側にある。修正してもらわないと困る。
• その設計(仕様)は誤っている。当初レビューした時には気づかなかったけれど、我々はシステム開発のプロフェッショナルではない。あなた方が気づくべき誤りなんだから、修正してもらわないと困る。
  
• 新しいアイデアを思いついた。簡単な変更なので取り込んで、よりよいシステムにしたい。
• 追加のコストや、スケジュールの変更は受け入れたくない。
  
• 開発者 / 受注者
• 設計(仕様)を新しく追加するのであれば、期間もコストもいただかないと出来ない。
  
• これは設計(仕様)の誤りかもしれないが、きちんとレビューも実施したし、誤りの責任は開発者だけではなく、ユーザにある。
• 変更は、見かけより大きな影響を引き起こす。とても予定コストとスケジュール内ではおさまらない。
• 新たな機能を追加するにしても、まずは現在開発しているプロジェクトを完了させて、そこに機能を追加しなければ全体が台無しになるリスクがある。

書いているだけでも悲しくなるくらい、ネガティブな内容が並んでしまいます。
まぁ、実際にはここまで酷くはないかもしれませんが、全体的に仕様変更は悪という雰囲気であることは確かです。

この仕様変更の問題対策としては、そもそもの開発方法を見直して「アジャイル開発」を取り入れるという方法があります。しかし、実際にはこれまでの作業の進め方を大きく見直さなければいけないことも多い為、なかなか定着しない/適用に踏み切れないのが実状です。

ところで、そもそも「仕様変更は悪」というのは本当なのでしょうか？

• 設計(仕様)決定時点では発見できなかった誤りを、カットオーバー前に発見できた！
• システムの価値を、格段に向上させるアイデアを新たに発明した！

と考えれば、むしろ仕様変更は宝である可能性もあります。実際に、仕様変更によって引き起こされるスケジュールやコストの問題が全てクリアされれば、その瞬間にネガティブがポジティブに大きく変換される。Negative Changing から Positive Changingへ。
というわけで、このネガポジ変換を実現するために、こんな戦略を考えてみました。

『仕様変更は全部受け入れる戦略』(Accept All Specification Changes Strategy : AASCS)

• 基本戦略
• 仕様変更は無制限に受け入れる。バグと区別はしない。
• 「このプロジェクトでは仕様変更を無制限に受け入れます」と宣言する。
• 仕様変更をやる、やらないの議論を禁止する。
  
• むしろ、仕様変更は喜びである。もっと仕様変更をしてほしいと思う(ただし、無意味な変更は除く)
• 対スケジュール戦術
• それが仕様変更なのか、バグなのかといった議論を一切しない。交渉スケジュールを短縮できる。
• 仕様変更によって引き起こされる作業の一部を、ユーザ(発注者)と共有する。
• 設計書の修正
• 結合テスト・受入テストのやり直し (極端な話、ユーザサイドで実施してもらう)
• 仕様変更によって引き起こされる作業の一部を、軽減する。
• 最低限のドキュメント以外の修正をやめさせてもらう。(ただし、出来る限りやったほうがよい)
  
• 単体テストのレベル(カバレッジ)を下げる。結合テスト/受入テストで担保する。(ただし、出来る限りやったほうがよい)
• 対コスト戦術
• それが仕様変更なのか、バグなのかといった議論を一切しない。交渉コストをゼロにする。
• 効果
• 仕様変更によって、ユーザと開発者双方のシステムへの理解度が上がることにより、品質が上がる。
• 仕様変更への後ろめたさが無くなり、ユーザが積極的に「使えるシステム」について考えるようになる。
• 仕様変更への後ろめたさが無くなり、開発者も仕様変更を提言できるようになる。「イケてるシステム」を作ることに参加できる。
• 発注者 vs 受注者、ユーザ vs 開発者ではなく、問題 vs 私たち になる。
• こんな気持ち
• すがすがしい。仕様変更に関連するネガティブなコミュニケーションはしなくてよいので、ストレスが減る。
• システムを開発することに集中できる。

こういうやり方も、アリだと思う今日この頃です。

Blogged with Flock

World Community Gridに入ってみた

昨日から、ウィキノミクスという本を読み始めています。まだ一章しか終わってないんですが・・・

ウィキノミクス マスコラボレーションによる開発・生産の世紀へ

posted with amazlet on 08.02.11

ドン・タプスコット/アンソニー・D・ウィリアムズ 井口 耕二
日経BP社 (2007/06/07)
売り上げランキング: 1713

Amazon.co.jp で詳細を見る

で、これを読んで分散GRID計算プロジェクトのことを思い出したので、久しぶりに導入してみました。
何を言っているのかというと、いわゆるPCの余剰計算能力を提供して、いろいろな問題解決の為の計算を行うというものです。以前はSETI@Homeなどが有名でしたが、いまではBONICという共通クライアントで、様々なプロジェクトが立ち上がっているようです。

もし興味があれば、IBMの提供するWorld Commnunity Gridなどからスタートすると良いでしょう。
というわけで、さっそくウチのPCも、FightAIDSプロジェクト(HIVの新しい候補薬の特定)などの計算を初めています。

最近のPCはマルチメディア対応でハイスペックですし、かといって四六時中使っているというわけではないので、こういった活用法ももっと一般的になるといいなぁと思う今日この頃。

勝間本ブームで産消逆転は加速するか

最近、日経IT Pro Watcherでもコラム「針路IT」を連載されている、田中克己さんの書籍「IT産業崩壊の危機―模索する再生への道のり」を読んでいます。で、本書の論旨とはちょっと外れているのかもしれませんが、産消逆転という話が面白かったので取り上げてみます。

ここで言う産消逆転とは、もともとは野村総合研究所の村上輝康理事長の発言によるものということですが、

• 産業界では、コンプライアンス対応や内部統制に注力した結果、IT活用が大きく遅れる
• 消費者サイドでは、ブロードバンド化、モバイル化、電子マネー、指紋認証etcのりようが進み、IT化が大きく進んでいる

という現象です。(詳細は書籍を購入しなくとも、「針路IT:内向きなIT投資が招いた“産消逆転”」で読むことができます)

これは確かにそうで、実際に職場のIT環境に比べたら自宅のほうがリッチな人というのは案外多いんじゃないでしょうか。私もつい最近、自宅環境を20インチのiMacに変更し、ネットワークはフレッツ光。人との連絡はSkypeとTwitter、Mixiを使い、メールはGMail、文書作成はGoogleドキュメントを使っています。まぁ、これは極端な例としても、「自宅では○○が出来るのに、会社ではできない」と思う人はけっこう多いのではないでしょうか。「なんで会社では○○出来ないの？　ネットだと簡単に○○できるのに」

そして、最近ブームの勝間本がこの流れを加速していきそうな気がしています。例えば話題のコレです。

週刊 ダイヤモンド 2008年 2/9号 [雑誌]

posted with amazlet on 08.02.07

ダイヤモンド社 (2008/02/04)

Amazon.co.jp で詳細を見る

ご存知の方も多いとおもいますが、MixiやGMail、Googleドキュメントを初めとするオンラインツールなどを存分に活用する方法を説明していきます。今までは一部のアーリーアダプターが使っていたこれらのサービスなどが、一気にマジョリティを獲得しそうな予感があります。

そうするとどうなるか。
企業内では今まで無視できた、マニアックな利用者の「なんで会社では○○出来ないの？　ネットだと簡単に○○できるのに」という声が、無視できなくなってくるのではないでしょうか。

• 会社のメールボックスは何で容量制限あるんだ？ GMailはほとんど無制限なのに。
• WordやExcelを購入する必要あるのか？ Googleドキュメントで十分なのに。
• なんで、社内の情報は検索できないんだ？

という声が、こういったトップセラーの書籍を読んだ偉い人から飛び出す確率が飛躍的に高まるのかもしれません。ううっ、社内の情報システム部門の人は大変そうだ・・・

とはいえ、これは一つのチャンスでもあり、「針路IT:内向きなIT投資が招いた“産消逆転”」に書かれているような内向き・防衛スタイルの情報戦略を、差別化目的の情報戦略に転換するチャンスであるかもしれません。

産消逆転をもういちど逆転することができるのか、逆にさらに大きく引き離されてしまうのか、ちょっと興味深いなぁと思った次第です。

IT産業崩壊の危機―模索する再生への道のり

posted with amazlet on 08.02.07

田中 克己
日経BP社 (2007/11)
売り上げランキング: 4917

Amazon.co.jp で詳細を見る

Blogged with Flock

要求開発の後の事を考えてみる

かなり暴走妄想気味ですが、要求開発の後に行うべきことについて考えてみました。

なお内容は前から実験してみたかった、Googleドキュメントで作成したスライドショーを貼り付ける形式にしてみています。ちゃんと見えるんでしょうか・・・。

Blogged with Flock

GoogleDocsで本を書く方法のメモ訳

本当にやるのかは別にして、参加しているコミュニティでちょっとしたドキュメントを作成する話題が出ています。今まではWordなどで文書を作成してそれをメールに添付してやりとりする、というスタイルだったのですが、これを変更してGoogleDocsにすればいいと個人的に考えていました。
と、ちょうどWebを眺めていたら、「Writing a Book in Google Docs」というエントリ(英語)を発見したので、和訳しながらメモをとってみました。

なお、内容の保証は無いので気になる方は原文をご参照ください。
というわけで、以下本題。

GoogleDocsで本を執筆する(オリジナルは「Writing a Book in Google Docs」です)のメモ訳

• アウトライン
• 「アウトライン文書」を、作業のベース文書として作成する。
• 各項へのリンクと作業状況、抜粋(要約)を記載する。
• 作業状況は色分けして表示する
• 緑：初稿
• 黄：校正?済みの初稿
• シアン：第二稿
• 灰：確定稿
• アウトラインから右クリックで各文書を開く
• 個別のドキュメント
• 各ドキュメントは同じテンプレートを使って作成する。
• デフォルトのGoogleドキュメントのStyleはイマイチなので、"HTMLの編集"で書き換えてしまう。
• 画像は非減色のPNGにして貼り付け、各章別にローカルで管理する。
• 画像を貼り付けたら"HTMLの編集"で1pixelの黒枠を追記する。
• 利用するフォーマットは限る。Ctrl+B(ボールド)とCtrl+I(イタリック)
• ワークフロー
• Googleの機能でスペルチェック
• HTML(Zipped)でエクスポートしてバックアップしてから、共有タブで共同執筆者に通知する。
• 共著者が校正作業を終えたら、「アウトライン文書」のステータスを変更する。
• 作成者は変更内容を"変更内容"タブで確認する。
• 文書の命名
• 短縮名 + 章タイトル + 項目名 のような形で。
• Googleドキュメントに新しいフォルダを作成して、そこで管理をすると良い。
• とはいえ、Googleドキュメントのエクスプローラでは画面の表示量が少ないので、「アウトライン文書」を活用したほうが良い。

メモ書きここまで。
ちなみに、元ネタBlogではこの方法で「Google Office Hacks」を執筆しているみたいなので、この本自体も楽しみですね。
最近すっかり、職務以外の文書書きはGoogleドキュメントを使っています。たぶん有料になっても金を払う。このあいだ自宅のPCをリプレースしたのですが、当然ストレスフリー。この便利さは、個人的には気に入っています。

Blogged with Flock

OpenEventのリスク

197xつながりなGoTheDistanceさんのところの「コミュニティ運営の難しさ」というエントリについて。
ちなみにBPMイベントは参加したかったのに諸般の事情で参加できず。ちょっと悔しい。

私も要求開発アライアンスの幹事をすることが多いのですが、オープンコミュニティを運営するリスクはいろいろあります。

• 参加者をコントロールし難い (会場とか人数とか、会費とか)
• 天候とか時期とか偶然によって、人数が大きく変化した時に金銭的リスクが発生する (懇親会とか)
• 内外からDISられる (何やってんだお前、とか、お前何様だ、とか)
• 全般的な運営コスト
  

というあたりは、避け難い壁としていつか直面するものだと思います。
このうち「運営コスト」や「参加者コントロール」についてはある程度ツールやサービスを活用して負荷軽減ができる(参考→「OpenEventの運営メモ」)ので極力これを活用した上で、残ったモヤモヤは、自分がコミュニティを運営することで得られるメリットと天秤をかけるしかないんだろうと思います。

「仕事のための12の基礎力～「キャリア」と「能力」の育て方～」という本にも書いてありましたが、やはり197xともなるとそろそろ人材開拓力を伸ばす時期なわけで、そんな中でオープンコミュニティの運営というのは比較的に金をかけなくてもできる(時間さえ投資すればどうにかなる)わけです。ある意味やっていることを個人的なキャリア形成の一部として考える事ができるのであれば、DISられても平気。

最後に金銭的なリスクが残るわけですが、これはまぁ基本的には参加者から若干多めに徴集してリスクテーク＋残金は次回に廻す、という基本的な戦略が一番である気がします。もちろん着服してはいけないので、残金はMLや何人かに伝えておく良心は必要ですけど。残金が残ると、次回開催へのモチベーションにもなるのでお勧め。

私はまだ経験がありませんが、全員バックレ とか、日程連絡ミスにより全損になった場合でも、50人程度の動員であれば最大でも30万くらいの損害しか出ないので、その時は勉強だったと割り切るんで良いんじゃないかと思っています。そういう意味で自分の中ではローリスクな投資だと思ってます。

Blogged with Flock

RfS（Ruby for Specifications）

牛尾さんが日経IT Pro Watcherに投稿していたオフショア時代を乗り切る明確な要求仕様作成術について。
ちなみに、牛尾さんは要求開発アライアンスの執行委員つながりです。というわけで、昨日も「大ネタを書いたんですよー」と事前に聞いていたのですが、こりゃ確かに大ネタです。

　Rubyという生産性の高い言語とフレームワーク，そしてアジャイル開発があれば，「仕様書としてのアプリケーション構築」が現実のものとなる。このようなRubyの使い方を，RfS（Ruby for Specifications）と名付けよう。そもそも要件定義フェーズは，作るものが決まっていない「準委任契約」のフェーズである。このフェーズで，動くか動かないか，または正確なのかが わからない紙ベースでの仕様を作るかわりに，Railsを使ったアジャイル開発で，迅速に「仕様書としてのアプリケーション」を構築する。要求開発でプロ ジェクト企画を行い，その後アジャイル開発を使って，実際に動くアプリケーションという「仕様」を作成していくのだ。

オフショア時代を乗り切る明確な要求仕様作成術

興味深いテーマです。基本的にシステム開発プロジェクトが失敗する(もしくは、リスクが高い)原因の一つとしては、

• 計画(設計)が間違っていて、後でこの誤りを修正しようとしてクチャクチャになる。
• 計画(設計)通りに作ってみたら、顧客のイメージと違い使えない。

これを防ぐ為に、ユースケースシナリオを書いてみたりしますが、やはりドキュメントは所詮ドキュメントであり、ユーザと開発者の認識があっていなかったり(解釈が違う)、ユーザが設計ドキュメントのレビューに慣れておらず、誤りを見逃してしまう可能性もあるわけです。(話が横道に逸れますが、ユーザは当然のことながら業務のスペシャリストであって、設計のスペシャリストではないわけです。よくレビューで見逃された不備を「仕様通りです」と押し切ろうとする人がいますが、ステークホルダーがそれぞれ何のプロフェッショナルとして参加しているのかの分析誤りであることがあります)

というわけで、RfSのアイデア及び、「動くものを早めにつくり、確認する」という発想はアグリーです。
とはいえ反論(やアイデア)もあります。

たぶん、Ruby(もしくは似たような何か)で構築されたプロダクトとコードを引き渡して実装に突入するのはさすがにリスキー。データモデルやオブジェクト構成、業務テストシナリオなどを引継ぐのは良いと思いますが、コード等までやってしまうと色々な問題が出てきそうです。
ソフトウェア開発の古典 「達人プログラマー　システム開発の職人から名匠への道(アンドリュー・ハント／デビット・トーマス著)」から引用しますが、

ヒント16. プロトタイプの真の目的は学びにある
プロトタイピングとは、学習経験のことである。その価値はできあがったコードにあるのではなく、学習した教訓そのものなのである。

という意味では、RfSで作成したプロダクトについても、きちんとした評価を行い教訓を導き出した上で開発に適用すべきなように思います。例えばこんな感じだとどうでしょう？

• RfSプロダクトについての、良い点と悪い点(評価レポート)
• RfSプロダクトで試した事、試さなかった事(評価レポート)
  
• 実際のユーザの使われ方(Flash Movieなどで)
• データモデルやオブジェクトモデルの設計(設計書/UMLやDDLなど)
• シンプルな業務テストシナリオ(RfSプロダクトを元に作ってドキュメント化する)
  

このあたりで断ち切ってしまえばちょうどよいかなぁ。
勢いで書いているので、間違ってたらごめんなさい。

ちなみにさっそくSeasar2のひがさんからツッコミが来ていますね･･･。両方知っているのでちょっと微妙な立ち位置･･･。

Blogged with Flock