デザイナー、ポニーテールのponyです。
今回は2022年1月から所属したプロジェクトを約1年間でメンバー間の関係性を築いた話をしたいと思います。（もちろん私がメインで築いたわけではなく、メンバーみんなで築いた話です！）
2022年1月からジョインして現在2022年11月のため、実際は1年ではなく11ヶ月となります。
1年の方がわかりやすい、このブログがリリースされるのが12月の可能性もあるので約1年としました！
私がデザイナーとして会社にてどんな仕事をしてるかの詳細は「事業部制会社のデザイナーの仕事内容 〜SO Technologiesの場合〜 - SO Technologies 開発者ブログ」をご覧ください。
どんなプロジェクトなのか
私の所属するプロジェクトはライクルというプロダクトの新機能開発チームです。
主にライクルの新機能を作り、既存機能の保守運用は別チームにお任せしています。
※リリース後の自分達のチームで作った機能の保守運用も一部行っています。
この1年間はローカル情報収集という機能を作っていました。
現在、フェーズ1をリリース済みで、今後更に大型アップデートする内容を現在も作り続けています。
ローカル情報収集の機能詳細は「選ばれるお店」を目指す多店舗展開企業向け 店舗ごとの特徴をマップ上でアピールする新機能を提供開始～『ライクル GMB』が、Google ビジネスプロフィール活用における多店舗運用の課題を解決～をご覧ください。
チームメンバー全員が共通で使っているコミュニケーションツールは主にnotionとslackです。
なぜ心理的安全の確保をできたのか
積極的にお互いの事情を自分から伝えていた
週1のkptや朝会で、業務のことではなく、私生活の事情も言える範囲で話していました。
例えば、「引っ越しをするため一時的に回線が使えなくなる」「ワクチン接種で稼働があまりできなくなりそう」という話から「産休育休に入るため抜ける」という話などさまざまです。
突然ですが、私はフィンランドで働いている作者chikaさんの「フィンランドおしごと日記」という漫画が好きでよく読んでいるのですが、この漫画に出てきたチームで大事にしたいことがうちのチームでも実践できていたのかなと思っています。
例えば仕事以外のプライベートで気に病むことがあったら…事情まで話す必要はないけれど、それが仕事に影響する時は"そういう精神状態である"ということはオープンにしていこう！
chika，2022，「フィンランドおしごと日記」, Woman type, (2022年11月21日取得，https://woman-type.jp/wt/feature/25443/ )．
先程話した個人のスケジュールの事情以外にも「風邪っぽさがまだ残ってる」「季節の変化で辛い」「午後の方が集中できるので午後に作業時間を確保したい」とか色々と各メンバーが共有していた記憶があります。
これは最初から全員できていたのかというとそんなことはなくて、一部の人が始めていたけどそういう雰囲気づくりを継続的に行い、辛そうな人がいたときは声かける文化が徐々に醸成できていたからだと思います。
ドキュメント管理の徹底
これはPdMのMさんや開発リーダーのSさんが率先して行ってくれたことなので、本当に感謝しています。
基本的に、わからないことがあったらドキュメントを参考にすれば経緯がわかるように運用されています。
MTGの議事録は当たり前に全て存在しますが、slackで話して決定事項があったら必ずnotionに残すということを徹底しています。
また、notionの記事は、いつ利用する記事か紐付けを明確にして(フェーズ1、フェーズ2など)、見ている人が意味のない古い情報のドキュメントがないようにしました。
もちろん最初はできていなくて、完全にメンバー全員が自主的な運用にできるようになったはここ2〜3ヶ月かと思います。
運用できるようになるまでは定期的に見直しをしていたし、今でも同じ話題のnotion記事が作られてしまった際はお互いが声かけをして1つにまとめる(主に元の方に統合することが多い)ようにしています。
全員が見えない場所の議論は結論と問題点を共有する
弊社はslackにtimesというチャンネルを作り、個人のTwitterのように分報や出退勤連絡、情報共有をすることがあります。
ライクルのメンバーはtimesが多いのですが、多いが故に他メンバーの前でまとまった意見を言う前の脳内情報の整理やつぶやきとして使われることが多いです。
そこでtimesの管理者以外のメンバーが書き込み、議論に発展することも当初はかなり多く、プロジェクトの全メンバーがその議論を把握できないまま一部メンバーだけが問題点を抱えているということが起きてしまいます。
当初はtimes内の議論が多かったのですが、現在は議論はしても大丈夫だけど、結論でなかった問題点or良い案が出た場合は次の日の朝会にて共有する課題表に載せるようにしてます。
timesで議論をしたいメンバーのみがそこに参加して、朝会では議論内容を要点だけ共有して新規提案や質問をその場にいなかったメンバーにできるので、逆にtimesを利用して効率的に話せるようになりました。
相談相手がプロジェクトの主要メンバー以外に存在する
各メンバーの相談相手がいるのですが、朝会などの主要会議には該当メンバーは参加していないメンバーが多いです。
例えば、フロントエンドエンジニアであれば、フロントエンドの相談役のKさん＋CTOのNさん＋スクラムマスターのFさん（＋朝会に同席してる開発リーダーのSさん）になります。
デザイナーであれば、プロダクトオーナーのNさん＋CTOのNさんです。
CTOのNさんとスクラムマスターとフロントエンド相談役のKさんは週1の定例&kpt会議には参加していますが、任意参加でいない時もあります。
いつも仕事をしていて毎日話しているメンバーとは違うメンバーに相談できる状況はとても大事で、違った視点の意見も聞けるし、自分の想定していなかった場所への働きかけや、普段言えない話ができるようになります。
相談相手も1人ではないため、複数人に相談したり専門分野の1人へ相談することもできます。
自分の業務とリソースの状況共有
事業部制会社のデザイナーの仕事内容 〜SO Technologiesの場合〜 - SO Technologies 開発者ブログにもありますが、私を含めてメンバーによっては複数の仕事を同時期に行っていることがあります。
その場合、どうしても期日が迫っている方を優先することもあり、特にデザイナーの私は朝会を任意参加(基本週2以上は参加してますが、どうしても参加してほしい場合は前日にslackから声がけしてもらいます)にしてます。
他のメンバーも機能リリース後の一部保守運用や大型アップデート以外のバックエンドのみで完結する機能改善や、デザイナーとフロントエンドのみで完結する機能改善など、全員同じ業務をやらないこともあります。
とはいえ、全員が行っているフェーズ1のリリースや今後の大型アップデートの開発をメインに進めているので、常に自分の状況と他業務で忙しい期間を朝会や定例で共有しています。
それにより、明確に言語化できない「今、長時間相手の時間を確保しても大丈夫か」「質問しているが結論が出ていない問題はいつ解決してくれるのか」などの不安に対して、大きく問題を感じることがない状況を作れているのではないかと思います。
また、忙しくても一次回答としていつまでに回答するか、見逃した質問・相談がある場合は朝会で相手に共有するなど、誰か1人がもやもやした時間を過ごすことがないようにしています。
起きた課題と解決策
なんだかすごくうまくいってて問題ないような1年間みたいですが、よくある開発プロジェクトにおける課題にもぶつかりました。
メンバーの入れ替わり
このタイトルだとずっと同じメンバーで築いた関係性のように思われるかもしれませんが、実際はメンバーはかなり入れ替わっています。
誤解を招きそうなので念のため書いておきますが、退職者が多いのではなく、同じプロダクトで別チームが存在し、そちらでも新機能の開発や保守運用、プロジェクトマネジメントなどしているため、部署内での配置転換や、同じ仕事のまま所属が変わったという形が多いです。
リソースの状況共有で記載したように、私もこちらのプロダクトだけでなく、別のプロダクトに関わっていたり、別チームの開発に一時的に携わることもありました。
また、産休育休や、兼務だった業務をやめてもうひとつの職種に集中するためにプロジェクトを抜けるといったこともあります。
このプロジェクト自体は2021年の冬にはすでに始まっていたのですが、その頃からいるのはエンジニアのTさん1人のみです。
また、2022年1月〜現在までずっといたメンバーはそのエンジニアのTさんとPdMのMさんとデザイナー(私)のみとなります。
人員が足りない
人員が足りない職種が出てきてしまうことがあります。
弊プロジェクトの場合はフロントエンドエンジニアが足りず、結果的にバックエンドのエンジニアTさんが担当してくれることになりました(本当に感謝)。その際はいろいろな人員補足の解決案を考えながら、状況を常にCTOや開発部長から共有していただき、この結果に辿り着きました。
その際はバックエンドの開発が先に終わってしまうということもありましたが、バックエンドエンジニアのAさんが仕様の調査や意見交換に積極的に参加してくれて、別の業務が進みました。
臨機応変にメンバーがいろんな業務をしてくれることで乗り越えてこれたと思います。感謝です。
新メンバーに対する業務共有
新しく参加したメンバーがいると、どうしても業務共有をしないといけません。
ドキュメントを整備するようにはしていますが、読むだけで誰でも進められるわけではなく、当時作った際には想定しないことがあって環境設定に既存メンバーが立ち合うこともありました。
その際は定期的に行ってるkptで業務共有に時間がかかって開発に時間が取れない状況を共有したり、その反省から次の新メンバーのためのドキュメント作成を行っていこうと話し合いました。
事前に準備してもイレギュラーな事態は発生してしまうので、次にどうするかを大事にして、その時にイレギュラーに時間がかかったことをネガティブに考えないようにしました。
開発フローの変更
プロジェクト自体は、先述通り2021年から存在しており、私と現在のPdMのMさんは2022年1月に参加しました。
メンバーにヒアリングして、今までやりたかったけどリソースの問題でできなかったことや、やるべきだったことを開発フローに盛り込んだりしました。
そうすることで、今までなかった工数の追加や過去に決定していたことの変更が起こり、そこに対する意見が出ることはありました。
具体的にはユーザーストーリーを明確にする工程を追加したのですが、最初は説明不足で始めてしまったことで、「なぜそれを今やるべきか？」と思ったメンバーもいました。
工程をテスト的に実行する前に必要であることの説明、説明した上で本当にやるべきかの精査をすべきだったと思います。結果的に説明したことで必要性がプロジェクトメンバー以外のステークホルダー(プロダクトオーナーなど)含めた全メンバーで明確になり、開発のスケジュールを見直して行うことになりました。
しかし、これがきっかけで今後新しいことを始める時は、発起人がドキュメントを持って提案するという方式になりました。
仕様や開発内容の変更
上記の開発フローの変更から、ユーザーの要望が明確になり仕様が変わることがありました。
その際、どうしても開発内容を変える必要があり、変える場合はその工数が膨らんだスケジュール調整が発生します。
全ての開発内容を変えるわけではなく、リリース後に検証で良い部分は仕様含め開発内容を変更せずに進めたり、スケジュール調整する場合は全体スケジュールも一緒にどこまで変えて良いか考えました。
初期の段階でこの問題に直面したことにより、フェーズ1リリース後の振り返りの時に同じことが発生した際にどうするか、仕様変更はどのレベルで行うのか、決定した内容変更はどのレベルなら行うのかを明確に全員で話し合えました。
未来の方向性に関する考え方のずれ
このプロジェクトだけでなく、プロダクト全体の方向変更から開発内容や全体スケジュールが変わることもありました。
いつも全員が同意してたわけではなかったので、このまま進めるとどうしてもモチベーション的に支障が出てしまうのではないかというとき、まずはメンバー内でお互いの気持ちの共有を行なって、必要あればメンバー外のプロダクトオーナーから説明する機会を設けてもらうこともありました。
この頃から、プロジェクト外のメンバーにも状況を伝えたり、プロジェクトメンバーだけで情報交換を終了させないような文化になってきたかと思います。
ルール化によって起こる必要ない業務
先程、要点で「徹底してる」「運用してる」という言葉を何度か使いましたが、ルール化してしまうと過去には必要だったけど現在では必要ないタスクや習慣が出てしまうことがあります。
リリース後の主要開発に関しては定期的に振り返りを設けることもできますが、大きなことではない場合、振り返らずにルーチンワーク化することもありました。
例えば朝会に関して、開発リーダーのSさんが気づいて「本当に今の形式でいいのか」という会議をゆるっと開いてくれたことがありました。その際にデザイナーのタスクを毎朝口頭のみで連絡してましたが、エンジニアからは「デザイナーのタスクの実行状況がエンジニアが気になる時に見たい」という意見があり、タスクの可視化をすることになりました。
可視化することでslackとnotionで二重でタスク記載をする必要がなくなったので結果的に効率化につながったと思います。
必要ない業務を発見したら気づいた人が提案して、必要あれば続ければ良いし、不要なら代案を実行するかなくしてしまうことを不定期で行っています。
補足:他プロジェクトでは併用できない可能性のある固有メリット
メンバーの性格特性
この1年のプロジェクトに参加していたメンバー全員が穏やかで議論を安定してできるという性格特性を持っています。
また、時間配分を自然と気にしてMTGを長引かせないようにする、無駄な話は自分から早めに切るということができる人たちでした。
これはどうしても不確定事項なので仕方ないですが、1人でも協調性に欠けたり、議論をする際の言葉遣いがキツい人がいたら成り立たなかったのかなと思います。
今後の仕事で活かせること
新しいプロジェクトでも参考にできる
一部、相談相手などはどうしても社内のメンバー人員の事情からできないこともありますが、他の要因は活かすことができると思います。
今後、新しいプロジェクトに参加した際に、なんだかこのプロジェクトは不安だなと思ったら、この記事に記載した要因の中のどれがクリアできてないか1つづつ課題を探ることができると思います。
良いプロジェクトの経験をして自信がついた
補足にも書きましたが、メンバー特性上できたことであり、この1年の業務内容だからできた可能性もあります。
莫大な業務量や解決できない機能開発、補えないメンバー事情など1つでも他の問題が出たら今の状況にはならなかった可能性があります。
ただ、今後他のプロジェクトに参加して問題にぶつかった時、一度もこのようなプロジェクト経験がなく解決するのと、経験したのとでは解決に対するモチベーションが変わると思います。
きっと他のメンバーもそう思ってくれてると思いたいです…！
これからのプロジェクトについて
今後は仕事全く関係ない個人的事情からプロジェクトを一時的に抜けて、4~5ヶ月後にまた戻る予定です。
その時、プロジェクトの体制やメンバーがどうなってるかわからないし、今の雰囲気とは違うかもしれません。
ただ、この約1年を通して行ってきたことで向き合い方も変わったし、また新しいチャレンジができると思います。
とても良い経験をさせていただいたので、2022年1月から参加してくれていた全てのプロジェクトメンバーにお礼を言いたいです！
ありがとうございました！
