サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

改善 旧館より 開発プロセス

「可視化」と「見える化」

投稿日:2012年2月22日 更新日:


先日「プロジェクトファシリテーションパーティ2012」に参加してきました。
#参加した皆さん、お話していただいた皆さん、スタッフの皆さん、ありがとうございました!

参加したセッション

マルチセッションだったので、迷いましたが、以下に参加しました。
パーティー2:「実録!プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」
パーティー4:「ようこそ“プロジェクトマネジメント保健室”へ!」
パーティー5:「上司・同僚にファシリテーションの重要性を体験してもらうワーク」

特に「実録!プロジェクトファシリテーションのWEBサービス開発運用現場への適用記」のセッションは「いつかお会いしたいなぁ」と思っていた方々の一人である、こしば(@bash0C)さんということもあって強く印象に残っています。

ここでは「ふりかえり」「見える化」「朝会」について「話す」→「グループでディスカッション」という流れで、@fkinoさんと@daiksyさんと同じテーブルでした。

お二人とはコンテキストは(多少)違うものの、マインドの部分は近いように思えたので、話が盛り上がりました。
そしてこの日一番の気づきもこの会話の中で出てきました。

一番の気づき

「『可視化』と『見える化』は違う」という@fkinoさんの言葉でした。ディスカッションした末の私の解釈は以下のようなものでした。

「可視化」と「見える化」は共に情報や事象を「見えるようにする」という点では同じです。
ですが「可視化」は「見えている」までで止まっています。
一方「見える化」は「見えている」情報や事象に対して【フィードバックができる】状態にあります。

【フィードバックができる】状態とは?

「こうしたらもっと良くなるよ」などのアドバイス、「こういう風にして欲しい」というより良くするリクエストをチームや関係者の間でやり取りできることです。
それには、場作りを含めた雰囲気、コメントをサクッと付けることができるツールだったり、プロセス、そのアドバイスを受け入れる姿勢などが関係してきます。

時々、上手く行っていないチームやプロジェクトに対し、この違いを分かっていないちょっと偉い人がテコ入れにやって来て「まずは『見える化』しろ」というシーンがあります。

その時にこの「可視化」と「見える化」の違いを意識していないと「よし、これで『見える化』ができた。大丈夫だ」と自己満足で終わってしまいます。

今まで見えていなかったことが見えるようになったのは最初の一歩としては良いのですが、その「可視化」されたことへフィードバックする環境ができていないことが多くあります。
つまり「見える化」できていないわけです。

これではチームはやる仕事(=可視化するためのタスク)が増えたにも関わらず、自分達の状況は改善しないことになり、ますますモチベーションが下がり、バラバラになってしまいます。

というわけで、「見える化」を目指す場合、「見えるようにする」のと「フィードバックができるようにする」の2つを意識する必要があるということでした。

「可視化」だけではうまく行かない

今まで、こういう「見える化」を何度もやってきた中で、うまく行った時、改善が出来た時は、この「フィードバックできる」環境に意識して、もしくは自然になっていたように思います。
一方、「なんかうまく行かないなぁ」という時には「可視化」で止まっていたことが、はっきりと分かりました。

他のセッション、懇親会でも色々な人の考えを聴いたり、自分の考えを整理して話すことができたりして、良い時間でした。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

※アイキャッチ画像:http://www.flickr.com/photos/caroslines/1371200717/

-改善, 旧館より, 開発プロセス

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

チームへのRedmineの効果

Redmine Advent Calendar jp 2011の25日目になります。 #余談。本場のAdvent Calendarは「24日まで」を窓を開けていくことでクリスマスを祝うそうです。一方、 …

何かを変えたい(チェンジ)時の5つのコツ

先日「AgileTourOsaka2012 in Minoh」に参加してきました。 箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです …

インプットとアウトプットのバランス

仕事ではインプットに対してどのようなアウトプット(成果物)を出すかが大事です。 一握りの創造性豊かな人以外にとって、そのアウトプットの元ネタとなるインプットが存在していることが大半です。 インプットは …

Redmineのチームでの使い方を紹介

Redmine Advent Calendar jp 2011の10日目になります。 私は(プラグインをガリガリ作ったりしてないので)「自分達のチームでの使い方」をいくつか紹介します。 コンテキスト …

朝早く仕事に取りかかるメリット

以前エントリ「自分のテンションを維持する方法」で「朝早く出社する」ことを書きました。 これを少し詳しく自分なりに考えてみました。 まずはやはり朝早くの時間帯は静かで本当に集中できます。電話ももちろん話 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。