議論をする前に整理しておくべき３つのこと

会議や話し合いでたまに、発散してただただ無駄に時間を過ごすことはないでしょうか？自分も最近、話が脱線してしまう話し合いや目的地の見えない議論めぐり合って、そのあまりの無駄さに頭を抱えている一人です。

そんな五里霧中な話し合いを少しでも減らすため、すごく当たり前のことですが議論をする前に整理しておくべきことを整理してみます。


■議論をする前に整理しておくべき３つのこと
　１．Goalはどこか（ToBe）
　２．Startはどこか（AsIs）
　３．期限はいつまでか（TimeFrame）

先に挙げてしまいますが、議論をする前に整理しておくべきことはこの3点に集約されるのではないかと考えます。
では以降、個別に考えていきます。


■１．Goalはどこか（ToBe）
「目的地のない旅」というとなんかカッコいい気がします。ですが、目的のない議論はただの口論にしかなりえないのです。

Goalを設定しないで闇雲な議論をするのは、真夜中に地図も持たずに山の中でする宝探しに似ている気がします。もしかしたら財宝が見つかるかもしれない、けど、それは存在しえない財宝を探しているだけかもしれないという賭けでもあるのです。

同様に、話し合いで落しどころを決めぬまま闇雲に話すなど、建設的ではありません。もちろんブレーンストーミングで何かを考えるなら、biasを取り払うためにGoalをあえて設定しないパターンもあるかもしれませんが、基本はGoalを設定し、そこに向かって積み重ねるのが最も建設的なProcessではないでしょうか？

会議は宝探しではありません。そこは決して忘れてはいけません。


■２．Startはどこか（AsIs）
例えばRPGをやっていて、魔王の居るダンジョンに向かう前に普通だったらパーティーメンバーの装備やステータスをチェックしたり、回復系のアイテムを補充する必要がないかチェックしますよね？パーティーにLvの低いメンバーはいないか、HPやMPは減っていないか、回復アイテムは十分か…普通は確認すると思います。

議論を始める前も同様で、現状はどこにあるのか、何が出来ていて何が足りないか、意識に乖離があるならばどこにあるのか、どれくらいの乖離なのか…これらを認識して議論することは重要です。

会議を開始する際、当然ながらStart地点の意思統一が図れていなければ阿、いくら議論を繰り返しても共通の結論など生まれるはずもありません。当然の如く齟齬が発生してしまいます。

仮にStart地点に乖離があったとしても、その乖離を認識した上で議論を行うのと、認識しないで議論を行うのでは全く意味が違います。

議論の前に共通の土台を持つことはとても重要です。


■３．期限はいつまでか（TimeFrame）
これが3つ目。会議という場では意外と漏れがちな要素です。

期限の無い仕事などありません。みな「何時まで」という制限の中でタスクを処理するのが普通です。
しかし議論の場ではなぜか「決めなければならない」という現状が先行してしまい、期限に対する意識が疎かになりがちです。

時間管理は大人の基本です。議論の場でも、熱くなりすぎる前に時間意識を持ちましょう。


この3つを整理してから話し合いに臨むだけで、その話し合いの生産性は高くなるのではないでしょうか？


■重要なのはタスクのライフサイクルを意識して行動すること
と、ここまで議論の場にフォーカスを当ててまとめましたが、これはあくまで議論の場だけに特化して必要なものではないです。
あくまでこの3つはプロジェクトマネジメントにも重要な3つの要素だったりします。
これは大きなプロジェクトだけに限らず、一人で行う小さなタスク処理も同様です。現状把握、目標の設定、作業期限の認識、この3つをちゃんと認識して作業を行えば、まず大きな目標からの乖離は発生しないでしょう。

“AsIs”“ToBe”“TimeFrame”、この3つについて整理してから議論に取り組んでみてはどうでしょうか。

Social Media In Japan (Ver 0.60)

先日のエントリでは様々な方からコメントをいただきました。本当にありがとうございます。
先日のエントリ後、コメント等を参考にSocial Media In Japanを更新いたしました。
ちなみにいただいたコメントについては今のところすべては反映できていませんが、じっくり考察した上で少しずつ反映させていきたいと思っています。


図 Social Media in Japan(ver 0.60)

改変点は、
　・Q&Aに「答えてねっと」の追加
　・文書/Wikiと、商品開発、クチコミの入れ替え
です。

この絵について先日のソフトウェアジャパン2009のセッションで、吉川さんが少し話をされていたそうですが、行けなかったのが非常に残念です。

吉川さんの書いている記事の方にも書かれていますが、これらの図は基本的には個人作成の図になりますので、非営利であれば改変・再利用は別にかまいません。
もし、コメントをいただいた方の中で「俺がやった方がもっといい図が描ける！」と言う方がいらっしゃったらぜひご連絡ください。

以下、リンク集になります。
上記サイトの利用がしてみたくなったら下記リンクを活用ください。

ソーシャルブックマーク

　　

ソーシャルニュース

　　

特化型SNS

　　　

SNS

　　　　

Twitter周辺コミュニティ

　　　　

ミニブログ

　　　

実名ブログコミュニティ

　　　　

匿名コミュニティ

　

ブログプラットフォーム

　　　

ブログ補助

　　

ライフログ

　　

音声系ブログサービス

　　　

ビデオ

　　　

ビデオ評価

　

音楽

　

写真共有

　　　　

お絵かきチャット

　　　　

地域/イベント

　　　　

商品クチコミ/コメント･評価

　　　　　　

ユーザー参加型商品開発

　　

文書/wiki

　　　　　

Ｑ＆Ａ相談

... Close

日本企業はソーシャルメディアを活用しないのか

アメリカの銀行Bank of AmericaがTwitter上にヘルプデスクを解説したそうです。

Twitter / BofA_help

怪しさ満点ですが、ちゃんと自己紹介に説明と注意点が書かれています。

# 自己紹介 Official BofA Twitter rep to help, listen, and learn from our customers. To ensure your privacy, never share account information in unsecured locations.

Twitter / BofA_help

このTwitterのアカウントに関するBank of Americaのコメントは、Bank of America＆MITのBlog：Future Banking Blogに書かれています。

Twitter and the Customer Experience at Bank of America | Future Banking Blog

With the advent of social networking sites and blogs, companies have the opportunity to listen and learn from their consumers in ways that were not possible before. Companies can gain powerful knowledge on everything from product enhancements, customer service interactions and unresolved problems–but only if they listen. Social networking sites like Twitter enable that listening in real time. According to Matt Dickman, VP of Digital Marketing at Fleishman-Hillard, “Twitter is the ultimate customer service tool. It’s live, instantaneous, community driven, open, two-way and multi-way, unfiltered and predictive.

“As of last week, we are now listening AND responding to customers on Twitter. You can find us at BofA_help.

Twitter and the Customer Experience at Bank of America | Future Banking Blog

この情報を、CNET Japan ブログのまなびとさんの記事で知ったのですが、なかなか面白い取り組みです。

日本の銀行も、そろそろ、ソーシャルバンキングへの対応を:ネットバンカー: Netbanking and beyond - CNET Japan

まなびとさんの記事を読んでいても感じたのですが、まだまだ日本の企業は保守的な部分が強くこのようなサービスの利用を行うのは難しいようですね。

これまでのTwitterのやりとりを見ると、Twitterで質問して、オープンにできない部分はメールで回答しているようで、他の人は、どのような回答があったのかわかりません。回答者はバンカメの社員で、David Knappという方ですが、1名で対応しているのか、銀行のサポートがあるのかも不明です。

でも、とりあえず、スタートしてしまうというのがすごいですね。まったく関係ない攻撃的な書き込みがあり、うまく答えられず炎上したらどうしようと考えると、「もう少し様子を見ようか」という方針になりがちです。

日本の銀行も、そろそろ、ソーシャルバンキングへの対応を:ネットバンカー: Netbanking and beyond - CNET Japan

そういえば昨年、NHKがSave The FutureのPRでTwitterを利用していました。残念ながらTwitterのことをいまいち理解していないらしく、Twitter上に吐き出されたPOSTも、人と人とを“つなげる”POSTではなく、ただ単に情報を“垂れ流す”POSTになっていて残念だったのを覚えています。

Twitter / NHK_onair

Twitterブログ: NHKが特別番組でTwitterを使います、スタジオからのつぶやきをチェック！

まなびとさんの挙げている話にしても、NHKが昨年していた残念なPRにしても、いまいちソーシャルメディアの活用に対するメリットを把握しきれていないように見受けられます。本来なら、顧客との距離を近づける最も簡単な方法だと思うのですが…。残念ながら日本企業にはまだ活用は難しいようですね。

... Close

「Microsoft IT Security Award 2009」が今日から開始

Microsoft IT Security Award 2009が今日から始まりました。



去年から始まったこの取り組み、今年で2回目です。話によると去年より問題は難しくしたとか。ちなみに期間は2009年1月15日から2009年2月16日までだそうです。

Securityに自信がある方自分を試したい方、ぜひトライしてみてください。またそうじゃない方も、この際やってみてください。

ちなみに去年はこんなのをいただきました。




【関連記事】
IT Security Award 2008 授賞式 - よっぱ主義。
　http://yoppa.blog.shinobi.jp/Entry/27/
IT Security Award 2009
　http://www.microsoft.com/japan/technet/security/award/2009/default.mspx

... Close

年末に起こったJR東日本のシステムトラブルの原因と対策を考えてみた

　先日JR東日本のシステムトラブルでの利用者への情報提供が甘いんじゃないかと書きましたが、そのシステムトラブルについて原因と対策についても考えてみました。


■情報を整理する
　報道された情報を次のようにまとめられます。

［速報］JR東の新幹線がシステム障害で始発から全面停止、復旧は午前8時に延期：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20081229/322115/

［続報］JR東の新幹線がシステム障害から復旧、前日データの反映に問題か：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20081229/322116/

JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/

　リンク先の情報をまとめるとこのような感じでしょうか。

図 JR東日本 COSMOSのシステムフローと今回の事象でのフロー（予想）

通常運用時（画像上部1）は、
　1-1.運行データを5時までに何らかの方法で準備。
　1-2.5時を過ぎた時点で新幹線総合システムCOSMOSが出力された運行データを取得。
　1-3.運行データを処理し6時以降の運行に向けて備える。
という流れで行われている。

今回の事象発生例（画像下部2）では、
　2-1.前日の車両故障と強風・雪害の影響で全運行が終了したのが29日の1時33分にまで及んだ。
　　　　そのため翌日の389本の列車の運行データを最適化するため変更、結果5時45分までかかった。
　　　　5時を越えて切り替えたため、運行データが翌営業日のものになってしまった。
　2-2.COSMOSが運行データを取得しようとするも、データが存在しないため取得できない。
　2-3.運行データが無いため運行の割り当てがされずトラブルが発生。


■問題があったのはシステム運用
上述の情報から明らかな運用ミスのように思います。その理由を挙げる前に、上に書いた流れでのポイントを整理しておきましょう。
ポイントはこの2点に絞られます。
　・運行データの作成に時間がかかりすぎた
　・5時以降に作成されたデータを読み込むことが出来なかった

(1)運行データの作成所要時間について

前日28日の長野新幹線の車両故障や山形・秋田新幹線の強風や雪害。その影響ですべての列車の運行が終了したのが29日の午前1時33分だった。その後 29日の臨時を含めて389本の列車が運行できるよう、車両を留置する場所などのデータを変更。作業は午前5時45分まで長引いた。

JR東が新幹線システム障害の原因発表、前日のダイヤ乱れで修正が限界超え：ITpro
http://itpro.nikkeibp.co.jp/article/NEWS/20090105/322199/

　結果的に4時間12分処理に時間がかかったことになります。単純計算で1本分計算するのにかかった時間が1分半でしょうか。実際にはマッチングや最適化等の処理が入るでしょうからもう少し短いと思いますが、以外と短くてびっくりです。
　このような計算系の処理システムだと、普通は「●●本の計算で●●分かる」ような想定所要時間を挙げておくのが普通でしょう。
　今回のトラブルでは、前日のうちから389本を計算する想定になっていたようですが、その想定所要時間と計算にかけれる時間（午前5時までの時間）はちゃんと天秤にかけて判断したのでしょうか？また想定所要時間がわかっていながらなぜ最終運行車両が戻るのを待ってから処理を始めたのでしょうか？前以て処理を開始できなかったのでしょうか？いろいろと疑問が涌いてきます。

(2)5時以降のデータの読込について
　JR東日本が運行している新幹線で、一番早い時間に運行するのが東北新幹線盛岡行です。そしてこの車両の運行開始が6時4分なのです。この5時から6時の1時間に、運行データの読込処理と何らかのシステム障害があった場合のリスク対応として設けているのは当然想定できます。
　さて、今回の場合は、そのシステム障害だったんじゃないのかという話ですが、想定される仕様である「午前5時までに運行データを作成する」というベースルールにすら則っていないため想定外だったのではないでしょうか。
　ましてや今回の場合「午前5時まで」というリミットについて、開発者側から運用側に当然伝わっている内容でしょうし、そのルールを守れなかった運用に問題があるのではないでしょうか？


■考え得る対応策
もう既にJR東日本が対応策を発表しているようですが。
12月29日に発生した新幹線輸送障害について[PDF]
残念ながら全く対策になってない気がします。今までもわかっていたであろう「5時までに日付切替作業を行う」ことを徹底するって言っているだけで、対策でもなんでもないです。そこで、上述の原因から考えられる対策を検討します。

今回の事象に対しての対応として想定されるアプローチは2つ、
　・運行データ作成にかかる時間を短縮する
　・5時以降に作成されたデータへの対応

(1)運行データ作成に係る所要時間短縮に関して
・マンパワーで解決
　　処理が終わらなかったのは処理能力が足らなかったからだ　→　ならば処理能力を高くすればいい
　　今回の運行データ作成がシステムによるものではなく手入力によるものだった場合の想定。
　　まさかそんなはずは無いと思いますが。

・運行データ予測調整システムの導入
　　各車両の翌日の始発駅が決定的になった車輌から次の日の運行データに当て嵌めていく方法。
　　全車両の運行が終了していなくても、確定している車両がある程度決まっていれば翌日の運行データ
　　作成は始められるはず。
　　少なくとも今回のように遅れることはなくなるのではないでしょうか？

(2)5時以降に作成されたデータへの対応に関して
・そもそも日付付加に関するルールを改変する
　　これについては達成するにあたって想定されるコストやリスクが大きすぎるため良くない対策でしょう。

・イレギュラーに関しては運用でカバー
　　これも一つの手です。
　　基本的にシステムでカバーできない点は運用でカバーするしかないでしょう。
　　今回のように5時45分に運用データが作成されて始発まで19分しかない状況だと厳しい気もします。


■所感
　少々偉そうなことを書きましたが、対策とはあくまで状況に対応するための方法・手段です。

たい‐さく【対策】
１ 相手の態度や事件の状況に対応するための方法・手段。「人手不足の―を立てる」「―を練る」「税金―」
２ 律令制で、官吏登用試験の一。文章(もんじょう)博士が問題を出して文章得業生(とくごうしょう)に答えさせるもの。また、その答案。

Yahoo!辞書 - たい‐さく【対策】

少なくとも今回提示した対策レベルのものを対策として示してはいけないのではないでしょうか？

... Close