「チームで働くことについて」に関する洞察：社内アンケートより

みなさまこんにちは！DS事業部広報担当です。この度DS事業部では、みなさまに社内の文化やチームの雰囲気を知ってもらうべく、社内メンバーへのアンケートを行い、その回答からチームの傾向性をまとめました。

今回のお題はこちら、

「チームで働くことの良かったストーリーと苦労したストーリー」

個性豊かなDS事業部メンバーですが、どんなストーリーが出てくるのでしょうか？チームの傾向性とともに見ていきたいと思います。

それぞれの質問に対する回答から得られたチームの傾向性

まずは、DS事業部のチームとしての特徴を見ていきたいと思います。それぞれの質問に対する回答をもとに、チームの傾向性をまとめました。

「チームで働くことの良かったストーリーを教えてください」という質問に対しての回答から得られた傾向性

1.チームメンバーの柔軟性とサポート

チームメンバーが互いにタスクを引き受けたり、支援したりしている様子がうかがえる。特に、他のメンバーがタスクを引き受けることで、プロジェクトのスケジュールや成果に対するプレッシャーを軽減している場面が複数ある。

2.リソースの効率的な配分

リソースが不足している状況や急な変更があった場合にチームが迅速に対応し、必要なリソースを追加したりタスクを再配分したりしている。

3.コラボレーションとコミュニケーション

チームが一丸となって問題を解決し、プロジェクトの目標を達成するために効果的なコラボレーションとコミュニケーションが重要であることが示されている。取引先やプロジェクトの要件に関する透明性や理解が、チームの成功に不可欠であることがうかがえる。

4.経験と学習の機会

新しい技術やタスクに対する経験や知識の不足が課題となるが、チームはそのような状況にも前向きに取り組み、経験を積み重ねる機会として捉えている。経験を共有し、新しい技術やアプローチに取り組む姿勢が重要であることが示されている。

こういった傾向から、メンバー間の柔軟性、サポート、効率的なリソース配分、コラボレーションとコミュニケーションの質、そして経験と学習へのオープンな姿勢によってチームワークが成功しているということがわかりました。

「チームで働いていて苦労したストーリーを教えてください」という質問に対しての回答から得られた傾向性

1.技術的な意見の相違

技術的な意見の対立や議論が起こることがある。特に、データベースの呼び出し方法やコンポーネント設計など、開発手法やツールの選択に関する意見の相違についての言及が多い。

2.メンバー間のコミュニケーションの課題

苦労の要因としてコミュニケーション不足が挙げられている。特にリモートワーク環境でのコミュニケーションへの課題が言及されている。

3.チーム内の役割や権限に関する課題

打ち合わせや意思決定の際に、メンバー間で力関係や役割の不明確さが問題となる場面が見られる。特に、議題が進まない場合や衝突が生じた場合に多い。

4.業務外のストレスや心理的負担

業務外のストレスや心理的負担が苦労の要因として挙げられている。特に、エンジニアやリーダーとしての役割に対するストレスや、チームメンバーとの関係に関するストレスが言及されている。

こういった傾向から、チームワークにおける技術的意見の相違、コミュニケーションの課題、役割と権限の不明確さ、および業務外のストレスが主要な課題であることがわかりました。効果的な解決策や明確なコミュニケーション、役割の明確化が必要であることもわかります。

社内メンバーの回答

続いて、社内メンバーの回答をそれぞれ見ていきたいと思います。

Q.チームで働いていて良かったストーリーを教えてください

スクレイピングをサーバーレスで実装する必要があったが、チームで実装経験が無く不確実性が高いものだったので自分でやろうとしていた。しかし自分は他のタスクで圧迫されており、着手できない状況が続いた。その際に、チームの別のメンバーが「それ自分がやりますよ」とタスクを引き取ってくれた。結果、爆速で実装が行われ、チームとしても実装知見を得ることができた。あの時はかなり焦っていて心理的にもスケジュール的にも助かった。（エンジニア）

チームメンバーにQAがアサインされたことで、それ以前に比べてバグを早期に発見できているように感じる。テストケースが単なる品質保証のための検査という役割を担うだけでなく、リリース後の動作保証をする証拠となるという考え方があるというのは学びであった。テストに関する専門的な知識はまだまだ乏しいが、QAの方から教わった基礎を大切に今後も開発を進めて行きたいと思えた。（エンジニア）

規模の大きい機能実装時に、自分は主にフロントエンドの実装を行っていたが、バックエンドのメンバーが自主的にフロントの不具合や実装漏れなどに気づいて、報告、修正をしてもらったことがあった。スケジュール的にかなり厳しいところもあったため、こうした柔軟な立ち回りをしてもらうことができてすごく助かった。（エンジニア）

新機能実装の納期が決まっていてずらせない状況の時に、当初は担当のメンバーで進めていたものの、途中からこのままでは終わらなさそうという危機感が出てきて、急遽別のメンバーを追加アサインすることにした。その結果、各メンバーの負担も減り、実装も無事終えることができた。（エンジニア）

取引先からの強い要望により、現実的に難しい要件と納期になってしまった。以前の体制からの引き継ぎでもあり、契約上どうしても守らなければいけない事情があったため、チームのメンバーに事情を伝えたら「全然やりますよ」とみんなが前向きに反応をしてくれた。実際、一人一人が自分のやるべき領域をオーバーラップしながら一丸となり、要件にも納期にも間に合う事が出来た。以前の体制から引き継いだ時はどうなる事かと思ったが、何とか乗り越えられて助かった。（PM）

テスト作成にも実施にも数日かかる規模のタスクが同時期に複数動き出したため、タスクごとにQAの窓口を設ける必要があった。窓口経験のないメンバーしかいなかったため躊躇したが、経験しないとずっと「経験がない」状態となってしまうため、サポート付きでアサインした。結果として、経験もできたし自分のリソースも圧迫せずに進められた。（QA）

集計系の機能実装時、細かな数値のロジックの確からしさを複数人の視点で確認したことで、要件漏れ、おかしな計算を防ぐことができた。（エンジニア）

インシデントが発生している状況で早さと正確さを要する時に、一緒に確認作業をしてもらえたり、分散して作業や対応をしてもらえる事は非常にありがたく、チームで働いていると感じた。（人事）

仕事を一人で完結させなくても、自分の苦手な部分を他の人が補ってくれるところ。例えば自分はバックエンドロジックを書くのが得意だと思っており、その関連でフロントエンドのロジックも書くことがある。UIの表示調整に関しては苦手だが、その辺りを他の人が対応してくれるのが有り難みを感じた。（エンジニア）

Q.チームで働いていて苦労したストーリーを教えてください

複雑なデータベース呼び出しをSQLクエリで書くかORMで書くかで言い合いになった。自分は経験の浅いメンバーを考慮してORMで書くべきだと主張したが、SQLクエリの方が高度に複雑な呼び出しを最適化して行えるという主張とめちゃくちゃぶつかった。最終的にはSQLクエリの実装で進んだ。今思えば難しい実装は経験が浅いメンバーはあまり触らないし、メンバーのレベル感に実装を合わせるのではなくあるべき実装をするべきなのでSQLクエリで全然良かった。（エンジニア）

フロントエンドのプロジェクトをVue2 から Nuxt3 へ乗り換える方向性で実装が進んでいる中、チームメンバーおよび実装方針の変更があった。新しいチームメンバーで途中までの作業を引き継ぎ、Vue3 へのアップグレードをする対応となった。納期が迫る中プロジェクトの大規模アップデートを進め、新しいメンバーとのコミュニケーションに慣れること、かつてのチームでやっていた作業の引き継ぎなど開発以外で苦労することが多々あった。新メンバーの支えもありながらなんとかリリースすることができ、今は落ち着いている。大変ではあったがチーム開発における苦労話として良い経験であった。（エンジニア）

フルリモートなこともあり、積極的なコミュニケーションが要求されるが、初めはあまりできていないことがあって苦労した。今では、疑問点や話したいことがあればすぐにslackやハドルで会話をするように心がけている。できていない頃は、コミュニケーションが足りていないという自覚があまりなかったという点で苦労していたと思う。（エンジニア）

コンポーネント設計の際に、APIレスポンスデータをそのままpropsに渡すか、必要な情報だけに整形して渡すかで話し合いをしたことがあった。その際、必要な情報だけを渡すべきだと思ったが、使わなくても一旦全部渡しといて問題はないという意見とに分かれた。当時の経験などがメンバーによってバラバラだったため、自分もうまく説明できず、使われていなければ、そのコンポーネント起因のバグにつながるわけではなく、そちらの案を通してしまった。しかし、設計の観点や保守運用の観点から見ても必要な情報だけを渡すべきだったし、使いたくなった時に初めて検討すべきものだった。（エンジニア）

営業側の主張とデザイナーの主張、エンジニアの主張がぶつかる際は苦労した。一人一人がプロ意識を持ってやっているからこそ、ぶつかるのは良い事ではあるが、最初のうちは感情的になる事や、自分の意見やストーリーを上手く伝えれない事があり苦労した。リスペクトを持って、「対話」を腹落ちするまで徹底的に行う事が大切なんだと気づいてからは苦労する事が少なくなった。（PM）

打ち合わせ中に衝突が発生し、議題の内容的にお互いの力関係が同じではなかったため、場が静まり返ってしまった。とりあえず、今か後日するべきか切り分けを行うなど軌道修正を行なってその場を進めた。職務的にも立場的にもなにかと誰かと誰かの間に立つことが多いため、このような場面に遭遇することが多くある。（QA）

機能実装時に、決定事項が決まらず何も進まない状態が長くあったこと。誰かがリーダーシップをとらないとタスクが進まなかった。（エンジニア）

問題が発生した時に個人的にトコトン突き詰めたい性格だが、他の方の温度感はあまり高く無く、苦労では無いがモヤモヤした。（人事）

開発メンバーで仕様の理解が進んでいないメンバーがいて混乱している事がわかったとき。そういう場合は時間を作って説明をして理解を深めてもらう必要がある。その結果、仕様に対する理解が深まり、自分が気づいていない問題点を見つけてくれたりするので大事な時間だと思う。（エンジニア）