「企画書書いてみ」 →「いきなりプレゼンツールでゴリゴリではなくて、アイデアまとめからだよな」 →「そういえばマインドマップというのをたまに見かけるっけ。ちょっと前から気になっていたんだよね」 →「ツール探し。Linux でも Windows でも動く FreeMind が良さそげ。」
操作がシンプルですぐ覚えられる。 キー操作によるインタフェースが良く出きていて、2次元的な図として書いていくのだけれど普通のエディタと同じような感覚で入力していける。このため変に思考を遮らないのが良い。
ただし HHK Lite には FreeMind で多用するカーソルや Insert キーがないのでちょっと不便。Fn と組み合わせて押さなければならない。 慣れれば問題ないとは思うけど。
それか、FreeMind のキーストロークをカスタマイズするか。
とりあえず、読まなくてもいいかなと。
特に系統的な方法論とかがあるような感じがしなかったし、そもそも、そういうのにしばられずに使うのが良いだろうし。
本でもWebでの紹介でも「脳のなんちゃら」とかって書いてあるけど、 そんなのどうでもいいんじゃないか? 実際本当にそうなの? 「表でまとめて考えると良い」って時は脳も表形式で機能しているの? 「グラフにまとめている」時は?
昨日と今日の2件のミーティングの内容をまとめてみる。 テキストで書くと、時系列ベースから抜け出しにくい。 かわりにマインドマッピングツールを使うとその場で木構造をいじって意見・提案・質問等に簡単にまとめなおすことができ、それにより話題のポイントが浮かびあがってくる。
なるほど面白い。すごく整理できてしまった感じ。
その他、頭の中で考えている内容をまとめたり、プロジェクトの問題点の洗い出しにちょっと使ってみたが、どんどんノードが増えていって面白い。
この記事もまず、FreeMind で下書きしてみた。 これぐらいの分量なら、十分下書きになる。
なかなかいい感じなので、しばらく使ってみようと思う。
1週間前のとは別のプロジェクトで「すごい会議」を開いてみた。 といっても参加者は、前回のメンバとほとんどかぶっていて、新たに一人加わった4人。 3人はすでに前回途中まで「すごい会議」をやっているので、勝手がある程度つかめているかなといった感じ。
最初の手順であるが、これが意外と時間がかかる。 4人で30分弱。 ただ、雰囲気作りと書いてから発表するという手順に慣れるという効果を得るにはそれぐらい費すべきか。
前回もそうだったが、本の通り「〜(精神的意味合い)となる」という形で考えるとなかなか困ってしまうようである。テンプレートを再考した方がよさそう。
それぞれの立場が列挙される。 「自分自身が一番影響を与える」という意識に参加者を導くという意味合いがある手順であるが、ここであげられた各人のテーマを司会者としてどう組んでいくべきのか悩む。 前回と同様の悩み。
これが今回一番ブレイクした手順。 今回は以下のルールのもと進めてみた。
このルールによって、面白いようにホワイトボードにアイデアが書きこまれていく。 「どのようにすれば〜」は分割統治法で問題を解くエンジンではないかとこの間ちょっと思ったのだが、今回それを実感。
残り時間が少なくなってきたので、忙がなければならない解決策は担当決め。 後できちんとコミットメントリストに入れる必要あり。
結局ここまでで、今日の予定2時間が経過したので、終了。 やはり、最低もう倍ぐらいの時間はないと最後までまとまらなさそうだ。
そういえばこのまえ雑談で「1人1台PC + プロジェクタ + Wiki」を使うことで、ホワイトボードに書く時間を減らして効率的にできるのではという話が出た。
1度はそいういう形式でやってみたいのだが、ホワイトボードに手を動かして書いていくというのも捨てがたい。
それから、噂のポスト・イット イーゼルパッドもぜひ使ってみたい。 ホワイトボードだと、先に書いた手順は消していってしまうから後で参照できない。 巨大ポスト・イットに書き込んでいって、会議の後の方でも壁に貼っていつでも参照できるようにするといった進めかたをしてみたい。
全員がそれぞれノートを取るのはちょっともったいないかも。 ミーティングのテンションが上がって、ホワイトボードへの書き出しが多くなるほどノート取りが大変になって、アイデア出しに使う頭が奪われてしまう。
あたりのルールを決めて始めた方が良いかもしれない。
そうそう自分は FreeMind でノートを取ってみた(結局自分も皆と同様ノートを取っていたのである)。 どんどん追記されていくホワイトボードをメモるのは、紙に書くより圧倒的に楽(紙だと書くところがなくなる)。 図がででくると困りそうだけれど。 やはりその時は手書きやデジカメ併用で、後で清書するしかないかな。
プロジェクトの後半で納品用ドキュメントの整備を始めるのだが、その時はたいがいもう切羽詰りはじめていて構成やら体裁やらマネジメントやらを工夫する余力が無かったりする。 ついつい(次回は改良しようと思っていつも思っている)前回のプロジェクトの手法を踏襲してしまいがちだ。 ともすれば劣化コピーになりかねない。
やはり、忙しくても日頃からの改善は重要である。
最近はアジェンダ・議事録・開発メモなどを、積極的に Wiki や Subversion で共有するようにし、その点では以前より改善してきている。
今後はさらに、出荷ドキュメントのレビュープロセスなどを確立し品質を高めていきたいところである。 現状でもチームメンバでのピアデスクチェックやパスアランドを非形式的に行っているのだが、「チェックの程度」やその後の「修正」および「修正の確認」については、まだなんとなくやったかなという具合。この辺りを工夫したい。
先月発売されていて気になっていた「開発の現場 Vol.003」に、何かヒントがあるかなと思って買ってみた。
パラパラと見た感じではテクニカルライティングの話はあまりなく、主にソフトウェア開発における中間成果物としてのドキュメントや開発者間ドキュメントをどうとりまとめていくかという話が中心のよう。 Wiki による開発資料のライトな共有など、うちのチームでも進めている話など。
「(最初から)完全なドキュメントを書こうとしない」というのはもっとも。 状況はほとんどの場合変わるし、最初の段階では未確定の部分も多い。 だからといって、いつまでたっても手元で温めていてもしょうがない。
技術的な話では Perl の Pod を活用しようという話。 Perl 以外の言語のコメント中に Pod 形式でドキュメントを書こうという提案や、Apache で動的に Pod ドキュメントを整形しようという話とか。
テキストフォーマットとしての Pod は =over / =item / =back によるリスト表現など、最近のフォーマットに比べてすごく読み易いわけではないが、たしかに他の言語のコメントに埋め込んでおいて処理するのは、標準の Pod 関連のモジュールでできるな。
自分も Pod でドキュメントを書くけれど、(Perl 以外は) 個人的には reStructuredText にしたいと考えている。 ただ Pod みたいに他のテキストの一部に埋め込んでその部分のみ処理する記法およびツールがが標準の reStructuredText / Docutils には見当らない。 実はどっかにあるのだろうか。
[ 読書ノート ]
伝え聞くところによると、本社の人が「その話初耳」という不満をまたもらされていたとのことである。
「本社での定例ミーティングの内容が伝わってこない」という不満を東京スタッフが口しているのをほとんど耳にしないということは、やはり実質東京サイドで回っているということなのだろう。
もちろん「聞いてないよ」問題に対する問題意識は多くの人が持っているが、なかなか改善されていないのが実情である。
という案も出たがそういえば先に進んでいないな。
この方法の問題は、情報の選別が行われてしまうこと、要約が行われることによりコンテキストが欠落してしまうこと。 これは議事録にしても同じだ(もっとも今は定例ミーティングでは各自必要事項をメモするだけにとどまり、議事録すらまとめておらず、基本的なところで問題があるとも言えるのだが)。
で、ふと思ったのだがミーティングを録音して Podcast にし、聞いてもらうといのうはどうだろうか。 はてなみたいに社外公開はもちろんしないとしても、東京側の定例ミーティングの空気がより本社にも伝わるのではないかと。
「聞く側の負担がどの程度か」「Podcasting したとして聞いてくれるのだろうか」というのが懸念かな。 ま、いろいろ工夫はできそうだ。
準備も手間もそれほどなさそうだし、まずはとにかくやってみますか。
のぼりとくだり。#photography
— Naney (@Naney) August 24, 2020
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/WyFYZfALks
ミーティングで話し合ったこと決めたことは整理して書き残してくことが大切だ。
最近読んだ本だと『amazonのすごい会議 ジェフ・ベゾスが生んだマネジメントの技法』(読書ノート)では
> アマゾンでは、会議を行ったら必ず議事録を残すことになっています。これを怠ると、そのときに何を話したかが振り返れなくなるからです。次の会議で、前回話した内容を遡ることに時間がとられるのは、無駄なことです。
と述べられている。
動機がない(書き残しておくことの価値を理解していない)か、能力がない(議事録を書くスキルが不足していたり、議事録を書いて共有する仕組み揃っていない)と議事録が書かれないことになる(参考: フォッグ行動モデル)。
上記に加えて抵抗感によって書かれないことも確かにあるなと今週話しをしている中で気付かされた。
ミーティングの参加者以外やチームメンバ以外に議事録が読まれることが恥ずかしいと思う、あるいは自分への評価が下がるのではと恐れてしまうことは確かによくあることだ。まだディスカッション段階の意見だけを読んで批判的に捉えられてしまうのは辛い。
話し合ったことを共有するために書き残すことに抵抗が感じられないようするには、気兼ねなく発言できるようにするのと同様に心理的安全性が必要だ。
チームの境界を超えて互いが信頼しあい尊敬しあう関係にある組織にしていこう。
間もなく新緑の季節。#photography#SEL1670Z pic.twitter.com/CJSK0OTvlr
— Naney (@Naney) April 12, 2022
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。