現職のUbie（のProduct Platform組織）で働きだして2年たち、働きやすいなと思う点がいくつもある。自社の働きやすい点は慣れてくると当たり前に感じてくるので、改めて軽く言語化してみようと思う。そうすればその点を意識的に改善できるし、カジュアル面談などで自社の魅力を伝えるのにも役立つ。
透明である
とにかく可能な限り情報を透明にしようとしてる点。アクセスしようと思えば一部の例外（従業員の給与だったり、ユーザの個人情報だったり）を除いてすべての情報にアクセスできる。
四半期ごとにOKRを事業チームごとにOKRをたてているが、その内容は当然見れるし、OKRの背景や進捗も見れる。他にも事業計画、事業代表が集まるMTGや各チームのMTGの議事録なども当然のように見ることができる。
アクセスできる人が限られていたり、議事録がなくて実質MTG参加者しか情報にアクセスできないというのを極力なくしている。そのため（だけでないが）、各チームのMTGは統一された方法で実施されてるし、ドキュメントツール（notionを使ってる）に情報を集約したり運用を頑張っている。
型を作り組織に展開する
組織を運営するために、色々なツールやプラクティスを導入することは各社普通に行われると思う。現職の場合はただ導入するだけではなく、運用しながら自分たちにあった形を見つけて最適化させつつ（社内ではこれを「型化」と呼ぶ）、それを組織に展開してみんなに使ってもらうようにしている（社内ではこれを「装着」と呼ぶ）。これはツールやプラクティスだけではなく、チーム内の業務においても同じようにすることもある。この場合はチームローカルなので組織全体に展開することはないが。
例えば採用面接の内容は、カルチャーミスマッチを防いだり面接官が自社のバリューを意識して選考できるように、圧倒的に型化されて面接官に装着されている。どういう点を深ぼるか、どういった視点で議論するかはまとめられているし、そのための質問観点リストもある。面接後の合否判断も（詳細は書けないが）、なるべく面接官ごとにブレがないように共通基準を使って判断するようになっている（とはいえ完全にブレを無くすことはできないが）。
余談だが現職の面接ではカルチャーマッチをすごく重視してるので、コミュニケーションがしやすかったり、メンバーにあった仕組みを整えやすいので働きやすいのもかなりあると思う。
エンジニア運用系タスクの理解
エンジニア同士なら必要性はよく分かるが他職種からだとちょっと分かりづらいというタスクが一定ある（エンジニアに限らない話だが）。例えば負債の解消、システムメトリクスやエラーの監視、ソフトウェアアップデートなどなど。
こういう仕事についてもPdMやビジネスメンバーはそれがなぜ必要なのか、いつやるべきなのか、どこまでやるべきなのかをエンジニアと話して理解したり、時には議論する。というか、エンジニアも暗黙的に必要と思っていたものが、議論することでタスクが明瞭化されて今は他のものを優先したほうがよいとか、実施する範囲が明瞭化される。
直近だとRailsアップグレードについて議論した。なぜやる必要があるのか、やらない場合のリスクはどういうものがあるのか、やるとしたらどれくらいコストがかかるのか。Railsアップグレードじゃなくてこの際システムをNodeアプリに書き換えるのはどうか？メリット・デメリット・コストなどは？というのをエンジニアだけじゃなくてPdMも含めて議論した。
「エンジニアが必要だと言ってるからやる」じゃなくて徹底的に議論と理解を経てやる・やらないが決まったものはその後の進めやすさが違うし、何より気持ちよく仕事に取り組める。
活動ごとの独立組織と組織間連携
自社のミッション（テクノロジーで人々を適切な医療に案内する）を達成するためには、色々な活動が必要である。例えばプロダクト開発、マーケット開発、リスクや財務の管理など。
これらの活動を高いレベルで実施するためには、それに最適な人たちが必要となる。そしてその人たちが最高のパフォーマンスを出すには、その人たちが働きやすい文化や制度（マネジメント方式・報酬制度・採用要件など）を作る必要がある。けど1つの組織の中にいろんな文化や制度を作ると、帯に短し襷に長しになったり、混ざってよくわからないものになる。
そこで、Ubieではそれらの活動ごとに独立して動ける組織を4つ作り、それらの中で最適な文化や制度を作っている。
普通の会社であればこれらは部署として区切られるが、Ubieでは本当に「独立した組織」として作られている。独立とは「SlackやNotionのチームスペースが別で勝手にjoinできない」「他組織のフロアには基本的には出入りできない」というような感じだ。一言でいうと「同じ会社の中にある別の会社」である。
一方で、同じミッション達成のために活動しているので、組織間の連携も独立させることと同じレベルで重要である。
プロダクトを開発するだけでは顧客のもとには届かないし、顧客課題を解決するためには顧客とのコミュニケーションだけでは解決しない。法律や業界ガイドラインへの準拠や様々なリスクへの対応は、目の前のプロダクトや顧客に集中していると気づけ無い（そもそも専門家じゃないとわからないことも多い）。なので各組織が独立して最高の活動をしつつも、それらを日々統合していく必要がある。
とはいえ無秩序に連携してしまうと、組織間の文化や制度の違いからうまく行かないことも多い。そこで各組織の連携のために組織間連携を実施する役割を作ったり、ミーティングやアジェンダの取り扱い方を決めたりしている（社内ではこの仕組みを接合面と呼んでいる）。他にも毎月の全社会では全社OKRについて担当する各組織から状況の共有があったり、毎四半期のオフサイト（オンサイト）では全組織で合同実施をするパートもある。
このように各活動ごとに独立した組織を作ってパフォーマンスを出しやすい環境を作りつつも、それらの組織をうまく連携させてミッション達成に向かうことができるのは非常に働きやすく感じる。
他にも色々働きやすい点はあるが、特に自分が感じる点はこんなところである。当たり前になりすぎて見過ごしてる点やもっと根本的に働きやすい点とかもあるかもしれないが。
ただし、これらの点にもやはりデメリットとのトレードオフがあったりもする。どんなものにもトレードオフがあって当然なので、それはそれとして認識しながらやっていきたい。
