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

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

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

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

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


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

参加したセッション

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

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

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

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

一番の気づき

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

執筆者:


comment

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

関連記事

打合せ前に少しだけ調べておく

とある社内での打合せの席で思ったことです。 「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。 その打合せは部門も違い、お互い初対面でした。 ただ、事前に「○○さん …

自発的に動いた人が損しない仕組み作り

危機意識を持って…もしくは思いつきで…、トップダウンの形で「組織風土を改善し、より強固にしよう」とか「ノウハウを共有して、ビジネスの力にしよう」という話が降りてくることがあります。 (トップから命令さ …

仕様を縦断する視点、横断する視点

外部設計や内部設計なんかの色々なレビューをしているうちにふと思ったことです。 レビューやインスペクションは画面単位(もしくは単機能を構成する複数画面)で行うことが多くなります。 そこではある要求仕様が …

週次フリカエリ

最近、お客様への納品が終わったプロジェクトで採用した「プチフリカエリ」について書きます。 (私の所属企業、かつ、知っている範囲では)「フリカエリ」は(大規模プロジェクトでは)工程の終了時、(小規模プロ …

白魔導師はファイアを使えません

最近、久しぶり…半年ぶり…にお客様常駐から社内に戻ってきました。 それで、あるプロジェクトのお手伝い…調査、プログラミングなどを少ししたのですが、その時のお話です。 プログラミングですが、当初はVB6 …

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