nDiki : 意思決定

2004年4月17日 (土)

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

rimage:ISBN:4822281116

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

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

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

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


[ 読書ノート ] [ お薦めの本 ] [ コンピュータ書籍 ]

スポンサード リンク
[ 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で上がったアイデアを漏らしてしまわないかちょっと心配だったんだけれど、もともと答を作る場所でなかったのでなければ構わなかったということか。

リストにしてオシマイ

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

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

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

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

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

となると合意は

となる。

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

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

[ 7月4日全て ]

2005年7月16日 (土)

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

rimage:ISBN:4822243516

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

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

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

朝開催

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

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

毎朝開催

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

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

トップダウン

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

「決める」会議

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

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

デッドライン

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

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

プレゼンテーション

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

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

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

継続

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

結論から言え

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

感想

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


[ 読書ノート ] [ お薦めの本 ]

[ 7月16日全て ]

2006年4月10日 (月)

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

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

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

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

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

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

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

issue tracking

開発中に発生する

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 30分ルール

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

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

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

[ 4月10日全て ]

2006年5月5日 (金)

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

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

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

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

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

SEの実力を磨く究極仕事術

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

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

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

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

1. 考える

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

2. メールを書く

 ○○様へ                     # 受け手

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

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

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

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

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

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

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

 項目2
 -----
 ...

 - リスト項目
 - リスト項目
サブジェクトを書く
  • 見ただけでわかるようにする
    • □ 具体的に書く
導入部を書く

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

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

結論を書く。

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

根拠・資料などを書く。

  • □ 受け手から見て必要十分な情報を書く
    • NG 「添付ファイルの通り」 → 要旨を書く
  • □ 受け手が読みやすいように書く
    • □ リスト化する
全般
  • □ 具体的に
    • NG 「来週までに……」 → 「×月×日までに……」
    • NG 「先日の……」 → 「×月×日の……」
    • NG 「この間の……」 → 「×月×日の……」
    • 説明は肯定形で書く (否定形だと具体的に何なのかわからない)
  • □ 論理的に
    • □ 構造化する
    • □ リスト化する (箇条書き化する)
  • □ 受け手が読みやすいように

3. 送信する

  • □ 送信する前に見直す
    • □ typo チェック
    • □ スペルチェッカ通す

A. メールを受信した時

まず返信する

どれか

  • リクエストを「受ける」 / 返信で処理する (意思決定を返すなど)
  • リクエストを「断わる」
  • 「別の提案をする」
  • 明確化の質問をする

メールでは不適当と思ったらコミュニケーション手段を 直接 / 電話に切り換える。

B. 返信する時

サブジェクト
  • □ テーマが変わったら書き換える
[ 5月5日全て ]

2006年9月15日 (金)

[ 映画鑑賞 ] 太陽

rimage:ISBN:4-7783-1028-4 ロシアのアレクサンドル・ソクーロフ監督による、昭和天皇ヒロヒトを描いた作品。

チネチッタ CINE 6

今日は「朝一番で見にいこう」ということで川崎チネチッタで 9:20 の回で鑑賞。 客数は 10名前後。

太陽

物語は過去のフィルム風の薄い色合いのトーンで、静かに淡々と進んでいく。 派手な動きはなく静かなのだが、何とも言えない張り詰めた緊張感が続く。

「嫁のバカ」の「アトムおじさん」など一人芝居のプロであるイッセー尾形はまさにヒロヒトの適役。 苦悩する孤独なヒロヒトを演じきっている。

最後に出てきた桃井かおりは個人的にはちょっと違和感があり。

天皇/皇室については特に思い入れもなく、私にとってはニュース・特番の中の存在である。 そんな私でも劇中天皇が米兵や記者、マッサーサーから非礼な扱いを受けるとなぜか憤りを感じてしまうのは、日本人であるが故であろうか。 それとも単に主人公に感情移入したからだけであろうか。

アメリカ大使館で、誰も開けてくれない扉を現人神自身が開けるシーンはかなり印象的だ。

ヒロヒトは苦悩する。当時得られた情報量からするにかなり悩んだ上で意思決定をしていったに違いない。

上映後、後の方の席で観ていたらしい杖をついたお爺さんが階段を降りてきた。 お爺さんはどんな風にこの映画を受けとったのだろう。

「あっ、そう」

image:ASIN:B0000DJWIK

[ 9月15日全て ]

2006年11月22日 (水)

プロジェクトマネジメント」はどうやって勉強すれば良いですか?

会社の後輩から問われた。

答えがあればこちらが知りたい。

プロジェクトマネージャには、そういう事を自力で模索し掴みとる能力が必要なのではないか。プロジェクトマネージャは答えの決まっていない問題の解決をしていかなければならないのだから。

もちろん他の人から学ぶというのも重要なので、質問すること自体は悪くない。 ただもう少し自分で考えてみて「○○と△△というのがあり、○○の方が~~で良さそうだと思うのですがどう思いますか?」などと、やるのが良いかと思う。

ちなみに私がどう試行錯誤しているか、何を読んでどう考えたかはココ (nDiki) に書いているから、後輩君なら(反面教師にせよ)見てくれればいいと思う。

ていうか、何か面白いもの見つけてきてドンドン紹介してクレ。

とはいえ自分なりに列挙してみる

ソフトウェアプロジェクトマネジメントで、必要なキーワードを思いつくままに挙げてみた。

[ 11月22日全て ]

2010年1月21日 (木)

まだ ADSL モデムレンタルしているんですか?

自宅に ADSL を引いたのが2002年4月。その頃は ADSL もまだ変化が激しかったので ADSL モデムADSL スプリッタレンタル契約した。 しかし気がつけば、もうすぐ8年。毎月490円(440円 + 50円)使用料を払い続けている。ずいぶん払っちゃったなあ。

ADSL モデムレンタル中に1度故障して交換してもらったことがあり、購入時のリスクを考えてつい今までズルズルとレンタルしていたというのもあるのだが、これ以上レンタルし続けるのももったいないので、買い取ってしまうことにした。 この古い機種を買い取るのもなんだかという気もなくはないが、まあまず安定しているしすぐには壊れないだろうし(と期待したい)、なによりレンタルし続けるのはそれ以上に馬鹿らしいので。

116 に電話して買い取り価格を確認。7年以上8年未満なので ADSL モデムが 1,700円。ADSL スプリッタが100円。 その電話でそのまま買い取りをお願いした。

今月の使用料は昨日までの20日分の日割計算。買い取り費用は ADSL の月々の費用と合わせてどこかのタイミングで請求されるとのこと。

意思決定すれば電話で10分の手続きで済み、以降ずっと継続的にコストダウンである。塵も積もればマウンテン。

今日のさえずり - 停電って近隣にいる Twitter-ers あぶりだしに最適

naney:4297884334

2010年01月21日

[ 1月21日全て ]

2010年8月19日 (木)

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

2010年08月19日

[ 8月19日全て ]

2011年6月14日 (火)

今日のさえずり: 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 ソースコードのフォーマットは基本的には郷に従え(ただし死んだバッチャンの遺言によるところは除く)。
[ 6月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.099972s / load averages: 0.55, 0.54, 0.41
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker