Backlog Advent Calendar 2018のエントリーです。少し遅くなりました。すいません。
まずは「オミカレ」とは？ですが、婚活パーティや出会いイベントなどのポータルサービスを行っている会社の名前です。
婚活パーティー、お見合いパーティーをまとめて検索 – オミカレ
今回は、このオミカレ内でのBacklogの位置づけについて紹介します。
どんな環境か？
社内には大きく分けると、社長以下カスタマーリレーションを行っているチームとCTO以下サービスの実装・開発を行っているエンジニアチームの2つで運営しています。また、拠点が東京（高円寺・本社）と岡山（私ほか3名）という形で、こちらも2つに別れています。
さらに、社員だけでなく、コンサルさんや社外のパートナーさんにもご協力いただいています。
利用しているツール
こうなると、当然コミュニケーションというのが重要です。弊社ではそのために利用しているツールは‥‥
まずは、Backlog以外のこれらの性格分けを簡単に紹介します。
GitHub
ソースコードの管理とissueベースでのエンジニアチームのタスク管理
Slack
主に社内のメンバーによるフロー型のコミュニケーション
Chatwork
社外の方々とのフロー型のコミュニケーション
GoogleDrive
ファイルの共有
Backlog
そしてBacklogですが、まずは短く書くと
社外の方々と非エンジニアチームとエンジニアチームによる課題ベースのタスク管理
となります。
BacklogとGitHub
こうやって見ると、「BacklogとGitHubって被ってない？」と思うかもしれませんが、これが別れていることのメリットというのは結構大きいです。
というのも、基本的にGitHubはエンジニアチームのみが接触する形になっているので、ソースコードに関わるタスクしか存在しない形になっています。ビジネス要件であるとか、ユーザー/クライアントからの問い合わせなどはBacklogで管理することになるので、GitHubのissueになっている時点で全てが開発上のものとして明確に対応方針が決まっているタスクとして扱えるのです。
頑張って図にしてみるとこんな感じでしょうか
これについては、別に2段構えにしなくても運用しているというところも多いかと思います。しかし、弊社においてはGitHubはエンジニア勢、そして開発フローと非常に相性は良い。かたやBacklogの親しみやすいルックアンドフィールやUIは、非エンジニア勢や社外の人たちにとってはそちらのほうが使いやすく、それぞれのツールの特色を活かすことでコミュニケーションもうまく回っています。
ざっと概略としてはこんな感じです。もっとそれぞれのツールの活用シーンや具体的な話などはまたどこかで機会があれば紹介してみたいですね。
以上です。ありがとうございました！
コメントを残す