🤼

トドケールのエンジニアチーム方針

2024/12/27に公開

はじめに

弊社に興味をお持ちいただいた方に向けて、弊社エンジニアチームで掲げているチーム方針についてご紹介します。
採用している技術や組織的な取り組みについては、以下の記事をご覧ください。

https://zenn.dev/todoker_blog/articles/7dec2e6cb8a5a7

チーム方針

トドケールで掲げているチーム方針は 5 つです。
それぞれどういった意図があるのかも含めてご紹介します。

社内外注ではなく社内共創

  • プロダクト開発を主導していると自負するために、各々が当事者意思を持ち主体性を発揮できる体制にする
  • 常に成果を発信して他チームへ存在感を発揮する

自社サービスを開発するエンジニアとして「仕様が上が考えるもの」という考え方ではなく、自らがプロダクトを開発している当事者意思をもって欲しいと思っています。
せっかく自社サービスを開発しているのだから、エンジニア全員が主体性を発揮し、自らの意見が反映されたプロダクト開発になるよう心がけています。

完璧主義ではなく実験主義

  • はじめから完璧なものはつくれない、課題に対して実験・試作を繰り返すことで解決を目指す
  • 計画にはなくても、各々が思いついたタイミングで提案をし、チームはそれを歓迎する
  • 減点思考から創造的思考に切り替え、批判よりも実験を行う

トドケールでは「とりあえずやっちゃう」というマインドセットを大事にしています。
思いついたら計画無しに動き出す、ということではなく、考えてもわからないときは立ち止まるのではなく走り出せる人を応援するカルチャーです。
他人の揚げ足とりではなく、誰かが始めたチャレンジには周りも協力的であることを明文化することで、全員が自分の意見を発信しやすくする狙いです。

ちゃぶ台はいつでもひっくり返していい

  • 新しいことにチャレンジするのは歓迎、でも間違っている気がしているのに引っ込みがつかなくなっているのはダメ
  • 間違いに気がついたらいつでも止める勇気を持つ
  • また、間違っていた時の代替案も考えた上でチャレンジする意識をもつ

こちらは「完璧主義ではなく実験主義」を実践する過程で陥りそうな「自分がいいだしっぺで始めたことだから引っ込みがつかない」といった状況を回避するために明文化しています
またプロダクト開発でよくある「開発終盤で今更仕様変更なんてできない」みたいな状況の対策でもあります。
一度リリースした機能をなかったことにするのは難しいので、間違っていると判明した時点で最初に戻るのが最善と考えています。

心理的安全性はメンバー全員で作る

  • 対立ではなく建設的な会話を心がけ、議論の最中でもチャーミングさを大切にする
  • 報連相よりも雑談を重視し、全員がメンバーに興味を持つ
  • ネガティブなフィードバックはできるだけ早く対面で行う

トドケールは各拠点にわかれて作業しているため、リモートでのコミュニケーションが主体となります。
チャットやビデオ通話では、意図せず威圧的に感じ取られることもあるため、まずはじめにメンバー間で信頼を築くことを重視しています。

困ったら即、手段を問わず人を頼る

  • 自分一人で何でも解決しようとしない、目的は物事を前に進めることなので周りを頼る
  • 忙しくてイライラしてる状況だったとしても、頼られる側は顔に出さないよう気をつける
  • 頼る側はイライラしてるなと感じても、自分が嫌われているわけではないことを振り返る

こちらは以下のツイートにあった一文をそのまま使わせていただいています。
リモートでのコミュニケーションでは相手の状況が見えにくいからこそ「アラートをあげられない」という状況が生まれやすいと考えています。
これを避けるために人に頼る事を方針として明文化しています

https://x.com/gatlingmiyuki/status/1752860434410131829

おわりに

簡単ですがチーム方針の紹介は以上になります。
すこしでも採用選考へ進むかの判断材料になれば幸いです。

トドケールテックブログ

Discussion