会社の人数が増えてきたこともあり、来月からの11期に向けて、人事制度の再整備をしているけれど、とても難しいパズルを解いているような気分。この半年ずっと考えて、ようやく解けそう。

私たちの会社の制度づくりで気をつけていることは、実際に起きている事象を分析して、適切な名前を付けて制度にしていくこと。間違っても制度から導入することがないようにしている。

なので、制度ができても現場レベルでは変わらないことが多い。もちろん伝え方に細心の工夫をして、出来てるかどうかはさておき、制度の導入に伴うハレーションや混乱が起きないよう努力してる。

新しい制度を考えるキッカケも、現場を観察して気付いたこと、社員との1on1で出てきた要望、トラブルやリスクへの対応などがトリガーになる。なので、常に歪みがないか現場を観察している。

全社員リモートワークということもあり、人もデータもデジタル上に存在しているから、時間も越えて見聞きできるし、広範に目配りができる。おそらくオフィスだったら難しかったかもしれない。

実態ありきで制度を作る順にしているのは、制度にした瞬間からレガシーになって、必ず実態の方が未来にいってるからなのと、制度にすると1/0（デジタル）になるけど、実態はアナログだから。

人数が50人を越えて事業も広がった中で、実態からの制度を作るとなると、分析・整理するのも骨が折れる。ただソフトウェア開発でいえば、データモデリングみたいなものでハマると気持ち良い。

特に人事制度は、ゲームデザインをしている気分になる。自由度と制約のバランスが悪いとクソゲーになるけど、うまく作れば、気持ちよく働きつつ個人も成長もできて、フロー状態に入ってもらえる。

ゲームデザインって考えると、自社のビジネスモデルが何なのか、シューティングかRPGか理解せずに、他社の事例や目新しいコンセプトなどを参考にして作ってもうまくいかないのは当然なんだな。

「孤独のグルメ」というドラマが好きで、Netflixで飽きずに何周も見てる。似た感じの店を探して飲んだり食べたりするドラマも好き。

誰に気にするでもなく、好きな店を選んで、好きなメニューを選び、好きなペースで食べる。そういうのが、自分も趣味で好きなのだ。

なんで好きなんだろうって、ふと考えてみたら、単純に美味しい食事が好きというのもあるけど、一人でする店選びが楽しいのかも。

それも自分一人で入る店を選ぶのは楽しい。誰かと行くことを考えると、失敗したくないから気を使うけど、自分だけなら失敗しても良い。

一人旅の旅先で、地元の人しかいなさそうな店に入ってみたりして。うまく溶け込めば楽しいし、外れなら早々に退散する。それも楽しい。

たぶん普段の仕事が、一応は経営の仕事なので、なんだかんだ決める場面が多いけれど、考え抜いてなるべく失敗の無いように決めている。

絶対に失敗しないってことは無理だけど、その時点での考えたベストな判断はしたいと思っている。なので多方面に配慮して決めている。

だから一人で気兼ねなく失敗しても良い店選びするのが好きなのかも。最近はあまり行けないけれど、また気軽に行けるようになると良いな。

採用面接の初回から私も出ることが多いのだけど、どうしても難しい方には、その場でお断りすることになる。とても心苦しいけれど、きちんと伝えている。ただ、結果は単純な合否ではない。

採用面接に向かうときの姿勢は、会社側として採用したいかどうかの視点はいったん横に置いて、応募してくださった方の人生にとってのベストな選択は何かを一緒に考えることにしている。

ベストな選択がソニックガーデンに入ることなら良いし、そうでないことがわかれば、どれだけ優秀な方でも引き留めずに、その選択を応援する。むしろ早くわかって良かったね、となる。

だから、まずは応募された方が本当に何をしたいのかを深掘りしていく。「入社したい」というのは、本質的ではないので、入社するかどうか関係なく何をしたいのかを問うところから始まる。

自分は何をしたいのか、どういう状態になりたいのか、案外と明確に言語化できてない人も多いから、色々な角度から質問してみたり、考えてもらったりして、自分自身で言葉にしてもらう。

自分がしたいことを、自分の言葉で表現するのは、人生の選択肢を考える上で、とても重要で、そこがすりあえば会社としても応援しやすくなる。内発的動機付けマネジメントの第一歩。

これは、もはや採用面接というより、コーチングみたいなものかもしれない。私たちの会社では、入社後も年に一度は、こんな感じで社員と自分がしたいことの「すりあわせ」をしている。

私たちの会社で「すりあわせ」をするときに使っているのがYWTというフレームワーク。「やったこと・わかったこと・次にやること」の、なんと日本語の頭文字。シンプルだけど強力。

なにも転職するときだけでなくても、定期的に本当に自分のしたいことを考えたり、自分が働いている会社と方向性のすりあわせしていく機会があっても良いと思うんだよな。

【理論編】情報の海に溺れないための航海術──「選択と集中」から「分散と修繕」へ｜安斎勇樹

この記事、めちゃくちゃ面白かった。経済合理性を目的から追求する「選択と集中」では変化の激しい中では機能しないため、探究したい問いを起点にした「分散と修繕」で取り組むのが良いという主張。

これまで私が経営の中で取り組んできた姿勢そのものが説明されていて、とても肯定された気持ちでスッキリした。こうして言語化されて嬉しい。

『「分散と修繕」の主眼は「どこかに到達すること」ではなく、あくまで「自己の変容」であり、自分自身のアイデンティティを探究していくことだ。』

経営してて考えることは、まさしくこれで、到達するゴールよりも、その過程におけるアイデンティティの探究で、問いに対して答えを見つけることを続けているに過ぎない。

現代の多くの経営論が、目標ありきのエンジニアリングだから、経営者の集いで違和感と居心地の悪さを感じてたのは、自分の流派が手元にあるもので工夫するブリコラージュだったからだな。

レヴィ＝ストロースの「ブリコラージュ」についても知っていたけれど、こんな風に、問いの探求と組み合わせることで、非常にクリアな論旨を展開できるなんて、美しさを感じる。

力強い洞察を得るためには、マルチタスクが重要で、多面的なインプットとアウトプットによって到達しうるというのも、私たちが兼務を推奨していることに通じるようだ。

『洞察は、これまで結びついていなかったAとBが結びつき、新たな知のつながりが生まれることで起こる。（略）これを「新結合」と呼び、経営学ではイノベーションや組織変革の源泉だとされる。』

「納品のない受託開発」のようなビジネスモデルも、管理ゼロのマネジメントの実践も、私にとって実験みたいなもので、自分の問いを証明したかったのが最初のモチベーションだった。

ある程度の答えが見えてくると、さらにまた新しい問いが生まれて、ずっと続くのかと思っていたけど、「自己の変容」が成果なら、むしろその状態が自然なことなのかもしれない。

まだ読み解けてなく、誤解してる部分もあるかもしれないけれど、私にとっては大きなインスピレーションを貰えた記事でした。

【理論編】情報の海に溺れないための航海術──「選択と集中」から「分散と修繕」へ｜安斎勇樹

私たちの会社には、コードレビューの文化があって、品質を高めるためにも、必ず同僚同士によるレビューが入るようにしている。

コードレビューでの指摘に慣れないうちは、レビューされる度にウッとなる。コードへの指摘だとわかっていても、自分にダメージがくる。

指摘している側は、なにも他意はなく、純粋に良いコードにするために必要な指摘をしているだけなので、ダメージを感じるのは受け手の話。

こうした感覚は慣れてくるものだとわかってはいても、慣れるまではツラい人もいるだろうし、それでレビューを避けるようになっては本末転倒。

その抵抗感への対処のアドバイスは、作ってからレビューを受けるまでに時間をおくことだ。作ってすぐは、まるで自分ごとになってしまう。

なんであれ創作物は、作ってすぐは、自分から切り離されていない。作品＝自分になってしまうけれど、時間が経てば冷静に客観視できる。

コード以外でも、私の経験だと、書籍の原稿なども書いてすぐに、編集の方からのチェックが入るとめげてしまうことも多い。

少しでも時間を置くことで、自分から切り離すことが出来れば、直していくのも前向きに取り組むことができるはず。とてもシンプルだけど効果的。

ふりかえり文化は私たちの会社では欠かせないもので、週に一度、誰かとふりかえりをして、自分の仕事や考えを内省し、客観的にフィードバックしてもらう機会にしている。

アジャイル開発で知られるふりかえりとの違いは、チーム活動でなく、個人ごとに実施している点。レトロスペクティブよりも、リフレクションの色合いが強い。

ふりかえりをすることで、自己改善と自己認知が進む。特に、内省と客観により自己認知が進むことが重要で、それによって結果的に改善も進む。改善テクニックより本質的。

ふりかえりは同僚と1on1の形で実施するので、その二人の関係性も深まる。1時間の時間をとっていれば、ふりかえりしながら雑談もするので、時間をとっておくのが大事。

（余談だけど、ソニックガーデンは代表取締役が二人体制で、毎週の経営ミーティングあるけど、これはある意味1on1で互いのふりかえりをしてたんだなって思った。）

マネージャーがいないこともあり、同僚同士でのふりかえりになるが、その結果をメモで見えるところに残してもらえると、社内の他の人からも存在を認知されるようになる。

そうした個人ごとのふりかえりの他に、リリース作業や顧客ミーティング、社内イベントなど、何かチームやペアで取り組んだ仕事があれば、その直後にふりかえりをしている。

こちらも、まず起きた出来事に対しての認識合わせから始まる。誰かは成功だと思っていても、他の人は違っているかもしれない。チーム内での認知の歪みを解消する。

個人でもチームでも、ふりかえりに使うフレームワークは同じで、KPTを使う。Keep/Problem/Tryで項目を出すという有名なやつ。ただ、最近ひとつ変えたいと思っている。

それは、Problemという言葉。日本語にすると問題となるけど、問題を出すと言うと、けっこう抵抗感がある。あと、解決できないような問題まで出てきてしまう。

そこで、KPTのPは、Potentialとした方が良いんじゃないかと考えている。改善すべき問題よりも、改善できる可能性。そう考えると、前向きにアウトプットできそう。

たかが言葉だけど、人の脳は言葉で考えるから、言葉を変えることで、向き合い方や気持ちの持ちようが変わるなら、変える意味は大きいと思うんだよな。

組織の設計や、制度の策定を考えている中で、もっとも悩むのが名前付けで、良い名前がバチっと決まったときは、その制度の運用を始めてもうまくいくことが多い。

プログラミングでも名前付けはとても大事。変数名、クラス名、テーブル名、様々な場面で名前を付ける。適当につけてしまうと、後で読み返すときに苦労する。

名前を付ける行為は、そこにあるはずの概念を言葉で掴み取ることだ。名前を付けられないとしたら、まだ本質を理解できていない。これはソフトウェア設計における重要な指針になる。

うまく名前付けできたら、あたかも昔から決まっていたかのような感覚になる。なぜ、もっと早くに気付けなかったのかと思うが、よくよく考えるから名前を捕まえられる。

Rubyをつくったまつもとさんも「適切な名前をつけることができた機能については、その設計の8割が完成したと考えても言い過ぎでないことが多い」と仰っていた。

この感覚が、プログラミングというコード（ソフトウェア）のデザインと、経営という組織・制度（ソフトウェア）のデザインの名前付けにおける共通点と言える。

コーポレートガバナンスコードという言葉があるように、組織や制度を支える規則のこともコードと言うから、やはり私にとっては経営もコーディングなのかもな。

ソフトウェア開発の世界には、その品質を評価する基準となる品質特性がある。機能性，信頼性，使用性，効率性，保守性，移植性が、国際規格で決められていて、開発時の指標になる。

こうした品質特性の考え方は、政治や経営の文脈でも考えることができそうだし、むしろ人の考えや概念を扱うのがソフトウェアだとしたら、とてもフィットするのではないだろうか。

機能性は、企業としてのパフォーマンスを示す指標であり、顧客への価値を高めることで売上や成長率といった数字に繋がる。

信頼性は、企業を存続させるためのリスクマネジメントしているかどうかで、トラブルなく続けられるかどうかに繋がる。

使用性は、社員にとってのUXを高めることで、働き方の柔軟さや働きやすい制度などを用意することで採用や離職に繋がる。

効率性は、そのまま業務効率のことであり、無駄なコスト構造を解消し、生産性を高めることで、より多くの利益に繋がる。

保守性は、企業が成長していくにつれて、体制や制度の見直しが求められる中で、変化し続けていけるかどうかに繋がる。

移植性は、企業のサステナビリティを高めるために、後継者の育成や適切な権限委譲などを進めていくことに繋がる。

これら品質特性は、売上だけ見ててもダメなように、どれか一つだけでは持続しないので、うまくチューニングしていくことで、良い状態を作ることができる。

こうした品質の観点をもって経営に取り組むことで、よりバランスの良い健全な企業経営が実現できるように思う。

ビジネスである限り、結果はとても大事だけど、結果だけを求めると、たまたま運が悪くうまくいかないときに辛いことになる。結果は大事にしつつ、そこに至る過程も大事にしたい。

もし仕事自体が楽しくできれば、少なくとも得るものはあったと思える。成功しないことは失敗ではないのかも。幸せになるまでは不幸であると思わない方が幸せという話に似ている。

旅をするときは、目的地があるけれど、目的地に辿り着くことだけをしている訳ではない。旅の途中で得た経験も財産になる。登山も自分の足で登るから頂上からの景色も一入になる。

過程を楽しむためには、健全な人間関係は欠かせない。むしろ、それが全てとも言える。気のおけない仲間となら、たとえ失敗してもフォローして、許し合えば一緒に笑い話にできる。

甘い話かもしれないが、仲間と共に楽しくやれている方が結果は後からついてくる気がする。現場が楽しく働いていれば結果が自ずと出るようにするのが経営かも。とても難しいけど。

仕事をしていく上で判断するときに、合理性がないといけない。合理的に説明できないことでは、人は動いてくれない。熱意や威圧なんかでは、瞬間的には動かせるかもしれないが長続きはしない。

直感や発想を否定しているわけではない。むしろ、新しいことを生み出すのに、合理的に考えても出てこない。合理性は、アイデアを補強していくことに有効であり、合理的でないアイデアは夢想。

一方で、仕事をするのが人だとしたら、情緒的に考えた仕組みにしなければ、誰も動いてくれない。合理的な内容は頭で理解できても、納得を引き出す訳ではない。感情を配慮しなければいけない。

閃いたアイデアの種を合理性でもって補強し、情緒性でもって柔軟にしていく。そこまで考え尽くしても正解とは限らないが、少なくとも誰に対しても説明できて、後から振り返って分析もできる。

マネジメントが「良い感じにすること」であるならば、情緒性を考慮することすらも、合理的に考えて必然のことになる。情緒性と合理性は相反するものではなく、同時に使いこなせばうまくいく。

理念に「遊ぶように働く」を掲げているので、改めて「遊び」について学んでみようと読んでみた書籍「遊ぶが学びに欠かせないわけ」。面白くて、良い知見がもらえた。

特に面白かったのは、心理学から捉えた遊びの効能の部分。これまで経営してきて、なんとなく実感してたことを、心理学の実験で説明されていて、心強い気持ちになったな。

ナレッジワーカーたるプログラマの仕事には、学び、問題解決、創造性が欠かせないけれど、それには仕事を遊びと捉えることが生産性の肝だと考えていたことに合致してる。

遊びの定義も参考になった。遊びは、自主的なもので、結果よりも過程が大事で、規則は参加者から生み出されて、想像するところから始まり、ストレスのない状態で行われる。

仕事を、まるで遊んでいるような状態にするには、そうした環境や構造をつくること。それこそが私たちがやってきたマネジメントだった。

また、農業以前の狩猟採集民の方が、豊かで幸せだったという話が興味深いものだった。

狩猟採集は、労働集約的ではなく、知識集約的・技術集約的なもので、高い技術と創造性が求められる。その仕事は、ワクワクして楽しいものだったので、仕事と遊びを分けることはしない。

狩猟採集の民には、骨を折って働くという仕事の捉え方はない。彼らはたくさんの物はなかったが、少ないニーズを少ない仕事で満たしたことで、たくさんの自由時間を持っていた。

その時間で、歌ったり、作曲したり、楽器を演奏し、物語を語ったり、ゲームで遊んだり、休んだりして過ごした彼らの社会を、文化人類学者が「最初の豊かな社会」と呼んだ。

これって、まるで私たちソニックガーデンで目指しているビジョンと合致していて驚いた。知識労働が中心になってくる中で、多くの人が望む社会の姿なのではないかなぁと思った。

チームに入ってすぐは、周りに相談するばかりで、良いチームほど助けてもらえるけれど、まるでお客様扱い。チーム内で人間関係を築いて相談できる相手を増やすことは大事だけど、それよりも周りの人たちから相談される存在になることの方が本質。チームとは、背中を預けられる同士の集まりでありたい。

一方的に相談したり助けたりする関係でなく、互いの強みを活かして相談しあうことで、チームとしての成果を出せる。そのために出来ることは、飲み会したり仲良くすることだけではない。チーム内で困ったことが起きたときに、声をかけてもらえるようになるには、自ら発信をして存在感を出していくこと。

例えば、チーム内で他の人には負けないと思えるような特定のスキルを身につけ、それに関するノウハウを発信して周りに知られれば、頼られるようになる。もしくは、スキルに自信がなくても、どんな仕事も前向きに受けることを伝えるだけでも、チーム内で困ったら相談しようと思ってもらえるようになる。

チームの一員だから貢献すべきと考えるより、チームの人たちから頼られる存在になれば本人にとって嬉しいし、それに応えて喜ばれると、さらに仕事も楽しくなると考える方が健全だし長続きする。自分に出来ることを探すのではなく、周りから頼ってもらえるようにする。チームワークに対する発想の転換。