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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

プログラマの成長ステージにも 、仲山 進也さんの加減乗除の考え方が適用できそう。加のステージでは、コードを書いたり読んだりする絶対量が必要。書くほどに速くなるし、経験するほど設計と実装の引き出しが増える。ある程度の要件なら、タスクばらしと見積もりできることを目指す段階。

作りたいものが作れるようになったら、減のステージ。いかに効率的に成果を出せるようになるかを意識する。コスパが上がれば、時間に余裕ができるようになり、新しい技術に挑戦できるようになる。また、チームのメンバーとうまくコミュニケーションして、苦手なことを減らし得意なことに集中する段階。

乗のステージでは、ゼロからフルスクラッチで作れる設計・実装・運用の全般的な開発力に加えて、専門的な技術領域を持ち、その分野でリードできる。チーム内でも他の人を助ける場面が増え、多くのプロジェクトで頼られて、複数の案件に関わりつつセルフマネジメントして並列で価値を出していける段階。

技術領域でなく、バイネームで存在感が出せるのが、除のステージ。仕事はプログラミングだとしても、組織で言えば経営の視点や視野を持ちつつ、自分で考えて成果を出す。自分の趣味嗜好でやっていることと、仕事で成果が出ることが一致しているから、使役される労働ではない。「遊ぶように働く」段階。