サイト開発における属人的なリスクを減らし、品質確保や生産性向上を図るために、dodaサイト開発チームへの「開発プロセス標準」導入が進められています。内製エンジニアの有志メンバーから始まったこの取り組みは、体制づくり、現場浸透のための取り組みへと、歩みを止めずに前進し続けてきました。
組織やサービスに合う仕組みを作るために、そして作って終わりではなく現場に浸透させるために、どのような思いが込められているのか－－取り組みを主導する坂井と、ガイドライン策定に携わった古沢に、取り組みの裏側と思いを聞きました。
※撮影時のみ、マスクを外しています。
※坂井は退職していますが、本人の同意を得て、掲載を継続しています。
有志の取り組みから、開発ルールやプロダクトの技術方針を扱う新体制へ
――まずは、改めてdodaサイトの開発が抱えていた課題とこの取り組みの概要から教えてください。
坂井：これまでいくつかのチームあるいはプロジェクトに分かれてdodaサイトの開発が進められてきた中で、開発チーム共通で使われる横串的な開発ルール・方針がありませんでした。その影響が開発や改修のしづらさに出てきており、コントロールがきかない状態になっていたのが、当時の課題感です。
そういった背景の中で、アーキテクトグループの方の「内製エンジニアでコーディングガイドラインを策定し、それが守られているかチェックするレビューの場を設けないか」という声をきっかけに始動した取り組みです。
内製エンジニアの中で有志を募り、必要なガイドラインにはどのようなものがあるかを議論するところから取り組みがスタートしました。「開発プロセス全般に関してルールを作っていかなければいけない」という課題が明確になったものの、まずはコーディングガイドラインの策定を進めつつ、ある程度の方向性が見えた段階でレビューを始める、という方針で走り出していました。
――前回お話を伺ってから今日に至るまで、どのように取り組みを進めてこられたのでしょうか。
坂井：まずマネジメント層でも、開発プロセスの構成について仕組み化しなければという課題感が上がっており、開発における属人的なリスクの低減・品質確保・生産性向上を図るための「開発プロセス標準」を作ろうという動きが新たに生まれました。
これを受けて、私たちが取り組んでいた開発ルール・ガイドラインを、開発プロセス標準を補完するものという位置付けで仕組みに組み込むことを決めました。
また、有志で集まったメンバーは「コンポーネントワーキンググループ」として、開発のルールやプロダクトの技術的方針・課題を扱いリードする役割を担うことにしました。
ガイドラインについては、有志のメンバーで議論した必要な項目、例えば「開発プロセス全体」「アプリケーションアーキテクチャ」「エラー処理」「Java言語」そして「dodaサイト特有の開発について」などをメンバーの得意領域によって担当分けし、それぞれで作成を進めていきました。
――ガイドライン策定について、方針や意識されたことなどはありますか。
坂井：全てを自分たちで一から作るのではなく外部の情報やノウハウを取り入れながらも、doda特有の事情についてはしっかりとドキュメンテーションする、という方針で進めています。書籍を選んでそれをベースとしたものを作成した方もいれば、doda特有の事情などについてはこれまでの経験則をガイドラインに込めたという方もいらっしゃいます。
古沢：私はJava言語におけるコーディングガイドラインを担当しています。機械的にプログラムをチェックする仕組みはあるので、機械でできるところは機械に任せ、人間でなければ判断できないような項目に絞って作成を進めてきました。
作成にあたっては「読む側が把握しやすく理解しやすいプログラムとは」を解説している書籍を一つピックアップし、その考え方をガイドラインの大前提として据えました。
読む側を意識したプログラムとは例えば、dodaサイトで求人に対してIDが振られている場合、何のIDかがわかるようにプログラム上の変数名は「id」ではなく「kyujinId」や「jobId」としましょう、というイメージですね。そういった機械ではわからない、人だからこそ配慮できる・すべきポイントを明文化しています。
皆の手で長期的に運用していくことを見据え、無理のない導入を
――新たな仕組みを作った次のステップとして、現場に浸透させるためにどのような取り組みや工夫をされているのでしょうか。
坂井：ガイドラインを作成した後に限定したチームの中で試験運用を行い、ある程度問題なく運用できそうとわかったので、下期から開発チーム全体に共有をかけています。現在はプロセス標準、ガイドライン共に正式運用を始めたばかりのタイミングです。
全体に展開する際には、あらかじめ各チームで開発を牽引する方々にこの開発プロセス標準で一番大切にしたい考え方を共有させていただき、「できるところから、エッセンスを取り入れるだけでもいいので少しずつ進めて欲しい」とお伝えしました。
仕組みを作って無理に当てはめようとするとハレーションが起きかねませんし、特にdodaサイトの開発についてはこれまでチームごと・プロジェクトごとのやり方が確立されていたはずですから。運用方法やサービス、扱うテクノロジーなどが変化していく中で、皆で考えを出し合って仕組みも変化させながら進めていくためにも、無理なく導入することを重視しています。
古沢：ハレーションを生まずに取り入れてもらうために、という観点は、私もガイドラインの内容で意識しました。よくあるコーディング規約やレビューシートのように「〜〜すること」とかっちりした決まり事を決めるのではなく、「Javaのソースコードレビューはこのような方向性で」と大まかな指針や目安を示すようにしています。
――仕組みを作って終わりではなく、内容から展開の方法まで現場に浸透させるための工夫が凝らされているのですね。有志メンバーからのスタートで、予算や体制を組みながらここまで漕ぎ付けられた要因は何だと振り返られますか。
坂井：これまでは、業務委託の方々によるdodaサイト開発に内製エンジニアが加わる形で、いわゆる「事業案件」として開発が進められており、技術的な課題は認識されているものの、やはり事業を前進させることが優先になってしまっていて技術的な改善活動がなかなかできずにいました。
そのような課題感がある中で、「技術的な課題を取り扱い、方向性を考えて手綱を握る役割を内製エンジニアが担う」ことは、いずれ絶対に必要になります。であれば「内製エンジニアで責任を持ちます」と宣言する代わりに予算や体制をしっかりと確保して進めていきたいという思いがあって、今回有志の取り組みを開発プロセス標準に取り込むことにしたんですよね。
「今後プロダクトや事業をどう良くしていきたいか」を常に頭におきながら、今回開発プロセス標準の話が出てきた機会を捉えて動けたことが、一つ大きかったかなと思います。
――古沢さんとしては、この半年の取り組みを振り返っていかがですか。
古沢：ガイドラインを作成するにあたり実際に「今週は忙しくて全然進捗がありませんでした」ということもあった中で、やはり坂井さんの旗振りが上手かったことが一番の要因なのかなと思います。
あとはメンバーのフラットな関係性でしょうか。やはり前職でもエンジニアをやっていて、同じようなことを経験し、同じようなことを思って事業会社に転職してきた人たちが集まっているからこそ、親近感があるんですよね。入社当時、まだメンバーが4名しかいなかった頃から変わらずフラットな関係性がありますし、だからこそ手を挙げた人に対して一緒にやろうという雰囲気があるのかなと感じています。
坂井：同じプロダクトを触って、似たような課題や価値観を共有してきたからこその関係性がありますよね。加えて、そういった私たちの活動に対して、上席の方が「それ必要だよね」と後押ししてくださったことも大きかったなと振り返ります。
長い歴史へのリスペクトを忘れず、さらなる環境改善を目指す
――ご入社されてから坂井さんは1年、古沢さんは2年が経ちますが、入社直後と比べてエンジニアの開発環境やdodaサイトの開発状況はどのように変わったと実感されますか？
古沢：やはり環境や状況は年々良くなってきていると感じますし、優秀な方がどんどん入ってきているからこそ、やれることも増えてきました。そしてその分、私たちの管掌領域も広がってきています。
この広がりには、私たちがガバナンスを効かせる領域が増えたというプラスの側面がある一方、ルールも文化も何もかも違う中でゼロから入ってスタートしなければいけないという難しさもあります。だからこそ横串のルールや仕組みが重要になりますし、まだまだやるべき領域があるなと感じています。
坂井：感覚としては私も同じですね。管掌範囲の広がりに対して、やはりまだまだこれからだなという思いです。
――これまでの開発経験を経て、プロダクト開発統括部の文化として感じるものがあれば教えてください。
坂井：このような取り組みもさせていただいていますが、内製エンジニアたちの中には決して「内製の立場だから、これまでのやり方を無視してトップダウンで物事を進めていこう」という思いはありません。
今まで業務委託も含めた多くの方が、色々なことをやってくださったからこそ今のサービスがあります。そこに対するリスペクトを疎かにはしないですし、どのような改善をするにしても「この課題に対してこういう風にしようと思いますが、どうでしょう」と進めていく、そういった振る舞いは共通していると感じます。
古沢：確かにそうですね。おそらく前職でさまざまな経験をしてきた皆さんだからこそ、そういう気持ちがわかるのかもしれないですね。
あとは開発作業をやっている中でやりづらさや引っかかりがあった時に、「そういうものか」「仕方ないことかな」とそのままにせず、「これに取り組もうよ」と課題として挙げられる、改善意識を持った人が集まっているのかなと感じます。
坂井：私たちは内製エンジニアだからこそ、プロダクトの改善も大事な仕事ですからね。有志で取り組んでいた頃から私の業務目標にはこの取り組みでの改善が含まれていますし、今年度からは更に踏み込んで、これらの改善のみに注力することになっています。自分たちが果たすべき役割だと認識していますし、組織としても改善のための行動を推奨しているところがあるのだと思います。
――それでは最後に、今後この取り組みをどのように進め、組織に対してどのように働きかけていきたいか、お二人の考えをお聞かせください。
古沢：「組織のためだけでなく、自分にとって新しい技術などさまざまなものに挑戦できる場として使っていって欲しい」という言葉を上長からもいただいています。
ガイドラインを作るにあたっての学び直しやコーディングする方の立場を考える経験などを通して、自身のスキルや市場価値も高めながら、組織への貢献を見据えたガイドライン策定や環境改善など一つひとつの取り組みを、楽しみながらやっていきたいです。
坂井：開発プロセス標準やガイドラインについては、現段階ではまず必要最低限のルールをできる限り早く提供した状態なので、今回出したものの改善や他に必要なルールの整備などは順次進めていきたいと思います。一方で、ルールや仕組みは増えすぎても人がついていけないので、今後は自動化・仕組み化などを進めて「意識せずともルールに則っている」状態を作っていきたいですね。
またコンポーネントワーキンググループでは、今後はプロダクト全体の技術的な課題や方針策定なども扱っていくつもりです。テクノロジーとビジネスのバランスを取りながらdodaをより良くする取り組みをしていきたいですし、私たちのはたらく環境をそれぞれのエンジニアの主義・思想をうまく反映できる場にしていきたいと思っています。
古沢さんのおっしゃったように、一人ひとりが市場価値を高めながら、プロダクト、ひいてはサービスを良い方向に持っていっていただいて、結果として我々の価値を皆さんに認めていただくことにもつながり、扱える領域をさらに広げていけたら嬉しいです。
――素敵なお話をありがとうございました！
（取材＝伊藤秋廣（エーアイプロダクション）／文＝永田遥奈 ／撮影 = 小野綾子）
坂井 一憲 Kazunori Sakai
プロダクト開発統括部 第１開発部 dodaサイト開発グループ リードエンジニア
SIerからキャリアスタートし、航空、金融、メーカー、医療など様々な業界を経験。前職ではECサイトを運営する事業会社にて内製エンジニア組織黎明期から参画。サイトシステム全般に関わりながらマネジメントも担当していた。現在は退職。
古沢 佑樹 Yuki Furusawa
プロダクト開発統括部 第１開発部 dodaサイト開発グループ リードエンジニア
新卒でSIerに入社後、主にメガバンクなどの金融系システム開発を行っていた。C言語やCOBOL言語で作られている現行基幹システムを、Java言語に置き換える大規模リプレースプロジェクトなどを担当。2019年9月にパーソルキャリアへ入社し、一貫してdoda本体サイトの内製エンジニアとして開発に携わっている。
※2021年11月現在の情報です。
