やったこと・書いたもの{2021,10}

OSS

github.com

ふと思いついて・・・くらいのノリだったのですが。
Sentryの公式SDKのREADMEに「3rd party integration」のセクションがあり、そこにconnehito/cake-sentryを掲載してもらいました。
(コネヒトCTOの了承済み)

勉強会・LT

PHP Conference Japan 2021に登壇しました

その他

Re: 成長戦略(2020)

「まとめよう、まとめよう・・・」と思いながらずっと時間が流れていってた。
今の会社に入って1年が経つので、このタイミングでケリをつけたい。
(その上で、この1年を振り返ってみたり、今考えていることを棚卸ししてみる土台としたい)
※ 2020年の7〜9月ごろから書いてたは貯め書いては貯めしていた記事になります。なので記事中で「ここ1年」とか言っているのは、2019年春夏 - 2020年夏秋くらいのことです。


公開タイミングはともかくとして、こんな記事を書いてから1年ほどが経った。

daisuki.nichiyoubi.land

記事中にも書いたとおり「内容についてはアップデートして行き続けられると良い」と思っており、また実際に自分の中で変化・変更した部分もあるので、改めて読み返しながら「2020年度上半期と下半期の変わり目くらいで考えていること」について整理してみたい。

以前の考え方

先の記事で表そうとした内容は、次のように理解している。

総論: いちエンジニアとしての成長実感の最大化

  1. 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか
  2. ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるか
  3. 「正しさ」を中心的な価値観に据えて、空気」よりも本質的な議論や意見交換に集中できること
  4. 自分がちゃんと本気を出しながら仕事に取り組める事

実際にコレを指針として行動をし・・というよりは環境を変え、そこでまた新しい刺激や「自分自身はどうした方が良いのか」と気付いた事が多々あり、今回の「差分」はそうした経験によるものがメインとなる。

今の考え方

結局の所は「どう成長していくか」をグルグルと考え続けている〜というのは変わらない。
また一言でまとめるならば、

総論: 主体的に不確実性を制御し、成長し続けるためのやり方の発見と実践をする

だろうか。

最も大きな「変化」というのは、実は自分の中の視点であり、逆に言えば「見方」が変わったのに比べれば自身の実力や経験値というのは然程変わっていないのかな、と思う。

その「変わったところ」というのが以下のようになる。

  • 「伸びる環境」というのはあるが、まず先出すのは自身の成長意欲と実践
    • 「すごい人」というのは居るし、憧れるが、「一緒にいる」だけで吸収できるものがあるはず・・というのは幻想
    • その「すごい人」をすごい人たらしめた要因はどこか?が重要そう
  • 「1つの事を徹底的に深くやる」よりも、「中心となる軸を、より立体的に捉えるための副次的な武器・視点」を得たい

これらについて、先のバージョンの「軸」を反省しながら照らし合わせる形で解きほぐしてみる。

差分の深堀り

1. 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか

これはまさに、この1年で経験できた。まだまだ結果が出た訳ではないが、自分にとってのターニングポイントになるものではないかと期待している。

「強い人と働けるのは福利厚生」というのは、この業界・職種でよく耳にするが、実際にそのとおりだな〜と思う。Slackで何気なくつぶやいた事に対して、さらさら〜〜っと関連する概念を紹介した上で「この本に書いてあるよ」とか言われるの凄い。普段の業務の中で出した、なんてことないPRに対しても「この本の概念を借りると〜」などと、原理原則まで立ち返って理解するきっかけをくれる。最高のUX!
他方で、あくまで「福利厚生」だなぁとも思った。

通常の業務において、「妥協せずに持てる知識・技量のすべてを注ぎ込んで成果を出すこと」というのは稀で、どちらかといえば「いま目の前にある課題にどうやって”対処”するか」が仕事の多くを占めていると思う。
時間軸やタスク観点でもそうだし、また組織内の「人」においてもそうだ。人によって、思考や技量が大きく違う。
そこでどうなるか?というと、「組織の平均くらい」の力が、おおよそのプロダクトの「質」になってくる。
もちろん、「内部品質がユーザー観点で即時的な価値を生むか?」というと否なので*1、「仕事をしなければいけない」以上はそれが正しい。
結果的に、「自分が扱う仕事」というのは、綺麗事や理想的なものでなんか出来ておらず、「集団の状態やレベルに合わせてやる」ことが業務となる。
(加えて言えば、大抵は「目の前にあるコード」をお手本としてプロダクトコードは増殖していくものなので、「昔書かれたコードの質が引き継がれる」という重力が強い。)

強い人が居るというのが「福利厚生だ」と思ったのがこの点で、働いたり組織に所属する上での魅力・楽しみになったりはするかも知れないが、「本来の仕事」の質へは必ずしも直接的に影響しないな・・・と。
当然、「その人が居ることによって、ちゃんとしていく部分」というのはもちろんある。しかし、「大多数がちゃんとする」までは「大半はそこそこのもの」であり続けるのだ。その「出来る人」が本当に「改革!!」「刷新!!」というところにフォーカスして動きでもしない限りは、そういう状態が続く・・・楽観的に見ても「ゆっくりしたペースでよくなる」くらいかな、と感じる。また、彼らも「与えられた仕事」があって、その仕事を選定するのは組織側の判断なので、結局「すごい人がいる」というのが「どのくらいの効果をもたらすか」というのは、当人対組織の関係性や働きかけの問題だったり、そもそもの組織としての価値判断がどうなっているか?に帰結していく。

リアルに「バスケットの国アメリカの空気を吸うだけで僕は高く跳べると思っていたのかなぁ…」という気持ちに。

しかしながら、自分にとっては、そこに気付いた事が強烈な希望となった。
「じゃああの人達はどうやって強くなったんだ・・?」という疑問に心を奪われ、自分なりに仮説を持つことが出来たのだ。

  1. そもそも「身を置いている組織や環境から、与えられた成長の質が高く、今の状態になった」という可能性が薄くなった
    • すなわち、「環境に依存せずに自己成長を規定できている」ことを意味する
  2. どうやって自己成長を支えているのか?を観察した結果、まずはインプット量が自分とは段違いだった
    • とにかく本を読む読む・・・!

「明確に自分と違う点」が見つかったことで、じゃあまだ自分も成長の余地が残されてるじゃん!!!という希望だ。

ということで、 「①自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる、「強い」人が近くにいるか」は、今はこだわりが無くなった。

居るに越したことは無いが〜〜〜と思いつつ、実際にはこの職種だとコミュニティだったりSNS上で人と出会ったり繋がったりすることができる。
なので、必ずしも「いつも働く場所」に居ることは必須条件ではない。

また、「自分は自力で成長できるか?」というのを試すためには、いっそ「自分しかいない」という所に身を置くとわかりやすい。
新卒して入った会社を発った理由の1つが(当時はWebアプリエンジニアが他にいなかったので)「自分は必要なフィードバックを受け取れているのだろうか」という疑念からだったが、PHPを弄り始めて10年目を迎えようというこのタイミングで、一周して「自分の実力を高めるには自分でガンガンやるしかない」に至ったのは何だか面白いな。

Update: 自分にとってプログラマとして刺激を受ける人が近くにいるか・学びを得られる「強い」人が近くにいるかに頼らずとも、自分が成長できるように考えて行動する

2. ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるか

これは、大事にしたい価値観として言えば、今も変わってないかなぁ。。

とはいっても、「結局のところ、組織や集団を動かしたり、既にあるプロダクト(コード)を変えていくのは大変なんだな」というのは先述の通り。
「自分が成長できるか」という期待を、身を置く環境(平たく言えば働く会社)に求めすぎていたなぁという反省を持っている。
なので、「必須条件」ではなくなったと思う。あるに越したことはない。ない場合、恐らく仕事はつまらない物になる・・

ただ、もうその辺りの「環境ガチャ」は不可避だと思うので、期待値を高める〜というよりリスクを下げる〜っていう方に重心を置いてみる方がよいのかな?と。
また、「自身の成長の幅を組織にコントロールされるべきではない」という点で言えば、「自身が影響を与え、変化させていく」という選択肢も必要。
この辺りを考えると「色々な現場で、色々な空気に触れる」というのは合理的かな〜と思うので、副業しながら動いていくのを前提としたいかな、という感覚。
「どこでも通用する技量やコミュニケーション能力」だったり「一般的に共通する課題、パターン」が身につけば、自分がもっと上手くやっていける可能性は高まると思う。

Update: ちゃんと技術について深く考え・力を付けようという気概があり、新たに得た知識や力をプロダクトに反映できるかは大事。そのために自ら働きかけ、築いていけるようにする力が必要

3. 「正しさ」を中心的な価値観に据えて、「空気」よりも本質的な議論や意見交換に集中できること

コレも本質的には変わっていないのだけど、でも掌返しだな・・・って思えるくらい、自分の中で感覚が変わった部分。

何が人格攻撃で何が違うか、は受け手の感じ方次第でしょと思う面がある。もしくは、人格攻撃でなくても「心が折れる」という状態が生じる。一生懸命やったはずが、自分なりの「誠実さ」が通じなくなってくるのは何よりも辛い。

そういうのまで気にし続けながら働くというのは、自分にとっては難しそうだなーと思う。

と先には書いたが、いざ自分が「1番無力な立場」になると、「やっぱりストレスを多く感じるな〜」と身を持って体験した。
この辺りは、↓に書いた内容にも通じる。 daisuki.nichiyoubi.land

「同じくらいの力量同士で、どんなボールでも投げあいながら論を交わせる」というのは理想だし効率良いんだろうなーと思いつつ。
争いは同じレベルの者同士でしか発生し得ないよなぁ〜と。 その上で、(前に人に言われたことだけども)「配慮を覚える」というコストは、支払うべき価値のあるものだな〜という感覚が現状。

そこに至るのが「驚異や不安に晒されてみて自分が辛かった、力を出せなかった」からだ・・というのが軟弱な人間だなぁガキだなぁとは思いつつ、自分自身に原体験として刻み込めたのは良い事。

それでも、「なんか良くないな、でも自分が持っている価値観を変えてまで”心理的安全性信者”になるべきだろうか?」と葛藤していた期間が短くなかった。
そんな時に「チームが機能するとはどういうことか」を読んで、その内容が非常に琴線に触れた。よ〜し掌でもなんでも裏返してやるぞーー!って思えるくらいには。

状況として「自分が実力でどうこうできる範囲なんて凄い小さいな」とも感じていた時期だったので、「より成功するためにはチームの力を引き出しきることが必要」「その目的のために、手段として心理的安全性」というような話が鮮烈に響いた。
心理的安全性」ありきではなくて、よりタフに前に進むためにやれる手段・・・であれば、自分も意気地になったりせずに合意しやすいコンセプトとなる。

確かに理性的に考えて&プロフェッショナルとして「言うべきことは言う」という選択も色々な場面で可能なはずではある。
が、それ以前に、「そもそも言ってみたくなる」とか「ちゃんとしたいと思えるか(気付けるか)どうか」についてもハードルがあると思う。その辺りは、「普段から快適な発言や意見交換を出来ているか」は無意識にフィルタリングされてしまうのではないか・・?

結局の所、「正論はガンガン言うべき」も「然るべき配慮を伴って発言をするべき」も、高次元でみたら目的は一致していると思う。
「誰かが意見を言ってくれない」というのが「自分にとって損な事」という点。
その目的地へと向かうにあたって、「ぶつけ合う」道を選ぶか「引き出す」道を選ぶか?というところ。
理屈として、突き詰めればその2つに差はないと思うんだけど。ただ、実際問題として「人間や心は面倒くさい」ので、「どちらがリスクが低いか」「コストが低いか」のバランスなのかなーと。
そう考えた時に、自分自身が「実際に参ってしまった」というのが「前回と今回の時点での差分」となる。

穿った見方をすると、「発言するのにハードルを感じる」のは「自身の正しさに自身を持ちきれていない」という側面もある場合もあり、すると「稚拙な意見」が表明される可能性もあるはず。
そうなった時に、「組織として成長する方法」を観点として持つことで、「全体的なベースラインを上げる」というのも実行可能な選択肢に含まれるはず。
であれば、「稚拙さ」がなぜ生じているのか・・?を考えるのは、重大な示唆をもたらすのではないか。
「知識が暗黙的になっていて、共有されていない」だとか「埋めるべき技量のギャップが放置されている」だとか。
そういった「寄り添い」がチームを育てると思うし、長期的には「多様な視点、複眼的な意見をチーム内にインストールしていく」という価値を形成していくはず。
だとすれば、やはり「みんなが色々と言いやすい・感じやすい」ようになる方向へと倒すほうが、合理的なんじゃないかな〜と。

もっとシンプルに言えば、「人の意見や感情に向き合う」という謙虚さから、自身やチームが学び取れることは多いはずだ、と。 スタンドプレーや結論を急ぎすぎる組織は、重大な見落としをしたり、ベストではない結論に手を出してしまいかねないリスクに晒されている。 もし自分が「あらゆる正解を出せる実力がある」と信じて、独裁的に振る舞っても問題がないとするのでもない限り、 「自分より他人のほうが凄いかも知れない」という可能性を肝に銘じておく。

Update: 「空気」よりも本質的な議論や意見交換に集中できることは重要。多様で複眼的な意見を吸い上げる事が、より「本質」に向かうための手段となる

4. 自分がちゃんと本気を出しながら仕事に取り組める事

これについては、文字面を見ると「それが出来るに越したことはない」と思いつつ。
他方で、「成長しよう」という観点から言えば、先述としては「環境に自身の成長を委ねすぎるな」が今の気分であり、当時と少し解釈が違うように思う。

先の記事で書かれた内容を掻い摘むとこうなる。

  • 「考えなきゃいけないこと」を減らしたい
    • 例えば自分に課せられているミッションがコロコロ変わるのは辛い
    • 「守らなきゃいけない領域・要素が増える」のは今の自分が望むものか?その場合、「職種」としての実力や経験値は増やせそう*4だが、「技術力を伸ばす」のに集中できるか?といったら、鈍化しそうだ。
  • そうすると、「組織規模自体が少し大きめで、各領域が専門化している・役割分担ができている」「組織開発に力を入れようとしているという姿勢が見える」という条件がついてくる
    • マイクロなところでいえば「EMが機能していそう」というのも含む*5。

すなわち、「1つの分野・領域を、とことん深掘れるようにする」ことに重きをおいている。

Update: 自分の「成長」の源泉はあくまで自分が作り出す。それと「会社に与えられたミッション」の同一性を求めすぎない。ただの「薄くて広い便利屋」にならないように、自身の提供できるトータルの価値を築く必要はある

これらを踏まえて今の気持ちを振り返ってみる

今回は特に②の後半「プロダクトに反映できる事」が重要かなぁという風に思う。
また、④についても芯は同じ。ただ、「EMが居て自分を引き出してくれる」状態を望んでいた前回に比べれば、変容もあり、「自分がやるべき仕事がある」ことを感じやすい環境が良さそう。戦略レベルでは同じだが戦術レベルでは総入れ替え、というか。
要するに、「もっと必死こいて手を動かして、会社やサービスを進化させる側に居る」とい状況を実現したい。

①については、口惜しくはあるが、有る種の「検証」が現職で出来たような感じ。プライオリティが落ちる。
「誰かから教えを盗む・もらう」だけでなく、「自分で学んだ・調べたことをアウトプットしていく」という学習の形も有る。実際、過去を振り返って考えてみると、最も自分の力が伸びたと感じたのは「新しい人が入ってきて、必死にその人のコードレビューをした時」だった。また、大きめのカンファレンスでの登壇を数回経験して感じたのは、「自身の思考を整理する」事によって得られる成長というのは間違いなくあるというもの。
そう思えば、「周りの人間に絶望するより前にやるべきこと」として、もしかしたら周囲のメンバーを惹き付けて相互学習したり、相手のレベルを高めるには?という観点に立つ事で、不満を解消できるかもしれない。

③については、過去の環境で「出来なかった」のがショックでもあったので欲していたが、少し”丸くなった”んと感じているた点。今なら気をつけられる気がする(し克服した方が良いのも理解はしているし)、「やっぱり皆で活き活きできるように頑張るの大事だよね・・・」という方に関心も少しは向いたので、ちょっと視点を変える。
とはいえ、「コトに集中して、理性的に互いへ向き合える環境であるか」の部分は変わらず。一体感が備わっている事は必要。

差分についてまとめると。
「深いところに行ってみたい」のは、当時も今も変わっていないが、「その道のりを変えてみても良いのかもしれない」というのが差分。 「身近に凄い人が居てもそれだけでは十分じゃなかった」という所から修正が加わったので、次は「自分が多種多様な打席に立つことで武器を増やし、それを使ってコアな領域も深める」という形でやってみようか?と。

ただ、これまでよりも遥かに「自学する」ことは必要になりそうだなぁ。そうでないと「浅いやつ」になっちゃう。

今の状態の総括と、今後のことを考えての大方針

  • 自分から見て「すごいレベルの高い人」と一緒に働けた事は大きくて、他方で「そういう人がいる環境で働きたい」といっている自分は「"外部環境"という非常にアンコントローラブルで不安定・不確実な因子に依存していないか」という事に不安を覚えた
    • その「すごい人達」がすごい理由は、自身で自己を高めるべく尋常じゃない研鑽(インプットだったりトレーニングだったり)に当たり前のように取り組んでいるからだ!というのを目の当たりにした
    • 自分も、そのように「自分で自分の成長を実現する」ような力をつける必要がある。主導権を取り返す。
  • 総合的に「より自身の選択について高い確実性を獲得するには」というのがテーマな気がする
    • 例えば「非常に小さなorアーリーな環境も選択肢に含めたい」と思った際に、よりハイキャリアorフルサイクル(もしくは両者)の経験が足りていない
    • 例えば「経験の深い言語やFWの制約を超えた選択肢を含めたい」と思った際に、経験領域の幅が足りてない、少なくとも「学びほぐし」の力は磨いておく必要がある
    • まして、「自分で何かを欲した時に学ぶ・深めることが出来ない」「学ぶべき課題を自ら発見できない」というのは、不確実性の最たるものではないのか。逆に、それができれば生き続ける事が、それまでと違う次元で可能になりそうな気配がする
      • 考えてみたら今の「職業プログラマ」だって、よくわからないままに「自分でコードをコピペしてみて、少し変数の内容を変えてみる」ところから始まっている。その結果として”あり得ない飛躍”が起こって、広告とかインターネットに少し興味あるようなそこら辺の社会学の学生が、「エンジニア職のキャリア」という世界線に突入できたんじゃないのか
      • 今や「コード書けて当たり前」すぎて意識しなくなっていたけど、確かに当時は「やり方がわからない」「出来ないからやらない」なんて全く思わなかったし、「これを真似したら動くの?」という素材集めと真似事みたいなものから始めていたし、むしろ「真似事をする」のが自分の世界観だった

ということで、これまでは

  • 自分の得意領域・強みを強化する形で、深めたい
  • そのために「師匠」といえるような人がいて、自分の取り組むべきコア以外についてはサポートしてくれるマネージャーや組織環境がある

ことを欲していた。これが、

  • 自分の好きなこと・得意なことは、腹くくって自分で勉強していかないと、打ち止めになる
  • 「成長する・できる」について、もっと総合的にとらえる(「仕事」がインプットやトレーニングの全てではない
    • 「会社を使って伸ばす部分」と「自分自身で伸ばす部分」を区別して考える
  • 会社には、いかの要素もしくはそのいずれかを求める
    1. 技術的な幅を広げる: 自分だけでは学習の手が動きにくそうな部分を会社を使ってやる。コンフォートゾーンを抜ける。
      1. インフラとか
      2. PHP以外とか(GoとかJS/TSとか!
      3. フロントエンドとか
    2. 職業的な経験を広げる: 独学しにくい部分、たとえば「集団や組織にまつわる」部分
      1. コミュニケーションやリーダーシップやマネジメントの経験
      2. 「環境に依存するのはリスク」と考えて、「自らが環境や他者に働きかけて”変えていく”側になる

(ここで時間が現在に戻ります!!)

2021年時点の考え、みたいなのも書いておきたいな〜〜〜キャリア的には割と大きい1年だった気がする!

やったこと・書いたもの{2021,07}

OSS

github.com

勉強会・LT

その他

突然(w)Podcastにお誘いを受けて、お喋りしてきました。
以前にもTwitterなどで相互に認識をしてた人にカンファレンスで「お話しましょう!」とメンションを貰って喋ったり、今回もイベントやらカンファレンスで見かける中でTwitter上でたまにリプライをもらったり〜からの招待だった*1ので、不思議なもんだなぁとかとても有り難いことだなぁって感じる。

anchor.fm

*1:共通の知り合いがいるのも大きかった気はするけど

エンジニアのためのマネジメントキャリアパスを読んだ

あまり丁寧な読書メモは作っていないのだけど。
前に、現職で人事的なアレがあった(打診された)タイミングでササッと掻い摘んで読んだ事はあったものの、確か全体は読んでおらず。最近、TLにてフォロイーの人が言及していたのを見かけたので、「そういえば」と思って手にとった次第。

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

全体的な感想

これは、その時その時にあわせて必要なところを何度も読む感じの付き合い方になる1冊かな〜という印象。もしくは、同じ記述を読んでも感じることや理解の仕方がどんどん変わりそうだ。
各章の「凄い上司、ひどい上司」の節は面白いな〜。定期的に、この節だけでも横串でパラパラと見てみるのも良いかも知れない。具体的な記述であり(=身につまされる思いになる・・・)、内容のリマインドとして効果的に使えそうに感じる。

続きを読む

やったこと・書いたもの{2021,05}

OSS

github.com

大変に時間がかかってしまった・・・・・・・Issueとかでコメント貰っていたし、マイルストーンも〆付きで設定したもののそこから詰めの作業が遅延してしまい、心苦しい。 1月くらいからCakePHP4+PHP8を業務で利用する流れを作った関係で、「自分自身が欲しくなった」という動機でソイヤソイヤと書いた次第。
元々「PHP8対応をやろう」って考えてて色々と煮詰まってしまい(そこで1回折れた)、「まず新SDK対応をやろう」「PHP8対応はその後にやろう、コレ自身は恐らく軽い」と方向転換をした事でコーディング作業自体はかなり進捗が上がった。
(実際、SentryのSDKが「設計レベルで大きな変更をしている」というメジャーバージョンアップを挟まないと最新版 = PHP8対応バージョンまで上げられない・・・しかしそのキャッチアップが割と大変そうだぞ、というのが作業序盤で自分の腰を重くしていた)

あと、「定期的にOSSをメンテしよう」という集まりが実施されたことも励みになりました。ありがとうございます

勉強会・LT

PHPerKaigi

その他

GWを振り返る

今年は「もう何もしなくてもOKよ!!」みたいなお墨付きをもらったような心地にて、まぁ何にせよ何もしないんですけど、ともあれずっと本を読みたい気分だったので「この連休は本を読むぞ〜!」をしていました。

↓1年前 daisuki.nichiyoubi.land

読書楽しいし積ん読が多い

「自身の技術力の伸長や成長実感みたいなものを、働き先の内容や環境に求めて良いのか?」というのを見直してみよう〜と思って動いたここ1年であり、何をしたかといえば「自分で頑張るぞ!」というのを基調にせねばならぬっていう思考の転換なのですが*1、実際として「ちゃんとインプットする、手を動かす、何が足りないのかを考える」ってやろうとしている・・のは充足感に与しているのでないか?という印象。

少しずつ(前・・・というか社会人になってから?プログラミングを始めてから?と比べて)本を読む量は増やせてきていると思うし、買う量はメチャクチャ増えた。
またどっかで壁にはぶち当たるのだろうけど、とりあえず現状で言うと「色々な事を自分で選んで知ったりするの楽しい〜〜〜」っていうモードなので、良し良しって感じ。

  • 読書楽しいし積ん読が多い
  • 本を読んだ
    • 全体的な所感
    • 読んだ本の記録↓
      • 4.29 LEADER's KPT
      • 5.1 会議のマネジメント
      • 5.1 ユニコーン企業のひみつ
      • 5.1 それがぼくには楽しかったから
      • 5.2 スクラム実践者が知るべき97のこと
      • 5.3 実装パターン
      • 5.3 Goならわかるシステムプログラミング
      • 5.4 PHPはどのように動くのか ~PHPコアから読み解く仕組みと定石
      • 5.4 NVC 人と人との関係にいのちを吹き込む法
      • 5.4 新版 コーチングの基本 この1冊ですべてわかる
      • 5.5 問いのデザイン
      • 5.5 ダイアローグ・マネジメント 対話が生み出す強い組織
    • 買った本

本を読んだ

てな感じで、たくさん積んである本の山を少し切り崩すべくして読書した!!

「数を読む」みたいな方に寄っちゃっていたかもなって反省は少しありつつ、まぁそうだとしても「ちゃんと冊数読む」が出来たのでよいかー。何かを失う訳でもなし!

良かったこととしては、なんとなく「本を読む感覚」を取り戻せたかもな?って気がする。
フロー状態とまでは言わずとも、なんか「夢中になって貪って読書をする!」みたいな境地は久々に味わえたような。あと、細部に拘りすぎないでテンポ良くよむ〜とか、没入感をもって読書そのものを楽しく目的化する〜とか。
本によっては少し「雑に読む」に振って、多読してみよう〜ってなれたおかげかな。

全体的な所感

  • 本を読む→買う本が増える
  • なんとな〜く技術書が少ないなー。あと重い本が少ない感じ。「数」に意識が寄ってるかな?
  • 内訳:
    • 組織、PJ、アジャイル: 3
    • 技術、開発: 3
    • ファシリテーション、対話、コミュニケーション: 5
    • ノンフィクション、文芸: 1
    • 元々読みかけていた本が1,新しく手を付けた本が11
  • せっかく「本を読む感覚」みたいなのを掴んだ気がするから、引き続き色々と読んでいきたいねぇ

読んだ本の記録↓

*1:そもそも、その辺りの話をまとめておきたいな〜・・・・って思いながら年末も年度末も、そしてこの連休も逃しちゃっているな!

続きを読む

然るべきをエンパワメントする

「せっかく優秀な人がいても、プロダクトコードや運用は必ずしもそのような姿にならない」ていうのありがちだよな〜って思っている面があり。
あの人がいながら、なんでこんなプルリクがはびこっているんだ!!みたいな。
「どうして突出した個人の力と組織の力は大きく乖離するのかい?」みたいなのは、自分の中で「現実」として受け入れられるようになりつつも、ガッカリ感とかモヤモヤ感があった。
逆に言えば、「自分が何かやれるなら、その沼のような谷のようなのを飛び越えられるような力学を手に入れたい!」というのに関心がある。・・・憧れ、といった方が正しいかも。

んで「ユニコーン企業のひみつ」を読んだのだが、(前提としてハイパワー人材を取り揃えてるよねってのはありつつ)そこに描かれているのは非常にイキイキとした組織像だった。
何度も強調されているのは「必要なのは、チーム(=現場、みたいなものだと思う)に権限と信頼を与える」というもの。

権限ってなんだろうね〜〜?
「会議に出ている」とか、「これからは◎◎をします!という宣言を出し、従わせることができる」とか?形あるものとしての権限ってなんだろうか。

例えば「草の根活動として自発的に勉強会をやる」場合、参加者の募集や日程の調整などの巻き込みは要るが、別に「組織や上長の承認を得て、下達な指示を出す」ことによって成立させるものではない気がする。
なので「権限がなくとも影響力を持つ」ことはできる、という気がする。

そうなると「公式なリソースに対して、動かす・変更するなどの影響を及ぼす」みたいなものが権限になるのかな?
「公式なリソース」と「非公式なリソース」というものがありそう。
草の根活動では「非公式な範囲で動かす」で通る。

「上長承認」を伴って行動を行う場合、それは「権限の代行・委譲」を受けて実行している、みたいなことか。authorityによるauthorize。
なので、その人自身の属性としての権限を与えなくても、行為への許可として一時的・局所的な権限を「お墨付き」によって分け与えているような形かも。

権限とは影響力の行使もしくは獲得なのだとすれば、「君が言うならやってみなよ」と上司に言わしめたり「あなたが言うなら乗ってみたいです」というような「信頼」の蓄積が大事な気がする。
「目に見える影響力」としての権限、「目に見えない影響力」としての信頼かな?
もちろん、両者が一致しているのが望ましいし、信頼ができてかつ影響力を発揮しようという人を上に引き上げるのが組織デザインだと思う。

と考えると、「信頼して権限を与える」というのは、本来であれば信頼や説得を担保に行われるはずの「上から下への権限の貸し出し」について、先に投資を行うようなものではある。でも、「形式と実態ないしポテンシャル」を非常に自然でシームレスにつなげるようなやり方だな〜と思った。

形式としての実態と、ポテンシャルとしての実態は一致しているのが良い。
これは、冒頭の「優秀な人がいるけどプロダクトコードが稚拙」問題と良く似た構造かも?

なるほど、「なんで突出した個人の力と組織の力は大きく乖離するのかい?」に対して「然るべきをエンパワメントする」のが有効なアプローチなのかな。

「誰をエンパワメントするか」「どこを引き伸ばすか」というのは、組織の意思決定なので、要するにビジョンに従って行われるものになる。
周りからの信頼(これがシーズとなり)、全体からの要望(これがニーズとなり)に応じて「見えない影響力」を発揮させ、さぁいよいよ発現させるぞ!!というのには、どうしても時間がかかる。彼本人の啓蒙によってビジョンを押し動かしていく必要がある。
その点、「行動を指し示す」のに際して「上の人」が合理的な影響力を利用するのはシンプルで、わかりやすく早い。

トップダウンな「お墨付き」でボトムアップなポテンシャルを「引き出す」というところで、良い方向へと進むように背中を押すことが出来るのかも。 君なら必ずみんなを良い方向に導いてくれるよねという信頼に基づき、もしくは「我々としては良い方向はアッチだと思っているのだけど、君なら良く理解して共感してくれるはずだよね」という信頼でも可能だけど、それをもって「あの人は凄いよ」という非合理的な影響力のある所に権限を与え、合理的な影響力へとアップキャストする。

どうしたら組織が動き始めるか。然るべきをエンパワメントする。
そうやって「あるべき姿」「そこに向かうための推進力」「現実」の三者が徐々に一致していき、イキイキとした組織が育まれる・・・ような気がする。
(もちろん、リーダーはビジョンやミッションを語り続けることは大前提として必要)