求められるマインド、チームの目線……フルサイクル開発の実態とは
株式会社VOYAGE GROUP 技術広報 丹野修一氏
――ではいよいよフルサイクルな開発の本質に迫ります。まずは、身につけるべきスキルとしてはどんなものがあるでしょうか？
河村：本質をとらえるマインドかと。
松本：全く同じことを答えようとしていました。
河村：良かった（笑）。うちは誰と話しても意見が一致することが多いです。分からないことがあればすぐに質問や相談をするという、オープンに作業をアウトプットすることに慣れたほうがいいと思います。
松本：本質をとらえるというところを具体的に言うと、「なぜその技術を採用したのか」といった質問に答えられるか、ということが大事です。
河村：あとはフルサイクルに限りませんが、Webやコンピューター工学から事業に対するものまで、多岐にわたる知識もあると望ましいですね。
――実際にフルサイクルな開発を始めた時、想像とのギャップなどはありますか？
河村：ありませんでした。逆にSIの時は多くがウォーターフローで、上流工程で決められたことを機能設計し、コーディングして、テストして……。「もっとこうあるべきでは」と感じて転職して「やっぱり、こうだよね」と納得できましたから。私にとって原点はSI時代の違和感です。
松本：自分もきっかけは受託のSIでした。ある機能で障害があり、対応することになった時です。月に8時間まで対応できる保守契約で、「10時間あれば本質的な改善までできます」と伝えたところ「（追加料金が発生しないように）8時間以内でできるところまででいいです」となってしまいました。本質的な修正ができなくてモヤッとしたことがあります。ただSIが悪いということではなく、事業の特性によるものですよね。
――実際にフルサイクルな開発を進めるにあたって、チームはどのように動くべきでしょうか？
河村：個人もチームも俯瞰できる目線が必要です。事業やプロダクトを中心にみんなが等距離となるよう、いろんな視点がある状態がいいと思います。近視眼的だと全体の不利益につながりますから。
松本：前職ではインフラエンジニアとバックエンドエンジニアと担当が別れていたので、サーバー構築や権限付与などを行いたければ、別途チケットを作ってインフラエンジニアに依頼していました。現職ではTerraformで管理されているので「プルリクエストを出してリポジトリに追加すればいいよ」と言われてびっくりでした。
丹野：開発におけるサイクルをなめらかに回すために、みんなに裁量と強い権限が与えられています。できるだけ、サイクルを回す度に必要な権限を申請したり依頼したりしなくて済むようにしているのです。
――フルサイクルになるとやることが増えるから業務量が増えるのではと思いましたが、各自が動くから減るのでしょうか。
松本：少なくともスピード感は高まるので減ると思います。
河村：ただ、議論する機会は増えるので、やることが増えたとも言えるかもしれません。
丹野：それでよくよく話してみたら「これさえやれば実現できるね」と分かり、開発するものが減ることもあります。
フルサイクルな開発を実現するために必要なもの
――これからフルサイクルな開発を始めるなら、どこから変えていけばいいでしょうか
松本：さっきのプロダクトマネジャーのお話で思い出しましたが、プロダクトマネジャーに権限が集中して配下の開発者との関わりが少なくなると孤立してしまいます。プロダクトマネジャーは開発者と対立したくないでしょうから、開発者のほうから「これはなぜ開発するのですか？」と質問すると良いと思います。むしろ喜ばれるでしょう。
丹野：VOYAGE GROUPも最初からフルサイクルではありませんでした。10年前からVOYAGE GROUP CTOである小賀が、開発者が事業を理解して価値を出すという考え方を浸透させてきました。ただし、開発者が事業に興味を持つだけでは一方通行になってしまうので、合わせてビジネスサイドにも開発者から質問されたら面倒がらずに答えて欲しいと伝えてきました。それが定着して現在に至ります。互いに「なぜ？」と聞いて説明し合える組織構造や文化が必要です。
――技術面についてもお伺いします。マイクロサービスアーキテクチャやDevOpsなど、相性のいい技術はありますか？
松本：スタートアップならマイクロサービスは要らないと思います。ある程度規模が拡大したら抽象化が必要になりますので、マイクロサービスは事業の成長度合いやフェーズによると思います。
河村：DevOpsは相性がいいです。DevOps的なマインドですね。機能改修など小さなところから関わり始めて、慣れてきたら根を広げて、どのサービスに関わったとか自分の実績を残していくと良いです。あとは可観測性を高めるための投資は必要ですね。「サービスを監視するとはどういうことか」「そのためのメトリクスは何か」「捕捉したエラーについて何をするか」という点で可観測性は重要な要素です。
丹野：マインドだけでは実践が大変になりそうなので、開発から運用までなめらかに回せるような環境づくりに継続的な投資をしていく必要があるかと思います。
河村：開発してリリースしたら終わりだと運用の前でサイクルが切れてしまうんですよね。改善をどうつなげていくかというところで可観測性が必要になります。
松本：そうなると、アプリケーションだけではなく、インフラ周辺もカジュアルに使えるようにTerraformなどでコード化されていると良さそうですね。そうなるとDockerも分かっていると良いと思います。
丹野：環境が整備されていると、開発のサイクルを回しやすくなり、その分リードタイムが減りますし、同じことを何度もやらなくても済みますからね。整備されているとミスを減らせるというメリットもあります。
松本：あとは、何かあったときに戻しやすいのは大事です。フルサイクルだとリリースが増えるので、障害が増えるリスクも高まります。リリースして、何かあったときにすぐに戻せる仕組みが大事です。
――組織づくりの観点では、議論ができる環境が重要だと思います。コロナ禍でオンライン化が進んでいますが、おすすめの工夫などありますか？
河村：前はスタンドアップミーティングがあったのですがオンラインになったので、Web会議をつなげたままにするとか、コミュニケーションの回数や密度を高めています。
松本：Slackの個人チャンネルで作業状況をオープンに発信する人もいます。ある意味、思考の垂れ流しです。そうした社内Slackがあまりに面白くて、Twitterを見なくなったという人もいるくらいです。
――もしあればなのですが、失敗して改善につながった経験とかありますか？
松本：失敗かどうかは微妙ですが、チーム人数が増えたらやりにくくなった経験があります。最近大きめの開発で7〜8人でチームを組みました。いつもはみんな一人で要件ヒアリングから機能の依存関係把握までできていたのに、人数が増えたら分担がうまくいかなくなってしまって。ガントチャートとか用意しておけば良かったねと。
河村：大勢になった瞬間できなくなってしまった例ですね。ここで学んだので次は大丈夫かと思います。大きめの開発ではレビューや反省会をするようにしています。エンジニアリングは百発百中で成功するとは限りません。失敗もオープンにして教訓にする文化が大事かと思います。
――話しづらい質問にも快くお答えいただき、ありがとうございます。そうしたオープンな姿勢がフルサイクルな開発に必要であることが、インタビューを通して良く分かりました。本日はどうもありがとうございました。
