31
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

議事録ってどうやって作成・管理してますか?
だいたい、以下のような感じだと思います。

  1. 会議中にメモを取る
  2. メモをもとに議事録を作成する
  3. 参加者に確認依頼をだす
  4. 修正し確定したものをメールに添付して送信する、あるいは共有フォルダとかに保存して通知する。

これに GitLab を使ってみると割と便利だったので紹介します。

1. 会議中にメモを取る

ここは、今まで通り頑張ってください。。。
あえて、GitLabに絡めるなら、GitLab のWeb IDEで作成していくとか。。

2. 議事録の作成

Markdown、AsciiDocのようなGitLabでプレビューがサポートされている形式で書きましょう。
それを GitLabのレポジトリで、新規ブランチを作成し、作成した議事録を追加します。

議事録のフォーマットがあるなら、それも一緒にレポジトリに入れておきましょう。

3. 参加者に確認依頼を出す

ここからが、GitLab で議事録管理するうえでの肝の部分です。

参加者への確認依頼をMerge Request(MR)で出します。
そして、この際、以下のルールを決めておきます。

指摘がある場合

通常のMRのように該当箇所にコメントをつけてもらいます。
こうすることで、全ての人の指摘が一箇所で確認できます。
メールでの回覧レビューだと各々が返信してくるので複数のメールをみて統合する作業が必要になってきますが、これだとその作業から解消されます。

また、レビュアーはコメントをするときに、他の人のコメントがすぐ目につくので、指摘が食い違う場合は、指摘者同士で議論してくれます。もう、板挟みからおさらばです :smile:

指摘がおわった場合

確認が終わったことがわかるアクションを決めておきましょう。

例えば

  • Thumbs up :thumbsup: マークを押してもらう

  • コメントに OK を残してもらう

  • MRの説明に、以下のような見て欲しい人タスクを作成しておきチェックしてもらう

    • Aさん
    • Bさん

こうすることで、指摘が完了したことをきちんと把握できます。

ちなみに、GitLab EEなら、MR時に必要な承認者を設定できる機能がある模様 Merge request approvals

宿題が出た場合

GitLab のIssue を作成し、かつこのMRとの関連をつけるようにします
(MRの reference をIssueに記載するだけで、双方向から辿れるようになります)。

これにより、次回の会議時に、宿題の結果や進捗の確認が容易です。
IssueからMRに飛ぶこともできるので、後から見た時に元の議事録を確認でき、宿題がでた経緯がすぐわかるようになります。

4. 修正し確定したものを保存する

指摘が完了したことを確認できたら、マージボタンをクリックします。

おわりに

上記の運用の場合、全てGitLabのUI上で完結できるので、「Gitなにそれ?」の人でも大丈夫です。

31
17
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
31
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?