「理論としての汎用性」を満たすために、2つの思考<ゼロベース思考><仮説思考>と、2つの技術<MECE><ロジックツリー>、そしてそれらを総合した1つのプロセス<ソリューション・システム>の、5つの基本的な考え方に集約させた。-- 問題解決プロフェッショナル p.200
というのが今日1日で読み切った「問題解決プロフェッショナル 『思考と技術』」の内容である。
様々な種類の問題に向き合うときに使える本質的な考え方であるが、本書はビジネス書としてビジネスの視点での適用を中心に説明されている。
<ゼロベース>思考とは、「既成の枠」を取り外して考えるということである。 -- 問題解決プロフェッショナル p.19
自分の狭い枠を越えて思考するという話。否定的に要素よりも、可能性を求めること。 その際に「顧客にとっての価値」を考えるとよいとのこと。
本書が述べている中では、ゼロベース思考が一番抽象的で捉えずらい部分である。 言っているところは理解できるが、実際にそうい風に考えるのは最初かなりの意識が必要のように感じる。習慣化する必要がありそうだ。
必ずその時点での「アクションに結びつく」結論(仮説)を持ち、実行に移すという考え方。 まずなにか仮説を立て、SO WHAT? (だから何なの)を繰り返すことで、アクションに結びつく結論(仮説)を出していく。
またそうすることで、「背後の理由やメカニズム」を自然と考えるようになるとのこと。
具体的なアクションまで落としていくという点では GTD に通じるところがある。
またスピード重視なのも特徴だ。絶対的な正解のないビジネス世界において時間をかけてベストな策を模索し続けずに、ベターな解決策を見つけたらすぐに実行に移すこと。 情報収集に時間をかけすぎないこと。
「課題の設定」「解決策の仮説」「解決策の検証・評価」という3つのステップによる解決策立案方法。
主要課題をロジックツリー(SO WHAT?)で個別課題にし、個別課題に対して個別解決策(SO HOW)を考え、YES/NO の結論(仮説)を出す。そしてこの個別解決策を組み合わせて主要課題に対する総合解決策を立案する。で、この個別・総合解決策を検証評価する。
一旦課題をMECE/ロジックツリーでブレークダウンし解決策を考え、また総合解決策にまとめあげるというステップが興味深い。
特に実行を重視している「仮説思考」が非常に興味深くまた、実践的に感じられた。 すごい考え方でいうところの「で、どうしたいの」だ。
また、「いつまでも辿りつけないベストな策」よりも「ベターな策で実行に移して、起動修正しながら精度を高めていく」方が効果的というスピード志向なところもカッコイイ。
「早朝会議革命 - 元気企業トリンプの「即断即決」経営」での「稚拙でもいいから速く」というのも同様な考えからきているのかもしれない。
仮説思考についてはもう少し掘り下げて実践してみたい。
…… SO WHAT? (自分)
家電であったり、カメラであったり、コンピュータであったり、何かを欲しいと思った時は、カタログをもらってくることに加えて、Web で検索して情報を集めることはごく日常の風景となった。 情報収集といえば今や Web が主流であるといっていいであろう。
一方、一昔前は本や雑誌、あるいは知人からの情報が数少ない情報源であった。 そのため、実際に店頭でいろいろいじって感じた印象が判断材料の大きなウェイトを占めていた。
しかし最近はついつい、他人のレビューに頼りがちである。 気をつけないと、自分で考えずに他人の(しかも知らない人の)意見だけで物を買ってしまいそうになる。
金銭的余裕がでてくると、今度は「買ってみないと所詮わからん」ということで今度はあっさり買いに走ってしまったり。
自分で考え、選び抜いて買った時の喜びをあらためて大切にしたい。
(選び抜いてもそうでなくてもハズレを引く可能性は同じぐらいな気もするが)
家に帰ってサスペンドから復帰した ThinkPad X200 を無線 LAN 接続に切り替えたがうまくつながらない。ルータを再起動しても駄目なので PC の方を再起動。
そしてら Debian GNU/Linux sid が起動しなくなってしまった。 udevd が設定ファイルが古い形式だよといった警告を出した後、/dev の作成の途中で止まっているっぽい。あちゃー。
とりあえず Windows 7 を起動して情報収集。 まだ設定が済んでおらず Firefox 入っていないし英語キーボード用の設定にしていないのでキー配列が違うし、入力切り替えボタンはないしで苦労しながら Web でチェック。
Debian の BTS によるとやはり udev 148-1 がハズレらしい。 ダウングレードするか。
GRUB で e して linux オプション行の ro を rw にし init=/bin/bash を追加して起動。 dpkg -s udev で 148-1 であることを確認。 幸い /var/cache/apt/archives/udev_147-5_i386.deb が残っていたので dpkg -i でダウングレード。 で再起動したら / を fsck しろといわれたので fsck して再度起動。これでようやく起動するようになった。
なお情報によるとタイムアウト待ちまで待ては先に進んだらしい。
またひとつ sid の醍醐味を味わった。
しかし過去の Debian パッケージが /var/cache に残っていなかったらもっと手間だったな。 インストールの時に作ったインストール CD 捨てようと思っていたが、やはりとっておいたほうがいいな。
昨日14時46分頃に三陸沖で発生した「平成23年(2011年)東北地方太平洋沖地震(The 2011 off the Pacific coast of Tohoku Earthquake)」時、東京都千代田区東神田3丁目のオフィスにいた。 電車が止まり夕方になって運転の再開の目処が立たないので、遅くなる前に徒歩帰宅することにした。
距離的には Google マップでも徒歩2時間30分ちょっとで、たいしたことはないのだが心配したのは道の混雑。
2008年の中央防災会議「首都直下地震避難対策等専門調査会」の報告中の帰宅行動シミュレーションでは、混雑度が6人/m^2を超えて満員電車状態になる道路が発生し、歩行速度は1時間400m以下となるとされていたからだ。
もっとも今回は都心部では建物の倒壊や火災もほとんど無く、それほど条件は悪くはないであろう。 ということでバックに地震の後にコンビニで確保していたミネラルウォーターとパンを入れて 18:20 頃会社を出発。
秋葉原駅と浅草橋の中間あたりの美倉橋から、裏道を選びつつジグザグに進み日本橋を通過。ヘルメットを被っているサラリーマン・OLもちらほら。やはりこの辺りの会社はきちんと準備しているんだろうね。 そのまま第一京浜を南下して、思ったほど混んでいなかった銀座を通過。 JR の終日運転見合わせ発表をここで知る。徒歩を選択して正解だった。 新橋で汐留通りに入って大門交差点・芝大門交差点を通り裏から芝公園グランド前交差点と進み日比谷通り。
ここで様子見がてら田町の実家へ立ち寄り。 トイレのガラスのヒビ割れ・風呂釜と浴槽のずれのせいと思われる漏水等の被害があったもものとりあえず母も無事のようで一安心。
トイレ休憩とバナナでの栄養補給(と母のグチの付き合い)を済ませて再び出発。
田町駅西口交差点の陸橋下西側の歩道のバス停あたりが非常に混雑していたので、引き返して横断歩道を渡り、ここからは第一京浜の東側の歩道を南下。
ずっと人の波が続いているけれども普通に流れており不快感を感じるほどではなかった。 第一京浜は田町駅・品川駅間では徒歩的に遠回りすぎない裏道が無いためもっと混雑していることも覚悟していたのでほっと一安心。 札の辻の歩道橋も予想外にスムーズに渡れた。
途中、徒歩帰宅者にプリントアウトした地図を配布している不動産屋や、ウォーターサーバを出して水を提供しているどこかのオフィスのボランティアなどに感銘しつつ品川駅前へ。
そのまま八ツ山橋交差点・新八ツ山橋交差点を通過。 警察が車道を一部臨時に歩道にしてくれていて、ここも混乱なく通過。
あとは途中で住宅街の裏道を通って無事帰宅。
ここまでの旅程はTwitter 上に記録。 途中実家立ち寄りをのぞけば、だいたい普通の徒歩の速さで到着できた。
早く帰宅するのにできるだけ立ち止まらないで歩き続けたいが、歩きながらスマートフォンに目を落とすのは他人への迷惑を避けることも考えて少な目にする必要がある(遠距離の人ならバッテリセーブの点でも)。 情報収集・状況の発信・家族・知人友人との安否情報交換などのためにアクセスしたい気持ちとのジレンマだ。
なお「周りのペースにあわせて歩けない人のケータイ利用」は迷惑。気持ちはわかるけどさ。 あとおしゃべりしながらの「2人以上組」もうちょっと状況を理解した方がいいかと。
都心でのこれだけの人の一斉徒歩移動はめったにできない貴重な経験であった。 (天候・服装・被災状況・パケット通信状況・ネットサービス状況などの)コンディションが今回はまだかなり良かったが、これが直下の場合はもっと過酷なものとなるのであろう。 今回の経験を生かせればと思う。
[ 東日本大震災 ]
東北地方太平洋沖地震当日に徒歩帰宅を経験したわけだが、ケータイのパケット通信が通常通りに使えた(NTTドコモ)ので、移動中もメール・Twitter・Facebook 等が利用できとても助かった。
余震が続いているし計画停電(輪番停電)の話も出ていることから、長時間の徒歩移動あるいは電車待ちが今後必要になることが十分考えられる。また停電中の情報収集手段としてもラジオ以上にスマートフォンがあると安心だ。
ということで Xperia の電源用として eneloop mobile booster KBC-L2BS を買っておくことにした。 昨年の YAPC::Asia Tokyo 2010 の時に欲しいと思ったんだけれど、まだ発売日前だったので見送ったやつ。 週明けではもう売り切れている可能性があるなと思って、本日午前中に近くのヤマダ電機 LABI に行って購入。なお懐中電灯・単1形乾電池などは既に売り切れ。 ケータイ用電池式充電器も完売してた。 電池系はしばらく入手しにくくなりそうだ。
DC5V/1A で2時間出力できる。バッテリ2個とこれがあれば随分 Xperia を連続運用できるはず。
この間買った充電式ニッケル水素電池タイプのソニーの USB 出力機能付きポータブル電源 CP-AH2Rは自宅で置いておいて、停電時の妻の FOMA 端末充電用として使うことにしよう。
東北地方太平洋沖地震後、当然固定電話・ケータイとも輻輳のため通話規制が実施されて、電話がかなりつながりにくくなった。 一方でパケット通信は通常通り利用できた(NTTドコモ)のはちょっと驚きであった。 ADSL 接続も問題なく、また海外のサービスである Twitter・Facebook も落ちることなく利用し続けることができた。
このため今回は移動中の人から/へ連絡のとりやすさの順は「Twitter や Facebook 等の SNS > ケータイメール > 通話」であった。
おりしも社内でも Facebook が流行りはじめていたこともあって Twitter とあわせて、特に直接連絡をとることなしに何人かの地震当日夜~翌朝の帰宅状況を知ることができ、一安心できた。逆に利用していない人の安否は次の出社まで不明であった。
もう小規模組織の1次安否情報システムは Twitter + Facebook でいいんじゃないかと思う。 ちょっと比較してみよう。
ケータイメール | 電話 | ||||
安否登録 | Tweet | ウォール投稿 | メール送信 | 通話(発信) | |
安否確認 | タイムライン /リスト | ニュースフィード他 | メールで | 通話(着信)・要記録 | |
複数人に伝わるか | ◎ | ◎ | △ (明示的に送信) | × | |
ケータイから | ◎ | ◎ | ◎ | ◎ | |
PC でチェック | ◎ | ◎ | ○ | × | |
あわせて最新情報収集 | ◎ | ○ | △ | × | |
通信料 | △ | △ | ◎ | ○ | |
事前の使い込み | 必要 | 必要 | 普通に使っているでしょう | 不要 | |
プライベート分離 | ×*1 | ×*2 | ○ | ○ | |
事前連絡先交換 | follow | 友達*3 | メールアドレス交換 | 電話番号交換 |
Twitter と Facebook については普段から活用してないと災害時に急にというのは難しい。また事前に follow しあっていたり友達になっていたりする必要があるので、人間関係がよろしくないと NG。
その辺りがクリアできれば、全員がわざわざ管理職にメールしたり電話したりしなくてもすむようになって手間・時間的にかなり楽になるはず。
なお mixi はそこに構築されているソーシャルグラフの関係上、企業組織内の安否確認としては推しにくいかと(ともだち同士の安否確認としては非常に有効。今回この地震を受けて「友人のログイン状況」という機能も今日リリースされた)。
話し方などで感情や様子を感じるにはやはり電話がベストだが、そもそも安否確認の時点では電話はつながらない前提で一番優先度の低い通信手段と捉えるべきたと思う(電話するなら家族へを優先するし)。
今回の地震が、スマートフォンと Facebook がより普及しているであろう半年後であれば、もっとこれらが活用されていたに違いない。
緒連絡や近況のシェアなどにカジュアルに使うことを目的として使い始めていた Facebook グループを、地震2日後の夜に全社向けメーリングリストで案内したところ、何人も新規登録してきてくれた。 この大震災をバネに、よりコミュニケーションが深まって組織の結束力が強くなるといいと思う。
[ 東日本大震災 ]
「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。
このチームが自主的に決めたワーキングアグリーメント(記事)に
スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」
というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。
環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。
開発メンバからは以下のような意見が出ました。
自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。
スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。