サイト案内

運営してるひと: @sters9

妻と娘と猫と神奈川県に住んでいます。最近は Go, Ruby, Rails, Kubernetes, GCP, Datadog あたりをしていますがもっといろいろやりたい!

サイト案内

開発環境の紹介

プライバシーポリシー

tools.gomiba.co

サイト内検索

アーカイブ

2024/03 (1) 2024/01 (3)

2023/12 (1) 2023/11 (3) 2023/10 (1) 2023/09 (1) 2023/08 (2) 2023/05 (4) 2023/04 (4) 2023/03 (4) 2023/02 (2) 2023/01 (1)

2022/12 (1) 2022/11 (4) 2022/10 (3) 2022/09 (2) 2022/08 (4) 2022/07 (5) 2022/06 (4) 2022/05 (9) 2022/04 (8) 2022/03 (10) 2022/02 (21) 2022/01 (8)

2021/12 (11) 2021/11 (1) 2021/10 (4) 2021/09 (2) 2021/08 (1) 2021/07 (2) 2021/06 (5) 2021/05 (10) 2021/04 (1) 2021/03 (8) 2021/02 (12) 2021/01 (8)

2020/05 (2) 2020/04 (2) 2020/02 (2) 2020/01 (1)

2019/12 (3) 2019/11 (2) 2019/10 (5) 2019/09 (3) 2019/07 (6) 2019/06 (4) 2019/04 (3) 2019/01 (2)

2018/12 (6) 2018/10 (4) 2018/09 (6) 2018/08 (7) 2018/07 (16) 2018/06 (7) 2018/05 (7) 2018/04 (5) 2018/03 (3) 2018/02 (10) 2018/01 (6)

2017/12 (8) 2017/11 (6) 2017/10 (10) 2017/09 (12) 2017/08 (12) 2017/07 (3) 2017/06 (1) 2017/01 (4)

2016/12 (5) 2016/10 (3) 2016/09 (1) 2016/07 (2) 2016/06 (1) 2016/04 (1) 2016/02 (1) 2016/01 (2)

2015/12 (1) 2015/10 (1) 2015/09 (3) 2015/06 (1) 2015/01 (1)

2014/08 (2) 2014/07 (3) 2014/05 (1) 2014/01 (7)

2013/12 (2) 2013/11 (4) 2013/10 (1) 2013/09 (1) 2013/08 (3) 2013/07 (4) 2013/06 (5) 2013/05 (2) 2013/04 (7) 2013/03 (1)

新しくチームに来た人向けに何を書いておくか

新しくチームに入ってきた人向けにオンボーディングドキュメントとしてどんなことを書くのか? イメージとしては、巷のフレームワーク、ライブラリ、ツール、その他諸々でよく見る Quick Start だとか Getting Started な記事があるといいんじゃないかなと思う。いきなりドキュメントここにあるぜドーンでオンボーディングしていくのは難しい。

このドキュメントを読むことで、こんなことがわかると嬉しい、のかな:

  • 概要系
    • チームの目的
    • 組織全体におけるチームの立ち位置
    • メンバー
    • よく出てくるステークホルダー
    • 見るべきリポジトリやツールなどの便利リンク集
  • 実務系
    • チームのワークフロー
      • 開発の流れ
      • 開発のときに気にすること
    • よく使う各種マニュアル、ガイド
  • ファーストステップ系
    • チームの一員になるためにすること
      • どこかのリポジトリで設定をする
      • なにかツールの設定をする
    • 最初のタスクをアサインして、最初のコミット〜最初のリリースまでにやること
      • リポジトリのクローン
      • コードの変更
      • PR作成
      • CI
      • レビュー
      • マージ
      • リリース

この時、記事の中に全部を書く必要はないだろう。それはチームドキュメントとも内容が重複しているはず。 例えばチームのワークフローで「スクラムやってます、進め方はこっち→」のようなかたち。 最初は1記事になるべく全部かいておいて、この話題はちょっと大きすぎるな、となったら分割していくやり方がいいような気がする。最初からきれいさっぱり分割して書いていくのは難しそう。

あとはチェックリストとかで、どこまでやったか、をわかるようにすると更によい。どこまで行っているのかわかりやすいし、自走もしやすい。とは思ったけど、このくらいの量なら1-2日フル稼働したらできそうな気がするので、チームにいる誰かが常にいてあげて質問受け答えやサポートをしてサクッと終わらせちゃうのがよさそう。で、徐々にサポートの量を減らしていって自走してもらう。


…などと、思っていくつかドキュメントを見ていたら、 Kubernetes のドキュメントのような「コンセプト」「リファレンス」「チュートリアル」だなと思った。この分類いいな〜

Kubernetes Documentation | Kubernetes