キムチのきもち

キムチのきもちになって考えてみよう

GitLabのドキュメンテーション技術を現場に取り入れようと目論んでいる

雑なアウトプットのためのメモです


GitLabに学ぶ パフォーマンスを最大化させるドキュメンテーション技術 数千ページにもわたるハンドブックを活用したテキストコミュニケーションの作法【PDF版】 | SEshop| 翔泳社の本・電子書籍通販サイト

ハンドブック作りてぇ

  • ドライブから資料探すのが大変
  • ドライブやSharePointにある資料を縦横無尽に駆け巡るための、地図が必要そう
  • 結局どれが最新情報で、どの仕様書で実装が動いてるのかわからなくて聞くことが結構多い
  • プロダクトのコンセプト、目的、ドメイン知識、ユーザーフローなどを、体系的・ストーリー的にまとめたハンドブックがあると、自走しやすい

用語集

  • プロダクトについて使うドメイン特化の専門用語集とか、あったほうが開発スピードと品質あがりそう

SSoT

  • Single Source of Truth:信頼できる唯一の情報源
  • 重複する内容を存在させない
  • 常に最新に保つ
  • ドキュメントの品質に責任を持つ人を決める
  • 不正確な情報を修正する

テキストコミュニケーション

Slackの使い方について

スタンドアップは非同期でやる

  • いわゆる朝会でやることをGitLabでは非同期でやっている
  • 昨日やったこと、今日やること、進捗を妨げているをSlackで共有する
  • ログが残るから振り返りもやりやすい
  • 同期でやったほうがよいことは同期でやるが、極力非同期にするのがGitLabの特徴

質問はオープンチャンネルで全体に投げかける

  • 一通り調べてもわからないことはSlackで質問するのが推奨される
  • それは多くの現場で同じかもしれない
  • DMでコッソリ質問しない
  • smalltalkのようなチャンネルで質問する試みは、Goodなんだなと感じた
  • プロジェクト外でもオープンに質問できるチャンネルが、もっと活用されるとよさそう
  • ナレッジがプロジェクトに閉じてしまうのを防ぐ第一歩として、プロジェクトをまたいで質問できる仕組みはよさそう
  • 質問以外でも困っている課題や悩んでることを相談することで、支援できそうなメンバーが名乗り出られる機会がうまれる

気軽な会話(インフォーマルコミュニケーション)

  • 趣味とか家族とか音楽とかの雑談チャンネル
  • GitLabでは音楽チャンネルで楽器をできるメンバーがコラボしてオリジナルソングつくって公開とかしてるらしい
    • 社会人の部活みたいな雰囲気

Slackでやらないこと

  • 一方でSlackでは、GitLab下記の目的で使用しないルールがあるらしい
* 承認を得る
* 決定事項の文書化
* 会社の公式記録やドキュメント保管
* 個人情報、機密情報のやり取り
  • たしかに、Slackはスレッドが流れていくから、追いかけづらいし、あとから探すコストも馬鹿にならない
  • クライアント定例のような議事録は、この意味ではしっかりとしたPJT進行のアンカーになっていると感じる
  • 基本僕とリーダーで相談して合意取って進めてるが、たとえば夕会に、その都度合意事項書き起こすとかは、できそう
  • そうすると「あれ、あの件って今どうなってたっけ?」「なんか忘れてる気がする」が減ってくれて、無駄な認知コストやスイッチングコストやコミュニケーションコストが割と減りそう
  • Backlogのwikiの運用についても、現状とくにルールはない
  • ただ、仕様の確認とか、今あるコードってどういう経緯でこうなってるんだっけ、とかはSlackやTeamsにしかない
  • 案として、Backlogのwikiに最新状態を集約して、仕様書などの各種資料は、その補助資料としてリンクを貼ったりするのがよさそう
    • ただし、文書化コストや運用ルールの設定、文書品質を保つための取り組みなど、課題はたくさんある

イシューの運用

  • GitLabでは、開発者以外のあらゆるメンバーも、アイデアの実装、昨日の実装、バグや修正事項の報告、依頼事項、質問、など全てイシューで管理する
  • 問い合わせ対応など、Excelで管理しているものも、一旦全部Backlogに起こしてチケットにログとSlackにログを残していくと、対応状況が把握しやすくなりそう
    • Backlogチケットのほうが、トレーサビリティが高く、コラボレーションしやすく、データの永続性が高く、構造化がしやすい
    • リアルタイム性については、Slackと同期されないため、解決法が必要そう
      • BacklogのSlack連携 – Backlog ヘルプセンター
      • パット見、課題の作成と更新通知ぐらいしかないが、調査してみたら何か出てくるかも
      • BacklogのチケットとSlackのスレッドを対応付けて、Slackにコメントつけたら、チケットのコメントにそのまま転機される、とかだと最高なんだけど
    • SlackCanvasのボードみたいなやつがいらなくなる
    • 欠点としては、Backlogのチケットコメント更新は、Slackに自動反映されない点をどうするかが課題
  • 日本企業は「人に厳しく、結果に甘い」と言われる
    • 結局一人ひとりがどんな業務に取り組んで、どんな成果を残してるかが把握できてないから、頑張ってるように見える人を評価せざるを得ない状況があるのでは?と指摘されていた
    • イシューベースで業務をできるようになると、個々人の動きが可視化されて、成果の評価もしやすくなる