nDiki : 意思決定

意思決定 - decision-making

スポンサードリンク

2004年4月17日 (土)

■ トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解

今年の1月からプロジェクトマネジメントをいくつか担当することになったのだが、まだまだ経験不足。ということで遅ればせながら、「ゆとりの法則」を読み始めた。誤った方向にマネージメントを進めていく前に手に取ってよかった。

社長からの「何をやっていいのかわからないスタッフがいるのでどんどん指示を出して、遊んでいる時間(指示待ち時間)を作らないようにして欲しい」というリクエストに違和感を感じていたのだが、この本の中にはその違和感が何かが説明されているようだ。

「適応型ソフトウエア開発」でも管理するのではなくリーダーシップをとってコラボレーティブにプロジェクトを進めていくといったような事が書かれていたと思う。

頭では理解しているのだがなかなか実践できない。プロジェクトのスケジュールをにらみつつ、またチームをまとめつつ意思決定を下していく技術を身につけなくては。一技術者としての能力を向上も忘れずに。

ゆとりの法則

[ 書評 ] [ お薦めの本 ] [ コンピュータ書籍 ]

スポンサードリンク

[ permalink ]

[ 4月17日全て ]

2005年7月4日 (月)

■ すごい会議の正しい手順

すごい会議FAQによると、付録の手順には誤りがあるらしい。

「最初の1、3、5が準備段階で一人でやる部分で、2からが参加者と一緒にやる部分」すごい会議FAQより。

とのこと。すっきり!

手順5がミーティング前に行うというのは自明なのでミーティング時にはパスしていた(事前の招待メール時に適用)。
その前に手順1、手順3 がくる事で手順5がパワフルかつ明確にできるようになると。
手順3。どおりで出席者が悩むわけだ。今回は既に走っているプロジェクトのメンバだった事からある程度方向性を共有していたのでそれなりに書けていたんだけれど、これは1人でやる手順なワケね。手順3と手順9がかぶっていて進をちょっと迷ったのだが、これですっきり。

@ 答えを作らない場所

また次の点も非常に参考になった。

ここでは、手順6、7、8は答えを作る場所ではないのです。問題を前向きな形でたな卸しするだけです。「答え」を提示する人がいたら、それはストップします(経営者自身がやってしまいそうになることも多くみます) ここで、誰かが「答え」を言ってしまうとドチッラケなのです。その答えが、各自、意識的または無意識のうちに手順11でコミットメントとしてその解決策が約束される可能性を最大化するためにやっているとお考えください。-- すごい会議FAQより。

もしや、思いっきりドッチラケだった?

さすがに手順8では答え作りしなかったけど、手順6、手順7では思いっきりアイデア出しに利用しちゃってたからなぁ。

初期の頃やっていたミーティングでは、手順6までしか時間的に進まなかったこともありそこでコミットメントに落としてしまっていた(担当と期日設定)。
先週の木金でやったミーティングでは、全手順を通してやるために手順6、手順7ではアイデア出しまでやった後、先に進めてみた。手順11でコミットメントを作る際、手順6、手順7で上がったアイデアを漏らしてしまわないかちょっと心配だったんだけれど、もともと答を作る場所でなかったのでなければ構わなかったということか。

@ リストにしてオシマイ

光栄な事にまた著者の大橋禅太郎氏よりコメントをいただいた。

初期のころの「この会議で達成したいことはなにか」を発表してもらってから、司会者がどうすればいいか? といったところがありましたが、司会者は特にそれについてはなにもすることはありません。そのほかにもグループとしての統一した「意思決定」がなくても進むやつは、リストにしてオシマイです。

ありがとうございます。非常に参考になります!

手順を眺めてみると、参加者と一緒にやる部分のうち前半はリストにしておしまいだ。確かにすごい会議の本文でも、実際に出席者が順に発言するところが描かれているけれどそれ以上は書かれていない。

そこに書かれていない何かをしているんじゃないかなとも思ったのだが、本当にリストアップだけで良かったのか。安心。

となると合意は

戦略的フォーカス
担当分野と担当
コミットメント・リストと、そのチェックのしくみ

となる。

やはりすごい会議は最後の手順までやらないとオイシイところが食べられないわけだ。ふむふむ。

はやく次のすごい会議の機会こーい。

[ permalink ]

すごい会議で、どの手順で前のどの手順を参照する? 何を記録しておく? (2005-07-07)
「すごい会議」2度目 (2005-06-03)
「すごい会議」をしてみる (2005-05-27)
すごい会議はじめての全手順(1/2) (2005-06-30)
すごいKPT事後評価セッション (2005-10-07)

[ 7月4日全て ]

2005年7月16日 (土)

■ 早朝会議革命 - 元気企業トリンプの「即断即決」経営

トリンプの吉越浩一郎社長による「会議を通したスピード経営」についてを、会議出席や社員へのインタビューを通して著者がまとめあげた1冊。

会議を中心とした内容であるが、「すごい会議」と同様ただ単に会議手法を述べた本ではない。会議を通した経営についてが述べられている。

同社のMS会議 (Marketing and Sales 会議) は吉越社長が自部門の改革として始め、粘り強く改善・継続して全社的なものになったもので、そう簡単に真似ることができるものではないが、そのエッセンスには学ぶものが多い。

@ 朝開催

多くの人間が集まる時間帯。
集中できる時間。
同日に即行動に移せる。

特に最後のは魅力的。やる気がみなぎっている間に行動に移せる。しかし、自分はオフピーク通勤が気にいっているからなぁ……。

@ 毎朝開催

当然週1回よりスピードがある。

回数は多いが、きちんと問題について意思決定しコミットメントに落としていくので無駄がない。

@ トップダウン

ただし民主的、フラット。

@ 「決める」会議

「誰が、何を、いつまでに」

ここら辺はすごい会議と通じる。

@ デッドライン

ドイツ系の会社から。
厳しく。でないとみんな逃げる。
最大限で1週間。それ以上はスケジュール化。
稚拙でもいいから速く。

毎朝会議が開催され議論されることで、1週間でまわしていける。

@ プレゼンテーション

プレゼンテーション自体を目的にしない。無駄に準備に時間をかけない。

@ コミュニケーションの場・情報共有の場

「和」を形成。
共通認識が広がる。
判断・決断までのプロセスを共有。プロセスから参加することに意味がある。
- 意思決定に変化があっても理解できる。
- 教育の場
  - 技は盗むもの。「教育なんてほんとはできっこない」。
オープン、フェアネス。

見習いたい。どのようにすれば我社で判断・決断プロセスから共有していけるようになるだろうか。

@ 継続

継続はトップの責任
改善こそ継続の母
成功するまでやれば、成功する。p.207

@ 結論から言え

言いにくくても、結論から言え。p.207

@ 感想

「決める会議」、「誰が、何を、いつまでに」という方針のメリットを再確認。

早朝会議革命 - 元気企業トリンプの「即断即決」経営

[ 書評 ] [ お薦めの本 ]

[ permalink ]

[ 7月16日全て ]

2006年4月10日 (月)

■ ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

@ ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

@ issue tracking

開発中に発生する

モジュール間のインタフェースの問題点(あるいは不明点・疑問点)などの確認/議論の必要なもの
ライセンス関連の問題など意思決定を要するもの

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

@ インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

@ 止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。技術不足とかそういうこととは関係なし。もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

[ permalink ]

[ 4月10日全て ]

2006年5月5日 (金)

■ ビジネスメールガイドライン案

以前メールによる社内コミュニケーションの問題について書いて以来、いろいろと考えてみている。

そんな中、東洋経済新報社の「Think! SPRING 2006 No.17 超ロジカルシンキング」の中に参考になる記事を発見。照屋華子氏の「ロジカル・ライティング - 論理的に考え、伝えるための3つの鍵を身につける」という記事だ。

すべてのビジネス・コミュニケーションは「伝え手」「受け手」「テーマ」「答え」「期待する反応」という5つの基本要素で成り立っている。-- Think! SPRING 2006 No.17 p.43

おお、ちょうどこういう切り口を探していたところだったんだ。電子メールによるコミュニケーションも全く同じ枠組みである。記事の中ではロジカル・シンキングをコミュニケーションで生かすという話題を中心に展開しているが、十分メールの書き方に通じるものがある。

この記事と、さらにちょっと前に買った「SEの実力を磨く究極仕事術」のメール術の章を参考にガイドライン案のスケルトンを作ってみた。

感情論は今回は置いておいて、情報共有・課題共有・リクエストの明確化・処理促進をポイントに列挙。それから署名その他、一般的な話もいまのところ省略。

ポイントを列挙しただけなので、他人にもわかる形にはなっていない。

まずは自分自身に適用して、整理していってみることにする。

@ 1. 考える

【伝え手】伝え手は誰? (自分)
【受け手】受け手は誰?
【テーマ】テーマは何? 問いの形で。メールのテーマは1つに絞られているか?
【答え】テーマに対する答え(テーマに対する説明)は何?
【期待する反応】受け手に期待する反応は何?
- 誰に、いつまでに、何をどうして欲しい?
コミュニケーション手段としてメールは適切?

@ 2. メールを書く

 ○○様へ                     # 受け手

 △△の××(自分)です。       # 伝え手

 テーマ
 ******
 コミュニケーション設定

 ○○の結論                   # 答え (結論)
 ==========
 ...

 (ここまででポイントを言いきる。)

 具体的な内容                 # 答え (詳細)
 ============

 項目1
 -----
 ....

 - リスト項目
 - リスト項目

 項目2
 -----
 ...

 - リスト項目
 - リスト項目

@ サブジェクトを書く

見ただけでわかるようにする
- □ 具体的に書く

@ 導入部を書く

コミュニケーション設定を行う。

□ 冒頭に宛先【受け手】を明記する。(誰に読んで欲しいのか? 他に誰に送られているのか?)
□ 次に発信者【伝え手】を明記する。(From: フィールドに頼らず書く → 印刷・コピー用)
□ 【テーマ】を書く。
□ (オプション)【テーマ】の経緯・背景を書く。(「なぜこのテーマのメールがくるの?」)
□ (オプション)なぜこの【伝え手】からなのかを書く。(←「なぜあなたからリクエストされるの?」)
□ 【期待する反応】を明記する。
- □ 「誰が」「何を」「いつまでに」「どのような品質で」して欲しいのかを書く? (← 「で何をして欲しいの?」)
- □ 反応のメリットを書く (←「なぜこの反応をとらなければならないの?」)
- NG 「ご意見があればお願いします」 → ない場合は?
- NG 「どちらが良いと思いますか?」 → 意見として? 決定として?
- NG 「ご検討ください」→ 検討した後どうして欲しいのか?
□ (オプション)なぜこの【受け手】に読んでもらいたいのかを書く (←「何で自分なの?」)
□ 特記事項があれば書く
- □ 答えの情報源など

@ 答え (結論)

結論を書く。

□ 詳細まで読まなくても済むようにする。
- NG 「以下のように……」 → 要旨を書く
- NG 「添付ファイルの通り」 → 要旨を書く

@ 答え (詳細)

根拠・資料などを書く。

□ 受け手から見て必要十分な情報を書く
- NG 「添付ファイルの通り」 → 要旨を書く
□ 受け手が読みやすいように書く
- □ リスト化する

@ 全般

□ 具体的に
- NG 「来週までに……」 → 「×月×日までに……」
- NG 「先日の……」 → 「×月×日の……」
- NG 「この間の……」 → 「×月×日の……」
- 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
□ 論理的に
- □ 構造化する
- □ リスト化する (箇条書き化する)
□ 受け手が読みやすいように
- □ フォーマットを工夫する (ソフトウェア技術者間なら reStructuredText がお薦め)