今朝は雨模様の長野県飯綱町です。
昨日、今日とストーブ無し、部屋の中でもコート・ジャンパー無し(笑)で快適に過ごせる気温です。暖かくなりましたね。
さて、本日は、昨日書いたGTDのことについて、あまり一般的なビジネス書では書かれていない、しかし非常に重要だと思っていることについて書きたいと思います。
そもそもGTDのようなタスク管理を実践する、もしくは実践したい目的というのはなんなのでしょうか？
「仕事を効率化したい」
「よりデキルビジネスパーソンになりたい。」
「収入を増やしたい」
「家族と過ごす時間を増やしたい」
e.t.c..
人はそれぞれ、いろんな考え方、価値観、きっかけから、『今のままではいけない』という衝動に突き動かされて、新しいメソッドに取り組むはずです。
しかし、これら様々な考え方・価値観を、ぐぅ〜んと抽象度を上げて眺めてみると、それはみな「より良い、幸せな人生を生きたい。」この一言に集約されるのではないでしょうか。
現状をより良くしたい、だから現状を変えたい、現状を変えたいから、新しいツールやメソッドを身につけたいという流れは、GTDに限らず、意欲を持って、なにか新しいことに取り組む際には、必ず心のなかにあると思います。
しかし、こういったタスク管理系のツール・メソッドは、その本質の部分を忘れて、「タスク管理をすることが目的化」してしまうと、当初の目的であった「より良い幸せな人生を贈りたい。」という目的にまで辿りつけなくなるというのが、個人的な体験談から思っていることです。
私も過去、ポスト・イットを使ったタスク管理や、７つの習慣の手帳術、その他著名ビジネスパーソンが推奨する手帳術等、たくさんの「人生コントロールツール」にトライしてきました。（そしてそのたびに挫折してきました。 orz）
たくさんのタスク管理手法を試してきた私が、GTDを実践する上で気を付けていることが、「必要以上にタスク管理を完璧にやらない。」という事です。
常に、車のハンドルでいう『遊び』をつくっておくわけですね。
ただし、車と同じで、全てに遊びを作っていいというわけではありません。
どこに遊びを作って、どこを精密にしておくかについては、車と同様に大事なことだと思います。
そこで私が実践しているのが、「嫌いな仕事は精密に・好きな仕事にはたっぷり遊びを」という管理手法(?)です。
例えば私の場合、嫌いな仕事というのが、領収書の入力であったり、書類の整理であったり、引き出しの整理であったりといった、あまりクリエイティブでない仕事。
こういった仕事は放っておくと、どんどん溜まってしまう傾向にあります。
そしていざ、これらの仕事に着手しようとしても、モチベーションが上がりません。
なんとなくネットに逃げたり、ダラダラとやっているうちに、３０分で終わる仕事が、すぐ１時間ぐらい過ぎてしまいます。
こういった自分の嫌いな仕事、不得意な仕事には、明確に締切りを設けて、出来ればタスクを１５分単位ぐらいにまで細分化して、小さなゴールをたくさん設定することで、モチベーションを上げるようにしています。
これにはGTD、そしてFreeMindがすごく役に立ちます。
逆に自分が大好きな仕事、例えば企画書を書いたり、システム設計をしたり、プログラミングをしたりなどのクリエイティブな仕事、創造性のある仕事については、できるだけ締切りを設けず、仕事も細分化しないようにしています。
理由は、自分が好きな仕事をしている時間は、フロー状態に入りやすい状況をできるだけつくるためです。
フロー状態については、書くと長くなってしまうので、wikipediaをご参照ください。
フロー：http://ja.wikipedia.org/wiki/%E3%83%95%E3%83%AD%E3%83%BC
フローに入るためにまず何よりも必要なのが、リラックス状態にあること。
なので、細かいゴールや細分化されたタスクは、かえってリラックス状態を作るのに、邪魔になるのです。
自動車でドライブをしているときに、５分おきに目的地がくるよりも、２・３時間のあいだ、楽しく運転している方がリラックス出来ますよね。
それと同じ原理です。（ちょっと強引？）
そしてリラックス状態をつくるためにもう一つ大事なことが、他に気になる未完了な仕事が可視化されていることです。これにはGTDが役に立ちます。
大好きな仕事をしている時でも、自分があまりやりたくない仕事が潜在的に頭の中にモヤモヤしていると、どうしてもリラックスした集中状態に入ることが出来ません。
なので、やりたくない仕事（出来れば先延ばししたい仕事：笑）は、できるだけ細かく、細分化して、見える状態にしておくことが大事なのです。
よって、「嫌いな仕事は精密に・好きな仕事にはたっぷり遊びを」という結論にたどりつき、またこの姿勢を実践していくなかで、効果を実感できている状態です。
纏めると・・・
・GTDを含めたタスク管理に取り組む上で大事なことは、その目的を常に意識すること。
・タスク管理そのものが目的化すると、必ず挫折する。
・タスク管理が苦しくなってきたら、なんのためにそれをやっているのか、その目的に立ち返ることが重要。
・必要以上に細かいタスク管理は、フロー状態を阻む。
・人間が最高のパフォーマンスを発揮できるのは、フロー状態にあること。
・タスクの特色や「主観的な好き・嫌い」で、細分化レベルをコントロールすることが望ましい。
こんな感じになると思います。
ちなみに、私はこのように自分が思っていることを文章にするのも大好きな仕事のひとつです。
なので、いつもとりとめのない長文になってしまうんですね〜
もう少し文章が上手に書けるようになりたいものです。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2011年4月9日土曜日
2011年4月8日金曜日
GTDタスク管理とサポートツール
ずいぶんと久しぶりの更新になりました。
最近FaceBookをはじめたのですが、FaceBookのノート機能がブログに近いということでしたので、そちらにはちょこちょこと投稿をしておりました。
まだイマイチ、ブログとFaceBookの住み分けが出来ていない私なので、いっときは双方に投稿してみようかと思います。
さて、今回はタスク管理に関する話題です。
ズボラの神さまから『分け御霊』をいただいて生まれてきた私としては、日々のタスク管理・ToDo管理が人生において解決すべき大きなテーマのひとつです。
このテーマに取り組んでいく中で、GTDという手法に出会いました。
私はこちらの本を読んではじめて『GTD』を知ったのですが、下記のWebサイトにも理論と実践をおりまぜた形の極めて分かりやすい情報が掲載されています。
ご興味をもたれた方はまずWebサイトをじっくりと読み込むことをおすすめします。
GTD関連の書籍
はじめてのGTD ストレスフリーの整理術：http://amzn.to/hFCCbh
ストレスフリーの仕事術―仕事と人生をコントロールする52の法則：http://amzn.to/g46to2
Webサイト
はじめてのGTD ： http://bit.ly/85aPEe
私がGTDを本格的に取り入れ始めたのはここ２ヶ月ぐらいですが、ようやく使いこなせるレベルになってきたという実感が持てるようになりました。
その『使いこなしている感』を感じている最大の理由のひとつが、GTDを実践する上でのツール群が手元に揃ったという感覚です。
GTDの特徴として、『ツールを選ばない』というのがあります。
これは柔軟性があって良いことなのですが、逆を言うと、自分の手に合うツールは自分で見つけなければならないということです。
そして私が様々な方法にトライして、ようやくたどり着いたのが次のツールたちです。
①FreeMind
②iPad
③iThoughts HD
④DropBox
⑤ScanSnap
⑥GoogleCalendar/GMail
ここから先はGTDの５ステップに準えて、各ツールをどう使うのか、書いていきたいと思います。
【ステップ１：収集】
このステップは、とにかく今頭の中にあるモヤモヤを、見える化することが目的になります。
一般的にブレインダンプなんてよばれるステップです。
私はこのステップでFreeMindを使います。
FreeMindはなんちゃってマインドマップを書くツールとして、私の周りではかなり普及しているツールです。
っというよりも、私が無理やり進めているという実態があるようです・・・
このFreeMindに、まず頭の中にある全てのもやもや（未完了タスク）を書き出します。
【ステップ２：整理】
ここで一気に吐き出したモヤモヤを、GTDのルールにしたがって、仕分けしていきます。
仕分けももちろんFreeMind上で行います。
FreeMindの良いところは、ひとまずばぁ～っとブレインダンプしたあと、それを構造化するのが極めて簡単だということです。
手書きのマインドマップだと、出すところ（発散）まではできるのですが、それを構造化（収束）させるために、もう一度別のマインドマップを書く必要があります。
しかしFreeMindなら、ブランチをグリグリと動かすだけで、サクっと構造化することが可能です。
未完了タスクの構造化が終了したら、次にそれらのタスクを完了するために必要な時間を見積もり、それを各タスクにラベリングしてきます。
私はこれにもFreeMindを使っています。
ラベリングは、FreeMindのVer0.9.0から使えるようになった「属性マネージャ」を使っています。
属性マネージャは、そのUIが極めて分かりづらいので、使いこなしている方がどれほどいるのか疑問なのですが、使い慣れるとこれほど便利なものはありません。
後日、属性マネージャの使い方についてもアップしてみたいと思いますが、ひとまず未完了タスクに、「５分以内」「３０分以内」「１時間以内」「半日以内」「１日以内」「１日以上」といった、ラベリングをするとだけ書いておきます。
こうやって属性マネージャを使ってラベリングをしておくと、吐き出した数十の未完了タスクから、５分以内に終了できる物だけをサクっとフィルタリングして表示させることができます。
この機能を使うと、ちょっとした空き時間が、５分以内に終了できるタスクを消化できる時間に代わります。
また、１日以上というラベルの付いたタスクは、まだその仕事の内容が十分に吟味されていない、つまり細分化が不完全という事なので、そのみ完了タスクに小ブランチをバンバンぶら下げて、仕事の内容を細分化していきます。
出来れば全てのを１位時間以内に出来ることまで細分化していきます。
細分化ができたら、それぞれの小ブランチに、同じく属性マネージャを使って、見積もり時間をラベリングしてきます。
こうして仕事を細分化すると、俄然、「未完了タスクの攻略」というミッションに、モチベーションが上がってきます。
さて、ここまでFreeMindをタスク管理に使っていると、当然FreeMindで作成したこの未完了タスクリストを持ち歩きたくなります。
そこで活躍するのが、iPad+iThoughts HD+DropBoxです。
iPadとDropBoxに関する説明はもはや必要ないほど普及していると思っていますので、ちょっとマニアックなiOSアプリである『iThoughts HD』だけ補足します。
これは、iPadでMindMapを書くことができるiOSアプリなのですが、PCで作成したFreeMindファイルをiPadで読み込み・編集ができるというスグレモノ。
DropBoxと組み合わせることにより、PCで作成したタスクリストをiPadでも読み書きできるようになります。
これがGTDを継続利用する上で、極めて重要な要素になります。
GTDを継続するうえで、重要な要素として、タスクリストがいつでも・どこでも参照可能・編集可能ということが挙げられると思います。
【ステップ３：整理】
ステップ３では、書き出したリストをそれぞれ自分の使い慣れたツールに落とし込んでいくというフェーズになります。
一般的には、このタスクリストを手書きメモやGMail/GoogleCalendar、RememberTheMilkなどのタスク管理ソフトに『転記』するというというのが具体的な作業になります。
私はここで、GoogleCalendarと、FreeMindのカレンダー・リマインド機能を「併用」しています。
ミーティング・出張等、ひとかたまりのタスクが数時間になるような予定、もしくは携帯メールにリマインドを飛ばしたいような締切りを持つようなタスクは、GoogleCalendarに転記し、それ以外の締切り管理はFreeMindで行っています。
最初は、締切り設定しているタスク全てGoogleCalendarへ転記していたのですが、これではあまりにも非効率ですし、作業量も膨大になります。
正確性よりも継続性を重視した結果、最低限の転記のみにしています。
その分、いつでもどこでもFreeMindが見れることが重要になってくるわけです。
【Step4：レビュー】
レビューの目的は、個人的に２つの役割を持たせています。
ひとつは優先順位変更や作業量ラベリングの付け直し、ひとつはアイデア出しです。
前者の「優先順位変更や作業量ラベリングの付け直し」は、書いて字のごとく、一度設定した優先順位、作業時間ラベルを、セルフレビューして付け直す作業です。
特に、人間は作業時間を見積もるのが下手です。
例えば、１日かかると思っていた作業が半日もかからず終了したり、２時間で終わると思っていた作業が、１日かかったりということはザラにあるのではないでしょうか？
未完了タスクを３０だして、それらすべての作業時間を正確に見積もってラベリングするのは至難の業です。
なので、直近の作業実績を勘案して、作業時間の見直しを行うのは非常に重要です。
そして後者の『アイデア出し』ですが、これは「今ある未完了リストをできるだけ早く終わらせるには？」や、今手がけている仕事から新しい仕事のアイデアは？っといった、発想の時間になります。
これには、あえて「手書き」のマインドマップを使っています。
発想を促すには右脳さんに活躍していただく必要があるのは既に常識になりつつあるのですが、その右脳を活性化するひとつの方法が手書きによるマインドマップです。
手書きであれば、図・イラスト等を多用することができます。
コンピュータを使ったマインドマップは、この部分が不得意なので、イメージを使った発想が必要な場合においては、あえて手書きのマインドマップを書くようにしています。
書いたマインドマップは、ScanSnapでスキャニングし、PDF化してDropBoxに放り込んでおきます。
以前はEverNoteを使っていたのですが、個人的にこのツールはどうしてもしっくりこないので、今は使っていません。
【ステップ５：実行】
あとはゴリゴリと仕事を片付ける。
片付けた仕事は、FreeMindから消すのではなく、別の完了MMを作成しておき、そちらに移していきます。
こうすることで、いつ何を完了させたのかがログで残ることになります。
以上、GTDの実践と、それをサポートするツールについて書いてみました。
書いている中で、もう少しブラッシュアップできそうな部分も見つかりましたので、そのあたりのアイデアも追々書いていきたいと思います。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2010年10月6日水曜日
IT業界のネガティブ7K・ポジティブ7K
久々のブログ投稿です。
こちら長野県飯綱町はすっかり晩秋のような涼しさで、早朝は白い息が普通になってきました。
お隣の妙高では、既に窓ガラスが凍っている地域があるようです。
これって私が生まれ育った宮崎だと「冬」と呼ぶのですが・・・（笑）
っということで、本題に入って生きたいと思います。
先日、サポートさせていただいているファザーリングジャパン(FJ)が主催した、ITパパママ育休セミナーに参加してきました。
ちょうど東京出張と絡めることができ、久々にFJ活動を楽しんできました。
そこでIT業界にかれこれ２０年いる私が始めて聞く言葉が出てきました。
どうもIT業界には「７K」というものがあるらしい。
その内訳を見てみると・・・・
は、初めて聞いた・・・
正確にはなんとなく聞いたことはあったのですが、さして記憶にも残らずスルーしていた感じです。
なぜなら私はITの仕事が大好きなので、この全てが当てはまらないんですね。
会社員時代から、自分の仕事に対してこんな７Ｋな印象を持ったことは無かったですし、会社員を辞めてフリーランスになった今にいたっては、これとはまったく無縁の「IT業界ライフ」を送っています。
個人的なIT業界の新・ポジティブ７Ｋは・・・
っといったところでしょうか？
５分ぐらいで思いついたものをパッと書きましたが、これはもう少し検証の余地がありますね。
最後の１句は個人的なものですし・・・（笑）
しかし、なぜ同じIT業界にいながら、これほどまで差が出るのでしょうか？
やはり、その根本にあるのは、この仕事が「好きか・嫌いか」にあるのだと思います。
「いや、７Ｋだから嫌いなんだ！」なんて声も聞こえてきそうですが、ここはSEであれば冷静に考えて見ましょう（笑）
そもそもなぜまったく同じ職場環境や業界にいながら、その状況をネガティブ7Kで捕らえる人と、ポジティブ7Kで捕らえる人がいるのでしょうか？
もちろんどちらの要素にしても、複合的な要因があると思います。
個人の資質の問題、会社組織の問題、通勤条件、給与条件など様々な要因が重なってネガティブな7Kになってしまうのでしょう。
中でも私は、「個人の資質」が最も大きいウェイトを締めているのではないかと思います。
多分、IT業界に関わらず仕事で高いパフォーマンスを発揮する人は、例外なくその仕事が好きな人たちのはずです。仕事が嫌いで嫌いでしょうがないんだけど、なぜか仕事のパフォーマンスは高いという人はほとんどいないはずです。
私の言う「資質」とは、俗に言う定量的に測定されるような潜在能力、例えば論理思考能力やコミュニケーション能力、文章力などではなく、単純にその仕事が「好きか・嫌いか」というそれ一言に尽きると思っています。
好きであれば資質が高い、嫌いなら資質が低いというところです。
そういえば京セラを起業された稲盛さんが、仕事の能力というのは「熱意」×「能力」×「考え方」で決まるということをおっしゃられていますが、「好き・嫌い」という資質は、これらに直接起因する、１レイヤー上の概念であると思ってよいと思います。
その仕事が好きであれば、熱意はもちろん高いレベルに維持されるでしょう。
その仕事が好きであれば、上達欲も高くなるので一生懸命能力を高めようとするでしょう。
その仕事が好きであれば、その仕事で得られた能力を世の中の役に立たない、私利私欲だけを満たす道具として使うなんて悪どいことは考えないでしょう。
こう考えると、仕事こそ「好き・嫌い」で選ぶべきなのにと思います。
こと仕事になると「好き・嫌いで判断してはいけない」といった風潮があるのは、個人的にどうしても不思議でなりません。
仕事は「好き・嫌い」で選ぶべきなのです。
はい。
そして、ここで多くの人がぶつかるのが、「何が好きなのか解からない・・・」という壁ではないでしょうか？
この壁は相当高く、そう簡単に「自分が好きなものはこれだったんだ！」という天職の入った宝箱に出会える人はそうそういるものではありません。
大よそ最初のうちは、人食い箱やミミックに出会ってしまうものです（笑）
しかし、極めて合理的な方法でその宝箱にたどり着く方法論があることも、また事実です。
その方法は・・・
後日のお楽しみということで（笑）
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
こちら長野県飯綱町はすっかり晩秋のような涼しさで、早朝は白い息が普通になってきました。
お隣の妙高では、既に窓ガラスが凍っている地域があるようです。
これって私が生まれ育った宮崎だと「冬」と呼ぶのですが・・・（笑）
っということで、本題に入って生きたいと思います。
先日、サポートさせていただいているファザーリングジャパン(FJ)が主催した、ITパパママ育休セミナーに参加してきました。
ちょうど東京出張と絡めることができ、久々にFJ活動を楽しんできました。
そこでIT業界にかれこれ２０年いる私が始めて聞く言葉が出てきました。
どうもIT業界には「７K」というものがあるらしい。
その内訳を見てみると・・・・
- きつい
- きびしい
- 帰れない
- 給料が安い
- 休暇が取れない
- 結婚できない。
- 子供がつくれない
は、初めて聞いた・・・
正確にはなんとなく聞いたことはあったのですが、さして記憶にも残らずスルーしていた感じです。
なぜなら私はITの仕事が大好きなので、この全てが当てはまらないんですね。
会社員時代から、自分の仕事に対してこんな７Ｋな印象を持ったことは無かったですし、会社員を辞めてフリーランスになった今にいたっては、これとはまったく無縁の「IT業界ライフ」を送っています。
個人的なIT業界の新・ポジティブ７Ｋは・・・
- 賢くなれる
- 給料が高い
- 個人で勝負できる
- コミュニケーションが得意になる
- 喰いっぱぐれがない
- かっこいい
- 高卒でも勝負できる：笑
っといったところでしょうか？
５分ぐらいで思いついたものをパッと書きましたが、これはもう少し検証の余地がありますね。
最後の１句は個人的なものですし・・・（笑）
しかし、なぜ同じIT業界にいながら、これほどまで差が出るのでしょうか？
やはり、その根本にあるのは、この仕事が「好きか・嫌いか」にあるのだと思います。
「いや、７Ｋだから嫌いなんだ！」なんて声も聞こえてきそうですが、ここはSEであれば冷静に考えて見ましょう（笑）
そもそもなぜまったく同じ職場環境や業界にいながら、その状況をネガティブ7Kで捕らえる人と、ポジティブ7Kで捕らえる人がいるのでしょうか？
もちろんどちらの要素にしても、複合的な要因があると思います。
個人の資質の問題、会社組織の問題、通勤条件、給与条件など様々な要因が重なってネガティブな7Kになってしまうのでしょう。
中でも私は、「個人の資質」が最も大きいウェイトを締めているのではないかと思います。
多分、IT業界に関わらず仕事で高いパフォーマンスを発揮する人は、例外なくその仕事が好きな人たちのはずです。仕事が嫌いで嫌いでしょうがないんだけど、なぜか仕事のパフォーマンスは高いという人はほとんどいないはずです。
私の言う「資質」とは、俗に言う定量的に測定されるような潜在能力、例えば論理思考能力やコミュニケーション能力、文章力などではなく、単純にその仕事が「好きか・嫌いか」というそれ一言に尽きると思っています。
好きであれば資質が高い、嫌いなら資質が低いというところです。
そういえば京セラを起業された稲盛さんが、仕事の能力というのは「熱意」×「能力」×「考え方」で決まるということをおっしゃられていますが、「好き・嫌い」という資質は、これらに直接起因する、１レイヤー上の概念であると思ってよいと思います。
その仕事が好きであれば、熱意はもちろん高いレベルに維持されるでしょう。
その仕事が好きであれば、上達欲も高くなるので一生懸命能力を高めようとするでしょう。
その仕事が好きであれば、その仕事で得られた能力を世の中の役に立たない、私利私欲だけを満たす道具として使うなんて悪どいことは考えないでしょう。
こう考えると、仕事こそ「好き・嫌い」で選ぶべきなのにと思います。
こと仕事になると「好き・嫌いで判断してはいけない」といった風潮があるのは、個人的にどうしても不思議でなりません。
仕事は「好き・嫌い」で選ぶべきなのです。
はい。
そして、ここで多くの人がぶつかるのが、「何が好きなのか解からない・・・」という壁ではないでしょうか？
この壁は相当高く、そう簡単に「自分が好きなものはこれだったんだ！」という天職の入った宝箱に出会える人はそうそういるものではありません。
大よそ最初のうちは、人食い箱やミミックに出会ってしまうものです（笑）
しかし、極めて合理的な方法でその宝箱にたどり着く方法論があることも、また事実です。
その方法は・・・
後日のお楽しみということで（笑）
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2010年9月20日月曜日
FreeMindですいすいユースケース分析
今日は朝から雨の飯綱町です。
既に半そででは肌寒い感じで、あと１ヶ月もすればこたつと薪ストーブが恋しくなる季節になります。
今年は猛暑で早く涼しくならないかと思っていたのですが、いざ夏が過ぎるとあっという間に冬支度の北信州です。
さて、今日も上流工程ネタで行きたいと思います。
先日、上流工程の情報は全てFreeMindにまとめなさい的な記事を書きましたが、今日はその続編ということで、FreeMindをどのように上流工程で使うかについて書きたいと思います。
上流工程で記述するドキュメントは前回の投稿でも書いたとおりですが、FreeMindが活躍するのは何といってもユースケース分析の時です。
ユースケース分析で記述するドキュメントは、ユースケース図とユースケース記述書があります。
私はユースケース図をAstahProfessionalで、ユースケース記述書はFreeMind0.9.0で書いています。
もちろん統合開発ツールであるAstahProfessionalにもユースケース記述書を書く機能は搭載されているのですが、ユースケース記述書が８割以上完成するまでは、AstahProfessionalの機能は使わず、FreeMindを使っています。
FreeMindをつかう理由は主に３つあります。
ひとつめは、FreeMindのほうが情報をスピーディーに構造化しやすいことです。
確かにAstahのユースケース記述書機能は、下記のように構造化された記述フォームが用意されています。
しかし、エンドユーザからヒヤリングしたてで明確な構造が見えていない状況において、いきなり形式化されたフォームにイベントフローなどを記述するのは、記述の目的と効率化の観点からあまりお勧めできるものではないと思います。
それよりも、FreeMindのようなツールで「まず明確なところから」そして「書きやすいところから」書くほうが、仕事ははるかに分析しやすく、そして仕事も速くなります。
ユースケースは記述することが目的ではなく、業務とシステムの境界線、プロジェクトのスコープを明確にし、業務全体を構造化することが目的のはずです。
そういう目的に立ち返ると、ユースケース記述書はあくまでも分析結果・構造化の結果を書くものであり、分析・構造化の過程を記述するには向いていないことが解かります。
なによりもきっちりと書式が整った書類に書くときのデメリットは、記述しながらわからないことや疑問点が出てきたら、そこで仕事が止まってしまうということです。
ここで仕事の生産性が落ちてしまいます。
もちろん、わからない部分をペンディングにして、それ以降を書き続けることもできるでしょう。
しかし、心理的にも人間の脳の特性的にも、完璧にフォーマットされた書類に、「中途半端」な状態で文書を保存しておくのは、なんだか気持ちの悪いものです。
その点、FreeMindでの記述だと、書式化されたものではないので、解からない部分はそのままにしておき、わかる部分からスイスイ書いていくことができます。
そしてわからない部分には、0.9.0から登場した強力な機能である「属性」機能でマーキングしておき、「フィルタ」を使って、漏れなく調査やヒヤリングすることができます。
そしてこの属性とフィルタ機能が使えることが、FreeMindをつかう２つ目の理由です。
FreeMindはバージョンが0.9.0になって「属性」と「フィルタ」という強力な機能が追加されました。
属性機能とは、ブランチに構造化されたタグをつける機能です。
例えば、経理部門に提供するサービスのユースケースを記述しているときに、ふと疑問点やヒヤリングが十分でない箇所が出てきたとします。
そういうときに、【要ヒヤリング / 経理部】という属性をブランチにつけておき、具体的な質問事項をブランチのノートとして記述しておきます。
そしてフィルタ機能で、全てのブランチから【要ヒヤリング="経理部"】という属性(タグ)のついたブランチのみをフィルタします。
こうすることで、ヒヤリング項目を効率的に管理することができます。
ちなみにこれには副次的な効果があります。
フィルタ機能は、単純にそのブランチのみを抽出するのではなく、上位ブランチと下位ブランチを表示することができます。
この機能により、その質問・疑問がどういった関連性を持っているのかをひと目で確認することができるのです。
Excelなどでヒヤリング台帳や質問台帳を管理し、それをもとにヒヤリングを実施すると、時に「自分はなぜこんな疑問を持ったのだろう？」と質問・疑問の「意図」や「本質」を忘れることはありませんか？
こういった質問・疑問の意図や本質というのはなかなか言語化しずらく、多くは記憶にイメージとして残っています。
このイメージを如何に効率よく引っ張り出せるかで、ヒヤリングの質というのはまったく変わるのですが、FreeMindをつかうと、MindMapがもつフィードバック効果を得ることができるので、ヒヤリングの質が飛躍的に向上するのです。
いかがでしたでしょうか？
FreeMindの0.9.0から実装された属性とフィルタの機能を使うと、こういったメモ以外にも様々な使い道があります。
「属性」はブランチで関連付けられている関係性とは別の視点・評価基準における関係性をブランチに付与することができます。
そして何よりもこの属性がに階層構造を持たせることができるのがすばらしい。
今回の例では、以下のような構造を作りました。
▼要ヒヤリング
│
├→経理部
│
これで２次元構造であったマインドマップが、立体的・３次元的な構造になり、より複雑な情報を効率的に管理することができます。
できればこの機能は本家のiMindMapにも実装してほしいところですが、恐らくトニーのおじさんから「そんなもんはマインドマップじゃない！」と一喝されそうですね（笑）
しかし、この機能はシステム開発の現場、特に情報が抽象的な上流工程では、その抽象的な情報を構造化するにあたって極めて有益な機能です。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
既に半そででは肌寒い感じで、あと１ヶ月もすればこたつと薪ストーブが恋しくなる季節になります。
今年は猛暑で早く涼しくならないかと思っていたのですが、いざ夏が過ぎるとあっという間に冬支度の北信州です。
さて、今日も上流工程ネタで行きたいと思います。
先日、上流工程の情報は全てFreeMindにまとめなさい的な記事を書きましたが、今日はその続編ということで、FreeMindをどのように上流工程で使うかについて書きたいと思います。
上流工程で記述するドキュメントは前回の投稿でも書いたとおりですが、FreeMindが活躍するのは何といってもユースケース分析の時です。
ユースケース分析で記述するドキュメントは、ユースケース図とユースケース記述書があります。
私はユースケース図をAstahProfessionalで、ユースケース記述書はFreeMind0.9.0で書いています。
もちろん統合開発ツールであるAstahProfessionalにもユースケース記述書を書く機能は搭載されているのですが、ユースケース記述書が８割以上完成するまでは、AstahProfessionalの機能は使わず、FreeMindを使っています。
FreeMindをつかう理由は主に３つあります。
ひとつめは、FreeMindのほうが情報をスピーディーに構造化しやすいことです。
確かにAstahのユースケース記述書機能は、下記のように構造化された記述フォームが用意されています。
しかし、エンドユーザからヒヤリングしたてで明確な構造が見えていない状況において、いきなり形式化されたフォームにイベントフローなどを記述するのは、記述の目的と効率化の観点からあまりお勧めできるものではないと思います。
それよりも、FreeMindのようなツールで「まず明確なところから」そして「書きやすいところから」書くほうが、仕事ははるかに分析しやすく、そして仕事も速くなります。
ユースケースは記述することが目的ではなく、業務とシステムの境界線、プロジェクトのスコープを明確にし、業務全体を構造化することが目的のはずです。
そういう目的に立ち返ると、ユースケース記述書はあくまでも分析結果・構造化の結果を書くものであり、分析・構造化の過程を記述するには向いていないことが解かります。
なによりもきっちりと書式が整った書類に書くときのデメリットは、記述しながらわからないことや疑問点が出てきたら、そこで仕事が止まってしまうということです。
ここで仕事の生産性が落ちてしまいます。
もちろん、わからない部分をペンディングにして、それ以降を書き続けることもできるでしょう。
しかし、心理的にも人間の脳の特性的にも、完璧にフォーマットされた書類に、「中途半端」な状態で文書を保存しておくのは、なんだか気持ちの悪いものです。
その点、FreeMindでの記述だと、書式化されたものではないので、解からない部分はそのままにしておき、わかる部分からスイスイ書いていくことができます。
 |
| FreeMindで構造化したユースケース記述書 |
そしてわからない部分には、0.9.0から登場した強力な機能である「属性」機能でマーキングしておき、「フィルタ」を使って、漏れなく調査やヒヤリングすることができます。
そしてこの属性とフィルタ機能が使えることが、FreeMindをつかう２つ目の理由です。
FreeMindはバージョンが0.9.0になって「属性」と「フィルタ」という強力な機能が追加されました。
属性機能とは、ブランチに構造化されたタグをつける機能です。
 |
| ブランチに属性（タグ）を追加する。 |
例えば、経理部門に提供するサービスのユースケースを記述しているときに、ふと疑問点やヒヤリングが十分でない箇所が出てきたとします。
そういうときに、【要ヒヤリング / 経理部】という属性をブランチにつけておき、具体的な質問事項をブランチのノートとして記述しておきます。
そしてフィルタ機能で、全てのブランチから【要ヒヤリング="経理部"】という属性(タグ)のついたブランチのみをフィルタします。
 |
| フィルタの定義 |
 |
| ブランチをフィルタした結果 |
こうすることで、ヒヤリング項目を効率的に管理することができます。
ちなみにこれには副次的な効果があります。
フィルタ機能は、単純にそのブランチのみを抽出するのではなく、上位ブランチと下位ブランチを表示することができます。
この機能により、その質問・疑問がどういった関連性を持っているのかをひと目で確認することができるのです。
Excelなどでヒヤリング台帳や質問台帳を管理し、それをもとにヒヤリングを実施すると、時に「自分はなぜこんな疑問を持ったのだろう？」と質問・疑問の「意図」や「本質」を忘れることはありませんか？
こういった質問・疑問の意図や本質というのはなかなか言語化しずらく、多くは記憶にイメージとして残っています。
このイメージを如何に効率よく引っ張り出せるかで、ヒヤリングの質というのはまったく変わるのですが、FreeMindをつかうと、MindMapがもつフィードバック効果を得ることができるので、ヒヤリングの質が飛躍的に向上するのです。
いかがでしたでしょうか？
FreeMindの0.9.0から実装された属性とフィルタの機能を使うと、こういったメモ以外にも様々な使い道があります。
「属性」はブランチで関連付けられている関係性とは別の視点・評価基準における関係性をブランチに付与することができます。
そして何よりもこの属性がに階層構造を持たせることができるのがすばらしい。
今回の例では、以下のような構造を作りました。
▼要ヒヤリング
│
├→経理部
│
├→総務部
│
└→経理部
これで２次元構造であったマインドマップが、立体的・３次元的な構造になり、より複雑な情報を効率的に管理することができます。
できればこの機能は本家のiMindMapにも実装してほしいところですが、恐らくトニーのおじさんから「そんなもんはマインドマップじゃない！」と一喝されそうですね（笑）
しかし、この機能はシステム開発の現場、特に情報が抽象的な上流工程では、その抽象的な情報を構造化するにあたって極めて有益な機能です。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2010年9月12日日曜日
上流工程の生産性を上げるツール
おはようございます。
今朝の飯綱町はちょっと曇り気味で、時折小雨も降っています。
本日は、上流工程の生産性を上げるツールというテーマで書いてみたいと思います。
上流工程の仕事はひたすらドキュメンテーション！
私が主に書くドキュメントは次のようなものです。
これらのドキュメントを書いていく上で、いかに早く正確にドキュメントを記述できるかは、私にとっての死活問題です。
フリーランスの技術者という商売は、多くが自分の時間を切り売りして収入を得ているので、収入を上げようとすると時間当たりの単価を上げるか、長時間働くかの2社択一になります。
もちろんこれ以外にも、自分で開発したソフトウェアのライセンスフィー収入や、著作からの印税収入なども見込むことはできますが、これができる技術者はなかなかいないのではないでしょうか。
そうであれば、時間単価を上げるか、長時間労働をするかの2社択一になります。
個人的には両方必要だと思いますが、時間単価を上げるということはすなわち短時間で人よりも多くのアウトプットができることが絶対的な条件になります。
ちなみに日本のSE単価は、ほとんどが勤続年数や相場など、その技術者の実力とはかけ離れたところで決まる部分があるので、エンドユーザ的に「ババを引いた…」と思うのは、時間当たりのアウトプット能力が低い技術者に当たってしまったときですよね…
特に上流工程は、特に情報の抽象度が高い工程を相手にするので、抽象思考やイメージ能力が高い技術者と、そうでない技術者のパフォーマンスには雲泥の差が出ます。
短時間で多くのアウトプットができて、さらに長時間労働ができる集中力・体力・モチベーションがあることが、フリーランスの技術者が最も確実に自分の価値をあげることができる手段になります。
そういえば長時間労働は、ランチェスター経営・「弱者の戦略」でもありましたね。
さて、前置きが長くなりましたが、このような上流工程で作成するドキュメントをいかに効率よく作成する「ツール」について書きたいと思います。
私はこれまで数あるシステム開発プロジェクトを経験してきましたが、SEさんによってドキュメントを記述するソフトウェアは様々です。
上流工程で使うプロ仕様のツール
フローチャートをExcelやパワーポイントで書く人。
フローチャートだけでなく、ネットワーク構成をはじめとする上流工程全てのドキュメントをExcelだけで書く人。（Excelって偉大だなぁ～）
もちろん、こういったツールの選択が「悪い」というわけではないのですが、個人的に思うのが、プロなんだからプロが使う道具で仕事をしましょうということです。
例えばフローチャート。
特に上流工程で必要となる部門間連携を表現するレーン付きのフローチャートや、産能式事務工程図を書く場合、とてもExcelやPowerPointで書ききれるものではありません。
もちろん手間と時間をかければ書くことはできるのですが、追加・修正などのことを考えるときわめて効率が悪くなります。
フローチャートであれば、それ専用のツールを使うのもプロの条件のひとつだと思います。
プロであれば、他人より圧倒的に早く仕事ができることもプロたる条件。
であればフローチャートを描くにはVisioや、ちょっと値は張りますがXUpperやJUDE/Bizといった専用ツールを使うべきです。
もし会社がそういったツールを買ってくれないというのであれば、そんな会社はさっさと三行半をたたきつけるべきです。（笑）
まぁ三行半というのは行き過ぎかもしれませんが、そこの経営者は、適切なツールの選択による生産性の向上と利益の増大よりも、目先数万円のキャッシュがもったいないという感覚なので、既に経営者としての視点は持っていないということでしょう。
そんな会社は遅かれ早かれ行き詰るのが目に見えています。
一番大変なのは、膨大な関連情報の整理と数百ページになるワープロ文書
先に書いたとおり、フローチャートをはじめとする特殊なドキュメントには、それを補完するためのプロ用ツールが出ているのでそれを使うことがプロとしての生産性を挙げてくれる重要なファクターであることは明白だと思います。
またこれ以外にも、ネットワーク構成やシステム概念図、ER図や簡単なGUI設計ツールもプロとしてしっかりと揃えておきたいところです。
さて、そんな上流工程の中で使用するツールでも、「プロ用」と分類できるようなツールが無いのがワープロです。
要件定義書やRFPは、最終的にワープロ打ちしてA4のドキュメントで納品するのが大体のパターンだと思います。
しかし、このワープロについてはプロ用と呼ばれるツールがありません。
要件定義書やRFPは、しっかりとやればやるほど、記述する内容は膨大になります。
技術要求・業務要求・非機能要求など、頭の中にぼんやりならイメージできるものでも、いざそれを正式な要求・要件として文字にしようとすると、膨大な量になります。
これを章立てして、論理的な構造で組み立て、さらにプロジェクトの利害関係者の誰が呼んでも一定のレベルで理解できる文言で書くのは、極めて手間のかかる作業です。
例えば一般的に3000万レベルの小規模プロジェクトでも、教科書どおりの要件定義やRFPを作成すれば、ドキュメントの記述量はA4用紙で直ぐに100ページを越えます。
こんな膨大な文書を書くのに、いきなりまっさらのWordを開いてゴリゴリ入力していくのは極めて非効率的です。
そこでは私は、この作業にFreeMindを使っています。
FreeMindは上流工程の乗り切るためのプロ用ツールになる。
FreeMindはいわずと知れた(?)、マインドマップ風アウトラインプロセッサ。
生粋の(?)マインドマッパーからいわせていただくと、これはマインドマッピングのツールではなく、アウトラインプロセッサです。
しかし、個人的にはこれが上流工程の作業で最も活躍するツールかも知れません。
先にも書いたとおり、上流工程で作成するドキュメントの特徴は、記載する項目が多岐にわたり、アウトラインが何階層にもわたって深くなるということです。
また、アウトラインごとに関連付けて記述したいことが多々あるのもこれらのドキュメントの特徴です。
例えばある業務要件と技術要件が密接に絡み合っている場合、できれば「○○を参照」と入れたいですし、書く側としては容易にその参照先にジャンプできること生産性があがります。
さらに、ある章の内容を書いているときに、ふと他の章の追加記述や、システム化のアイデアが浮かぶもありますし、エンドユーザへの質問事項が頭に浮かぶこともあります。
そういったものは忘れないうちに文字にしておくと、後から思い出す必要も無く、忘れてしまうというロスもなくなります。
こういった一連の作業を効率よくできるのがこのFreeMindです。
例えばエンドユーザに確認しなければならない事項が出てきたら、関連するブランチにノートとして記述し、[?]などのアイコンをつけておけば、次回のヒヤリングで漏れなくそれを訴求することができます。
また、ふとしたシステム化のアイデアも、関連するブランチにノートとして記述しておき、電球アイコンなどをつけておけば、エンドユーザに漏れなく提案することができます。
さらに、ドキュメントを記述中に出てきたToDoもすばやく記述して、チェックマークなどのアイコンをつけておけば、ToDoを漏らすことがありません。
ここでFreeMindの素晴らしいのが、アイデアでも質問事項でもToDoでも、何をしているとき、何を考えているときにそれが生まれてきたかを関連付けて記録することが可能なことです。
これが別のノートやToDoリストに書き出してしまうと、「これは何の作業をしているときに出てきた質問事項だ？」となってしまいます。
FreeMindを使うと、そういった「何を源泉にこのToDoや質問が湧いてきたのか？」が、直ぐにわかります。
さらに素晴らしいのが、これらの質問事項やToDoを数あるブランチから一瞬にしてソーティングして一覧化することができることです。
マインドマップの原則を守るとありえないことですが、RFPや要件定義をFreeMindで書いていると、A0サイズの紙で印刷してもまだ足りないぐらいの大きさになります。
それだけの文書から、あるところに記述したToDoや質問事項を見つけ出すことが、FreeMindでは簡単にできてしまうのです。
もちろん、これ以外にもFreeMindを使った「上流工程ハック」はたくさんあります。
外部ファイルへのリンク埋め込みやURLリンクの埋め込みを使えば、周辺資料のまとめも極めて効率的にできますし、ドキュメントの作成時にも、あらかじめ全てのアウトラインをブランチとして書き出しておけば、書ける所から書いていくという作業が可能です。
ワープロだとどうしても頭から書いていくので、あるところで躓くとその先がどうしても進まなくなります。
こういった躓きによる作業中断がFreeMindを使うとかなり解消できます。
これらFreeMindを使った「上流工程ハック(?)」は、それこそ相当な量のドキュメントを書く必要があるので、また別の機会に詳しく書きたいと思います。
情報は全てFreeMindにまとめなさい？
今回はFreeMindを使った上流工程作業について書いてみました。
FreeMindは別にプロ用のツールというわけではなく、価格もフリーです。
上流工程を「Excel」と「Word」だけでがんばっている技術者さんには、ぜひ知ってほしいツールになります。
上流工程では、とにかくMECE精神で関連する多くの情報をかき集め、論理的に整理して問題点を定義し、バラバラと出てくる改善点も同じく論理的にまとめて要求・要件を定義していく作業、そしてそのかき集めた情報を文字化していく作業がその大半になります。
この作業を極めて効率的に行えるのがFreeMindです。
ちょっと前に「情報は全て100円ノートにまとめなさい」という本が出版されていましたが、私の場合は全てFreeMindにまとめなさいといったところですね。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
今朝の飯綱町はちょっと曇り気味で、時折小雨も降っています。
本日は、上流工程の生産性を上げるツールというテーマで書いてみたいと思います。
上流工程の仕事はひたすらドキュメンテーション！
私が主に書くドキュメントは次のようなものです。
- 情報システム活動計画書
- RFP
- 要件定義書
- 業務フローチャート
- 業務記述書
- ユースケース図
- ネットワーク構成図
- システム概念図
これらのドキュメントを書いていく上で、いかに早く正確にドキュメントを記述できるかは、私にとっての死活問題です。
フリーランスの技術者という商売は、多くが自分の時間を切り売りして収入を得ているので、収入を上げようとすると時間当たりの単価を上げるか、長時間働くかの2社択一になります。
もちろんこれ以外にも、自分で開発したソフトウェアのライセンスフィー収入や、著作からの印税収入なども見込むことはできますが、これができる技術者はなかなかいないのではないでしょうか。
そうであれば、時間単価を上げるか、長時間労働をするかの2社択一になります。
個人的には両方必要だと思いますが、時間単価を上げるということはすなわち短時間で人よりも多くのアウトプットができることが絶対的な条件になります。
ちなみに日本のSE単価は、ほとんどが勤続年数や相場など、その技術者の実力とはかけ離れたところで決まる部分があるので、エンドユーザ的に「ババを引いた…」と思うのは、時間当たりのアウトプット能力が低い技術者に当たってしまったときですよね…
特に上流工程は、特に情報の抽象度が高い工程を相手にするので、抽象思考やイメージ能力が高い技術者と、そうでない技術者のパフォーマンスには雲泥の差が出ます。
短時間で多くのアウトプットができて、さらに長時間労働ができる集中力・体力・モチベーションがあることが、フリーランスの技術者が最も確実に自分の価値をあげることができる手段になります。
そういえば長時間労働は、ランチェスター経営・「弱者の戦略」でもありましたね。
さて、前置きが長くなりましたが、このような上流工程で作成するドキュメントをいかに効率よく作成する「ツール」について書きたいと思います。
私はこれまで数あるシステム開発プロジェクトを経験してきましたが、SEさんによってドキュメントを記述するソフトウェアは様々です。
上流工程で使うプロ仕様のツール
フローチャートをExcelやパワーポイントで書く人。
フローチャートだけでなく、ネットワーク構成をはじめとする上流工程全てのドキュメントをExcelだけで書く人。（Excelって偉大だなぁ～）
もちろん、こういったツールの選択が「悪い」というわけではないのですが、個人的に思うのが、プロなんだからプロが使う道具で仕事をしましょうということです。
例えばフローチャート。
特に上流工程で必要となる部門間連携を表現するレーン付きのフローチャートや、産能式事務工程図を書く場合、とてもExcelやPowerPointで書ききれるものではありません。
もちろん手間と時間をかければ書くことはできるのですが、追加・修正などのことを考えるときわめて効率が悪くなります。
フローチャートであれば、それ専用のツールを使うのもプロの条件のひとつだと思います。
プロであれば、他人より圧倒的に早く仕事ができることもプロたる条件。
であればフローチャートを描くにはVisioや、ちょっと値は張りますがXUpperやJUDE/Bizといった専用ツールを使うべきです。
もし会社がそういったツールを買ってくれないというのであれば、そんな会社はさっさと三行半をたたきつけるべきです。（笑）
まぁ三行半というのは行き過ぎかもしれませんが、そこの経営者は、適切なツールの選択による生産性の向上と利益の増大よりも、目先数万円のキャッシュがもったいないという感覚なので、既に経営者としての視点は持っていないということでしょう。
そんな会社は遅かれ早かれ行き詰るのが目に見えています。
一番大変なのは、膨大な関連情報の整理と数百ページになるワープロ文書
先に書いたとおり、フローチャートをはじめとする特殊なドキュメントには、それを補完するためのプロ用ツールが出ているのでそれを使うことがプロとしての生産性を挙げてくれる重要なファクターであることは明白だと思います。
またこれ以外にも、ネットワーク構成やシステム概念図、ER図や簡単なGUI設計ツールもプロとしてしっかりと揃えておきたいところです。
さて、そんな上流工程の中で使用するツールでも、「プロ用」と分類できるようなツールが無いのがワープロです。
要件定義書やRFPは、最終的にワープロ打ちしてA4のドキュメントで納品するのが大体のパターンだと思います。
しかし、このワープロについてはプロ用と呼ばれるツールがありません。
要件定義書やRFPは、しっかりとやればやるほど、記述する内容は膨大になります。
技術要求・業務要求・非機能要求など、頭の中にぼんやりならイメージできるものでも、いざそれを正式な要求・要件として文字にしようとすると、膨大な量になります。
これを章立てして、論理的な構造で組み立て、さらにプロジェクトの利害関係者の誰が呼んでも一定のレベルで理解できる文言で書くのは、極めて手間のかかる作業です。
例えば一般的に3000万レベルの小規模プロジェクトでも、教科書どおりの要件定義やRFPを作成すれば、ドキュメントの記述量はA4用紙で直ぐに100ページを越えます。
こんな膨大な文書を書くのに、いきなりまっさらのWordを開いてゴリゴリ入力していくのは極めて非効率的です。
そこでは私は、この作業にFreeMindを使っています。
FreeMindは上流工程の乗り切るためのプロ用ツールになる。
FreeMindはいわずと知れた(?)、マインドマップ風アウトラインプロセッサ。
生粋の(?)マインドマッパーからいわせていただくと、これはマインドマッピングのツールではなく、アウトラインプロセッサです。
しかし、個人的にはこれが上流工程の作業で最も活躍するツールかも知れません。
先にも書いたとおり、上流工程で作成するドキュメントの特徴は、記載する項目が多岐にわたり、アウトラインが何階層にもわたって深くなるということです。
また、アウトラインごとに関連付けて記述したいことが多々あるのもこれらのドキュメントの特徴です。
例えばある業務要件と技術要件が密接に絡み合っている場合、できれば「○○を参照」と入れたいですし、書く側としては容易にその参照先にジャンプできること生産性があがります。
さらに、ある章の内容を書いているときに、ふと他の章の追加記述や、システム化のアイデアが浮かぶもありますし、エンドユーザへの質問事項が頭に浮かぶこともあります。
そういったものは忘れないうちに文字にしておくと、後から思い出す必要も無く、忘れてしまうというロスもなくなります。
こういった一連の作業を効率よくできるのがこのFreeMindです。
例えばエンドユーザに確認しなければならない事項が出てきたら、関連するブランチにノートとして記述し、[?]などのアイコンをつけておけば、次回のヒヤリングで漏れなくそれを訴求することができます。
また、ふとしたシステム化のアイデアも、関連するブランチにノートとして記述しておき、電球アイコンなどをつけておけば、エンドユーザに漏れなく提案することができます。
さらに、ドキュメントを記述中に出てきたToDoもすばやく記述して、チェックマークなどのアイコンをつけておけば、ToDoを漏らすことがありません。
ここでFreeMindの素晴らしいのが、アイデアでも質問事項でもToDoでも、何をしているとき、何を考えているときにそれが生まれてきたかを関連付けて記録することが可能なことです。
これが別のノートやToDoリストに書き出してしまうと、「これは何の作業をしているときに出てきた質問事項だ？」となってしまいます。
FreeMindを使うと、そういった「何を源泉にこのToDoや質問が湧いてきたのか？」が、直ぐにわかります。
さらに素晴らしいのが、これらの質問事項やToDoを数あるブランチから一瞬にしてソーティングして一覧化することができることです。
マインドマップの原則を守るとありえないことですが、RFPや要件定義をFreeMindで書いていると、A0サイズの紙で印刷してもまだ足りないぐらいの大きさになります。
それだけの文書から、あるところに記述したToDoや質問事項を見つけ出すことが、FreeMindでは簡単にできてしまうのです。
もちろん、これ以外にもFreeMindを使った「上流工程ハック」はたくさんあります。
外部ファイルへのリンク埋め込みやURLリンクの埋め込みを使えば、周辺資料のまとめも極めて効率的にできますし、ドキュメントの作成時にも、あらかじめ全てのアウトラインをブランチとして書き出しておけば、書ける所から書いていくという作業が可能です。
ワープロだとどうしても頭から書いていくので、あるところで躓くとその先がどうしても進まなくなります。
こういった躓きによる作業中断がFreeMindを使うとかなり解消できます。
これらFreeMindを使った「上流工程ハック(?)」は、それこそ相当な量のドキュメントを書く必要があるので、また別の機会に詳しく書きたいと思います。
情報は全てFreeMindにまとめなさい？
今回はFreeMindを使った上流工程作業について書いてみました。
FreeMindは別にプロ用のツールというわけではなく、価格もフリーです。
上流工程を「Excel」と「Word」だけでがんばっている技術者さんには、ぜひ知ってほしいツールになります。
上流工程では、とにかくMECE精神で関連する多くの情報をかき集め、論理的に整理して問題点を定義し、バラバラと出てくる改善点も同じく論理的にまとめて要求・要件を定義していく作業、そしてそのかき集めた情報を文字化していく作業がその大半になります。
この作業を極めて効率的に行えるのがFreeMindです。
ちょっと前に「情報は全て100円ノートにまとめなさい」という本が出版されていましたが、私の場合は全てFreeMindにまとめなさいといったところですね。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2010年9月7日火曜日
情報システム開発業における弱者の戦略
こちら長野県飯綱町は、朝夕に関してはすっかりすごしやすくなりました。
我が家周辺は治安が良いこともあり、夜寝るときは窓全開で寝ているのですが、朝方は寒くて目が覚めることがあります。
今年は記録的な猛暑で、寝苦しい夜が続いていたのですが、ようやく北信州らしい気候になってきました。
さて、今日は情報システム開発業における弱者の戦略ということで書いてみたいと思います。
情報システム産業は、長引く不況の影響で、経営が苦しくなるソフトウェアハウス・システムインテグレータが相当数に昇っているのは、業界の方であれば周知の事実であると思います。
実は先日も、複数のソフトウェア開発会社の営業さんや経営者さんから、仕事が無くて困っている、案件が決まらずに困っているという話をお伺いしました。
２００８年のリーマンショック以降、「真水キャッシュフローの源泉」である常駐技術者を返されたり、1000万円を越える案件の受注率が極めて悪くなったりと、中堅・中小規模のソフトウェア開発分野における経営環境は極めて悪くなっているようです。
翻って、私がお付き合いをさせていただいている開発会社さんの中には、仕事を断らなければならないほど活況な会社もあります。
双方ともに規模としては数十名規模、同じソフトウェア開発会社を生業としているのに、この差はどこから出てくるのでしょう。
今日はこんなことを考えてみたいと思います。
考えるベースになっている世界観は、弱者の戦略・ランチェスター経営です。
現在の日本におけるソフトウェア開発会社は、メーカー系の大手を除いてその９９％が「弱者」と考えてよろしいでしょう。
例えばこの地域では一番の・・・という会社でも、ここ数年の技術動向から考えると「弱者」であると考えるべきです。
それが数十名から数百名規模の中堅・中小レベルであれば、圧倒的な番外弱者と考えたほうが良いでしょう。
このランク付けのキーとなっている技術動向・技術トレンドというのはズバリ「クラウド」です。
この技術トレンドのおかげで、地方の小さな開発会社であろうが、都内の数百名規模の会社であろうが、世界的なクラウド技術プロバイダーであろうが、同じ競争空間に放り込まれてしまうのです。
クラウド化の本質は紛れも無く仮想化・バーチャルかであり、これを経営戦略という視点からみると、競争の優位性が物理空間（リアル）から情報空間（バーチャル）に移ることにあります。
情報空間とは限界効用逓減の法則が働かない世界なので、独占した人たちが圧倒的に優位な競争空間です。
世界的企業と数名・数十名規模でシステム開発している会社が、バーチャル空間上で同じ土俵に上げられて、いつの間にか競争させられているんですね。
だからこそ、一般的な開発会社は弱者の戦略を徹底的に研究し、それを実践するしか生き残る道が無いのです。
冒頭に上げた、経営が汲々としている会社さんと、仕事を断るぐらいお客さんから問合せが来ている会社の違い。
これは、意識的にか無意識的にか解かりませんが、後者の会社さんはしっかりと「弱者の戦略」を実行されているように思えます。
顧客・商品の絞込み、そして「接近戦」といったことをしっかりされているんですね。
さらに戦略ではなく戦術レベルの話をすると、ソフトウェア開発業で極めて重要なのが、自社で取り組む技術分野の絞込み。
これは「武器の選択」といっても良いでしょう。
弱者が採用すべきは、接近戦に優位な武器。
自社が絞り込んだ業界・客層に優位な武器は何なのかをしっかりと見据える必要があります。
ここで明らかなのは、強者が使う武器を使って戦ってもダメだということ。
弱者には弱者にふさわしい武器があるし、その武器が通用しないところには出て行ってはいけない、そういった土俵に登ってはいけないということになります。
ちなみに、私はこの弱者の武器としてFileMakerテクノロジーを選択しています。
私は「実装能力のあるITコンサルタント」なので、システム企画や要件定義の仕事がメイン名のですが、実装フェーズに自らが動くこともあります。
その時に使うのがFileMakerテクノロジーです。
これは、私のような弱者にはぴったりの武器です。
これを使うことで、強者の武器を使って戦っている中小規模のソフトウェア会社の技術者数人分の仕事を、私１人でこなすことができます。
結果、お客さまからは喜ばれるし、自分自身の仕事にも誇りと自信を持つことができます。
注意しなければならないのが、世の中に出回っている技術情報は、そのほとんどが強者が使うべき武器の情報で、弱者が使うべき武器の情報はまったくといっていいほどメジャーなメディアでは取り上げられないということ。
情報システム開発業における弱者の戦略は、メジャーメディアでは絶対に取り上げられないので、自らが研究し、実践し、トライアンドエラーで見出す以外に方法はありません。
また、弱者の戦略を勉強するのであれば、ランチェスター経営の竹田先生が作られている教材、そして神田昌典さんのダントツ企業オーディオセミナーをはじめとする各種教材はすごく勉強になります。
ランチェスター経営：http://www.lanchest.com/
神田昌典さん：http://www.kandamasanori.com/
弱者の戦略、勉強しましょう！
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
我が家周辺は治安が良いこともあり、夜寝るときは窓全開で寝ているのですが、朝方は寒くて目が覚めることがあります。
今年は記録的な猛暑で、寝苦しい夜が続いていたのですが、ようやく北信州らしい気候になってきました。
さて、今日は情報システム開発業における弱者の戦略ということで書いてみたいと思います。
情報システム産業は、長引く不況の影響で、経営が苦しくなるソフトウェアハウス・システムインテグレータが相当数に昇っているのは、業界の方であれば周知の事実であると思います。
実は先日も、複数のソフトウェア開発会社の営業さんや経営者さんから、仕事が無くて困っている、案件が決まらずに困っているという話をお伺いしました。
２００８年のリーマンショック以降、「真水キャッシュフローの源泉」である常駐技術者を返されたり、1000万円を越える案件の受注率が極めて悪くなったりと、中堅・中小規模のソフトウェア開発分野における経営環境は極めて悪くなっているようです。
翻って、私がお付き合いをさせていただいている開発会社さんの中には、仕事を断らなければならないほど活況な会社もあります。
双方ともに規模としては数十名規模、同じソフトウェア開発会社を生業としているのに、この差はどこから出てくるのでしょう。
今日はこんなことを考えてみたいと思います。
考えるベースになっている世界観は、弱者の戦略・ランチェスター経営です。
現在の日本におけるソフトウェア開発会社は、メーカー系の大手を除いてその９９％が「弱者」と考えてよろしいでしょう。
例えばこの地域では一番の・・・という会社でも、ここ数年の技術動向から考えると「弱者」であると考えるべきです。
それが数十名から数百名規模の中堅・中小レベルであれば、圧倒的な番外弱者と考えたほうが良いでしょう。
このランク付けのキーとなっている技術動向・技術トレンドというのはズバリ「クラウド」です。
この技術トレンドのおかげで、地方の小さな開発会社であろうが、都内の数百名規模の会社であろうが、世界的なクラウド技術プロバイダーであろうが、同じ競争空間に放り込まれてしまうのです。
クラウド化の本質は紛れも無く仮想化・バーチャルかであり、これを経営戦略という視点からみると、競争の優位性が物理空間（リアル）から情報空間（バーチャル）に移ることにあります。
情報空間とは限界効用逓減の法則が働かない世界なので、独占した人たちが圧倒的に優位な競争空間です。
世界的企業と数名・数十名規模でシステム開発している会社が、バーチャル空間上で同じ土俵に上げられて、いつの間にか競争させられているんですね。
地方で数名規模でソリューション開発をしている会社と、SalesForce.comのような世界規模で商売をしている会社が比較されてしまうのが「情報空間」における競争の本質です。
例えば、「いつも付き合いのあるあの会社に開発をお願いするのと、セールスフォースを使うのはどっちが得だろう？」
ソフトウェアを発注する側であれば、こういった考慮は必ずされるでしょう。
実はこの時点で、数十名規模の会社と世界規模のクラウド屋さんが比較されてしまっているのです。
だからこそ、一般的な開発会社は弱者の戦略を徹底的に研究し、それを実践するしか生き残る道が無いのです。
冒頭に上げた、経営が汲々としている会社さんと、仕事を断るぐらいお客さんから問合せが来ている会社の違い。
これは、意識的にか無意識的にか解かりませんが、後者の会社さんはしっかりと「弱者の戦略」を実行されているように思えます。
顧客・商品の絞込み、そして「接近戦」といったことをしっかりされているんですね。
さらに戦略ではなく戦術レベルの話をすると、ソフトウェア開発業で極めて重要なのが、自社で取り組む技術分野の絞込み。
これは「武器の選択」といっても良いでしょう。
弱者が採用すべきは、接近戦に優位な武器。
自社が絞り込んだ業界・客層に優位な武器は何なのかをしっかりと見据える必要があります。
ここで明らかなのは、強者が使う武器を使って戦ってもダメだということ。
弱者には弱者にふさわしい武器があるし、その武器が通用しないところには出て行ってはいけない、そういった土俵に登ってはいけないということになります。
ちなみに、私はこの弱者の武器としてFileMakerテクノロジーを選択しています。
私は「実装能力のあるITコンサルタント」なので、システム企画や要件定義の仕事がメイン名のですが、実装フェーズに自らが動くこともあります。
その時に使うのがFileMakerテクノロジーです。
これは、私のような弱者にはぴったりの武器です。
これを使うことで、強者の武器を使って戦っている中小規模のソフトウェア会社の技術者数人分の仕事を、私１人でこなすことができます。
結果、お客さまからは喜ばれるし、自分自身の仕事にも誇りと自信を持つことができます。
注意しなければならないのが、世の中に出回っている技術情報は、そのほとんどが強者が使うべき武器の情報で、弱者が使うべき武器の情報はまったくといっていいほどメジャーなメディアでは取り上げられないということ。
情報システム開発業における弱者の戦略は、メジャーメディアでは絶対に取り上げられないので、自らが研究し、実践し、トライアンドエラーで見出す以外に方法はありません。
また、弱者の戦略を勉強するのであれば、ランチェスター経営の竹田先生が作られている教材、そして神田昌典さんのダントツ企業オーディオセミナーをはじめとする各種教材はすごく勉強になります。
ランチェスター経営：http://www.lanchest.com/
神田昌典さん：http://www.kandamasanori.com/
弱者の戦略、勉強しましょう！
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
2010年8月30日月曜日
情報システム戦略に関する考察 ～記述の粒度について～
昨日は娘が通う幼稚園の行事で、根子岳に登ってきました。
去年の根子岳登山で、ウチの娘はベソかき・ケツ持ち部隊で、最後はオンブしながらの下山だったのですが、今年は出発前からガンガンに気合いが入っており、出発時には初代隊長に任命されました。
その隊長任命でさらに気合いが入ったのか、出発直後から隊列の先頭をビシビシ登っていきます。
去年までの弱々しさはまったく無く、気合いの入った表情で隊列を引っ張っていく４歳の娘には感動すら覚えました。
７時に登山口を出発して、数回の休憩を挟み、１１時３０分には山頂に。
そこには北アルプスまで見渡せる素晴らしい景色が待ち受けていました。
我が家は山頂で、炭焼きのスペアリブを楽しみ、手作りのメダル授与式などのセレモニーを経て１３時３０分ごろ下山開始。
予定通り、１５時には無事登山口に到着しました。
驚愕したのはその後。
登山口に到着後、ほかの家族の到着を待っている間に、友達と走り回っていました。
子どもの成長というのは本当に素晴らしい。
子どもにゴチャゴチャと小言を言う前に、親自身も、もっともっと成長しなければということを痛感した一日でした。
─────────────────────
さて、本日は情報システム戦略に関する情報の粒度について書きたいと思います。
情報システム戦略を文書化するときに、どういった情報の粒度（抽象レベル）で書いてよいのか迷うことはありませんか？
何を書かなければならないのかを迷うのはもちろんのこと、どの粒度で情報を書けばよいのかがよく解からない方というのは、意外に多いのではないかと思います。
情報システム戦略を文書化する上での粒度を知るためには、まず戦略と戦術の違いについて知っておくことが重要だと思います。
戦略と戦術の違いは、その語源をたどるとわかりやすい。
戦略とは、その語源がラテン語の「ストラテジア」にあり、英語の「ストラテジー」の語源になっています。
1864年に山口県の大村益次郎がこの「ストラテジア」を「将帥の術」と翻訳し、「見えざるもの」との解説を加えました。
そして、明治のはじめヨーロッパで兵学の研究をしていた軍人が、これを「戦略」と翻訳し直しました。
これが戦略と戦術の基本的な違いになります。
では次に、これを「情報システム戦略」に当てはめてみましょう。
まず、情報システムそのものが「見えざるもの」的な部分が大きいので、混乱してしまいがちですが、私はこれを解かりやすく解釈するために、オブジェクト指向の考え方を取り入れています。
そしてオブジェクト指向の考え方をどう取り入れているかについてですが、私は、戦略＝クラス、戦術＝オブジェクト（インスタンス）という階層構造で捉えています。
こう捕らえると、「戦略」は、その下位概念である「戦術」に一定の規則性・法則性を持たせるものともいえますね。
いくら屈強な兵士をたくさん揃えたとしても、その兵士が適材適所で配置され、タイムリーにそのタスクを遂行できる状態でなければ、その能力は十分に発揮することができません。
情報システム戦略も同じで、いくら優れいたインフラ・プロダクト・ソリューション、そして人材を揃えたとしても、それが適切に機能する状態でなければ、ガラクタ以外の何物でもなくなります。
適切な兵士の配置には、一定の規則性・法則性を見出して、それらが適切に機能するように再拝する必要があります。
オブジェクト指向では、下位概念のクラスやオブジェクトの規則性・法則性をまとめた抽象概念をクラスと表現しますが、戦略と戦術の関係はまさにこの階層構造に当てはめることができる関係性を持っています。
そこで本題の情報システム分野における戦略と戦術ですが、これはズバリ具体的な製品・プロダクト・ソリューション等、固有名詞が明確なものに関しては戦術レベルの記述であり、それらの上位概念で記述されているものは戦略レベルの記述であると考えます。
つまり情報システム戦略を文書化したものに、具体的なプロダクト名やベンダー名等が記述されているものに関しては、情報システム戦略を表現する文書として具体的過ぎる、抽象度が低すぎるということです。
これは、「木を見て森を見ず」状態の戦略構築の危険性があります。
情報システム戦略の文書化における情報の粒度に関する留意点としては、その情報粒度がクラスレベル、つまりその下位概念に別のクラスやインスタンスが存在するかどうかを意識して文書化することが望まれます。
例えば、情報システム戦略を記述する上で、RDBMSやデータベースという単語ははクラスレベルの記述となるでしょう。
なぜなら、その下位概念には、MS-SQLServerやOracle、FileMakerProといった下位概念のクラス（インスタンス）が存在するからです。
また、SFAやCRMという記述も抽象的だといえます。これに具体的なSalesForce等といったプロダクト名・製品名が入るのは戦術レベルの情報粒度といえます。
いかがでしたでしょうか？
今回は、情報システム戦略を文書化する局面にあたっての情報粒度について書いてみました。
これはあくまでも私個人が勉強して、ビジネスの現場で「使っている」考え方でありテクニックです。
世の中には、MBA的なアカデミックな解説・解釈はいくらでもあると思いますし、Google検索するとそういった解説は山のように出てくると思います。
ただ、私の実力や知識が伴わないせいか、こういった解説を読んでも、いざ具体的に文書化するとなると、とたんにペンが進まなくなる。（キーボード入力ですけど・・・）
こういった局面に陥ってだいたい次にやることが、どこかの会社の事例を探したり、テンプレートを探したりというのが多くの人の行動パターンだと思います。
十分な時間を与えられず、形ばかりのアウトプットばかりを要求される現代においては、それも仕方が無いと思う反面、やはりその本質だけはしっかりと理解しておくことは極めて重要なことだと思います。
また注意事項として、ここに書いてあることが「ITストラテジスト」等の「知識」を問う試験対策にはお役立ていただけません（笑）
試験対策には、上記に書いたようなアカデミックな知識を身につける必要があります。
次回は、戦略を構築する上で重要な「予見力」について書いてみたいと思います。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
去年の根子岳登山で、ウチの娘はベソかき・ケツ持ち部隊で、最後はオンブしながらの下山だったのですが、今年は出発前からガンガンに気合いが入っており、出発時には初代隊長に任命されました。
その隊長任命でさらに気合いが入ったのか、出発直後から隊列の先頭をビシビシ登っていきます。
去年までの弱々しさはまったく無く、気合いの入った表情で隊列を引っ張っていく４歳の娘には感動すら覚えました。
７時に登山口を出発して、数回の休憩を挟み、１１時３０分には山頂に。
そこには北アルプスまで見渡せる素晴らしい景色が待ち受けていました。
我が家は山頂で、炭焼きのスペアリブを楽しみ、手作りのメダル授与式などのセレモニーを経て１３時３０分ごろ下山開始。
予定通り、１５時には無事登山口に到着しました。
驚愕したのはその後。
登山口に到着後、ほかの家族の到着を待っている間に、友達と走り回っていました。
子どもの成長というのは本当に素晴らしい。
子どもにゴチャゴチャと小言を言う前に、親自身も、もっともっと成長しなければということを痛感した一日でした。
─────────────────────
さて、本日は情報システム戦略に関する情報の粒度について書きたいと思います。
情報システム戦略を文書化するときに、どういった情報の粒度（抽象レベル）で書いてよいのか迷うことはありませんか？
何を書かなければならないのかを迷うのはもちろんのこと、どの粒度で情報を書けばよいのかがよく解からない方というのは、意外に多いのではないかと思います。
情報システム戦略を文書化する上での粒度を知るためには、まず戦略と戦術の違いについて知っておくことが重要だと思います。
戦略と戦術の違いは、その語源をたどるとわかりやすい。
戦略とは、その語源がラテン語の「ストラテジア」にあり、英語の「ストラテジー」の語源になっています。
1864年に山口県の大村益次郎がこの「ストラテジア」を「将帥の術」と翻訳し、「見えざるもの」との解説を加えました。
そして、明治のはじめヨーロッパで兵学の研究をしていた軍人が、これを「戦略」と翻訳し直しました。
次に戦術ですが、これはその語源がラテン語の「タクティコース」にあり、英語の「タクティクス」の語源になっています。
これも同じく大村益次郎が「兵士の術」と翻訳し、「見えるものと」と解説しました。そして、兵学を研究していた軍人が「戦術」と訳したといわれています。
つまりシンプルに解釈すると
「戦略は大将の術であり見えざるもの」
「戦術は兵士の術であり見えるもの」
といえます。
これが戦略と戦術の基本的な違いになります。
では次に、これを「情報システム戦略」に当てはめてみましょう。
まず、情報システムそのものが「見えざるもの」的な部分が大きいので、混乱してしまいがちですが、私はこれを解かりやすく解釈するために、オブジェクト指向の考え方を取り入れています。
そしてオブジェクト指向の考え方をどう取り入れているかについてですが、私は、戦略＝クラス、戦術＝オブジェクト（インスタンス）という階層構造で捉えています。
こう捕らえると、「戦略」は、その下位概念である「戦術」に一定の規則性・法則性を持たせるものともいえますね。
いくら屈強な兵士をたくさん揃えたとしても、その兵士が適材適所で配置され、タイムリーにそのタスクを遂行できる状態でなければ、その能力は十分に発揮することができません。
情報システム戦略も同じで、いくら優れいたインフラ・プロダクト・ソリューション、そして人材を揃えたとしても、それが適切に機能する状態でなければ、ガラクタ以外の何物でもなくなります。
適切な兵士の配置には、一定の規則性・法則性を見出して、それらが適切に機能するように再拝する必要があります。
オブジェクト指向では、下位概念のクラスやオブジェクトの規則性・法則性をまとめた抽象概念をクラスと表現しますが、戦略と戦術の関係はまさにこの階層構造に当てはめることができる関係性を持っています。
そこで本題の情報システム分野における戦略と戦術ですが、これはズバリ具体的な製品・プロダクト・ソリューション等、固有名詞が明確なものに関しては戦術レベルの記述であり、それらの上位概念で記述されているものは戦略レベルの記述であると考えます。
つまり情報システム戦略を文書化したものに、具体的なプロダクト名やベンダー名等が記述されているものに関しては、情報システム戦略を表現する文書として具体的過ぎる、抽象度が低すぎるということです。
これは、「木を見て森を見ず」状態の戦略構築の危険性があります。
情報システム戦略の文書化における情報の粒度に関する留意点としては、その情報粒度がクラスレベル、つまりその下位概念に別のクラスやインスタンスが存在するかどうかを意識して文書化することが望まれます。
例えば、情報システム戦略を記述する上で、RDBMSやデータベースという単語ははクラスレベルの記述となるでしょう。
なぜなら、その下位概念には、MS-SQLServerやOracle、FileMakerProといった下位概念のクラス（インスタンス）が存在するからです。
また、SFAやCRMという記述も抽象的だといえます。これに具体的なSalesForce等といったプロダクト名・製品名が入るのは戦術レベルの情報粒度といえます。
もちろん、これだけが戦略と戦術を分ける決定的な要素ではなく、今回はあくまでも情報システム戦略を文書化する局面における情報の粒度にフォーカスして書いているので、ご了承ください。
今回は、情報システム戦略を文書化する局面にあたっての情報粒度について書いてみました。
これはあくまでも私個人が勉強して、ビジネスの現場で「使っている」考え方でありテクニックです。
世の中には、MBA的なアカデミックな解説・解釈はいくらでもあると思いますし、Google検索するとそういった解説は山のように出てくると思います。
ただ、私の実力や知識が伴わないせいか、こういった解説を読んでも、いざ具体的に文書化するとなると、とたんにペンが進まなくなる。（キーボード入力ですけど・・・）
こういった局面に陥ってだいたい次にやることが、どこかの会社の事例を探したり、テンプレートを探したりというのが多くの人の行動パターンだと思います。
十分な時間を与えられず、形ばかりのアウトプットばかりを要求される現代においては、それも仕方が無いと思う反面、やはりその本質だけはしっかりと理解しておくことは極めて重要なことだと思います。
また注意事項として、ここに書いてあることが「ITストラテジスト」等の「知識」を問う試験対策にはお役立ていただけません（笑）
試験対策には、上記に書いたようなアカデミックな知識を身につける必要があります。
次回は、戦略を構築する上で重要な「予見力」について書いてみたいと思います。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
株式会社ライジングサン・システムコンサルティング
岩佐和紀
URL : http://www.risingsun-system.biz/
認定資格 :
上級システムアドミニストレータ
FileMaker認定デベロッパーVer10/11
登録:
投稿 (Atom)