日経ITProに記事書きました(2)
前回に引き続き、こんな記事を書いてみました。
要求開発とコタツモデル(2)－－アンチパターンを活用する：ITpro
モトネタは要求開発アライアンスの3月定例勉強会で発表したネタだったんですが、なかなかちゃんとした記事風にするのは難しいものですね。良い思考トレーニングになりました。
火曜日, 6月 17, 2008
金曜日, 5月 30, 2008
日経ITProに記事書きました
こんな記事を書いてみました。
要求開発とコタツモデル(1)－－失敗パターンに陥らないために：ITpro
要求開発アライアンスではいろいろな議論や発表がされています。これを、もうすこしわかりやすく、ていねいに紹介したら良いのではないか？ と常々思っていたのです。というわけで、今年はこんな内容で何回か記事を寄稿してみようと思っています。
ちなみに、書くにあたっては『「超」文章法』をかなり参考にしました。個人的にはちょっとブームです。
Blogged with the Flock Browser
水曜日, 5月 28, 2008
IT複合汚染
ひょんなことから、有吉佐和子さんの有名な小説(?)『複合汚染 (新潮文庫) 』を読んでいます。本作は、ちょうど私が生まれた年の朝日新聞に連載された環境汚染問題をテーマとした文芸作品です。興味があるかたはWikipediaなどもあわせてご参照ください。
本作を読んで、ふと気づいたのが昭和40年代の複合汚染の状況と、現状のITを取り巻く環境の類似性です。
例えば農業の近代化というと、耕作機械の導入、化学肥料の導入、農薬の使用なのだそうです。そして近代化した結果、農家は高価な耕作機械の購入にあえぎ、化学肥料と農薬によって荒れた土地で耕作を続ける為にさらなる化学肥料と農薬を投入し、最終的には複合的な農薬汚染によって病気となったり自殺してしまったりする(30年前の話ですが)。
特に本作で取り上げられている「複合汚染」では、農薬や化学肥料などが複合的に組み合わさった場合の副作用を検証せずに、それぞれ単品では「害が無い」と判断してドンドン投入した結果、結果として公害病や生産者の健康被害に至っている。
最近、ITを取り巻く環境についても様々な問題が取りざたされています。
- メンタルヘルスの問題
- 多重請負構造の問題や受託開発の問題
- 開発リスクや、システム開発の成功確率の問題
利用者の役に立つシステムを適切な価格で提供する。これを目標にスタートしているはずなのに、みんなうまくいっていない。歯車が噛み合っていない。
というところで、『IT複合汚染』という単語を思いついたんですが・・・
Blogged with the Flock Browser
水曜日, 5月 21, 2008
読書強制システム
またまたBlogの更新が滞ってます。連載宣言(?)をしたコタツモデルの話の続きも書けていないのですが、続ける気はもちろんありますので、もし万が一にも興味を持っている方は気長にお待ちください。
で、今回は私の読書強制システムについてのご紹介です。読書強制システムとは、スパルタンに大量の本を読まざるをえないようにするシステムの事です。この記事を読んでて思いつきました。
本は「欲しい」という前に買え。そう思います。私も同じように考えていますが、より自分に読書プレッシャーがかかるような仕組みにしています。
よく本が読めないとかいう人がいますが、そういう人に共通してるのはまず読めないという前に、読む本をもってないでしょ、ってこと。
そりゃ、持ってなければ読めません。読むためにはまず読むべきものを所有することです。そこからです。しかも、１つじゃなくて常に複数読みたいものを所有しておくこと。それもできるだけいろんな種類のものであった方がいい。
本は「欲しい」という前に買え：DESIGN IT! w/LOVE
具体的には・・・
- 読むべき本は、とりあえずAmazonの「ほしい物リスト」に入れる。このリストをゼロにするのがゴール。
- 週次にただちに限度いっぱいまで、市立図書館で予約する(私の住んでいる自治体では6冊)
- 予約した本はランダムに貸出可能になる。貸出後2週間以内に読まなければいけない。
- 図書館で予約した本以外に、常に手元に数冊あるようにする。
- 図書館で借りた本が切れた時に読む。
- ただし、せっかく買ったのに読まないと旬が過ぎてしまうので1ヶ月以内には読み終わりたい。
- オプションとして、上司や会社の偉い人の本棚から本を借りる
- これはかなり早めに読み終わらないといけない。
- 会うたびに「どう、読んだ？」と言われてプレッシャーをかけてもらえる。
- もう一つのオプションとして、本の著者に会う機会を作ってしまう。(勉強会などで講演を頼んだり)
- 事前に読了することは必須。
ちなみに現在の未読数は227冊です・・・
Blogged with the Flock Browser
水曜日, 5月 14, 2008
svn switch --relocateではUUIDが異なるリポジトリのSwitchはできない
今日ちょっとハマったのでメモ。Subversionという構成管理ツールのお話です。
Subversionのリポジトリを格納するサーバですが、当然のことながら永遠に同じマシンの上で運用するわけにはいかないので、移行をする必要があります。で、移行した際にはローカルのWorkSpaceを、古いリポジトリから新しいリポジトリに切り替えてあげる必要があります。
この操作は、Subversionのswitchコマンドで行うのですが、、、
実は、UUIDが異なるリポジトリへの切り替えは、現在のバージョン(1.4.x)ではできません。
UUIDのチェックロジックが埋め込まれており、回避は不可能です。
(ここまで調べるのにけっこう疲れた)
次期バージョンでは--ForceオプションによるUUIDチェックの回避ロジックが検討されているようですが、リポジトリを移行する際には留意する必要があるようです。
うへぇ。
Blogged with the Flock Browser
火曜日, 5月 13, 2008
FlockにGoogleGearをインストールする方法
最近のお気に入りのブラウザはFlockです。ベースはFirefoxで、これにいろいろなSNS的ツールを追加したものですが、便利に使っています。日本語版はありませんが、基本的にはFirefoxなので特に利用に支障はありません。
ちなみにFlockの詳細はWikipediaが詳しいのであわせてどうぞ。
さて、FlockはFirefoxベースなので基本的にはFirefox向けの拡張機能はすべてインストールすることができます。ですが、なぜかWindows版ではGoogle Gearだけは簡単にインストールできないので注意が必要です。
Windows向けのGoogle Gearですが、利便性を重視して専用のインストーラが配布されます。このインストーラがFlockを検知してくれないために、Flockへのインストールはうまくいかないようです。(ちなみにMac OS Xではこの問題はないようです)
ではどうやってインストールするかというと、次のような方法で手動インストールができます。
- まずはGoogle Gearをインストールする。(インストーラを実行する)
- 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> - 最後に、このフォルダにあるすべてのファイルを1つのアーカイブにZIPする。
- ZIPファイルの拡張子を、xpiに変更する
- Flockを立ち上げて、ToolsメニューからAdd-onsを選択し、拡張マネージャを立ち上げる
- xpiファイルを拡張マネージャにドラッグ
Blogged with the Flock Browser
木曜日, 4月 17, 2008
Doingリスト
ライフハック交差点：第10回 未来を引き寄せる ToDoリストの作り方 ｜gihyo.jp
で紹介されている、ToDoリストならず、Doingリスト。これ、オススメです。ひとことでいえば、「今なにをやっているかをメモなどに書くということ」です。Doingリストを作成すれば、割込みの作業や電話などがあっても、何をやっていたか、次に何をやるべきかについて見失う事はなくなります。
個人的なコツはこんな感じ。最近はRHODIA#13(文庫本サイズのRHODIA)を使っています。
- 仕事の種類や公私などでリストを分けずに、単に上から順に書いていく。
- 仕事中は常に手元に開いておいて、すぐに閲覧と更新ができるようにしていく。
- アクションリストで書く。「～の件」ではなく「～の件をメールする」という感じ。
- 終わったら気持ちよく斜線を引いて消す。
参考：
ゆっくりと動きながら高速でこなす、一流の研究者の Doing リスト | Lifehacking.jp
Blogged with the Flock Browser
木曜日, 4月 10, 2008
svnsyncの使い方
svnsyncというのは、プログラムのソースコードなどを管理するバージョン管理システムSubversionのコマンドの一つです。ちょっと最近ハマったので調べた事をここにまとめてみます。
■svnsyncとは
svnsyncとは、Subversionのリポジトリを同期・複製するためのコマンドです。Subversion 1.4から追加されたらしい。リポジトリを同期・複製するための選択肢としては他にSVKというものがありますが、これはSubvesionには含まれずサードパーティ製ツールという扱いになります。主な違いは次のような感じです。
- svnsync
- Subversion 1.4以降に含まれる
- 基本的に「ターゲットと同期する」ことしかできない。
- SVK
- サードパーティ製のツールである(Subversionのインストールには含まれていない)
- Perlでできているらしい
- svnsyncより出来る事は多い。特定のリビジョンをスキップしたり、特定のリビジョンまで同期するというようなオプションが用意されている。
- 個人的な印象ですが、svnsyncほどの完成度ではない気がします(実際に今回ハマった部分はSVKでは回避できず、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 - もしもリビジョンを変更したら、それに合わせてリポジトリのリビジョンもインクリメントさせる必要があります。うまい方法が見つからなかったので、私はプログラム以外のテキストファイルをちょっとだけ修正してコミットして調整しました。
■参考資料
とにかくこれが一番だと思ってます。しょっちゅう開いています。
Subversion実践入門—達人プログラマに学ぶバージョン管理
posted with amazlet at 08.04.09
Mike Mason
オーム社
売り上げランキング: 170542
オーム社
売り上げランキング: 170542
他に今回の作業をするに当たっては、以下のページを参考にしました。
Blogged with the Flock Browser
水曜日, 4月 09, 2008
メモシステムの変更
久しぶりにメモ/手帳システムを変更してみました。というのでメモ/手帳のお話です。
ここ数年は基本的に、いわゆるスケジュールを記入する手帳は持たずに手帳サイズのノートを使っていました。
人によって手帳のニーズは違うと思うのですが、個人的には、
- 会議や外出する予定は、会社で提供されるスケジュールサービスで管理せざるをえない。
- スケジュールをいちいち紙に転記するのは面倒だし、あまり意味がない。
- 記入するのは、基本的にはToDo(アクションアイテム)と作業メモが中心である。特に私は机の上が付箋紙でゴチャゴチャするのが嫌いなので、作業メモは一元的に管理をしたい。
- 仕事中はずっと開いた状態で机の上に置き、常に見る/書くことができる状態にしたい。
- 罫線はあっても無くても良い。方眼でも良い。
- メモ魔なので、必ず1日平均2ページを消化してしまいます。
- 年齢的にあまり貧相なのはイヤ。フォーマルな打合せでも使えるルックスが必要。
- かさばるのはイヤ(なので、システム手帳は嫌い)。
ここ数年来は定番のMoleskinを使ってました。Moleskinは最近はとても入手しやすくなっていますし、開いた状態がキープできる(180度開く)ので愛用してきたのですが、最近は製造が中国になったり品質が落ちたという噂もあるらしいので、類似のノートもいろいろ試しています。
- RHODIAのePure
- 180度開いて使うという点で少し難あり。あと、開いた状態でずっと使っているとかなりクセがついてしまうのがイマイチ
- 能率手帳の能率手帳ポケット4
- 本当は2008年はこれで決定！というくらいに素晴らしい商品だったのですが、季節商品なので、年の始まり以外では入手が困難になってしまうという問題があります。補給性が低いのが凄いデメリット。
- 商品としては、最初に数ページだけマンスリースケジュールがあり、それ以降は全部メモという商品でした。Moleskinほど180度オープンをサポートしているわけではありませんが、耐久性についても申し分なし。
それは、過去のノートが増えてきて邪魔というものです。
私のペースだと、Moleskin換算でだいたい3ヶ月で1冊使い切ってしまうのです。1年で4冊。最初のころは使い終わったMoleskinが増えていくのが嬉しかったりもしたのですが、10冊を越えるとだんだん苦しくなってくる。各ノートには思い出もあるので捨てるのもしのびないというわけです。
というわけで、2008年度版の能率手帳の能率手帳ポケット4を(やっぱり)3ヶ月で使い切ってしまった後、少し奮発してBRIT HOUSEのTHEMEという「スケジュール手帳」＋「RHODIAの#13」が両方使える皮手帳に変更してみました。イメージはAll About Japanのレビュー記事が参考になります。今のところなかなかに良い感じです。
- 左側が手帳、右側が文庫サイズのRHODIAの配置の手帳カバー。
- 基本的にはメモカバーなので、当然のことながら180度開いた状態で使うことができる。
- メモ部分はRHODIAなのでどんどん使える。また使った分は切り取って保管/廃棄できる。。現在は1週間単位で切り取って、クリップ止めしてデスクに保管するようにしています。
- 長期的なメモやスケジュールなどは手帳サイドに記入し、作業ログはRHODIA側に記入するという使い分けが可能。
- ちょっとオシャレ
というわけで、特にトラブルが無ければ当面はこのメモシステムでいってみようかなぁと。
Blogged with the Flock Browser
月曜日, 4月 07, 2008
コタツモデル・アンチパターンズ(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式ワークアウト)
(ii)ビジネスオーナーへのインタビューをスケジュールに組み込む
キックオフやエンドポイントミーティングの実施の実績が無く、文化的にも受け入れられない場合は少なくともシステム開発の要求開発・要求定義フェーズで複 数回ビジネスオーナーへのインタビューを行えば良いでしょう。目的は、オーナー不在モデルで抜け落ちる「ビジネスオーナーの視点」を補うことです。なお、 ビジネスオーナーは忙しく、なかなか時間の確保をすることも難しいかもしれません。コンサルティングファームの技法の一つに「3分で行うエレベータープレ ゼンテーション」というものがあります。これはエレベータで移動する間の3分間で役員にプレゼンをすることなのですが、極端な話3分でも十分に確認や意見 を得ることは可能です。
■小話
ビジネスオーナーをプロジェクトに巻き込むのは最初はかなり躊躇します。ビジネスオーナーは、悪く言えば丸投げ、よく言えば権限を担当者に委譲しプロジェクトからは距離を置くのが一般的です。しかし、最終的に「ビジネス価値の高いシステム」を構築する上で、ビジネスオーナーは避けるわけにはいかない重要なプロジェクトメンバーの一人なのです。
プロジェクトは3ヶ月ほどの短期のものもあれば、数年間に渡る長期のものもあります。その期間たくさんのメンバーがシステムのために作業を行います。途中に苦しい時期もあるでしょう。そうやって作るシステムが「使えない」「使いにくい」「ポイントを外している」というのは、非常に悲しいことです。
オーナー不在プロジェクトに安住せずに、勇気をもってプロジェクトからアクションをするのが、大切ではないかと私は考えるのです。
日曜日, 3月 30, 2008
コタツモデル・アンチパターンズ(1)
■はじめに
2008年3月の要求開発アライアンス定例会で「コタツモデル再考」という発表をしたのですが、予想外に好評だったので調子に乗って、発表内容をベースに「コタツモデル・アンチパターンズ」という標題で詳しい内容を書いてみようと思います。週1回ペースくらいで書いていこうと思いますので、興味のある方はRSSリーダ等に当ブログを登録お願いします。
■コタツモデル
システム開発プロジェクトは沢山の人によって進められます。特にシステムそのものの目的や方向性そして仕様を決めるプロセスは重要で、ここで失敗するとシステム開発プロジェクト自体が失敗するといっても過言ではありません(実際に、システム開発プロジェクトの7割は失敗しているという調査もあります)。
失敗する要因には様々なものがありますが、特に次の3種類のプロジェクト参加者が、システムの目的や方向性について合意形成していることがプロジェクトを失敗させない為には重要です。
- ビジネスオーナー (ビジネスの方向性や方針を決めるが、システム開発や現場業務には詳しくない)
- 現場担当者 (実際に業務を担当している現場担当者)
- システム担当者 (システム部門の担当者または開発ベンダ)
ソフトウェアはコミュニケーションで出来ているとはチェンジビジョンの平鍋さんの言葉ですが、特にシステムの目的や方向性の決定、要件定義について、コタツモデルを形成することが、システム開発の成功確率を高める一つのポイントではないでしょうか。
■コタツモデルとアンチパターン
ソフトウェア開発において「こうあるべきだ」という典型例を集めたものデザインパターンであるのに対し、「こうあってはならない」という典型例を集めたテンプレート集がアンチパターン。デザインパターンと言うと、設計やプログラムコードのお手本として捉えられることが多いのですが、これに対してアンチパターンは組織やプロジェクトマネジメントまで非常に幅広く取扱うことができます。書籍「アンチパターン -ソフトウェア既得患者の救出-」や、Wikipedia(英)のAnti-Patternには様々なレベルのアンチパターンが言及されています。
はてなダイアリー：アンチパターンとは
さて、コタツモデルは人間関係のメタファーであるため、次のような難しさがあります。
- 容易に修正したり、制御することは出来ない
- コタツモデルではない事はすぐにわかるが、簡単には是正できない
- 対症療法をとるしかない。
■コタツモデルの良いところ
要求開発では、そもそも「要求はあるものではなく，開発するものである」という前提をおいています。過去のシステム開発プロジェクトの焦点は電子化や自動化が多く、既存の業務の仕組みを調査分析をすることでシステムの目的や仕様を決定することができました。しかし現在においては、システム化の対象範囲は広がり、人間系とシステム系が複雑に入り組み混在化したビジネス系そのものを扱う事もしばしあります。こういったシステムの要求は調査分析をしても見つけることはできず、プロジェクトメンバーによって検討(開発)しなければならない、ということです。
限られた期間、限られたメンバーで要求を検討(開発)する際に重要となるのはバランスです。
- 視野のバランス ・・・ 複数の視点から見て、合理的かつ効果的な検討を行うため
- 権威のバランス ・・・ 特定の発案者の意見に従うのではなく、参加者がフラットに意見交換を行う為
コタツモデルでは、ここで(実現可能かは別にして)ビジネスオーナー、現場担当者、システム担当者が対等な立場で議論を行い合意する関係性を提示しています。これは、単なる絵的なもの以上の価値があるのではないか、と考える今日この頃です。
長くなってしまいましたが、次回からはさっそくアンチパターンについて紹介していきたいと思います。興味のある方は引続きおつきあいくださいませ。
月曜日, 3月 17, 2008
メモを取らないとハイパフォーマーになれないよ
いつか書こうと思っていたんですが、ひがさんのBlogで言及されていたので反応的にエントリ。
なぜメモを取るのか。
* 記憶は頼りにならない
* メモを取ることで、脳を「考えること」に使える
* 記憶は共有できないが、メモは共有できる。メモを書くことは、他人と情報を共有することになる。
などです。メモを取ることは、一手間かかるようで、実は非常に効率的なのです。
2008-03-14 - reponの日記
メモを取ることで、満足しちゃうんだよね。頭を使わなくなる。だから、相手の話を聞くときには、その話に集中し、メモなんか取らないほうが良い。
メモを取ったほうが良いのか - ひがやすを blog
ちなみに私はちょっとしたメモさえあれば、台本のような詳細議事録を書ける特技を持っています。なんでできるかというとよくわかりませんが、学生時代に芝居の勉強をしているときに身についたような気がします。芝居だと自分と相手のセリフだけではなく動きも含めて記憶しないと演技が成立しないことがあるので、そのときに短期記憶が発達したのかもしれないと思う今日この頃です。
さて、個人的にはメモは取るべきだと思っています。以下理由。
- 目上の人と話をするときには、マナーとして
- 相手の貴重な時間を浪費しているのですから、「きちんと話を聞いて記録する」という立場で望むべきだと思います。ちなみにこれは私が社会人のキャリアを始めたときに先輩から教えてもらったことだったりします。
- 重要な事は忘れない、と自分を過信せず、トラブル防止の観点で
- プライベートであれば話は別ですが、特に仕事であれば、トラブルを防止しようとするのはあたりまえのことです。絶対に忘れない、と断言できない場合はメモを取るべきだと思います。
- 呼ばれたら飛んでいく
- 大きな声で返事する
- きちんとメモをとる
Blogged with the Flock Browser
金曜日, 3月 14, 2008
要求開発アライアンス3月定例会発表資料
私が運営にも参加している要求開発アライアンスの2008年3月定例会で、ちょっとした発表をしてきました。
詳しい話は別途近いうちに書きますが、とりあえず資料を公開します。
(SlideShareがなかなか表示されなかったり、エラーとなる場合は、こちらからPDF版を取得してください)
以下簡単なふりかえりです。
- よかったこと
- たくさんの人に「気づき」を持ち帰ってもらえたようで嬉しかったです。
- 発表したことによって、皆さんから新たなアイデアをたくさんいただけました。知の連鎖を引き起こすことができたような気がしています。
- 反省点
- リハーサル不足だったので、スムーズに喋ることができませんでした。リハーサルは重要ですね。そもそも、人前でスライド発表すること自体かなり久しぶりだったので、焦ってしまいました。
- 時間配分に失敗して、自分の予測より15分くらい超過してしまいました。もうすこしスライドに対して説明する内容をシンプルにすべきだった。
- マイクを使わずに発表したのですが、後ろの人まで聞こえるかのチェックを忘れていました。聞き取りにくかった人がいたらごめんなさい。
- 今後に向けて
- 皆さんにいただいたアイデアを再整理して、ブラッシュアップします。
- 次に発表する時には、絶対に練習してから望む。
Blogged with Flock
水曜日, 3月 12, 2008
デスマーチの誤用や誤認について
某所でデスマーチについて議論しました。その時点ではいくつか私の誤認もあったので、改めてデスマーチについて考えてみます。
個人的な意見としては、みんな「デスマーチ(ﾟ∀ﾟ)」と言いすぎると思っています。
なお、このエントリのBGMはマイ・ケミカル・ロマンスの「ザ・ブラック・パレード」で・・・
■個人的なデスマーチの定義（注：これはマチガイです）
デスマーチとは、ソフトウェア開発における悲惨なプロジェクトのメタファーです。メンバーに極度な負担を強い、かつ成功する確率が低い状況を、「死の行進（デスマーチ）」と呼びます。
後で調べて間違いだと気づいたのですが、個人的にはデスマーチの定義を次のように考えていました。
- これはデスマーチである
- 仕様が発散し、プロジェクトが収束する可能性が無い。仕様変更が多発し、つくれどもつくれども楽にならり。
- 品質が発散し、やはりプロジェクトが収束する可能性が無い。バグがバグを呼び、治せども治せども楽にならざり。
- これはデスマーチではない
- 単に、見積り・計画・メンバー・設計などに大きな間違いがあるため、期間内・コスト内に目標としたシステムを完成する可能性が低い為、ハードな労働を強いられている状態。
- プロジェクトの後期に大幅なメンバーの追加などを行った結果、コミュニケーションパス数が爆発し、混乱が発生し、結果として非常にハードな労働を強いられる状態。
■真デスマーチの定義
改めて調べると、デスマーチの定義はこんな感じです(Wikipediaより)
- 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
- 与えられた期間が、常識的な期間の半分以下である
- エンジニアが通常必要な人数の半分以下である
- 予算やその他のリソースが必要分に対して半分である
- 機能や性能などの要求が倍以上である
- これはデスマーチである
- 公正かつ客観的にプロジェクトのリスク分析 (技術的要因の分析、人員の解析、法的分析、政治的要因の分析を含む) をした場合、失敗する確率が50%を超えるもの
- かつ、上記の状況に対して適切な対策を実施する前の状態
- これはデスマーチではない
- プロジェクトを成功させるために、不適切な労働を強いる状況 ( それは組織としてはダメですが、デスマというわけではない )
- よくわからないが、うまくいっていないプロジェクト
みんな「デスマ」「デスマ」と言いすぎだと思っています。
「お前らに本当のデスマーチを思い知らせてやる！」
これはうそです。私もこんなデスマーチには参加したことはありません。キツイプロジェクトはありますけどね。
Blogged with Flock
月曜日, 3月 10, 2008
システム開発上流工程における権威勾配
■権威勾配について
権威勾配とは、正確には「操縦室内権威勾配(Trans-cockpit Authority Gradient)」のことで、航空業界におけるクルーリソースマネジメント(CRM)に出てくる概念です。
CRMとは航空機パイロット(クルー)向けの学習プログラムで、『利用可能なすべてのリソースを、最適な方法で最も有効に活用することにより、クルーの トータルパフォーマンスを高め、より安全で効率的な運航を実現することを目的とする考えかた』という定義です。ITプロジェクトにおいても、チームのトー タルパフォーマンスを高める事は大きな課題なので、いろいろと参考になりそうなアイデアが詰まっているようです。詳細は下記の本などを参照ください。
で、権威勾配は何かと言うと、(飛行機が)安全な運行を確保するための操縦室内での権威の力関係のことになります。
- キャプテン（機長）、コーパイ（副操縦士）及びフライトエンジニア（航空機関士）間の勾配は大きくても小さくてもいけない。
- 適当な勾配を保てば、クルー間の自由なコミュニケーションが保たれ、航空機の運航もモニターも改善される。
- 勾配が急すぎると、コミュニケーションは減り、相互チェックが減じる。
- 勾配が浅すぎると、キャプテン（機長）が権利を行使できなくなる。
システム開発の上流工程(要求開発とか、要件定義など)においても、この権威勾配が重要なファクターではないだろうかと、最近考えています。主要な登場人物としての「ビジネスオーナー」「ユーザー(業務担当者)」「エンジニア（開発担当者）」の権威勾配が適切でない状態でシステムを開発すると、「使えないシステム」や「ビジネスに効かないシステム」が出来上がってしまうのではないか。
私も参加している要求開発のコミュニティでは、コタツモデルというメタファーを使って「ビジネスオーナー」「ユーザー(業務担当者)」「エンジニア（開発担当者）」の適切な関係を定義していますが、これをいかにして形成していくのか、について権威勾配の概念がピタっとはまるのではないか？
過去のシステム開発プロジェクトは、既存業務の自動化や情報化であり、比較的にシステム開発の着地点も見えやすかったのですが、これからのシステム開発は、より人間系を含め(技術的ではなく業務的に)複雑化していくと思います。
その中で成功確率を高めるためには、適切な権威勾配をステークホルダー間で構築し、コミュニケーションと相互チェックを実現していくべき、というのが私の意見です。
※蛇足
ちなみに、次回の要求開発アライアンス定例勉強会で「コタツモデル再考」というタイトルでお話させていただくことになりました。発表資料は本Blog等にもあとで掲載しますので、興味のある方はよろしくどうぞ。
金曜日, 3月 07, 2008
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
Pragmatic Bookshelf (2007/06/15)
売り上げランキング: 1092
というわけで、ちょっと調べてみました。
- The Pragmatic Bookshelfで少しだけ立ち読みできる。またPDF版を安く購入できる。
- モトDECで、現在YahooでDirectorをしている人が書いている。
- リスクベースで、ソフトウェア開発において意思決定をするためのガイドブック(と序文にある)。
- 実践的であることに注力しているっぽい。サンプルが読めるChap.4だと、ローテクツールでのスケジュール管理と題して、付箋を使ったスケジュール管理について書かれていたりする。
Blogged with Flock
水曜日, 3月 05, 2008
Googleドキュメントのプレゼンテーションで文字欠け
このあいだ、梅田望夫さんの「ウェブ時代をゆく」を読んだのですが、その中に出てくる「第5章 手ぶらの知的生産」が気に入っています。梅田望夫さんの言う「手ぶらの知的生産」とは、
- 物理的に「手ぶら」でも、情報にたどりつくことができるようになったということ
- 知的生活を送るために、膨大な蔵書などの物理資産を持たなくてもよくなった
さて、この本に感化されたわけではありませんが、最近個人的なノートや資料などは、自宅のローカルPCなどに保存するのではなく、Googleドキュメントで書き溜めるようにしています。これは「手ぶらの知的生産」ではありませんが、PCを持ち歩かずとも、随時自分の外部脳を取り出せるようにしておきたいためです。Googleドキュメントでは現在、ドキュメント・スプレッドシート・プレゼンテーションの3種類がサポートされているので個人的な書き物には不自由することはありません。
と、そのはずなんですが、どうやらプレゼンテーションには文字化けの問題が残っているみたいです。
回避策をいろいろと考えたのですが、どうやら無さそうな模様。
その問題とは、
- 特定の文字コード(具体的には、Unicodeの特定の文字(20592～20950)が、PDFには出力されない。
- おそらく、Google側のサーバにフォントが無い orz...
現在プレゼンテーションは、PDFかテキストファイルにしかエクスポートできないので困っちゃいますね。特に発表資料などを作成して、オフラインな会場に持ち出せないのが苦しいところ。
HTMLに書き出す等の裏技も探しましたが、今のところはなさそうです。
というわけで、とりあえずはGoogleのサポートにバグ報告しておきましたとさ。
Blogged with Flock
月曜日, 3月 03, 2008
ITシステムの導入で失われる知力について
前回のエントリでマインドマップまで書いて挫折してしまっていますが、ITシステムの導入で失われる知力に関する文章です。
ITシステムの導入は、その価値や生み出すものばかりに目がいってしまいがちですが、逆に失われるものもある、ということをよく考える必要があります。
■Google前後の世界
梅田望夫さんの有名な著書「Web進化論」を引くまでもないですが、Googleの出現によってわたしたちの知識に関する考え方は一変してしまいました。現在のわたしたちは、わからない事があれば考える前に検索するのです。結果として知識習得のためのコストが大きく下がった事はとても良いですが、逆に書籍などを読み、自分で考えるという力は低下しているような気がしています(これは個人的な主観です)。
■ITシステムとナレッジのトレードオフ
ITシステムを導入すれば、基本的には利用者はそのシステムによって処理能力を引き上げられ、今まで人間ではできなかったほど高度な分析や処理ができるようになります。システムにチェックロジックなどを組み込むことにより作業は平準化され、ミスが防止されるようになります。しかし、こういったメリットを享受した場合、同時に失っているものもあるのではないでしょうか？
- 遂行能力の引き上げ vs 能力そのものの低下
今までは、行うべきこと(たとえば、見積り書の作成)のために、たくさんの物事(考え方やルール)を知る必要がありました。しかし、システム化してしまうことにより、そういった知識が無くてもそれなりの処理ができるようになります。結果として、利用者の能力そのものは下がってしまう事があります。
- 処理の平準化 vs 工夫力の低下
システムを導入すれば、たくさんの仕事をシステムを活用して(何も考えずに！)処理できるようになったりします。また、処理は定型化/汎用化されているので、システムが示すとおりに入力すればすむようになったりします。今までは「能力の高い人は精度高く、能力の低い人は精度低く」だったのが平準化されます。しかし、これは、能力の高い人についても平均的な作業レベルまでしかさせない、という事にもなります。結果として、個々人が工夫をしたりする力が減ることがあります。
- 処理の高度化 vs ブラックボックス化
今までは想像もできないような非常に複雑な処理も、システム化することによってできるようになります。しかし、逆に業務の一部がブラックボックス化してしまい、誰にも理解できないという事になりがちです。ちなみに構築当初は精通していた人がいても、その後担当者が異動してしまいシステムが変更できないというのも、よくはる話です。
- 処理スピードアップ vs コミュニケーションの減少
システム導入により、今までは人間系でおこなっていた作業がスムーズに、スピードアップしてできるようになります。しかし、当然のことながら、コミュニケーション量も減っていきます。いままではコミュニケーションによって防止されていた作業の落とし穴が露呈したり、全体的な利用者のモチベーションが下がるということも発生する可能性があります。
得てしてITシステムの導入は、その正の価値ばかりばピックアップされます。なんといっても人は新しいものに期待をしてしまいがちです。しかしITシステムは企業やビジネスのインフラでもあります。上記のような観点で、負の影響についても(前向きに)意識し、議論をすることによって、防止したり縮小することができるのではないでしょうか？
Blogged with Flock
水曜日, 2月 27, 2008
ITシステム導入のポジティブな影響とネガティブな影響
仕事がらITシステムの導入に関係することが多いのですが、ITシステムの導入はビジネスにポジティブな影響を与えるだけではなく、同時にネガティブな影響も与えます。システム構築に際してはポジティブな影響(例「1日3000件の処理を可能とする」)をゴールとする事が多いのですが、ネガティブな影響についてはあまり論じられないような気がしています。
というわけで、ちょっと考えてみたのですが･･･図まで作って力尽きたので、次回につづく。
ちなみに今週の月曜日は、PFP関東ワークショップに参加してきました。今回もいろいろな気づきがあったのですが、ワークショップの内容はpapandaさんのBlogが詳しいので省略します。
水曜日, 2月 20, 2008
SHELLモデル
前回のエントリに引続き、クルーリソースマネジメント(CRM)の話題です。
本書の中で紹介されているSHELLモデルが個人的にはとても気に入っています。というわけで、今回はSHELLモデルに関する話です。
SHELLモデルとは、KLMオランダ航空のパイロットであるHawkinsさんが提唱したもののようです。分野としては、人間工学(ヒューマンファクター工学)で論じられるものらしい。
- 中心のL = Liveware すなわち人間
- S = Software 作業手順や規則、規定のたぐい等
- H = Hardware 関連する機械、設備、使用機器、道具等
- E = Enviroment 物理的環境(空調、照明、騒音等)だけではなく、気象現象や社会環境など、仕事や行動に影響を与えるすべての環境を含めて考える
- L = Liveware あなたが接しなければならない、あなた以外の人。対人関係
- それぞれの要素が噛みあっていない箇所では、ヒューマンエラーが発生する。
このSHELLモデルは出自の関係からか、航空分野を中心にしか利用されていないようです。
ITシステム開発では、関連する話題として、次のようなものが個別にありますが、現時点では統合的な捉え方がされていないように考えています。
- アジャイル開発のプラクティスでは、人と人および、人と道具(SHELLにおけるHardware)の関係を中心に論じている (ex.「プロセスやツールよりも、人と人との交流を」「アジャイルツール(Wiki,バージョン管理,ユニットテスト,ビルドの自動化)の活用」)。
- プロジェクトファシリテーションでは、人と人(プロジェクトチーム)の生産性の最大化を中心に論じている。
- 開発プロセス論やテスト方法論では、規約(SHELLにおけるSoftware)による作業管理や品質保証について論じている。
- ピープルウェアといった書籍等は、物理的環境(SHELLにおけるE)と、人との関係について論じている。
というわけで、次にプロジェクトを立ち上げる時には、SHELLモデルを中心に計画を行おうと考える今日この頃です。
登録:
投稿 (Atom)
