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

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