PFP関東ワークショップ#5に行ってきました

ポストが少し遅れてしまいましたが、4/24にPFP関東ワークショップに参加してきました。
PFPとはProject Facilitation Projectの略で、プロジェクトファシリテーションを推進する会という意味だそうです。

ファシリテーションに興味を持っている今日この頃、What's ispire me? のちささんにお願いして参加させていただいた次第です。
全体としては、やはりPFに興味を持っているメンバーが仕事の後に集まっているということもあり、アイスブレーク、発表、ワークショップ全てにわたって、ポジティブフィードバックに溢れる集まりということで、いろいろなヒントだけでなく、元気も手に入れることができるワークショップであったというのが感想です。

というわけで、以下レポートになります。

■会場は、ATLシステムズさんのオープンスペース。他のイベント等でも何回か利用させていただいたことがありますが、素敵なスペースです。また、喫煙所が素敵なのは、喫煙者にしかわからない秘密・・・・・・。

■プレゼンテーションの切替えをしている間に、簡単なアイスブレークのためのエクササイズを。こういった技を身につけておくのはとても重要ですね。

■最初は、古家さんによる事例紹介。プロジェクトへのPFの導入に関する発表ですが、とても参考になりました。全体的にPFに前向きではない状況の中での、PF利用ということで、いろいろヒントをいただきました。特に良かったのが「二次会」というキーワード。
ドライブ感のないプロジェクトへの朝会の導入はわたしもよく行うのですが、やっぱり所要時間が長くなってしまいがちです。というわけで、この事例では、気になる話題が出た瞬間に「二次会！」と声を上げて、「朝会の二次会」を別途やるという・・・・・・これは良いアイデアだと思いました。

■というわけで、事例紹介の後はワークショップです。今回のテーマは「プロジェクトにおいて良い雰囲気とは」についてのグループディスカッション。５人ずつにわかれて着席し、最初は『平鍋メソッド』で自己紹介を行います(この手法、WEB上で公開されていないようなので、とりあえず詳しく書かないでおきます)。その後は、

1. 「プロジェクトにおいて良い雰囲気ってどんなとき？」をポストイットに書いたあと、皆で発表してまとめる。
2. まとめた「プロジェクトにおいて良い雰囲気ってどんなとき？」について、実際に皆が「出来ているか」「出来ていないか」を集計
3. ひとつだけ「プロジェクトにおいて良い雰囲気ってどんなとき？」を選んで、「なぜできていないのか」「どうすればできるようになるか」「できたらどうなるか」をディスカッション
4. 最後に、個々人が今後やることを、自分のカードに書いて持ち帰る

という流れでした。写真は、わたしの着席していたテーブルのディスカッション時に使ったワークシートです。なかなか盛り上がり、話は二転三転しましたが、楽しく時間を過ごすことができました。

■PFPの集まりの良いところは、非常に前向きであるということです。今回のワークショップのテーマもそうですが、「プロジェクトの○○を良くする」ということについては、なかなか普段集中して考えたりディスカッションする機会がありません。今回のテーマ「プロジェクトにおいて良い雰囲気とは」についても、皆で議論を行い「うんうん、そうだよね」「エーッ、それすごい！」という会話をしていく中で、わたし自身がとてもポジティブな気分になれたことが、とても良い体験でした。

システム監査技術者試験 振り返り

さて、既に数週間が経過してしまいまいしたが、情報処理技術者試験を受けてきました。賛否両論ある資格試験ということもありますが、個人的にはスキルの棚卸しと、学習姿勢を維持するための筋トレの一種として受験しています。

受験したのは「システム監査技術者」です。この区分は、通常のエンジニアとは少し異なる視点で、システム開発を論じており、試験の合否は無視するとしても、かなり興味深い学習だった、というのが感想です。

システム監査技術者とは

被監査部門から独立した立場で、トップマネジメントの視点で、情報システムが経営に貢献しているかどうかを、安全性、効率性、信頼性、可用性、機密性、保全性、有用性、戦略性など幅広い側面から総合的に調査し、あるべき姿を描くことによって自ら形成した判断基準に照らして評価し、問題点について説得力のある改善勧告を行う者
JITECのWEBサイトより

という定義というわけで、プロジェクトマネージャや、エンジニアとは立場が異なり、ユーザ側、もしくは経営側の人間として描かれています。

通常システム開発プロジェクトに参加していると、見える範囲はスポンサー(お客様の責任者)、ユーザー(お客様の担当者)、そしてプロジェクトメンバーや自社の管理部門などに限られてきます。もちろん提案時にはトップマネジメント(経営者)に会うことはありますが、それ以降のプロジェクト実施中に、あまり意識することはありません。まぁプロジェクトによるかもしれないけど。

こういったプロジェクトやシステムを、独立した視点でチェックし、問題点や改善方法を直接トップマネジメントに報告するのが、システム監査技術者の位置づけです。

Wikipediaなどを見ると「受験生は他の情報処理技術者試験とは違い、技術者と言うよりも経営者側に立つ人が多い。また、本来監査業務を独占業務としている公認会計士にも受験者・資格所持者が多い。」とありますが、私の意見としては、プロジェクトを外部から見る目を手に入れるという意味で、むしろエンジニア側も勉強する価値のある試験区分であると考えています。

私も参加している要求開発アライアンスでもおなじみですが、我々が意識しなければいけないのはビジネスに役立つシステムを、どうやって作るかということです。この時に忘れてはいけないのは、単にユーザの要求を満たし安価であればよいということではなく、管理の始点からも適切なシステムを作る必要があるということ。

システム監査技術者では、この管理の視点を得ることができるような気がしています。

さて、堅い話はこのへんにして、受験をふりかえってみたいと思います。
＜良かった事＞

• 学習期間は4ヶ月。受験申込直後から、午後の試験対策を中心に参考書と過去問をコンスタントにこなしていきました。これまでは過去問題中心の問題集で勉強することが多かったのですが、午後に小論文を書かなければいけないことから、試験よりも説明中心の「情報処理教科書 システム監査技術者(翔泳社)」を選択。結果、午後の試験はあまり苦しむことはありませんでした(得点がどうかはわかりませんが)。
• 私は普段はボールペン類しか使わないのですが、試験は鉛筆かシャーペンを使わなければいけません。今回は、シャープペンシルに加えて、太めに削った鉛筆を何本か持ち込み、問題文のマーキングや考えをまとめる時には、鉛筆を活用してみました。シャープペンシルだと、折れたり紙が破れたりがあるので、これは良かった。
  

＜悪かった事＞

• 今回の最大の失敗は、午前対策をうっちゃっていたことです。一応10年くらいこの業界で働いているので、大丈夫だろうと思っていたら、意外と新し目の問題が解けません。油断大敵。
• 会場の座席がキツイ。試験会場は池袋の某大学だったのですが、机とイスの間隔が狭い、動かすことのできない木製のイスがひどかった。クッションとか持ち込んだほうがいいかも・・・最近オフィスのイスが良くなってきているので、落とし穴でした。
  

ちなみに、自己採点は怖くてやってません。
忘れた頃に、合格通知が来ると嬉しいなぁ。

Input+Output and Community

偶然発見したCSS Niteというコミュニティの発表資料が素晴らしすぎて、感動したのでご紹介します。本質的にはWebデザインそしてCSSに関する内容なのですが、その末尾の「コミュニティについて」のくだりが、とても心に響いたのです。
Webデザイナー関連のコミュニティということもあり、資料もとっても洒落ています。















最近でこそ、日経SYSTEMSなどで「社外コミュニティで自分をのばす」という特集が組まれたりしてコミュニティ力の認知度は上がってきていますが、それでも自分の周りを見渡すとまだまだ浸透していません。これが本当に残念でならないのですが、何か良い手はないものでしょうか？

ネットを日本語化する

Firefoxのアドオンでこんなものを見つけました。
ネットを日本語化する：Japanize
これはすごい！
知らなかったのは私だけ？

最近海外のWebサービスを普通に使うのがあたりまえになってきました。
例えばソーシャルブックマークのdel.isio.usとか。
もちろん類似の国産日本語ツールも良いですが、海外のサービスも単にインターフェースが英語というだけで、メニューの英語も慣れれば気にせずに使えます。
とはいえ、普段と異なる操作をしようと思うと、英語のメニューやヘルプを解読するのは、ちょっとストレスです。

ネットを日本語化する：Japanizeをインストールすると、なんと代表的な(話題の)海外Webサービスを日本語化してくれます。
さっそくインストールしてdel.isio.usにアクセスしてみると・・・
おぉー、日本語です。

ちょっとした事なのですが、やはり自国語で表示されると安心感があるものですね。
というわけで、Firefoxユーザにはお勧めです。
他にもYouTubeやTwitterなど、いろいろなサイトに対応しているみたいです。

というわけで、ちょっと感動したエントリーでした。

質問を活用する

以下のBlogエントリを読んで思い出した事があるので、徒然と書いてみます。
TECH-moratorium：テクモラトリアムさん経由で発見した記事です。

先日米国で幾つかの技術系セッションに参加したのだが、その折に感じたことを書いてみる。
日本で技術系のセッションに参加すると、聴衆は結構皆行儀が良いというか、大人しくきちんと話を聴いている。ただし余り反応もなく、話に関心があるのかないのか、賛同しているのかどうかが、比較的分かりづらい (他人のことは言えないのだが)。
反応なくじっと聴いているので、うけなかったのかと思うと、事後のアンケート結果が割と良かったりする。
それに対して、米国のセッションでは、(中略)聴衆の方にもセッション自体の価値を上げる責任がある、と考えているようなのだ。
翔ソフトウェア (Sho's) Fujiwo の日記:質問を受ける態度

リクルートワークス研究所の所長である大久保幸夫さんの著書「仕事のための12の基礎力」では、職業人が20代までに身につけるべき力の一つとして「反応力(リアクション力)」というものを定義しています。



日本人は、(という書き出しは非常に抵抗があるのですが)国民性というか、学生時代までにリアクション力を学ぶ場面が非常に少ないためだと思うのですが、やはり反応力は少ないと思います。最近アジア圏のエンジニアさんと仕事をしているのですが、言葉の問題はあるものの、反応力が十分あれば、むしろ良好なコミュニケーションができるように思います。

ちなみに私は大学生時代にインプロのトレーニングを行う事によって、反応力がついたように思っています。

さて、「仕事のための12の基礎力」の「反応力」の章には、「講演会や勉強会で適切に質問するためのポイント」が書かれています。本自体は手放してしまったため手元にないのですが、ノートがあったのでそこからご紹介します。

大前提「質問するつもりで聞く」

1. あらかじめ講師がわかっている時には、その人の書籍や発言している内容などについて目を通しておき、講演では「ここが知りたい」というテーマを持って参加する
2. 講師の言うことを鵜呑みにせず、「本当にそうだろうか？」という疑問を持って聞く
3. 質問は大抵「反論」「確認」「展開」の３種類に分かれる。内容のどこかに疑問を持ったら素直にぶつけて講師の考えを聞く「反論」、私はこう理解したが、それでいいかと言う「確認」、「ではこういうケースはどうか」あるいは「具体的にはどういう事例があるか」等を聞く「展開」である。どの種類の質問をするかを、講演を聞きながら絞り込んで行く
4. できるだけ最初に質問する。始めは遠慮して手を挙げる人が少ないので指名されやすく、他の人に同様の質問をされてしまう心配もない
5. マナーとして始めに講演のお礼を言い、名前を名乗り、それから質問をする。一人で２つも３つも質問せずに、１つに絞ってするのがベター
6. 誰からも質問が出ない時は、講師が持ち時間の中で話しきれずに省略したところを質問してあげる
7. 全体の質問時間の中で質問ができなかったときは、講演終了後に演台に行って直接諮問してもよい。個別性の高い質問の場合はこのほうがいいときもある。

大久保幸夫「仕事のための12の基礎力」より

個人的には赤字のところが、覚えておくと良いテクニックだと考えています。