セオリーは無視。システム開発の議事録は新人に任せるな!

  • このエントリーをはてなブックマークに追加
  • Pocket
セオリー無視の提言。システム開発の議事録は新人に任せるな

必要性は理解できるし、せっかく書いたのに誰が読んでくれているのかもわからない、それが打合せ議事録です。

システムの打合せでも重要な議事録。しかし「書き方をちゃんと教わった記憶がないぞ?」というITエンジニアも多いのではないでしょうか。

そんな打合せ議事録の在り方について提案します。

議事録とは?

議事録は打合せ内容を書き記したものであり、決定事項や決定に至る経緯を記入します。

会議に参加しなかった人に伝えたり、後から証拠として確認したり、大事な役割があります。

特にシステム開発の現場では打合せなしでは仕事が進みません。システム開発は姿形の見えないシステムを作るので、極端に言えば「想像上の話」をしていることが多いものです。

文書に書く、文書に残す、ということが意思の疎通のためにも重要となります。

新人が議事録を書くという風潮

問題は、作成する議事録の質です。

多くの企業で見られるのが、議事録は新人に書かせるという風潮です。

新人に書かせる意図は、打合せに参加して欲しい、経験を積んで欲しい、など、部下の成長を期待しているのですが、本来は議事録の目的と新人の育成は別物だとうことを忘れてはダメです。

よく新人の議事録の出来栄えに不満を漏らす先輩は多く見かけますが、残念なことに、きちんとした議事録の書き方をレクチャーする場面は見かけません。

ダメ出しばかり言う先輩社員もまた、誰からも議事録の書き書き方を教えてもらえず、後輩に指導することができないのが本音なのです。

議事録の重要性を理解し、必要性を感じているならば、作成のコツは先輩社員がまず手本を見せて教えるべきだし、議事録を取りやすいように、アジェンダとして会議の議題を決めて、議題から話を脱線させないような打合せのファシリテートが必要です。

議事録のフォーマットについて

議事録のフォーマットは各社で決められたドキュメントフォーマットがあるはずなので、そちらに従う事になりますが、書きやすいドキュメントかどうかは定期的に見直した方がいいでしょう。

IT業界にありがちな「Excel至上主義」によって、あらゆるドキュメントのフォーマットがExcelで作成されていたりしますが、議事録に関してはExcelにこだわる必要はありません。理由はのちほど。

議事録に書くべき内容

議事録に書く要素は決まっているし、書き方のコツは調べれば色々と出てきます。

議事録に必要な要素とは、

  • 開催場所
  • 開催時間
  • 参加者
  • 議題の決定事項や決定の経緯
  • ToDo事項(誰が何をいつまでに)
  • 次回予定

といった内容になります。

書き方については、発言者まで明確に書く場合がありますが、ケースバイケースです。

書き方を関係者で事前にすり合わせしておくか、以前に書かれたものを先に入手しておき、書き方を真似るなどしましょう。

システム開発における議事録記入のコツ

システム開発における打合せ議事録という観点で考えると、5つのポイントがあります。

1.見えない物を扱う意識を忘れない

システムという目に見えないものを扱う以上、文章で可視化する意味は重要です。画面設計に使う打合せ資料などが別にあったとしても、見えにくいものを議題としていることを念頭に置きましょう。

2.専門用語に注意する

ユーザー企業の業務部門が使う専門用語はそのまま使い、ベンダー側が使うITに関係する専門用語は分りやすく表現するのがコツです。もちろん、打合せで使う言葉に注意すればそのまま議事録に記入できますが、議事録は言葉の定義を両社で確認する意味を持つので表現に注意です。

システムの打合せ議事録は複数の会社が関わるということを考えれば、意思の疎通に細心の注意を払うべしというわけです。

3.スピードを重視する

Excelファイルを議事録フォーマットに採用している会社もあるかもしれませんが、ハッキリ言ってシステム開発の議事録は見た目よりも内容とスピード重視です。
顧客に提出するものだからという理由で見た目の体裁を整えようとしているのなら本来の目的を見直した方がいいでしょう。

時間をかけて見た目にこだわるくらいなら、テキストファイルにメモ帳で書いてすぐに提出するほうがはるかに意味があります。

アジャイル開発に代表されるように、要件定義から開発までのサイクルがどんどん早くなっているのに悠長にドキュメントを整える暇はありません。

議事録の清書のために残業するとかマジありえません(笑)

4.論点を構造化する

打合せの時間軸に沿って書くだけでなく、議題の関連事項はまとめて書くほうが見やすい仕上がりになります。どの話題が関連しているのか、関係のある論点はどれかを考えると、必然的に物事を構造化して整理することになります。

構造化するスキルとはつまり論理思考そのままです。構造化を考えて書くということはエンジニアとしてのスキルアップにつながります。

5.忘れるために書く

人間は良くも悪くも忘れてしまう生き物です。無理に頭の中に記憶としてしまっておくのではなく、忘れるために書き残すのです。

書いて忘れてしまえば、頭のキャパシティに余裕ができるということですから、別のクリエイティブな新しい事に脳を使えるというわけです。

生産性や効率を考えると意識して忘れることは有効です。

必要なのは議事録の前準備

議事録を書く事以外にもやることは沢山あるので、時間をかけすぎず質の高い内容をまとめるのは難しいものです。難しいからこそ書き方をきちんと継承させる必要があります。ただ新人に任せればよいという考え方は間違いです。書き方を教えるという前準備があってこそ質が上り、生産性や効率アップにつながります。

さらに、難しい事を議事録担当者に任せるので、まとめやすい会議進行をすることも気配りです。議事録というアウトプットを意識すれば、必然的に会議の質も上がります。

まとめ

誰もが必要だと思っているのに軽視されまくり、なかなか先輩が手本を示せていない議事録。

読まれなければただの紙屑でしかなく、もしかしたら印刷すらされない屑ファイルかもしれません。そうなってしまうと作成時間のムダでしかありません。

新人に議事録記入を任せたとしても、先輩からのフィードバックが正しくなければ意味がありません。正しいフィードバックが返せるということは正しい書き方を理解していることですから、そもそも書き方を教えない文化がある以上、まったく意味がないということです。

IT業界の議事録は、文化の違う会社同士が同席することがほとんどです。議事録は新人が書くというセオリーを捨てて、生産性アップや効率アップを真剣に考えましょう。

  • このエントリーをはてなブックマークに追加
  • Pocket

無料レポート 失敗ITプロジェクト事例集 プレゼント

誰かの「やっちまった!」が明日のあなたを救う!

通常、失敗事例は世の中に出回りません。なぜなら、失敗は忌むべきもの、隠すべきもの、として扱われるからです。
しかし、失敗の共有こそ学びの宝庫です。

意識が上がり、もっと仕事ができるようになる
「これをやってはいけない」が学べる
自分の活動に当てはめて考えることができる
歴史から学ぶ
他人の失敗から勇気をもらえる

ITプロジェクト推進に役立つスキルアップのための失敗事例集です。
ぜひ、あなたのエンジニアライフの充実のため、キャリアアップのためにお役立てください。


無料レポートをダウンロード

SNSでもご購読できます。

スポンサーリンク

コメントを残す

*