1週間前のとは別のプロジェクトで「すごい会議」を開いてみた。 といっても参加者は、前回のメンバとほとんどかぶっていて、新たに一人加わった4人。 3人はすでに前回途中まで「すごい会議」をやっているので、勝手がある程度つかめているかなといった感じ。
最初の手順であるが、これが意外と時間がかかる。 4人で30分弱。 ただ、雰囲気作りと書いてから発表するという手順に慣れるという効果を得るにはそれぐらい費すべきか。
前回もそうだったが、本の通り「〜(精神的意味合い)となる」という形で考えるとなかなか困ってしまうようである。テンプレートを再考した方がよさそう。
それぞれの立場が列挙される。 「自分自身が一番影響を与える」という意識に参加者を導くという意味合いがある手順であるが、ここであげられた各人のテーマを司会者としてどう組んでいくべきのか悩む。 前回と同様の悩み。
これが今回一番ブレイクした手順。 今回は以下のルールのもと進めてみた。
このルールによって、面白いようにホワイトボードにアイデアが書きこまれていく。 「どのようにすれば〜」は分割統治法で問題を解くエンジンではないかとこの間ちょっと思ったのだが、今回それを実感。
残り時間が少なくなってきたので、忙がなければならない解決策は担当決め。 後できちんとコミットメントリストに入れる必要あり。
結局ここまでで、今日の予定2時間が経過したので、終了。 やはり、最低もう倍ぐらいの時間はないと最後までまとまらなさそうだ。
そういえばこのまえ雑談で「1人1台PC + プロジェクタ + Wiki」を使うことで、ホワイトボードに書く時間を減らして効率的にできるのではという話が出た。
1度はそいういう形式でやってみたいのだが、ホワイトボードに手を動かして書いていくというのも捨てがたい。
それから、噂のポスト・イット イーゼルパッドもぜひ使ってみたい。 ホワイトボードだと、先に書いた手順は消していってしまうから後で参照できない。 巨大ポスト・イットに書き込んでいって、会議の後の方でも壁に貼っていつでも参照できるようにするといった進めかたをしてみたい。
全員がそれぞれノートを取るのはちょっともったいないかも。 ミーティングのテンションが上がって、ホワイトボードへの書き出しが多くなるほどノート取りが大変になって、アイデア出しに使う頭が奪われてしまう。
あたりのルールを決めて始めた方が良いかもしれない。
そうそう自分は FreeMind でノートを取ってみた(結局自分も皆と同様ノートを取っていたのである)。 どんどん追記されていくホワイトボードをメモるのは、紙に書くより圧倒的に楽(紙だと書くところがなくなる)。 図がででくると困りそうだけれど。 やはりその時は手書きやデジカメ併用で、後で清書するしかないかな。
前回は松下君と2人で。 2人だとホワイトボード1枚で書ききれて、ある程度手書きでノートできる範囲。 3人を越えると厳しくなってくる印象。
今日は別のプロジェクトで、体調不良のプロジェクトマネージャーと飛び入り総務部スタッフ。 2時間で「いま直面している問題はなにか?」+「コミットメントリスト作成」まで。 過去3回と同じ進み具合。
若手出席者中心で適用してみた今までとは違い、今回は「いま、うまくいっていることはなにか?」「達成したいことはなにか?」「この会議で、達成したいことはなにか?」はサクサク進んでいく。 この辺りは年の功か。
この方法でミーティングを進めていくと核心をついた問題解決に辿りつけるのだが、スコープが大きくなりすぎるきらいがある。 プロジェクトの範囲を越えて、組織の体制のプロセスの改善まで包含してしまうものもしばしば。
裏を返せばそこから改善しないと適切な問題解決にならないということで、それを実行すれば効果も大きい。普段なおざりになっている部分も出てくるし。
しかしながら労力とコストも結構なものになるので、どの程度までやっていくかのバランスが難しいところだ。
すごい会議でコミットメントリストを作成していくと、コミットメントが明確になるぶんやる事も多くなってくる。問題解決のためにやってこなかった事だっだり、今まで気がつかなかった事だったり。
これらを達成していくと効果的に前進していけるはずであるが、さすがに多いと目がくらむ。重要度を把握し時間管理するスキルを高める必要がありそうだ。
ということで、まずはフランクリン・プランナーで有名な 「TQ - 心の安らぎを発見する時間管理の探究」を読んでみることにする。
昨日の続き。
一人6つ程度担当分野を考えホワイトボードに書いた後にそれぞれ番号をふり、「n番とm番は一緒」という風にマージしていく。
結局4人のチームに対して8つの担当分野が決まった。
ここからは「一番効果的な担当者」を決める作業。 まずそれぞれの担当分野に適任と思う人を手元の紙に1人づつ書いてもらう。 書き終わったら挙手で人数を数える。
参加者の中で自身を少な目に投票した人がいて、その人が最初担当に浮かびあがってこないという事があったが、未決担当を再投票しなおして確定。
皆で決めた担当に対して反対意見はなし。 逆にちょっとそれがこわかったりするけど、皆それが一番効果的という事で納得したということでいいのかな。
それから一つの疑問は「どのようにすれば学習的配慮を含む担当決めができるか」。 この手順だと一番効果的な担当者が決まるのだが、もし「多少効果が低くなるけれど、スタッフの学習を考えた担当決めにしたい」時にはどうするのがよいだろう?
コミットメントリスト作り。
皆それぞれ手元に書いてから、ホワイトボードにリストアップ。 依存関係をチェックして期日を調整したり足りないコミットメントを追加したりして、最終的に30強のコミットメントが確定。
自分も含めまだ、コミットメントのタイトルづけは不慣れ。 作業として書きがちな部分もあるが、慣れればコミットメントらしい表現ができるようになるだろう。
メジャーメントは今回明示的に書かなかった。 影舞上のコミットメントリストに登録する際に、整理して決めることにする。
チャレンジに必要なエネルギーのプレゼント手順。
自分にもチャージしておく。
2日に分けて全手順完了。
全手順やったという満足感と同時に、担当決めとコミットメントリストを獲得。
「すごい会議」全手順は、プロジェクト開始時に1日かけてばっちりやるのが一番効果的なんだろう。で、チェックポイントでは「集団解決の型」を使う。
そういえば「集団解決の型」はまだ実践してないな。 今度使ってみよう。
「最初の1、3、5が準備段階で一人でやる部分で、2からが参加者と一緒にやる部分」 すごい会議FAQより。
とのこと。すっきり!
また次の点も非常に参考になった。
ここでは、手順6、7、8は答えを作る場所ではないのです。 問題を前向きな形でたな卸しするだけです。 「答え」を提示する人がいたら、それはストップします(経営者自身がやってしまいそうになることも多くみます) ここで、誰かが「答え」を言ってしまうとドチッラケなのです。その答えが、各自、意識的または無意識のうちに手順11でコミットメントとしてその解決策が約束される可能性を最大化するためにやっているとお考えください。-- すごい会議FAQより。
もしや、思いっきりドッチラケだった?
さすがに手順8では答え作りしなかったけど、手順6、手順7では思いっきりアイデア出しに利用しちゃってたからなぁ。
光栄な事にまた著者の大橋禅太郎氏よりコメントをいただいた。
初期のころの「この会議で達成したいことはなにか」を発表してもらってから、司会者がどうすればいいか? といったところがありましたが、司会者は特にそれについてはなにもすることはありません。そのほかにもグループとしての統一した「意思決定」がなくても進むやつは、リストにしてオシマイです。
ありがとうございます。非常に参考になります!
手順を眺めてみると、参加者と一緒にやる部分のうち前半はリストにしておしまいだ。確かにすごい会議の本文でも、実際に出席者が順に発言するところが描かれているけれどそれ以上は書かれていない。
そこに書かれていない何かをしているんじゃないかなとも思ったのだが、本当にリストアップだけで良かったのか。安心。
となると合意は
となる。
やはりすごい会議は最後の手順までやらないとオイシイところが食べられないわけだ。 ふむふむ。
はやく次のすごい会議の機会こーい。
すごい会議をしてみて
という点が悩ましい問題であった。
その点について大橋禅太郎氏に質問して教えていただいた。 回答を私のサイトで掲載することのお許しをいただいたので、以下にとりまとめ。
手順6,7,8,9,10,11。コミットメントリストをつくる際に、手順6,7,8,9,10の内容が見えればOK。 ホワイトボードでやるとはまるので、やはり巨大ポスト・イットを使うのがよい。
目標達成に今役立つなら「コミットメントリスト」に日付を入れた形で入れる。 そうでなければ(もしどうしても残したければ)どこか個人的にメモに残しておくのがお勧め(扱う情報は少ない方がよいとのこと)。
上は私が要約しちゃったけれど、メールでいただいた返信は本の文章と同じ気さくでやさしい感じの文調であった。 いやむしろ、普段の雰囲気がそのままうまく本になっているというべきなのかな。
には
そのとうりです。で近くにいいゴミバコがないことがほとんどなので、薄かったら、「床にすてる」が手順です。(あとでゆっくりゴミバコに入れればいいです)
とコメントいただいた。最高!
会社の人が市販のガントチャートソフトウェアを購入して、現在本格導入を検討しているとのこと。
社内にはコミットメントをコアにした管理手法もあり、 その優位性は十分に認めている。 しかし、単純にガンチャートがすきなのである。 特に見た目、がね。 — GAKUさんの日記 「これは好みなのだ」 2005年10月18日 13:10 より
とのことだ。 コミットメントリスト派とはまさに私の事である(多分)。 いい機会なので自分の中でも、コミットメントリストとガントチャートについて整理しておこう。
ここで言うところのコミットメントリストというのはすごい会議で紹介されているものである。
ちなみに私はプロジェクトマネジメントについては教育を受けたこともないし、明確な手法を導入したプロジェクトマネージャーの下についたこともない。 「ガントチャートは駄目」だとも思っていない。 以下は試行錯誤を繰り返している中での現在の私見である。
どちらも特徴・欠点があり適材適所(と好み)があるのだと思う。 両方同時に使っているケースもあるであろう。 またこれらは一つのツールであるから、本来はもっと上位の管理手法まで議論しなければならないであろう。
コミットメントリストでは「期日」という点で「成果」をリスト化する。 一方ガントチャートでは「期間」という点で「作業」をリスト化する(たいがい)。
逆に言うとそうでない場合は、コミットメントベースの方が合っているように感じる。
ソフトウェア開発で線を引いてみたときの感想
現在自分がマネジメントしているような、ソフトウェア開発の含まれる少人数体制のチームではコミットメントリストベースがかなりイケているように思われる。
必要であるならば適応型ソフトウェア開発にあるような、タイムボックス(サイクル)を設定してコンポーネントを割り当てる形で長めの計画をコミットすればよいであろう。
ガントチャートは、それこそ「依存関係のある工程が順番に進んでいく」「クリティカルパス重要」のようなプロジェクトにはいいんだと思う。 自分が扱っているプロジェクトがそういうものではないのだなと。
影舞でコミットメントリストを作成して運用している。
今までコミットメントに設定できる状態として
を用意していた。
担当は「割当済み」コミットメントを達成すると状態を「完了」に変更するのだが、そうすると割当済みリストから消え、よく見る影舞のプロジェクトトップページに表示されなくなる。 メンバにメールで通知がいくものの、全員で完了の合意が取れていないのがちょっとよくないな。なので、
のようにしてみた。 担当が達成したと判断したら「確認待ち」とし、コミットメントリストの進捗チェック時に皆で確認した上で「完了」とする流れに。 これでより、プロジェクトの状態を皆で共有できるのではないかと。
ちなみに「提案」は一度も使われていないので不要のようだ。
プロジェクトの後期フェーズのキックオフミーティングをすごい会議スタイルで開催。 もろもろの制約条件があって2時間程度しか時間がとれないので、今日はスピーディに進めたい。 幸い参加者はみなすごい会議慣れしていて、結束力もある。
今までのすごい会議では参加者が「各発言時にホワイトボードに書く」という部分に時間がかかっているようなので、今回は買ってきた情報カードを利用してみることにした。
参加者は計4人。
はっ、速い。
今回はミーティングスペースの都合から前半ホワイトボードが使えなかったこともあり、発表はテーブルの中央に情報カードを披露する形で行うようにした。 ホワイトボードに書く手間だけでなく、立って移動する手間もない。
さすがに時間が短いし参加者が慣れているということで、いくつか手順をはしょろうかと思っていたのだが、結局フルセットやって2時間15分で完了した。
巨大ポスト・イットも使ってみたいけれども、コスト的にもスピード的にもカード式もなかなか良いことを実感。
4人で着席してやるならば、情報カードは最初からもう少し小さいものでもいいかもしれない。
チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。
興味深いポイントについて:
今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。
先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。
ぐらさん言わく「見えない化」
開発中に発生する
などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。
後半「コミットメントリストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。
やはり基本は顔合わせということを実感。
またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。
どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。
できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。
(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)
複数人開発で途中開発者間にまたがるインタフェースの仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。
通常開発中のコード内でのこのようなインタフェース変更については
のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。
ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。
変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。
「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。
関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。
チームのトータルのスループットを最大にするようにコミュニケーションしよう。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。