専門が違うメンバーでできたチームは、どう仕事を進めている？　開発体制の変化で得られたメリット・生まれた課題

開発体制の変化で変わったこと・生まれた課題

futaba：次のトークテーマにいければと思います。開発体制が変化してきて、さらに今どうやって開発を進めているかというのがわかったところで、「みなさんの仕事って体制の変化とともにどう変わったのでしょう？」というところですかね。よかったこととか、「今何が課題になっていますか？」みたいなところを何人かに聞いてみたいなと思います。

変化がよくわかるのは古い人かなと思って……。古い人呼ばわりして申し訳ないんですけど（笑）まず一番古株のmiyashitaさんに、エンジニアとして何が変わったかとか、よかったこと、課題みたいなものをちょっと教えてもらえたらと思います。どうですか？　

miyashita：そうですね～。古株的な感じで言うと、先ほど（の話に）もありましたが、エンジニアはやはり開発が中心というか。仕様のこととかを考えることももちろんやっていましたが、いろいろな職種とやることで職能の幅はすごく広がったというか。本当に企画の部分から一緒に考えられている感覚があります。

あとは、先ほどkeroyamaさんが紹介されたようなエンジニアの方がヘルプを書いたり、最近は有志の方がfigmaの使い方をwentzさんと一緒に覚えながら職能の幅を広げようとしている動きもけっこうあったりして。「そのプロダクトを開発していく上で必要な部分は、率先して広げていこう」みたいな感じの動きがあります。

自分が入社した当初と比べると、「自分がこういうところに手を出していきたい」みたいな気持ちがあれば、わりとほかの方が全力でサポートして積極的にやっていけるかなという印象があります。

futaba：なるほど。逆に課題はどんなところがありますか？　

miyashita：これはけっこうみんな感じていますが、単純に人数が純増しているので、その部分のコミュニケーションコストはそれなりにかかっているのかなと思って。

「みんな揃って同期的にミーティングをしたいね」みたいなタイミングがあっても、なかなかスケジュールが押さえづらいとか、意思決定の部分とか。時間を合わせてなにかやるみたいなところはやはり難しい感覚があります。

futaba：確かに私も今回のこのイベントの打ち合わせを調整するとき、みなさんのGoogleカレンダーを合わせると全く隙間が見つからなくて（笑）。という小話だけ挟んで、もう1人くらい聞いてみたいです。

futaba：次なる古株でQAエンジニアのgennyさんにも聞いてみたいんですが、どうでしょう？

genny：課題はだいたい今出ていたのと一緒です。どう変わったかでいうと、わりと初期の頃は、開発が終わったもののテストを実施することがQAエンジニアとしては多かったです。

いろいろな職能の方が入ってきて、クロスファンクショナルみたいな取り組みが増えることによって、テストもいろいろな職能の人が取れるようになった。それによって、QAエンジニアである自分も、例えばヘルプの修正のタスクを取ったり、それこそ自動テストを書いたり実装にチャレンジしたり。

そういうことを、自分だけではなくていろいろなQAエンジニアがやっていると思うんですが、たぶんQAエンジニアだけじゃなくていろいろな職能でそういうことが起きていて。ほかの人がほかの職能にチャレンジしたり、ほかの職能の人が自分の仕事をやってくれるから、さらに新しいチャレンジができるようになっているんじゃないかなと思います。

futaba：なるほど。QAの領域だけじゃなくて別のお仕事をしたり、逆に自分のお仕事をほかの職能の人にお任せしているということなんですね。

genny：そうですね。

futaba：ほおお、すごい。ありがとうございます。せっかくなのでもう1人くらいいこうかなということで、次はkissyさんに聞いてみたいなと思います。今日のイベントはけっこうPdMの方もたくさん参加いただいているんですが、ご自身の仕事の変化をぜひ教えてもらってもいいですか？

kissy：よかったことはたくさんありますが、「PdMが本当にやるべきことに注力できるようになった」というのはすごくいいことかなと思っていて。たぶん今まではPdMががっつり仕様を考えて、デザインの仕様や機能の細かいところも考えた上でチームに委ねるみたいな。昔はそういう開発の仕方がけっこうあったんですけど。

今は、先ほどの話にもあったとおり、初期からみんなで考えられるようになってきているんですよね。なので、自分でもできるかもしれないことを、ほかのもっとできる人に任せられるみたいな。PdMは「なぜ作るのか？」みたいなところに責務を負っているポジションではあるので、そういった、自分がやるべきことに時間をもっと割けるようになるというのはすごくよかったことかなと思ったりします。

これはSmartHR本体機能だけではなくて、たぶん開発組織全体のどのPdMにもつうじる話かなとは思います。

futaba：なるほど〜。ありがとうございます！

UXライターにおけるプロダクトの技術への理解とライティングスキルの割合

futaba：事前質問の中でkeroyamaさん宛にUXライティングについて質問があったので、これも答えられればと思うんですけれど。

「UXライティングにあたって、プロダクトや使われている技術への理解とライティングスキルの両方が必要だと思うのですが。お仕事をする中でこの2つをどのくらいの割合で使っていると感じますか？」みたいな質問がありました。ほかの職能の仕事をされることもある中で、どんな感じなんですか？　

keroyama：割合で答えるのは正直難しいなと思っていますが、強いて言うなら、もちろんUXライターではありますが、その前にやはり「開発チームのメンバー」みたいなところがあったりするので。「プロダクトへの理解が基礎にあって、その上でライティングを専門としている」みたいなニュアンスが近いのかなと思っています。割合で答えられなくて申し訳ないんですけど。

ライティングのスキルだけあっても、やはりプロダクトとか、どういうコンテキストなのかみたいなのをわかっていないとまったく意味がないので。そこは土台として絶対必要だと思っています。

専門性が違う集まりで仕事を進めていくための工夫

futaba：では次のテーマにいきたいと思います。職能横断というかたちでお仕事を進めていくのは、専門性が違うみなさんの集まりなので、やはり難しそうだなと。

特にデザインとかライティングって素人目からするとやはり難しそうというイメージです。そういうのをうまく進めるための仕組みや取り組みってあったりするのかなと。例えばデザインの領域で（お仕事されている）wentzさんに教えてもらいたいなと思うんですけど、どうですか？

wentz：たぶん技術的な難しさというよりは、意思決定をする時にどれが妥当なのか、どれがお客さんにとって最も価値が出るかみたいなところですかね。それはデザインシステムという仕組みを使って、エンジニアやデザイナーではなくても、ある程度意思決定ができるような仕組みがあります。

インターフェイス的なところはもちろん専門性は必要だと思いますが、それをどう組み合わせて目的の機能、要件を達成していこうかとなった時に、「一緒にみんなで考えてみよう」というのが1つ私がよく使う手段です。“モブデザイン”と言っています。

このモブデザインの時間を週に1時間とか枠を作ってもいいし、スプリントタスクの中のスパイクチケット、一時的な対応として「このデザインをやるぞ」みたいなチケットを作って実施しています。さっき見たFigmaというデザインツールを使ってみんなで画面をコピーしながら、「このコンポーネントはこう配置したらいいんじゃないか」とか（を話し合う）。

あとは、「誰がファシリテーターで整理しながら進んでいく」とかではなくて、「こういう文言もあるんだけど、この文言だとわかりづらいよね」みたいなところを、みんなでワーっと、あーだこーだ言いながらやりつつ、その意見をどんどん収束していきながら、「これが一番よさそう」となったら、「次はユーザビリティテストやってみましょう」というところで検証のフェーズに移っていくこともできて。みんなで議論をして進めていくことは、かなりやっていますね。

futaba：考える段階のリードを自分の強みの専門のある領域でやって、（そのあとは）モブデザインだけじゃなくて、例えばモブライティングとかモブプログラミングとか、そういうものでやっているんですかね。モブライティングじゃないか、モブ……何でしたっけ？

wentz：モブヘルプ。

futaba：モブヘルプ！

keroyama：そうですね。モブヘルプだったり、デザインと同じように画面上の文言もモブで揉んだり。完全に同期的じゃなくても、チャットツール上で案を出してワイワイしたりする感じでみんなを巻き込みながら（やっています）。1人で抱え込んで考えて、「じゃあこれでいきます！」ということはもうなくて、本当にみんなの意見を取り入れながらやっていくことを、文言とかヘルプページでもやっていますね。

正直、ヘルプページはまだまだ発展途上なところがあったりしますが、それでもやはり「どういうことを考えて作っているのか」みたいなことはみんなに見せながら、合意を取りながら進めていくところは大事にしています。

futaba：自分の領域もほかの人に任せつつみたいな感じなんですかね。わかりました。

コミュニケーションの問題にどう対処しているか

futaba：課題としてコミュニケーションの問題が出てきていたと思います。そこは例えば新しいメンバーが増えている中で相互理解を進めることであったり、あとプロダクトサイドのメンバーはフルリモートだと思いますが、そういう環境でもうまくやるためにやっていることとかあるのかなと。

課題に対してどのように取り組んでいるのかも、ちょっと教えてもらいたいなと思います。wentzさん、いいですか？　

wentz：先ほどは期待値調整とかをやったと説明しましたが、そういうワークショップみたいなことはけっこうやったりしていて。期待値調整のほかに、ドラッカー風エクササイズとか、あとはスクラムに対しては豊田さんという偉大なアジャイルコーチの方がいらっしゃるんですけど、そのアジャイルコーチの方がチームに妖精のように居座ってくださって……。

futaba：妖精!?　妖精というのはすごくかわいいですね（笑）。

wentz：常日頃からコーチがフィードバックをすごくくれるというよりは、長いことスクラムイベントとかにいてくださって、その中で気づいたことや「ほかのチームではこんなことをやっているよ」みたいなことをフィードバックしてくれたり。

あと、その方の提案で、「まずはお互いのことをよく知りましょう」ということでタイプ分け診断をやっています。それぞれのチームや、自分がどういうタイプなのか、相手がどういうタイプなのかを相互理解をしていくことで、「どういうコミュニケーションだったら取りやすくなりそうか」などお互いの得意不得意を明らかにしていって、コミュニケーションをスムーズにしていくこともやっていたりします。

futaba：すごい。開発チームの中だけじゃなくても、生きる上でも大事そうな取り組み（をしていること）がすごく勉強になります。業務の透明性とか、リモート環境でどうやるかみたいなところってありますか？

miyashita：ほかのチームでやられている施策を、言い方をためらわずに言うと、パクったというか（笑）。導入させてもらったみたいな感じで言うと、ほかのチームでは「Working Out Loud」といって、自分の状況とかを発信していて。今、僕たちはSlackを使っていて、Slack上に「今どんな状況です」「これからこんなタスクをやっていきます」とか、あとは「こういうところで詰まっている」みたいなことも、もしあれば気兼ねなくポンポン投げ込んでいくような話をして。今はみんなで積極的にSlackで状況共有するようにしています。

基本リモートで隣にいるわけじゃなかったりするので、それを導入し始めてから、みんながどんな状況かはけっこう見えやすくなかったかなと思っています。

futaba：へ～、すごいですね。「Working Out Loud」は私も初めて聞いたんですけど、自己開示をするのはけっこう勇気がいると思いつつ、大事なことだなと。

miyashita：最初は「これは書いていいのかな」みたいなためらう感じでしたが、「みんなで書いていこうぜ」という強い気持ちでポンポン投げるようにしていますね。

futaba：大事ですね。そういうのが働きやすさとか、先ほども言いましたが心理的安全性にもつながっているような感じがすごくしました。ありがとうございます。

仕様検討などに別の職能の方が入ることはエンジニアの不満にはつながらないのか？

futaba：質問にも答えていけたらなと思います。口頭で答えられるものがあれば、ぜひどなたかお願いしたいんですが、いかがですか？　

miyashita：（スライドを示して）一番上の「エンジニアの方が仕様検討などから参加することで、開発に集中できる時間が短くなったりするかと思いますが、そのあたりはエンジニアの方々にとって不満につながったり、開発スピードが遅くなったりするのでしょうか？」というところに関しては、エンジニア陣でメチャクチャ不満（がある）みたいなことは、自分が見る範囲ではあまり聞きません。

確かに一緒に仕様を考えたり、いろいろと揉む時間は発生しますが、昔の開発スタイルに比べると、キャッチアップのコストがほぼかからないというか。みんなで一緒に考えたものを作っていくことで、そういったハードルがほぼなく開発につなげられているので、時間的なコストはかかっている部分もあるんですけど、結果的に見れば短くなっているんじゃないのかなと思っています。

あと最近テックブログで「フィーチャーチームの取り組み」というものを掲載していて。実際に開発スタイルが変わってどうなったかも書いているので、そちらを見ていただけるとイメージしやすいかもしれないです。

futaba：ありがとうございます。いい記事がメチャクチャたくさんあるので、ぜひぜひテックブログを（見てみてください）。

miyashita：自分も勉強になったので。

futaba：あとスケジュールのお話とかはどうでしょうか？　「チームメンバーの方はチーム以外のタスク、プロジェクトも受け持っているのでしょうか？」。

kissy：それはたぶんどの職種の人も受け持っているんじゃないかなと思っていて。僕だとcokeチームのPdMという役割だけではなく、SmartHR本体機能のPdMでもあるので、ほかのPdM陣との打ち合わせもあります。

あとはアジャイル推進室という「SmartHRのプロダクトサイド（プロダクト組織）をもうちょっとアジャイルにしていこう」みたいなサブプロジェクトをやっていたりもするので、そこのミーティングもあったり。

各自、cokeチーム以外の仕事もけっこう積極的にやっているので、純粋なスクラムのイベント以外のタスクもみんなちょいちょいあるかなというのはあります。

futaba：ほかの方も全員そんな感じなんですかね？

keroyama：そうですね。

futaba：うなずいていらっしゃる。わかりました。ありがとうございます。そうしたら、あと1個ぐらい答えますかね。なにか答えられそうな質問はありますか？

keroyama：（質問を見て）「ミーティングの時間は何時間です！」と言うのはけっこう難しいですけど、最近ちょっと課題になっているということは確かにあります。「チームの開発の時間に割く時間って実はけっこう少ないんじゃない？」みたいな話がcokeチームでもあがっているし、そのほかのチームでもあがったりしていて。

cokeチームだと、何十時間当てられるのかをちゃんと洗い出して、「本当に開発に割ける時間ってどれくらいなんだろう」というのを出していこうとちょうど今日話していて。「まずは現状をちゃんと把握しよう！」みたいなことからやっていったほうがいいよねという話をエンジニア以外もみんなでしています。

futaba：わかりました。ありがとうございます。

今のやりかたに固執せず、チームで日々改善を続けていく

futaba：ほかの質問も来ていますが、残り時間があと3分くらいになってしまったので、最後のトークテーマをお1人に答えていただいて、クロージングに入っていければと思います。

今いろいろと工夫してみなさんで開発を行っていますが、「今後どうなっていきたいか？」など、チームへの期待をお話しいただきたいです。

あとは、今日聞いている方はもしかしたら（SmartHRの採用に）興味があって聞いていただいているかもしれないので、「どんな人に来てほしいか」をgennyさんから代表して答えていただきたいなと思うんですけれども、よろしいでしょうか？

genny：チームへの期待を聞きたいということで、わかりました！　

まず今後の展望やチームへの期待というところでいくと、いろいろトライはしていますが、今がベストだとはたぶん誰も思っていないはずなので、今のやりかたに固執しないで、引き続きより早くいいものを作っていけるようにチームでいろいろ試していきたいと思っています。ちょっとふわっとしていますが、そんな感じで日々改善していきたいなと思っています。

「どんな人に来てほしいか」というところでいくと、「いいプロダクトを作っていきたい」というプロダクト志向の方に来ていただきたいなというのがあって。いいプロダクトを作るために職種の垣根を超えていろいろとやっていける人。今日（の話に）あったフィーチャーチームであったり、クロスファンクショナルな取り組みに共感していただける方は弊社で楽しくやっていけるんじゃないかなと思っています。以上です。

futaba：ありがとうございます！　今日はいろいろな職種の方に参加していただいていますが、どんな方であってもいいプロダクトを作りたい、チームで開発に携わっていきたいという志向性の方がよさそうですね。ありがとうございます。