現在、80人超の規模となっているエス・エム・エスのプロダクト開発組織。今の規模にまで成長する過程で、開発組織としての文化や価値観が醸成されてきました。そして現在、更なる組織の成長のために、全社のバリューを土台にしつつ、開発組織独自のバリューを言語化し、組織内に更に浸透させていく活動を始めました。活動の概要や、具体的なバリューについては以下の記事で紹介しています。
上の記事の内容を踏まえつつ、バリューに即した行動や考え方がどういうものなのかをよりイメージしやすくなるように、具体的なメンバーの仕事を事例として取り上げて紹介していきます。今回は、「あなたがコミュニティ」のバリューの事例として、EMの @emfurupon777 から名前が挙がったカイポケ伝送チームの @koma_koma_d を紹介します。「チームという環境をメンテナンスする」ための具体的な取り組みやその原動力についてインタビューしました。
「あなたがコミュニティ」であるために、主体的にチームづくりへ貢献する
──これまでのご経歴と、現在の業務内容について教えてください。
文系大学院の修士課程修了後、金融系のシステム開発会社などを経て、2020年4月にエス・エム・エスへ入社しました。入社後は、介護事業者向け経営支援サービス「カイポケ」の介護レセプトチームに約2年間所属し、2022年3月に今のカイポケ伝送チームへ異動になりました。現在は、カイポケリニューアルを見据えた既存サブシステムのリプレイスを担当しています。立場としては一貫して開発者ですが、入社2年目ごろから採用広報や組織改善の取り組みにも携わるようになりました。
──「あなたがコミュニティ」という開発組織のバリューをどのように解釈されていますか。
技術責任者の田辺さんからはじめてバリューの話を聞いたとき、自分が取り組んできたことに近い考え方で、つながりがあるものだと感じました。前職時代からアジャイルなどのコミュニティに参加し、Scrum Developers Night!などの社外の勉強会運営などにも携わるなかで、自分たちが過ごしている環境は他人任せにするのではなく、自分たちで維持・改善していくべきだという考えをずっと持っていました。
コミュニティは放っておいたら廃れてしまいます。コミュニティを維持するためには、新しく入ってきたメンバーをサポートしたり、他のメンバーが気持ちよく動けるようにしていったりといった活動が必要です。これらの取り組みを特定の誰かに担ってもらうのではなく、各メンバーが主体的に行っていくことが重要だと考えています。問題意識を持って自ら動くということが、「あなたがコミュニティ」というバリューにつながってくると思っています。
メンバーの悩みごとを拾い交流を促す「カイポケチームをよくする会」
── 具体的に「あなたがコミュニティ」を実現するために、どのような活動に取り組まれていますか。
具体的には「カイポケチームをよくする会」という名称でチームづくりの活性化活動に取り組んでいます。例えば、マネージャー・メンバーという関係性以外で行う「ピア1on1」や、カイポケ開発組織全体に向けた「DevMeetup」というイベントなどを運営しています。
これらは、他のメンバーとの交流が少なく悩みを相談できず困っていたメンバーがいたことがきっかけでスタートした取り組みです。コロナ禍を受けてリモートワークへ移行し、チームによっては日常的なコミュニケーションが減ってしまったことで、定期的にメンバーの悩みや困りごとを拾う仕組みが求められていました。また、カイポケは現在、既存システムの開発・運用を継続しながらリニューアルに向けた開発を進めており、これに伴い組織規模も拡大しているところです。
チームが違うと通常の業務のなかではコミュニケーションを取る機会が少なくなりがちなので、カイポケチーム全体として人的な交流や他チームが取り組んでいることを知る機会を設けることも重要だと考えました。
──ピア1on1はどのようなテーマで行われることが多いのでしょうか。
ピア1on1の「ピア」とは、英語で「同僚や仲間」を表している単語からとっています。マネージャーとメンバーという関係ではない人との間で行う1on1で、例えば、入社して日の浅い人や普段業務では関わることの少ない違うチームの人にカジュアルに話を聞きにいくといった形で行っていました。「チームをよくする会」の自分以外のメンバーにはマネージャー職の人も多いのですが、ピア1on1では対象のメンバーの組織図上のマネージャーとは別の人を割り当てるようにするなど、なるべく対等な関係で話ができるように設計しました。
もちろんマネージャーとメンバー間の継続的な関係のなかで行われる1on1も大切ですが、「お隣さん」のような対等な関係の方が話しやすいこともあると考えていたからです。たとえば、フラットな関係で普段の仕事の仕方やどういう仕事をしていきたいかなどのキャリアの話を聞いていくなかで、「そういえばこういう課題がありました」や「ここって組織としては方針どうなってるんでしたっけ？」といった話が出てきたりしました。
──DevMeetupはどのような役割を担っているイベントですか。
月に1度開催しているDevMeetupは、新しく入ったメンバーや違うチームのメンバーなど、普段仕事で密なやり取りがない人たちとの接点を生む場となっています。カイポケの各開発チームは担当している領域が大きく異なったり、開発のやり方も違っていたりするので、チームごとにどのような開発をしているか紹介することで、「今度使おうとしているこの技術/プラクティス、あのチームで実績があるみたいだから聞きにいこう！」といった動きも生み出すことができています。
このほか、チームをよくする会の定例の場では、カイポケの開発組織に関する最近目にした課題や、これから取り組んでみたいと考えていることなどをざっくばらんに話し合うようにもしています。個人ではなかなか荷が重い活動も、他のメンバーと一緒であれば動きはじめやすいという点は、会として取り組む意義だと考えています。
「ソフトスキル」の強みを活かし、課題解決に貢献する
──そのほか、チームメンバーが快適に働けるようにするための取り組みは何かされていますか。
「Slack巡回」を積極的に行うようにしています。自分のチーム以外のチャンネルや他のメンバーの分報チャンネルを見て回って、「XXがしたいけれど、どこに申請すればよいかわからない」といった困りごとや他の人にも役立つ情報を発信している人がいないかを見ています。
Slackを巡回するなかで困っている人が見つかれば、関連するドキュメントの場所を伝えたりします。本来は、私がSlackで見つけなくても本人が自力で解決できるようになっていることが理想なので、ドキュメントを新しく書いたり、既存のドキュメントへの導線を整備したりするほか、同じことで困る人が出ないようにするためにも、「そういう困りごとはここで質問するといいですよ」といった形で参加人数の多いSlackチャンネルに誘導するようにしています。また、Slackで情報共有する際には、あとで検索しやすいような言葉やまとめ方にすることを心がけています。
また、Slack巡回にも関連しますが、日常的にドキュメントを書く文化を作ることも意識しています。リモートワークが中心の現在はSlackに一次情報が書き込まれることが多いのですが、それを後から見つけやすいようにするためにはドキュメンテーションツール（esaを主に利用しています）に載せていくことが大切です。私個人は日常的にSlackの検索を駆使して過去のフロー情報を業務に役立てることも多いのですが、ストック情報として整備する必要性がなくなるわけではありません。
例えば、介護レセプトチームに所属していたときの話になりますが、ドキュメントを書かずに終わってしまう理由として「小さいことだから書かなくていいか」と「ちょうど良い置き場所がない」の二つが、最も多い理由だと当時感じていました。そこで、特に内容を問わずに「将来誰かの役に立つかも」というもの置いておく場所として「転ばぬ先の杖」というディレクトリ（esaでの言い方は「カテゴリ」）を用意したところ、多くのメンバーが何かあればそこにドキュメントを書くようになりました。もちろん、このディレクトリよりも適切な置き場所がある場合もありますが、まずはドキュメントを書いて他の人の見えるところに置く習慣を身に付けることが重要だと考えています。こうしてドキュメントとして情報共有する文化ができてくれば、普段の業務で感じた困りごとを自ら解決できるようになるだけでなく、新しいメンバーのオンボーディングにも役立ちます。
──ちょっとした工夫で情報共有の仕組みがうまく回り始めているんですね。こうした活動に取り組まれてるなかで、どのようなことを大切にされているのでしょうか。
自分が「もっとこうだったらいいのに」と思ったり、誰かが不便そうにしていたりするときは、改善の提案やそのためのアクションを積極的に取るよう意識しています。ツールの管理者や他部署の人を巻き込まなければならない場合もありますが、そこまで含めてやることも多いです。
一方で、みんながみんな何か問題意識を持ったら自ら改善のためのアクションまで取らないといけないかというと、そうではないと考えています。私はもう入社4年目なので、どうすると改善の動きが進めやすいかなども割とわかってきているのですが、逆に現状に慣れてしまっていて問題意識を持ちづらくなってしまっていることも感じます。また、人の個性としても問題によく気がつく人、声を上げやすい人というのは必ずしも改善の動きを実際にするのが得意な人とは違ったりするので、声を上げるだけでも貢献だと考えています。これは、OSS開発でissueを立てるだけでもよくて、必ずしもpull requestを送るところまでやらなくてもいいんですよ、ということに似ています。もちろん、新しいメンバーがpull requestを送れるように、組織の文脈でいえば改善のための動きを取れるように支援するということも大切ですけどね。
自ら改善のアクションを取ろうとするのは、単純に困っている人を助けたくなるという自分自身の性格的なところが大きいかもしれません。また、もともと情報系のバックグラウンドがほとんどない状態でエンジニアとしてのキャリアをスタートしたので、技術的な知識やスキルが他の人に比べて弱かった分、ソフトスキルで貢献しようという意識を持つようになったというのもあります。開発者であれば、ツールを作成したり、CIを整えたりというアプローチで他のメンバーの働く環境を良くして組織全体のパフォーマンスを上げるのが一般的で、自分もそういった形での貢献をもっとしていきたいと思いますし、実際に取り組んでもいるのですが、自分の場合はより広く技術以外の部分も含めて環境を整えているというイメージです。組織や同僚のために今の自分ができることはなんだろう？と模索をした結果、こうした活動に行き着きました。
自分以外に同じような活動をする人が増えてほしい
──どのような思いや考えが活動の原動力になっているのでしょうか。
仕事をしている時間は生活の中でも結構長いので、楽しく快適に仕事に取り組めるようにしたいですし、周りのメンバーにもそうであってほしいという思いがあります。また、自分や一部のメンバーにとってだけ快適な環境では他の人に皺寄せがいってしまって持続性がないので、チームや職種を問わずみんなが快適だと感じ、組織として成果を出せる環境を目指すべきだと考えています。
──活動を通して課題に感じられている部分や苦労されていること、今後やっていきたいと思うことなどはありますか。
オンボーディングや環境づくりはマネージャーの仕事というイメージがあるのか、入社して間もないメンバーから「マネージャーだと思っていました」と言われてしまうことがあります。そう言われるのが嫌なわけではないのですが、本意ではありません。マネージャーでなくても、自分たちの組織を良くする活動には積極的に取り組んでもらいたいからです。
こういうふうに思われてしまうのは、「あなたがコミュニティ」というバリューがオンボーディングの中でまだ全体に十分に伝わりきっていないからかもしれません。また、自分がやりすぎているというのも要因の1つなのでは？と最近は感じています。「あの人がやっているから自分はやらなくてもいいや」と思われてしまうと、組織としての持続可能性がなくなってしまうので、マネージャーやリーダーが委譲をするのと同じで、一歩引いて他に同じような活動をしてくれるメンバーが出てくるのを待つことも必要なのかなと感じています。ついつい関わりに行ってしまうので我慢が必要なのですが……（笑）
こうした課題感があるので、今後はもうひとつ上の視座から、チームや組織の改善活動に取り組んでいきたいと考えています。
