nDiki : 意思決定

今日のさえずり: 浴衣コスらせてる

2010年08月19日

• 09:29 今朝は洗濯物を外干しにするか部屋干しにするかの意思決定をせまられる天気予報。
• 09:50 缶コーヒー 100円。
• 12:07 今度の日曜日 10:30 で床屋予約。ずいぶん伸びたな。
• 12:16 弁当とコーヒー 396円。 (@ ライフ 神田和泉町店) http://4sq.com/aMU2tQ
• 12:57 Google マルチ ログイン設定きた。とりあえず有効にしてみる。
• 14:53 Strawberry Perl を 5.10.0 系から 5.12.1 系へアップデートする。
• 15:42 Strawberry Perl で CPAN モジュールを使って Perl モジュールをインストールしようとした際に、"Couldn't move... と出るのは Norton Internet Security のせいか。止めたら進むようになった。
• 15:59 @bulkneets なるほど、ありがとうございます。他にも同様な目にあったりしたのはこれが原因かもしれないです。
• 18:47 中継観られそうなので急いで帰る。
• 19:29 急いで帰ってきて花輪ばやしの中継に接続したところ。まだ駅前には屋台きてないな。
• 19:56 屋台きた。
• 20:03 浴衣コスらせてる。
• 20:11 谷地田町きた。
• 21:37 駅前から屋台退場。中継満喫。
• 23:14 お祭り(リモート)なので金麦飲んだ。
• 23:27 久しぶりに Perl で GUI つけたいと思ったら Padre に辿り着いた。Perl で書かれた Perl IDE とか、オシャレすぎる。

今日のさえずり: 1/f ゆらぎを導入すれば bot も心地よくなるかな

2011年06月13日

• 09:47 @rtmjp iPad でのリストの並び順変えられるんですか? ぜひ手順を教えてください! (ちなみにリスト内のタスクの並び順じゃなくてリストの並び順です)。
• 09:58 @rtmjp いえいえ、わざわざありがとうございます。リストの並び順変更ができるか、Web 版の並び順と同じになると嬉しいです。指定リストの非表示ができるともっと嬉しいです。
• 11:14 週末と今朝で Remember The Milk ルーチンワーク見直した。これでスムーズ感が少し戻るはず。
• 11:39 mixi 「足あと」機能改修。昨日の時点で総アクセス数 184352 だった。 #mixi
• 11:45 先週末納税通知書が届いていたのでそれをもって、特別徴収のお願いしてきた。
• 12:39 若鶏唐揚二段弁当 450円。 (@ ローソン渋谷東一丁目店) http://4sq.com/jUQIGi
• 13:29 「先週の訪問者」きた。
• 14:05 ちょうどいい機会なので次の説明会は iPad でノート取ってみるよ。
• 20:54 退勤。

2011年06月14日

• 09:20 告白手当とかいいな。
• 09:25 RT @s_harada: 人のコードは平気で糞だと言うくせに、プロダクトに関して糞だと言えない時点でやっぱり部署間の空気の違いを感じる。
• 12:49 渋谷駅周辺で RODHIA 安く売ってるのどこだろ。
• 12:51 キムカル丼 490円。 (@ 松屋 渋谷宮益坂店) http://4sq.com/kS7ZiQ
• 12:53 1/f ゆらぎを導入すれば bot も心地よくなるかな。
• 13:20 ヒグチで FRISK 165円。この辺りで底値か。
• 17:12 iPad 2 の書類出した。
• 17:13 1フロア上のコーヒーの方が若干濃い。若干ね。
• 17:56 iPad 場所を変えて何か検討するときにいいね。タイピングもまあまあいける。親指2本で。
• 21:27 意思決定会議が不足している。
• 21:49 退勤。
• 22:03 ソースコードのフォーマットは基本的には郷に従え(ただし死んだバッチャンの遺言によるところは除く)。

ミッションはクールか? ビジョンは誰のか? バリューは一致するか? ゴールは知的か?

ミッション→クールか? ビジョン→誰のか? バリュー→一致するか? ゴール→知的か?

— Naneyさん (@Naney) 2013年4月11日

ミッション・ビジョン・バリュー・ゴールは、どんなものだとリーダーとメンバがシェアして同じ方向に向かっていけるのだろう? 考えてみた。

ミッションはクールか?

そのミッションの T シャツ作って着て街を歩けるか?

いつも心の中に置いておけて他人に熱く語れるクールなのがいいよね。あと難しい熟語とかカタカナ語とか入ってないと良い。

ビジョンは誰のか?

そのビジョンは、一緒に実現したいと思うリーダーが本気で立てものか?

同じ内容でも「このリーダーだったら一緒に実現させたい」「この人のビジョンなのか……」というのは少なからずある。

もし組織のではなく、自身のビジョンについてであれば、それは与えられたものではなく自分自身が考えたものでないと。

バリューは一致するか?

そのバリューは自分の価値観と一致するか?

価値観は個々の意思決定基準につながっていくから、ここは組織のバリューが自分のバリューとマッチしていると迷いが無くてハッピー。大きく相反していなければ、うまく融合させていければいい。

ゴールは知的か?

そのゴールは SMART か?

ここがふわっとしているとアクションもふわっとしてしまうから、ここはカッチリが良い。

金曜日健歩したいんですよとか【日記】

金曜日に会社休んで健歩したいんですよ。ケンコウゾウシンしたいんですよ。

この間の日曜日が予定の日だったんだけれど、雨の予報だったんで見送って(結局晴れたので TCK 行って)、次の候補として金曜日をターゲットにした訳ですよ。で週間天気予報を毎日見ているんだけど、日に日に降水確率が高まって、ジャン、傘マークつきました。

また意思決定が迫られているのです。

1. 大前提として雨だといろいろ面倒でかつちょっと不快。
2. 土曜日より金曜日の方が天気予報が悪いというリスクと、土日より平日の方が空いているというリターン。
3. 予報を見て見送ったら、晴れてしまった体験。
4. 限られた健歩大会開催日。先送りすると後が無くなる。
5. 金曜日はやめとくとなると有給休暇その他も含めて再調整が必要。
6. 金曜日行けちゃえば、土曜日に床屋とか行きたい。
7. 見送ったら要弁当手配。

いろいろ悩ましくはあるんだけれど、こうやって書いてみているとまあ気分を除いては金曜日でしょうという感じに思えてきたんだけど、まあその気分のウエイト大きいのよね。あまりカメラ濡らしたくないし。

ということで最終決定的には明日の夕方の天気予報を見つつ、雨の予報でも当日朝「あー、晴れたよ行けたよ……。」ってならないように、スタンバるって感じかな。

意思決定基準とか【日記】

やるか、やらないか。

個人としては「わくわくする方を選ぶ」というマイクレドがありますが、それ以外にもいろいろと判断基準を言語化しておく必要があるなと感じた1日でした。

TOKYO CS JAM #2 「最高のチーム/組織づくり」

株式会社メルカリ主催の TOKYO CS JAM #2 に参加してきました。メルカリ主催の CS 系イベント参加は今日が3回目。いつもありがたく参加させていただいております。

• 過去の参加
  • Drink Meetup with Mercari #7
  • Drink Meetup with Mercari #22

CS JAM は

「CS レベルアップのための企業混合 Study Session」をコンセプトにした Customer Support 業界 (Customer Experience, Customer Service, Customer Success なども含む)を盛り上げるための、勉強会、交流会的なコミュニティイベント -- http://csjam.connpass.com/event/33258/

で東京開催は今回が2回目。メルカリは CS に関するイベントを積極的に開催されています。ネットサービス関連のスタートアップ事業/ベンチャー事業界隈での CS 交流については、メルカリが主導してくれているといっても過言じゃないと思います。

今回のテーマは「最高のチーム/組織づくり」。2つのセッションに分かれていて前半は「株式会社メルカリ 山田和弘氏」「ランサーズ株式会社 冨樫謙太郎氏」「freee株式会社 中島伸吾氏」によるパネルディスカッション。去年のスクーの「スタートアップCS担当によるカスタマサポートの極意」というオンライン授業の続編という位置づけで、その時のモデレーターだった大木しのぶさんが進行をされていました。トークと仕切りはさすがの超プロでした(スクーの宣言もうまく織り交ぜてたり)。

そして後半はそのディスカッションを踏まえての各テーブルごとのグループディスカッションです。

グループディスカッションの時間は30分。私たちの7人のテーブルは「組織文化」がお題でした。模造紙に発表内容を書き出すのも含めて30分はあっという間です。ディスカッションでは組織において「大切にしたい考え方」をきちんと共有・浸透させていくことが重要だという切り口で「ロールモデルとなる人を軸に組織に新しく入る人も含めて定期的に共有していく機会を作っていこう」という結論になりました。

30分ではもちろん議論が尽くされたとは言いがたいのですが、ほぼ初対面の方々と集中してまとめていくというワークは良い刺激になりました。

山田氏が締めの言葉で「ネットサービス業界とその CS 部門では、スピードある意思決定と対応が必要」と言われたのを聞き、今日のグループディスカッションの30分の意味をあらためて理解したのでした。

限られた情報と時間の中で不完全な状態でも答えを出して走りだし、フィードバックを得ながら方向修正しつつ進んでいく仮説思考の大切さを思い出させてくれる良い機会になりました。

何度か意見交換させていただいているメルカリの方と久しぶりにお話できたりもして今日は良い刺激を得られるセッションでした。メルカリの方々・登壇者の皆さま・参加者の方々ありがとうございました。

(画像は http://csjam.connpass.com/event/33258/ より。)

「権限の7つのレベル」の訳語

Jurgen Appelo 氏の Management 3.0 では「権限の7つのレベル(The Seven Levels of Authority)」として以下を挙げています。

1. Tell
2. Sell
3. Consult
4. Agree
5. Advise
6. Inquire
7. Delegate

権限が委任/移譲されているレベルが高いほど数字が大きくなります。委任/移譲が段階的であることなどを学ぶデリゲーションポーカーではこの7レベルを使ったり、デリゲーションボードでこの7レベルで共有したりします。

訳語は人によっていろいろあるようです。

1. harakachi 氏・NuWorks合同会社の場合

http://qiita.com/harakachi/items/d75461402815d76b12c5

http://nuworks.jp/ja/2016/12/09/deligationpoker/

1. 命令する(私が彼らに決定を伝える)
2. 説得する(私が彼らに売り込む)
3. 相談する(彼らに相談し私が決める)
4. 同意する(私と彼らが合意して決める)
5. 助言する(私は助言するが彼らが決める)
6. 尋ねる(彼らが決めた後で私が尋ねる)
7. 委任する(私は彼らに完全に委ねる)

2. Ryuzee.com の場合

http://www.ryuzee.com/contents/blog/3669

1. 指示する: 管理者として意思決定を行う
2. 売り込む: 意思決定についての人々を納得させる
3. 相談する: 決定する前に、チームからの意見を得る
4. 同意する: チームと一緒に決定を下す　
5. アドバイスする: チームによる意思決定に影響を及ぼす
6. 問い合わせる: チームの決定後のフィードバックを求める
7. 移譲する: 特に影響を及ぼさずチームに任せる

3. エッセンシャル スクラムの場合

今読んでいるエッセンシャル スクラムでも「7段階の権限」として取り上げられていて以下の訳語があてられています。

1. 通知
2. 説得
3. 相談
4. 合意
5. 助言
6. 確認
7. 移譲

しっくりきそうなもの

好みの範疇なのでどれでも良いといえば良いのですが、単語によって自分の感覚だとこの組み合わせかなというのを考えてみました。

1. 指示する
2. 説得する
3. 相談する
4. 合意する
5. 助言する
6. 確認する
7. 移譲する

こんな語感かなと。実際にチームで使う時は harakachi 氏が挙げている 1. にしようかなと思っています。

第13回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー。

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

• チームを編成する
• チームを育てる
• 環境を合わせてなじませる
• 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

第14回 エッセンシャル スクラムを読む会

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の14回目。今日は第14章 スクラムのプランニングの原則。

原則とは?

今回は「原則」の章ということで、今日の発表当番だった CSM の人があらためて「原則とは?」という点について掘り下げてくれました。「価値とプラクティスを結ぶ」原則について

「原則なしに上辺だけプラクティスを実行してても意味ないよ」

と CSM の人が語ってくれました。「アジャイルソフトウェア開発宣言」と「アジャイル宣言の背後にある原則」についてその場でみんなで見返しました。

事業体としての価値観と原則、個人としての価値観と原則、そして開発プロセスフレームワークとしての価値観と原則と、この辺り自身でも整理しないとなと最近考えているところです。

プランニング

プランニングについては出来上がった計画よりも計画のための対話などのプロセスが重要なのだなと最近感じるようになりました。

• 事前にきちんと計画を作れると思うな
• 計画を守ることよりも、計画の調整や再計画を重視する

ということで継続的にプランニングし直していくことが大切なのだなと。

14.4 プランニングの選択肢は、最終責任時点まで変更可能にする

についてはここではかなりあっさりとかかれています。物事を進めるには常に大小様々な意思決定をしていく必要があるので、さらっと読むと気持ちわるい感じがします。ここは 3.3 節にも

重要で後戻りのできない決定をしかるべき最後の瞬間まで行わないのである。

とあるので、方向転換できない状態に早い段階でならないようにするといったところなのだと理解しました。

14.7 早めにリリース、頻繁にリリース

については原則として頭にいれつつ、実際には適切なフィーチャーが揃っているかをきちんと考える必要がありますね。あまりに小さなリリースすぎて早い段階でユーザーに見限られてしまう危険性や、頻繁な変更によってユーザーが負担を感じて満足度が低下してしまう可能性も常に意識すべきかと。

この章でも

この手法には限界もある。まずどんなプロダクトであっても、最低限これだけは揃えないとリリースできないし市場で勝負できないというフィーチャー群がある。

と言った上で

もし部分的にでもよいから少しでも早めに受け取りたいという業界を相手にしているのなら、小さい単位で頻繁にリリースするという原則はとても重要になる。

としていました。

• エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

今年は自分の頭で考える

何かを考える時、何かを書く時、何か良い情報はないか頼れる正しい意見はないかと必要以上に情報を探してしばしば時間をかけすぎてしまいがちです。気が付けば内容も他人の意見をまとめたものになってしまうことも。

今年は「自分の頭で考える」をより意識してみることにします。

情報を遮断する

自分の意見を考える時、情報を探しにいくプロセスをいったん止めてまず自分の頭で考えて書き出してみる時間を作ります。 PC を使っているとついつい調べたくなるので

• 紙のノートとペンをもって PC から離れる。
• distraction free なテキストエディタ(Ulysses や iA Writer など)をフルスクリーンモードにする。

のどちらかの環境にして情報を遮断して考えるようにしてみます。

きちんと文章化する場合は、考えがまとまった後に初めて用字用語の校閲やハイパーリンク付ければいいかな。

毎日考える時間をとる

意思決定をするとか意見を出すとかそういった決まったトピックについて考えるのとは別に、毎日考える時間をとって主体的に仕事をし生きていくようにも今年はしていきたい。こちらは1日15分などと時間を区切り、その時間の中で情報を遮断して湧き上がるアイデアや考えをまとめて行動につなげるようにしていきます。