 |
|
|
| 前のページ 1 2 3 4
|
|
| 今一度「会議」を考えてみる
|
システム開発において会議はとても重要な活動です。会議が重要だというのは当たり前ですが、その割には特に工夫がなされていないように見受けられます。筆者自身、IT業界に入ってから特に教育を受けたわけでもありません。筆者の知る限りでは特に教育や議論の対象となることなく会議が行われているようです。
例えば、社内会議で新人に議事録をとらせるのと同じような考え方で、その場に居合わせる開発側の最も経験の浅い者が議事録をとることになる場合があります。つまり、末端にやらせる「雑用扱い」的なイメージす。また、議事録も基本的に発言した言葉を記述し、その後ろに括弧書きで発言者名を記述するという形式のものをよく見かけますが、これは「証拠」として扱われているといえます。
議事録については「雑用」という一般的な捉え方がそのままあらわれていると思います。筆者自身、新人時代に議事録を書かされる中で雑用だから新人の自分がやることになると思っていましたし、もちろんできれば避けたい面倒な作業だと思っていました。
自分自身が何かの担当となって仕事の一部を任されるようになれば、「いった／いわない」になっても大丈夫なように顧客との会議の記録を証拠として取っておかないととても不安になります。
記録を証拠としてとることは面倒ですが、確実にやっておいた方が得だといえます。しかし、その一方で会議そのものは基本的に面倒なものという捉え方が人間の根底にあるように感じる場合があります。
これは、会議自体で何かがよくなったという経験が少ないこと、そして会議に必ずといってよいほど付随する、あまり意味を感じられない資料の作成などの悪い印象が影響していると思います。
しかし、いったんこういった考え方から離れて、「そもそも会議とは何か、議事録とは何か」ということを考えてみます。会議が生み出すのは、「（公式な）決定事項」であり、議事録は「（公式な）決定事項の記録」です。何かしら決めていなければ、行動するわけにはいきません。実施する、実現すると決定していないのに、勝手にそれに向けての行動をするということはありません。ですから、開発を前進させるために決めるべきことを決定することは最低限必要な活動であり、プロジェクト全体を通して最も重要な事柄の1つです。
|
| 会議は大切な機会
|
記述の通り、プロジェクトによっては会議は開発側の能力／苦労／要望を伝える大切な機会と捉えることができます。開発側は徹底的に効率よく会議を活用するべきですし、顧客側としても注意深く建設的に物事を運んで、かけたコストによって得られる成果を少しでも価値あるものとする大切な機会です。
会議は「面倒だけど仕方なくやる」というものではありません（仕事そのものが面倒で仕方なくということなのであれば、そうともいえます）。
その結果として得られた「（公式の）決定事項」が会議の（無形の）成果物となり、それを誤解のない表現によって記録したものが「（有形の成果物としての）議事録」となります。
|
| 決定事項の読み上げと表現の吟味
|
何かしらの決定事項が明確になったら、まずはプロジェクタを通して皆が見ている議事録に入力します。入力は速いことにこしたことはありませんが、プロジェクタ上で入力の過程が見えますので、それほど、参加者がイライラすることはありません。
この時、書記と進行役は議論が勝手に先へ進まないようにします。この後の手順を踏んで、議論の結果の「決定事項」を「誤解のない表現として記録」しなければ、会議の意味がありません。
入力が終わったらその内容を読み上げます。このことによって、参加者に決定事項に集中してもらいます（ベストは全員で読み上げることですが、そこまではする必要はないでしょう）。その上で、「この表現で誤解はないでしょうか？」と議事録の表現を確認します。
確認の際、例えば表5のような質問によって誤解を招きそうな表現を潰していきます。
- 「『売伝送付（ウリデンソウフ）』という表現は、本当にこれでよいでしょうか？」
- 「どこかの部署で他の意味になったりしませんか？」
- 「これは、Aさんの部署では、他の意味に使ってませんでしたか？それでも問題ないですか？」
表5：誤解を招きそうな表現を潰すための言葉
必要に応じて、関係部署全員が集まっているその場で注意深く新しい名称を定義することも行います（以降、定義した名称を徹底して使います）。この時、進行役や書記が業務分析によって「顧客業務の徹底理解」を行っていれば、問題点の指摘もツボをはずしにくくなり、新しい名称の定義についても誤解を招きにくいものが提案できるなど、その効果を発揮して直接的に顧客側の安心感へとつながります。ですから、開発側のより上位のマネジャーから経営者まで、プロジェクト・チームが初期段階をいかに密度の高い「業務分析」に集中できるような環境を作り上げるかということが、極めて重要となります（中途半端なものではダメです）。
また、初期段階からプロジェクトに参加しているプログラマのリーダー役（スペックパターン開発プロセスでは、インプリメント・リーダー（IL）と呼んでいます）から得た実装に関する問題点や注意事項を必要に応じて提示していくことで、決定事項についてもあらかじめ実装上の配慮を加えることができます。このような「顧客業務の徹底理解」に裏打ちされた適切な実装上での情報提示などによっても、顧客側に安心感を持ってもらうことができます。
次回は、今回解説した会議法・議事録術を考える発端となった、会議での問題点などを明確にします。今回紹介した手順では対処していないこともあわせて、どのような考え方で会議を進めていく必要があるのかについて解説したいと思います。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
株式会社イマジンスパーク 深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。
|
|
|
|
|
|
