dodaサイトの開発における技術的負債の解消・予防のため、新たなプロジェクトが始動。システム設計や実装に対するガイドラインとレビューの枠組みを新設することで、システムのあるべき姿を目指して対話が生まれる仕組みづくりを目指しています。
今この課題に取り組む理由、そして入社4ヶ月目にしてこの大きな取り組みの推進に手を挙げた意義とは――本プロジェクトを主導するdodaエンジニアリンググループ リードエンジニアの坂井に、取り組みの現在地とその背景にある思いを聞きました。
※坂井は退職していますが、本人の同意を得て、掲載を継続しています。
サービスの長い歴史を紡ぐため全体を支えるルールが必要――
――まずは、dodaサイトの開発における課題感や、今回開発ガイドラインの策定に着手した背景を教えてください。
坂井：これまでのdodaサイトの開発には、きちんと明文化・運用されている共通のルールや方針がありませんでした。かつては設計書なども存在していたでしょうし、それをもとにシステムを作られたエンジニアの方々の思想もあったのだとは思いますが、それらが口伝で伝わっていくうちに、だんだんと形骸化してしまっていたのです。またサービスの長い歴史の中で人の入れ替わりも多くありますから、過去の方針や思想から現在の最新の状況まで、全体像を把握できている人もいない状況でした。
――全体の統制が取れていないと、システム上にどのような影響が生まれてくるのでしょうか。
坂井：全体の共通ルールがないということは、各スクラムチームやプロジェクトがそれぞれ独自の方針で開発を進めることになります。各エンジニアの良心に支えられ、それでも開発を続けることはできていましたが、全体で見るとやはりズレは生じるものです。「開発がしづらい」「改修やそのための影響調査に時間がかかる」「改修を入れたことで、別の箇所にエラーが出てしまう」といった影響が発生し、コントロールが利かなくなってきていました。
dodaのようなサービス規模になると、細かい部分まで統制し切ることは現実的でないとは思いますが、最低限守ってもらわなければいけない部分はどうしても存在します。そのポイントを各チームで横串的に押さえてもらうためには、やはり全体のルールが必要だろうということで、「ガイドラインを内製エンジニアで作らないか」とアーキテクトグループの石川さんからご提案いただき、今回のプロジェクトが始動することになりました。
※アーキテクトグループの石川の記事はこちら
――基幹システムも大きいですし、部署横断でルールを設けるのは、大掛かりな取り組みになりますよね。フィジビリのスタートまで、どのような流れで進められたのですか？
坂井：石川さんからは、
- プログラミングを行う上で守るべきコーディングガイドラインの策定
- それがきちんと守られているかどうかをチェックするための、レビューの場の設置
の2点を実施しないか、というご提案をいただいきました。そのお話を受けて、まずはdoda開発に関わる内製エンジニアの中から有志のメンバーを募り、「そもそもどのようなガイドラインが必要か」を議論しました。その中で明確になったのは、必要なものはコーディングガイドラインだけではない、ということだったんです。
例えば「処理の中でエラーが起きた時に、何が起きていて・どのような対処が必要かが分かるようにしよう」という設計指針や、「処理の過程で作成・編集したデータを蓄積すべきか、削除すべきか」といった運用方針など、設計の段階で指摘しておくべき事柄もたくさんあります。またコーディングガイドライン一つをとっても、読みやすさのためのものか、プログラム自体の信頼性や堅牢性を担保するためのものなのか、目的によって求められるルールは別物です。すると、非常に多くのルールが新たに求められることになります。
――全ての完成を待ってフィジビリを行っていると、なかなか前進するのが難しいですね…。
坂井：そうなんです。この枠組みで解決しなければいけない課題は明らかにそこにあるので、すぐにでも走らせたいところですよね。そこで、ガイドラインが100%完成していなくても、ある程度方向性が見えた段階でできるところからレビューを始めることに決めました。領域ごとに「ここはこうすべき」という最終判断ができる人はいるため、少し無理やりであってもレビューを始めた方が、開発を進める上でメリットがあるだろう、という判断ですね。
――まずは一定のカテゴリや観点の中でレビューをしあい、クリティカルな課題や特に注力すべきポイントを明確にしていこう、というイメージですね。
坂井：その通りで、ガイドラインについては現在策定を進めているところです。ただ全てを自分たちで作らなければいけない訳ではなく、webや書籍の情報をうまく取り入れていくことはできるので、そういった外部のノウハウで補えるところは補いながら、dodaのシステム特有の事情についてはしっかりとドキュメンテーションする、という形で切り分けて進めています。
大切なのはルールを守るのではなくサービスが良くなること――
――フィジビリをスタートされる中、他のエンジニアからの反応はいかがですか？
坂井：取り組みを始めた直後に、内製エンジニアがいないプロジェクトから「プログラムの品質が大丈夫か気になっているので、レビューをお願いしたい」と依頼を受けてました。ガイドラインの大枠が見えてきた頃だったので実際にレビューを実施したのですが、「第三者目線できちんとチェックしてもらえてよかった」「レビューというと大きな指摘ばかりが挙がり対応に苦労するイメージだったが、バランスを見ながら基本的なところをしっかり押さえてもらえた」など、こちらが恐縮するくらい褒めちぎられたフィードバックをいただけました。
また指摘事項については、「必ず対応してください」「これはなくてもいいかもしれません」「後でもいいので検討してみてください」など重要度のラベリングをしており、これをもとに優先順位をつけてご対応いただくことができたと伺っています。
そのほかに、私と面識がないにもかかわらず依頼をいただいたプロジェクトもありました。上長から「坂井という人が、こんなことをやっているらしい」という話を聞いて、つながりに来てくれたそうなんです。そうして広まっていくほど、この取り組みが求められていたのかなと感じています。
――それほど皆さんが同じような課題感を持たれていたということですね。改善につなげやすい建設的なレビューの場にしよう、というのは意識されていたのでしょうか？
坂井：そうですね。やるからにはいいものを作りたいし、いいサービスにしてユーザーに価値を提供したい。そのために、一方的にできていないところを指摘するのではなく「これをもっと良くするためにどうしたらいいか？」「この場合ルールより優先すべきものがあると思うが、どうだろうか」と相談したり、フランクに話し合ったりできる場を作りたいという思いがありました。
結局大切なのは「ルールを作ること・守ってもらうこと」ではなく「それによってプロダクトをより良いものにして、ユーザーに価値提供をすること」ですから。ガイドラインを守ってもらう方々にもそう受け取ってもらえるように、細かな配慮を考えてきたつもりです。
――枠組みを作ることは目的ではなく、広い視点で見てサービスを良くするための手段だと。
坂井：はい。そしてさらに広い視点で見ると、この取り組みは「スクラムやプロジェクトを横断した共通ルールを導入するための枠組みづくり」なので、今回のプロジェクトを完遂させたその先で、この枠組みをさまざまな場に活かしていきたいという思いがあります。
開発の仕方などもっと大きなルールが必要になった時に、今回作る枠組みを活かして、部署横断的に話をしたり共通のルールを守ってもらったり、アドバイスをしたりできればなと思っています。
「内製エンジニアがいてくれてよかった」と思ってもらえるような価値発揮を
――ここからは、坂井さんにフォーカスしてお話を伺っていきます。今回プロジェクトを担当されたのは他部署の方のお声がきっかけということでしたが、どのような思いで参画を決められたのでしょうか。
坂井：入社当初から、「システムがどうあるべきか」を判断するための横串的な共通ルールや枠組み、組織がないことが気にかかっていました。スクラムでさまざまな案件を扱う中で、歴史あるシステムならではの課題に直面することも多いのですが、抜本的にシステムを改善したいと思っても、加える変更は他のチームにも影響してしまうため、一つのスクラムチームでできることには限界があります。かといって、チームを横断してディスカッションできる場もないため、どこに話を出せばいいのかも分からず、前に進める難しさを感じていました。
そうした中、システムのより良い姿を追い求めるために、プロジェクトオーナーやスクラムマスターを説得して回るのがいいのか、先に予算をとってきてしまう方がいいのか、と考えていたタイミングで、ちょうど石川さんからお話をいただいたんです。内製エンジニアがやるべき仕事なのに、他部署の方に指摘させてしまって申し訳ない気持ちが半分、このタイミングを逃す手はないという気持ち半分。そんな思いで今回の始動を決めました。
――新しく入った坂井さんだからこそ見える目線が、これまでの課題と融合したような感覚なのでしょうか。システムやエンジニアリング組織を変える可能性があるプロジェクトを、入社して間もない中、担っていこうと思われたのがすごいなと感じます。
坂井：横串的なガイドラインに沿った開発が、前職では当たり前に行われていた、という要素が大きいのかもしれないのです。あるいは問題があると対処したくなる、というエンジニアによくある性質が、私にもあるのかもしれませんね。課題に対して手当てをすることで、より良いものが作れて、自分も楽になる。さらにその経験を活かしてもう一段上のことができるようになるかもしれないですし、その自分の後ろ姿をみて成長してくれる後輩がいるかもしれない。そう考えると、一歩踏み出すことに抵抗はありませんでした。
――入社から今日までの9カ月間、dodaの内製開発に携わってこられましたが、今はどのようなところに面白さや醍醐味を感じていますか？
坂井：月並みではありますが、事業会社の基幹事業であり歴史あるサービスを内製エンジニアとしてシステム面で支え、「今後どうしていくか」を自分たちで決めて価値を追い求めることができる、というところに醍醐味があると思っています。特にBtoC事業であれば、全世界に自分が手がけたものを届けることができるという側面もありますね。
その中でも特にdodaの開発においては、今回の私のように新参者でも手を挙げればチャンスがもらえるのがやりがいでありますし、いざやり始めるとさまざまなところで手を貸していただける部分に、やりやすさも感じています。
――より良い価値提供ができるように、また働きやすいように、システムや環境を変えていきたいという思いがあれば、歴は関係ないのですね。一方で、課題として感じている部分があれば教えてください。
坂井：これまでのdodaサイトの開発では、案件をこなして新たな機能を実装〜リリースするというところに注力していたので、その裏にはやはり多くの技術負債が存在します。それをいかに解消するかという課題には、しっかりと取り組んでいかなければいけないと思っています。
その中で、誰がリードして推進していくべきかというと、やはりそれは内製エンジニアだと思うのです。これまでは横串の枠組みがなく、どうにかしたいと思っても大きく変化を起こすことは難しかったと思いますが、内製エンジニアとしてのバリューを発揮するためには、自分たちで取り組まなければいけないことなのだと捉えています。
――坂井さんの考える内製エンジニアのありたい姿とは、どのようなものでしょうか。
坂井：発揮できるバリューには「外部に委託せずに自分たちで開発ができます」という側面もありますが、求められることは決してそれだけではないはずです。特に現代においては、事業会社の中でエンジニアが事業貢献できる領域が広がってきています。
エンジニアリング力以外に、事業部としての仕事のやり方や業界の知識などさまざまな知見を引き出しとして持ち、それを自在に操りながら対話ができること。そして課題を実際に解消するために一歩踏み出すこと、これらが内製エンジニアとして求められているのだと考えています。
今回のプロジェクトに関しては、たまたま他グループの方が話を持ってきてくださって、背中を押してもらえたところが大きいと思っています。本来であれば、開発を委託された外部のエンジニアではなく事業会社に所属する社員である以上、課題を自分たちで見つけてきて解決策を考え、自ら動き出して勝手に仕事の幅を増やしていくのが筋だと思うんです。それによって「内製エンジニアがいてくれてよかった」「もっと内製エンジニアを増やせば、より良くしていける」と思ってもらえるようにすることも、仕事であり価値発揮の一つなのかなと思いますね。
――今回のガイドライン策定は、その価値発揮の大きな第一歩になりそうですね。それでは最後に、今後の展望やガイドライン策定の先で思い描く世界観を教えてください。
坂井：共通のルールや方針がないというのは今回のガイドラインに限った話ではなく、開発のプロセス全般に言えることです。そこで現在、開発プロセスの標準を作り、守ってほしいガイドラインや条件に応じて通すべきレビューの枠組みを作ろうと始動しています。その取り組みもしっかりと前に進めながら、「自分たちのシステムがどうあるべきか」をきちんとディスカッションし、アクションにつなげられるような仕組みづくりを続けていきたいと思っています。
もちろん、ここでもむやみにルールで縛りつけるつもりはありません。一定の基準を設けて余計なところで悩まなくていい状況を作り、その上で自分たちのあるべき姿をもう一度考えて議論しよう、価値提供のために何ができるかを考えよう、という景気づけになったら嬉しいです。
――素敵なお話をありがとうございました！
（取材＝伊藤秋廣（エーアイプロダクション）／文＝永田遥奈）
坂井 一憲 Kazunori Sakai
プロダクト開発統括部 エンジニアリング部 dodaエンジニアリンググループ リードエンジニア
SIerからキャリアスタートし、航空、金融、メーカー、医療など様々な業界を経験。前職ではECサイトを運営する事業会社にて内製エンジニア組織黎明期から参画。サイトシステム全般に関わりながらマネジメントも担当していた。現在は退職。
※2021年7月現在の情報です。
