入社は11年前　現在はシステム本部を牽引する「CTO室」へ

僕がDMM.comラボに入社したのは11年前で、その頃はまだ社名もDMM.comラボではなくドーガという会社でした。当時は東京には開発拠点はなく、僕も金沢でエンジニアとして、レンタルやマーケットプレイス等のサービスや、購入システム等のプラットフォーム開発を担当してきました。

現在は金沢と東京を行き来しながら、CTO室のマネージャーをしています。

CTO室は、今後DMM.comラボがテクノロジーの会社として飛躍するために先端技術やソリューションを導入し、システム本部を牽引していく部門です。今では10名ほどの組織になり、R&Dだけではなく、他の開発チームに対して提案やコンサルのような動きもできるようになってきました。

また、最近ではプロジェクトとしてApache Sparkやkafkaなどを活用したシステム開発にも取り組んでいます。

プロジェクトの全体像を可視化するために、JIRAの導入を決定

JIRAについては、昨年の夏頃からCTO室で導入を始めました。それ以前は、ずっとRedmineを利用してチケットでプロジェクト管理をしてきました。Redmineは、シンプルでチケット管理をするだけなら非常に良いツールです。

ただ課題だったのは、プロジェクト全体の流れが非常に見えづらかったことです。今やるべきタスクはわかりやすく見えるのですが、次にどんなタスクをこなすのか、最終的にどのような成果物がプロジェクトとしてが出来上がるのか、という点が見えにくいという課題がありました。

そこでRedmineを利用していた頃は、別のツールでWBSを引いてRedmineのチケットとは別にスケジュールを管理していました。そのためチームとして確認すべき場所が分散されてしまっており、管理コストがかかっていることを非常に煩わしく感じていました。

そのような理由から、新しいプロジェクト管理ツールを探し始め、2014年7月に「JIRA（ジラ）」の導入を決めました。

エンジニア主導でハンズオン勉強会を開催し、組織への浸透を図る

ツールの選定にあたって他のサービスも検討したのですが、JIRAは特に他のAtlassianのサービスと連携して使える点が気に入りました。実際に現在CTO室では、JIRAの他にConfluence、Hipchat、StashといったAtlassianのサービスを連携させて利用しています。

▼プロジェクト管理ツール「JIRA」

導入に関しては、エンジニアは新しいツールが大好きなので、比較的スムーズに浸透したかと思います。ただ開発ツールなので、プロジェクト全体で見ると、ディレクターやデザイナーにはなかなか広まりづらい部分はありました。

そこで、弊社でよく開催している技術の勉強会のスキームを利用し、エンジニア主導でJIRAやConfluenceのハンズオンを社内で開催しました。

実際に時間をとって新しいツールに触ってもらうことで、自然とJIRAの便利さを理解してもらうことができました。そのようにエンジニア以外の人の導入ハードルを下げることで、徐々にプロジェクト全体でJIRAが活用されるようになっていきました。

Atlassianの他サービスとの連携で、円滑なプロジェクト進行を実現

今では、JIRAと他のAtlassianのサービスを連携させて使うことで、プロジェクト全体が非常に進めやすくなりました。

例えばConfluenceは、ナレッジを共有をするためのツールです。仕様書や議事録、設計図などのドキュメントもまとめています。そしてConfluenceで要件定義をしたタスクは、クリックひとつでJIRAにチケットとして登録することができます。

▼ナレッジ共有ツール「Confluence」

また、Gitリポジトリのバージョン管理ツールであるStashとJIRAも連携させています。Stash上でお互いにコードレビューし合い、レビューが終わったらプルリクエストをプロジェクトオーナーに出します。

そのプルリクエストの通知はチャットツールのHipchatに飛ばしていて、さらにプルリクエストが承認されると、JIRA上の対応するチケットのステータスも自動で「完了」になります。

何をするにしても、JIRA、Confluence、Stash、Hipchatを連携させることで、作業のずれやドキュメント漏れがないような開発体制をとっています。同じAtlassianのサービス同士だからこそ、このようなシームレスな連携が可能になっています。この柔軟性が高いところは、非常に重宝していますね。

1チケットに1アウトプットを必ずひも付けることが大切

JIRAの運用で気をつけていることは、1チケットに対して必ず1アウトプットをしっかりと示すようにしていることです。1つのチケットに対して複数のアウトプットがでるような粒度でチケットを切ると、チケットの終わりがわかりづらくなってしまうんですよね。

特に 設計や要件定義は、非常に曖昧な部分が出やすいと思うんです。そのようなことがないように、しっかりとチケットにはアウトプットをひも付けます。

調査検討のようなチケットであれば「何を調べたのか」、設計であれば「どの機能のどの部分の設計をしたのか」と言う形で、すべてにアウトプットを残しています。そうしなければ、プロダクトが仕上がった時にふわっとしてしまう部分がでてきてしまうんですよね。

JIRAで工数を可視化したことで、MTG時間の削減にも成功

JIRA導入の直接的な効果ではないのかもしれませんが、エンジニア工数を最適化することもできました。JIRAのタスク消化の時間をCSVでエクスポートし、メンバーの時間の使い方を見直してみたんです。

実際にかかっている時間を可視化を見てみると、MTGの数が驚くほど多いことがわかりました。そこで、MTGもタスクとしてJIRAにチケットを積むようにしていきました。

このように可視化されたことで、無駄なMTGが減り、チーム全体でMTGの時間が削減できました。週で5時間ほどの削減ができたメンバーもいたんですよ。

これまでMTGをしていた時間を開発に割けるようになったので、エンジニアとしての仕事により価値を発揮できるようになり、チーム全体の生産性を向上させることができました。

エンジニアにとって理想的な、無駄のない環境づくりを続けていく

私の目標は、エンジニアができるだけ開発に集中できるように、無駄を極力減らしたプロジェクト運営を行うことです。

ひとまず直近は、現在のJIRAを活用した開発体制を熟練させていきたいと思っていますが、ただ、JIRAも完璧なわけではありませんので、ツールや運用方法の見直しは継続して実施していく必要があります。会議やレビューも、より効率化できないかと日々模索していますね。

無駄を限りなくゼロに近づけることで、エンジニアにとって理想的な環境を作っていきたいと考えています。（了）