• 株式会社DMM.com ラボ
  • システム本部 事業サービス開発部
  • 西岡 景子

デザイン受け渡しのGit運用を再構築。「用語の壁」を乗り越えるための取り組みとは?

〜チームの成長に合わせてGit運用を見直し、デザイナーにまで活用の幅を広げた事例〜

エンジニアには馴染みの深い、「Git」。GitHubなどのサービスの登場により、プログラミング未経験者でも耳にする機会は増えているが、敷居の高さを感じている人も多い。

DMM.comが提供する、モノづくりのためのプラットフォーム「DMM.make」。その開発・運用を担当する株式会社DMM.comラボのDMM.makeチームでは、デザイナーとエンジニアの「デザイン取り込み」作業に課題を抱えていた

どのデザインがどの案件に対応しているのか分からず、確認作業が発生するなど必要以上に時間がかかる状態だったという。

その課題を解決するため、デザイナーにGitを浸透させたのが、同社に2015年卒で入社したエンジニアの西岡 景子さん。

Gitに限らず、運用の改善が好きだと語る西岡さんに、デザイナーにまでGit活用を広げることに成功したノウハウついて、詳しくお話を伺った。

新卒でDMM.comラボに入社し、Webサービスの開発を担当

私は大学の情報学部でプログラミングを学び、新卒でDMM.comラボに入社しました。在学時にはハッカソンにも2、3回参加し、勉強会やカンファレンスにもよく行っていました。

参加したあるハッカソンで弊社CTOと出会い、何度か面談を重ねるうちに、代表の開田の話に惹かれて入社を決めました。

入社後はDMM.makeチームに配属され、Webサービスの開発・保守をしています。DMM.makeチームは他の事業部と比べても特殊です。通常は企画営業の下に開発チームがつくのですが、DMM.makeは会長直轄です。

会長が「こういうのがあったら面白いんじゃない?」というアイデアに対して、私たちが肉付けしていきます。

そのため、いろいろなことを柔軟に試せる部署でもあります。伸ばしたいスキルがあればクォーター単位で目標設定し、案件もそれに沿う形で振ってもらえます。また、発言すれば何でもさせてくれて協力してくれる部署でもあるので、通常業務と並行して改善業務も行っています。

片付けないと気がすまない性格から、Gitの運用改善を始める

何か気になることがあると、片付けないと気がすまないんですよね。システムや開発手法でイケてないところがあると、付箋に書いて机に貼ってメモしています。そのせいで、机が汚い四天王みたいになっているのですが(笑)。

▼西岡さんの机の様子

保守作業の合間などに、その中から気になったものを取り出し、今日はこれを片付けようと決めて進めています。そういった作業にも「時間をとってやっていいよ」と言ってもらえるチームで良かったです。

その中でも、Gitの運用は私が主導して改善していきました。Git自体は入社する前から使われていたのですが、その運用がイケていなくて、気になってしまったのです。

というのも、Gitを導入した当時は、Gitを使ったことのあるエンジニアがチームリーダー1人だったらしいんです。そのため難しい運用は取り入れず、「リリース用のブランチだけ汚さないように」という簡単なフローで運用していました。

ですが、私が業務フローを覚えてきたころには、他のエンジニアもGitにも慣れていたので、エンジニアのGit運用から改善を始めました。

コミットの内容がコードを読まないと分からなかったり、履歴がうまく追えなかったりするなど、Gitを使っているのに無駄に時間がかかりすぎていた点を、ブランチのルールやコミットの基準を決めることで改善していきました。

次は苦行の「デザイン取り込み」の効率化へ

エンジニアのGit運用は、Git flowやGitHub flowを参考にして、チームが一番使いやすい形に調整していきました。そこはスムーズに進んだのですが、次の課題は「デザイン取り込みに時間がかかりすぎること」でした。

私たちのチームでは、以前からデザイナーもGitを使ってはいましたが、成果物を受け渡しているだけで、有効活用できていませんでした。Gitの使い方もよく分からず、ひとつのブランチに全ての成果物を入れていたので、この修正はどの案件のものなのかが分からなかったんです。

その状態だとデザイン取り込みの作業が苦行でしかなかったので…(笑)。「Gitをもっと有効活用して、効率化していこう!」とデザイナーに相談したところ、快く受け入れてくれました

勉強会は開かず、個別の説明を大事に

始めるにあたり「Git勉強会を開いてよ」という提案がデザイナー側から挙がったのですが、それは実施しませんでした。

というのもおそらく、勉強会を実施するよりも、詰まったときにホワイトボードにイメージを書いて説明したほうが通じるなと思ったんです。

「こういう事がしたいんです」という相談を受けて説明をすると、「じゃあこの時はどうするの?」と追加で質問が出てきます。それに答えながらGitの有用性を浸透させていきました。

デザイナーとしても、以前のGit運用では「これ、どこの案件なの?」と聞かれることが多すぎて困っていたようです。そのため、ブランチを案件単位に分け、ブランチと案件を1対1で対応させるところから始めました。

デザイナーにとってGitは「ただ納品するためだけのツール」という認識だったようで、「Gitにこんな使い方あったんだ」と感心してましたね。

デザイナーには、「用語の壁」を乗り越える事が重要

しっかりと解説はしたのですが、それでもデザイナーにGitを理解してもらうのは苦戦しました。

そもそもGitをバージョン管理システムとして使っていなかったというのも要因のひとつなのですが、それ以上に「用語の壁」が大きかったです。Gitの用語をそのまま使うと伝わりづらいんですよ。「チェックアウトって何ですか?」「フィーチャーって何ですか?」という具合に(笑)。

Gitの用語ばかりで説明すると混乱するので、分かりやすい言葉に変換して説明していきました。

西岡ブランチは、西岡の作業分のことです」とか「フィーチャーはバグじゃないやつです!」という風に、Gitの用語を使いながらも身近な言葉に置き換えて意味を伝える。そうすると理解度も上がり、繰り返しているうちに段々と通じるようになりました。

今ではデザイナー・エンジニア問わずGitを活用

デザイナーはSource TreeというGUIツールでGitを使っていたんですよね。私はコマンドしか使ったことがなかったので、逆にGUIツールの使い方が分かりませんでした。デザイナーにコマンドの使い方を学んでもらうのは効率的ではないと思ったので、私がGUIツールの使い方を勉強することにしたのですが、苦戦しました(笑)。

そのようなツールの使い方もマニュアル化して、「この通りに作業してください」と伝えていました。デザイナーの作業の中心はGitではないので、本来の業務であるデザインに集中できるように「このボタンを押しておけば大丈夫です」「ブランチはこういう命名規則で作成してください」という形でマニュアルにしていきました。

こういった取り組みを3ヶ月前くらいから始め、今ではエンジニア・デザイナー問わずGitを活用してくれています。

解決までの道筋を明らかにすることが大切

実は私は、「DMMエンジニア女子会」というイベントの運営メンバーもしています。その第1回目で「女子力を高めるGitの使い方」という内容で登壇しました。特に女子力が上がる内容ではなかったですが(笑)、Gitによる開発フロー改善の取り組みを「同じ悩みを持つエンジニアに共有したい」という思いで登壇しました。

▼DMMエンジニア女子会の様子

実際に、同じようにデザイン取り込みに課題を抱えている方が沢山いて、思っていた以上に共感していただけました。デザイナーとの資産共有の問題で、「画像の後ろに日付を入れている」や「日付でディレクトリが作られる」といった、あるあるを抱えていましたね(笑)。

そういった課題には、まず解決までの道筋を明らかにしていくことが大切だと思います。「何でこの作業はこんなに大変なんだろう」という本質的なところから考えて、「誰がどうやったら解決できるのだろう」という風に考えていくと、次にやるべきことがわかると思います。

「自社開発しています」というイメージをつけていきたい

DMM自体、男性向きの会社というイメージが先行してしまうんですよね。今は、DMM.makeの他にもいろいろなサービスがあるのですが、勉強会で「DMM.make事業部です」と言っても「たけしの会社ですね」と言われてしまって(笑)。

いい意味で何でもやっているんですけど、悪い意味では何をやっているのか分からないという、難しい状態ですね。

自社で開発をしているということを知らない人もたくさんいるんですが、今後はそのイメージを塗り替えていきたいですね。女性エンジニアが活躍しているというイメージもあまり無いので、DMMエンジニア女子会のような活動も広げていきたいです。

個人としては、今後はミドルやインフラ部分にも携わっていきたいです。今のチームは色々なことを吸収できますし、実験できる環境でもあるので、チームの特性を活かしながら挑戦していきたいと思います。(了)

;