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