忖度を促すマネジメント(?)

自戒を込めて。
この壁を超えた先に、何かが見えるかもしれない。
超えるための何かを見つけるために書き留める。


「悪意なく」行われている気がする。
マネジメント2.0の世界観に近い?
上司と部下の関係性
オレンジとグリーンの壁なのかな。
マネージャーとマネジメント難しい。わからない。

部下に忖度を促すマネジメント(?)

えらい人「マグロおいしそう」
部下「わかりました。マグロですね!」
部下「おい、部下の部下。マグロ料理を用意するんだ」
部下の部下「わかりました。買ってきます」

スーパーにマグロが売っていない!!

部下の部下「マグロが売っていません」
部下「スーパーになければ、釣ってこい。なんとしてでも手に入れるんだ!」

部下の部下は遠洋漁業でマグロを釣りに行く。疲弊する。
部下の部下「ぜーはーぜーはー。マグロ連れました....」
部下「マグロの準備ができました!」

えらい人「やっぱり今日は牛肉の気分」
または
えらい人「たかがマグロごときに金と時間かけ過ぎなんだよ」

(お前が言ったんじゃないか!!!)

特徴

  • 意思決定を委譲せずに、実行責任だけを求める。
    • 情報を(無意識的に)隠蔽し、意思決定プロセスを手放さない
    • 具体的な指示をせず、丸投げ。情報を共有しないため、前提や制約、優先順が伝わらない
    • 優先順の意思決定や判断に必要な情報を委譲しないため、部下は「お伺いをたてる」
    • 時には過剰な個別最適化が進む
    • 「お伺い」に対して、判断を明確に示さずに「AとBのどちらですか?」に足して「C''がいいかもしれない」と、別の話をもし出しつつ、責任を持たずに相手に渡したまま、意思決定を行う。部下「あー、じゃあ、それでいいっす」
  • 成功を自らの評価とし、失敗を他社の評価とする。
    • YESマンを評価し、NOをいう相手は敵とみなす。
  • マネージャーとメンバーの関係は、「顧客とベンダー」である。受発注の関係に近い
    • メンバーはマネージャーが発注した「要件()」を忖度し「納品」する
  • マイクロマネジメントなんて時代遅れなことはしないよ!「部下に信じて任せてます(`・ω・´)キリッ」
    • 放置プレイと納期プレッシャー
  • 何気なく言った一言がメテオフォールを生み出す。「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない。」
    • 説明のための説明資料

部下の行動

部下の行動。忖度の兆候かも?

  • 部下は「承認」や「お伺い」と言葉にする
  • 「(ダメだと思っていても)言われた通りにやる」
  • 「○○さんに聞いてみないとわからない」
  • 都度確認・議論するのは、面倒だし「言っても無駄」で疲弊するだけだから従う
  • 「さすが○○さん!ご慧眼ですね!」
  • 上司「質問ありますか?」部下「しーん」
  • アナーキストは、黙ってやる。下剋上

上司のお言葉

「よきにはからえ」「うまいことやって」
「(上司の)変化に(部下が)適応が大切」
「説明責任!プロフェッショナル!KPI!」
「経営者目線をもつように」
「自己組織化してください」
「俺にわかるように話せ」
「プロセスは言い訳だ。結果がすべてだ」
「いい提案したら検討してあげよう」
「俺はそんなこと言ってないけど?」
「そうじゃない。なんでわからないかなあ?」

これもそうかも?負の無限ループ

「上司や先輩に言われて嫌だった言葉ベスト3のコーナー!」

(中略)

「第一位 『わからないことがあったら聞いてって言ったよね?』
     『チッ、それくらい自分で考えてほしかったんだけどなぁ……』
     『ねぇ、なんで俺に聞かないで勝手にやっちゃうの?』 の無限ループ」
 刹那、その三つの言葉が俺の頭の中で、ウロボロスよろしくぐるぐる回った。
「どう行動しても詰んでるじゃねぇかそれ……、なに、この世界のバグなの?」
「逃れようのない究極三段活用! これが天地魔闘の構えか……」
 材木座がごくりと喉をならして汗をぬぐう。この隙のない三段構えを食らえば新入社員の半分は脱落するだろう。

やはり俺の青春ラブコメはまちがっている。

対処方法

アジアのフォース?組織の重力?

アジア人は私たちの住む宇宙が体系的に動作するためにはすべてが階層化されているべきだと信じている。陰と陽がある。カースト制がある。若者は年上をうやまうべきだし、部下は上司に伺いをたてるべきだ。なぜなら上司がすべての答えを知っていると多くの人たちが信じているからだ。王が絶対的な権力をもついくつかのアジアの国々では、王がすべてについて最終的な答えをもっているべきなのだ。

西洋人が平等を信望する一方で、おおくのアジア人は、自身の位置と、どう振る舞うべきかの習慣とルールを把握している階層の中にいると安心する。みんなが自己組織的な行動で機能横断的に協調して働く自由な組織を持つことは、システムから外れたようにみえるため、不合理であるとみなされる。

qiita.com


組織重力の3つの法則
第1法則:組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける。
第2法則:組織における個人は、自分のチームやサイロの心地のよさのなかでいちばん簡単に完了できる作業を優先する。
第3法則:進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない。

kobase16.hatenablog.com

はげちゃびんになっていないか?

古い知識と成功体験にとらわれたままのエンジニアは「はげちゃびん」になってしまう可能性があるのでは?
中途半端に知識があると危険

抜け出す鍵?

情報共有と意思決定の委譲。
役割とオーナーシップの醸成。

まずはここからかなあ?

組織重力の第3法則「進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない」にそれな!と思った #みんアジャ

これは本当にそれな!と思いました。
「あー、これ!これだよ、これ!」

これは「みんなでアジャイル」に書かれている「組織重力の3つの法則」のひとつ。

組織重力の3つの法則
第1法則:組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける。
第2法則:組織における個人は、自分のチームやサイロの心地のよさのなかでいちばん簡単に完了できる作業を優先する
第3法則:進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた

  • 作者:Matt LeMay
  • 発売日: 2020/03/19
  • メディア: 単行本(ソフトカバー)

本の紹介や感想ではなく、読みながら考えたことを書き留めておく。
書いてる時点では、読んでる途中。

本書の中心は「変化に対応できる顧客中心組織の作り方」に関する原則がメインテーマではあるが、関連する「組織重力」に着目して本記事を書く。
私が書く内容は、ネガティブワードが多めだと思うが、あくまで本書の一部です。

「みんなでアジャイル

原著は「Agile for Everybody」
タイトルを読んで内容を想像できなかった。
Amazonで予約購入したけど発売日に発送されなくて、
ようやく届いたあとに、本棚に入れる前にぱらぱらめくった。

「訳者あとがき」を最初に読み、次に「まえがき」を読んで、惹かれた。

組織重力の3つの法則

「組織重力」というネガティブ面の切り口で書かれている「アジャイル本」は初めて出会ったかもしれない。
出会ったタイミングの問題はありそう。

私は、この手の謎のマイナスパワーをバイアス、力学、フローなどの言葉にしていたが、あまりしっくりきていなかった。
「重力」は、しっくりくる表現。

この「重力」を無視した設計をすると、何かが歪んでくる。
重力の下で「どういう働きかけをすると、良い結果に向かえるのか?」
それを考えていきたい。ファシリテーションや関係性構築なのかな?

おそらく、3つの法則は関連している。
まずは、第1法則を認識して、重力との整合性を保つ文化。
次に、第2法則の重力乗って加速させる文化。
最後に、第3法則の重力下で変化と適応を行う仕組みと文化。
繋がっていて、関連しているんじゃないかな。

第1法則:組織に属する個人は、日々の責任やインセンティブと整合性がなければ、顧客と向き合う仕事を避ける。

「顧客価値」「早く失敗」「変化に適応」と言い、ビジョンやミッションを掲げる企業は多いけど、
現場担当者の日々のお仕事や評価・報酬の仕組みと「整合性がない」という組織は少なくないと思う。
大切だとは思っているけど、優先順低いよね?
意見を押し通りたり、評価時期になって急に思い出したように、それっぽいこと言い出す。
その重力下で、えらい人が「顧客第一でない」と憤る。

それはそうじゃん?

納期がー。
工数がー。
「顧客第一で僕の給料はあがるんですか?」

顧客対応は、カスタマーサポートのバイトがなんとかしてる
ソフトウェアエンジニアは顧客が使っている姿を知らないし、なんなら「自分で使ったこともない」

この重力には抗えなくて、「整合性」を保つことが大切。

私が「アジャイルどうこういう前に、評価を変えないとどうしようもない」と、ときどき感じていたのは、この重力だったのかもしれない。

悪い方向に進んでいる兆候

顧客との直接的なやりとりが見下されていたり、外部委託されている
新しいプロダクトやサービスのアイデアに「革新的」「破壊的」といった枕詞がついている
組織内に顧客からの良いフィードバックしかない
アジャイルの旅の進ちょくを適応状況や速度などの運用指標のみで計測している

第2法則:組織における個人は、自分のチームやサイロの心地のよさのなかでいちばん簡単に完了できる作業を優先する。

つながりやコラボレーションしやすい輪の中で、仕事をしようとする。
話しやすい人とだけ話す

他チームとの打ち合わせの調整がー。
マネージャーが捕まらないー。
承認がー。

チームやサイロ、極端な場合は、個人に閉じた中で簡単に完了できる作業を優先する。
各部署と調整して全体最適化をしたほうが良いとはわかっているけど、いろいろ面倒だから局所最適化が進む。

また、これコンウェイの法則と繋がるんだ。
この重力があるから、組織のコミュニケーション構造を模したシステム構造が自然に生まれる

これは、当たり前で、自然なんだと思う。

だからこそ、
全員同席や機能横断スモールチームというアプローチをとって、
「自分のチームやサイロの心地のよさのなかでいちばん簡単に完了できる作業」ができるようにする。
この重力をうまく利用して、促進させる。重力に乗って加速させる。

また、本書の中では「報告と批評の文化」について言及がある。
この状態では、「完成してから共有しよう」になるだろうし、チーム同士の利益相反が起きて、チームを超えて協力するメリットがなくなる。

私自身「報告と批評の文化」が染み付いている。
なかなか抜け出せないと感じるのだけど、

整合性と保った上で、対話と関係性をどう促進するか?
ここは、ファシリテーションアジャイルラクティスが効きやすい部分かもしれない。

悪い方向に進んでいる兆候

会議が小学校の読書感想文の発表のようだ
完成して洗練も終わっているものがチーム間で共有される
インボックスが非同期のフィードバックの依頼で一杯だ

第3法則:進行中のプロジェクトは、それを承認したいちばん上の人が止めない限り、止まることはない。

3つ目。
これだよこれ!

「えらい人が言ってるんだから~」と不評買いたくない。忖度する。
「これ作って意味があるの?」と思いながらも作り続ける。「なんで俺の言ったことをやらないんだ」「いいからやれ」って言われるし。
「意味がないと思うんですけど」とか言えない。きっと私にはわからない「最上位者の知ってる何かがあるんだろう」
「ルールで決まってるから」
増え続けるチェックリスト。

不確実性が高く予測できないとは言っているけど、一番近くで実感しているはずの現場担当者の判断で、やめられない。
やめるには相当な労力を伴う。

「オンスケです!」「大丈夫です!」「素晴らしいお考えです!」
えらい人にそういうことは自然な流れ。

えらい人に「ご意向を伺わなければ!」→えらい人が数日後に「え?俺はそんなこと言ってない」「変化が大事なんだ」とひっくり返す
メテオフォール!


個人的には「ルールは、作った人かそれより上位者しか、変えられない・止められない」から作らないほうがマシと感じる。
最近の私は「変化し続けるプロセス」を作るプロセスを設計することが大切だと感じている、

最上位者がそれを自覚して、組織に促し、そのタイミングを設計どう設計するか?
どうやって巻き込むか?
本を読んでいる途中だけど、策はあまり腹落ちできていない。
でも、重力を意識して、行動につなげたい。

悪い方向に進んでいる兆候

あなたの組織では、決定を下す際に100%の確実性を要求する
次年度の年間計画会議や予算会議まで重要な情報を保留し続ける
アジャイルなので」その仕事の仕方をしている。それだけだ

「重力」と向き合いたい

本書では「組織重力の3つの法則」が紹介されているわけだが、私が生きている世界では、他にも「重力」は存在すると思う。
組織、集団、人間関係。その中でいろいろな重力はあると思う。
重力の存在を無視して、「そんな組織はクソ」だよと言ってしまうことは簡単で、
正論や理想論から、否定することは容易いんだろうけど、私は向き合いたい。
こういうマイナス面と向き合って、私はなんとかしたい。

重力に抗える勇気や行動力のある人はすごいし、
プラスをプラスにするのは、もっと得意な人がいるので、お任せする。

それは私に向いてないし、
私は人を幸せにすることはできないと思うけれど、「不幸をなくす」をしたい。
コミュニケーションだとか、重力に潰されている人とかをなんとかしたい。

そのためにも「重力」に向き合いたい

その他

組織重力以外にも、印象に残る内容はあった。

アジャイルは手法か?マインドセットか?それともムーブメントか?
フレームワークの罠

メンバーは選んだ手法の「エキスパート」になっていました。やり方はまったく以前と変わっていませんが、呼び名だけが変わっていました。

・ページによって、言葉が違ったのも興味深い。原文の英語が違うのかな?
組織重力の部分だけでも、英語で読んでみたい。

組織重力の3つの法則
・組織の個人は、日々の責任ややる気を伴わない場合、顧客対応を避ける
・組織の個人は、自分のチームのサイロの居心地のよさのなかでいちばん簡単に完了できる仕事を優先する
・進行中のプロジェクトは、プロジェクトを承認した最上位者の決定がない限りは続く

・6章以降は未読。読もう。

「割り込みが多くて困ってるんですけど、どうすればいいですか?」「やらなければいいと思うよ」

「割り込みが多くて困ってるんですけど、どうすればいいですか?」
「やらなければいいと思うよ」

と書きかけて、放置していた。せっかくだから書きかけのまま投稿する

あるある?

メールとチャットと打ち合わせをして
困っている人の相談を受けていたら、一日が終わっていた。
予定していたタスクは何ひとつ完了していないのに。
本来やるべきことに時間が取れない。
そして残業でカバー。

「あれ?私はこんなことしてていいのかな?」でもお客様や仲間が困ってるし、お仕事しなきゃ助けなきゃ
嫌な顔せず、いろんな人の話を聞いて手伝っていたら、さらに仕事が増えた
定時間際にお仕事を頼まれる「今日中にお願い!」

次々と新しいことが増えると、新しいものから対応するスタック型に陥る。
すると、タスクの抜け漏れが発生し、後回しにされ対応されないタスクが現れる「え?すぐ終わるのに、まだやってないの?」
対応をしても旬を逃している「え?なんでそんなことやってるの?そんなのもういらないよ?」
「割り込み片付いた終わったー。さっきまで何やってたっけ?」思い出して集中し始めたところに、通知が飛んでくる。

やるべきタスクが進まない。
仕方がないから、休日に誰もいないオフィスに出勤する。
すると、休日はなぜか仕事が捗る。2〜3日分の仕事が一気に片付いた。

どうしよ?

「これって、アジャイルで解決できますか?」
できるんじゃない?知らんけど。
できないんじゃない?知らんけど。

  • 割り込みの見える化
    • 可能であれば、物理カンバンが他の人にわかりやすいのだが、メールやSlackの依頼だと紐付けしにくいことがある。その場合は、Trelloのような電子かな?
    • 見える化することで、定性的定量的な側面が見えて、次の手を打てるようになる。最初から完璧は目指さない。少つずつ見えてくる
    • 「こういうのやって」「わかりました。今これだけやりたいことあるんですけど、どこに入れます?」と、できるといい感じ
  • 課題の共有(シェア)
    • シェアできている範囲でしか、最適化は難しい。
      • 権力で強制することはできるけど
    • 個人の課題ではなく、チームの課題
    • チームの成果として、何をいつまでにやるか?優先順をどうするか?
    • そういう意識で、仕事を進める。忙しい人がいるなら、みんなで助ける
    • みんなの仕事
  • ステークホルダとの共有
    • チーム
    • 上司
    • 他チーム
    • 特にスポンサーに対して「このお金に何に使います?」を合意できてると良いかなー
      • いろんな方向からくると、優先順も決められないから、一箇所にまとめてステークホルダ同士に自然と伝わるようにする
        • 「どちらの部署の案件から優先しましょうか?」をステークホルダどうして決めてもらうといい感じ
  • 量が多い
    • 単純にキャパシティーオーバーである
    • この状態は、予算確保者と認識があっていない可能性が高い
    • 人員増加や取捨選択を行うべき
    • 残業前提の計画になっていないか?
    • 依頼者に、私たちのチームのタスクキューは見えていますか?
    • 「タスクキューに優先順にところに入れてください」
    • 割込バジェットを設定する
  • 煩雑なタスク、人手が多い、繰り返しが多い
    • VSMでリードタイムのボトルネックを可視化
    • 人間が頑張らないようにする
    • そもそもなくす
    • 自動化、セルフサービス化
      • そのための時間が取れない
  • 対応者が偏る
    • 動機がない(メリットが少なく、デメリットが多い)
    • 特定の誰かにしかできない、知らない
    • 日直のような当番制
      • 当番制にすることで、負荷を分散する
    • リバースプロキシ
      • 有識者や特定の誰かしか知らない場合、引継先にしたい人をリバースプロキシにする。
        • その過程で、知識や意識決定プロセスの委譲を行うことができる。また、「特定の誰か」は、仕事が集中しやすい人であることが多いが、多方向から依頼があると、それを管理するだけで時間が取られてしまうため、プロキシ役からのみアクセス可能にすることで負担を軽減する。
    • チームの外からは「誰に依頼すらばいいのかわからないから、知り合いに聞くか、全員に聞くか」になる。
      • 窓口が決まっていると対応がしやすい。
      • チーム内であれば、「誰なら詳しいか、誰にアサインすると良いか」を判断しやすい。
  • 時間が取れない
    • 毎週何曜日の何時〜何時は、「◯◯のための時間」と決める、リズムを作る
    • チームやスポンサーと合意できると「その時間帯は話しかけないで」とできる。チームに守ってもらうことができる。
  • いい人問題。いい人は評価されにくい。 

www.slideshare.net

  • スイッチングコスト
    • フローとフロー
  • その割り込みは、本当にやる必要はありますか?
    • ほうっておいても、実は大丈夫なのでは?
    • やらなくても、意外となんとかなったりする
    • 形骸化しているだけで、うっかり忘れても誰も困らないのでは?
    • 伝統的にやっていることは、現時点で冷静に考えて見て、費用対効果は十分か?
  • 100点を取ろうとすると、工数は無限に増える。
    • どれくらい失敗を許容できるか?その設計が必要
    • 40点や60点では、何が問題になる?
    • 頑張って100点とったら、それは再現可能な期待値だと認識される。「次は120点とって!」
      • 上がり続けるハードル
  • 「割り込みが多い」からは、具体的に何が困っているの?
    • 早く帰れない?精神にくる?お金がもらえない?生産性が増える?スイッチングコスト?もともと予定していたことができない?家族との時間が取れない?評価が下がる?
    • 組織として、チームをそれをどう考えている?
    • 自分がババを引かないように表面上にこにこしながら、机の下で足を蹴り合って押し付けあってたりしない?

正論

これらは、きっと正論
直面している問題とは、何かが乖離しているでしょう?
ここに書かれたひとつの解決策で解決するなら、悩んでいない
複合的で複雑な問題をシンプルに捉えようとすると、矛盾が生じる

正論では解決できそうにない、違うものがあるだろう
うまくできない、と思うならその差分は何か?そこに制約や目的が隠れていることがある

but...短期的な力技で解決する(疲弊、燃え尽きリスクをとる)ことを除けば、

  1. タスクを小さくして、優先順を決めて順番にやる
  2. 個人の課題ではなく、チームや組織の課題としてシェアする
  3. がんばらない

にするしかなさそうかなー

優先順を決めるにしても、個人で判断するには限界がある
スポンサーに「予算配分どうします?何を優先します?」
シェアして「みんなで雪かきしようよ」
に持って行かない限り、誰かに負担が集中して苦しむだけになりそう

あと、全部はやれないから、やれることだけやる
「できるから、やる」
「できないから、やらない」
そうではなくて「できるけどやらない」
疲弊してしまわないように、本当にやりたいこと・やるべきことを効果的にできるように。

細野さんの公演を見ながら勝手にシンパシーを感じていたのが、決して無理しないRSGTのモットーみたいなもの。近年のRSGTにおきましては会場のキャパも座席数も需要に追いついてない感じで、チケットが取れない方には大変心苦しい限りですが、見えない誰かに無理無茶を押し付けてしまわないことが、ウォーターフォールに比べてのアジャイルの決意みたいなものだと思うんです。スタッフの皆さんにおかれましては、すぐにアンドンのコードを引いて欲しいと思っています。担当者がギブアップするまで続けるチキンレースはやりたくない


「できないかもしれないけどやる」が若きベンチャースピリット、「できることをやる」が伝統的なエスタブリッシュメントのスピリットだとすると、「できるけどやらない」がアジャイルのスピリットなのかな、って改めて思いました。

kawaguti.hateblo.jp

2018年くらいのあとで見たいスライド

書きかけの記事の掘り起こし。

AdventCalendar

adventar.org

adventar.org

adventar.org

スライド・記事

www.slideshare.net

www.slideshare.net

https://codeiq.jp/magazine/2016/05/41303/

fullswing.dena.com

kuranuki.sonicgarden.jp

speakerdeck.com

kyon-mm.hatenablog.com

cybozushiki.cybozu.co.jp

www.ryuzee.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

デブサミ

speakerdeck.com

speakerdeck.com

www.slideshare.net

speakerdeck.com

speakerdeck.com

また読む

qiita.com

www.slideshare.net

speakerdeck.com

デブサミ

speakerdeck.com

www.slideshare.net

speakerdeck.com

cybozushiki.cybozu.co.jp

speakerdeck.com

speakerdeck.com

www.slideshare.net

speakerdeck.com

https://speakerdeck.com/kawaguti/enterpriseagile-to-agileenterprise

PO祭り

www.slideshare.net

d.hatena.ne.jp

speakerdeck.com

「最高の仲間と最高の仕事を全力でして、最高に楽しかったー!」ってのをやってみたい

そういえば、やったことがない。

青春の忘れ物がある私の迷子の軌跡。
「あの頃の私たちはアジャイルだった」そんな青春を送りたい。
今のもやもやを書き留めておく。

こんなチームに憧れる。

tomomo1015.hatenablog.com

私も自分探しの旅に出たい。
変わりたいな。

ただただ同じ日の繰り返し。緩やかに劣化する日常。
「明日も今日と同じ日が待っているのかな?」
じたばた
私は、あと数年で体力的な限界が訪れるだろう。
それまでに一度だけでいいから、持っている能力を全力で賭して、できることをやってみたい。最高のチームと一緒に。

私がやりたいこと?

10年以上、ソフトウェアのデベロッパーをやっている。
これからもそれを軸にすることは変わらないとは思う。

自分がやりたいことをできてない感は強くある
「じゃあ、何をやりたいの?何がやれるの?」と言われると言葉に詰まる。
イメージはあるけど、地に足がついていない。ビジネスや顧客に近いところで働いてみたいとは思う。

「ぼくのかんがえたさいきょうのソフトウェアを作りたい?」
うーん、何か違うなー。しっくりこない。

ポジション、役割、ロール

「一人で道を極める?チームで協力して達成する?」
どちらでもなく、その狭間かなー。
私は何かを生み出すことは得意でないから、誰かが生み出したものをちょっと良くする手伝いしかできない。
チームの一員でいながら、一人で極めたいの気持ちも持っている。

チーム外側と内側のちょうど間にいるくらいがやりやすい。
ポジション(担当や守備範囲)が決まっていると、私はその範囲内でしか動けなくなるから、決まっていないほうがやりやすい。
「遊撃」が言葉としてはしっくりくる。定位置がない方が動きやすい。
隙間を埋めたり、落ちたものを拾うことは得意。

「リーダー」は向いていない。ビジョンとカリスマが圧倒的に足りない。
副リーダー、影のリーダー、スーパーサブ、シックスマン、セカンドボーラー。一番ではなく二番。
ビジョンを描いて、人を導くのは向いてない。
私は、本質的に他人に興味はないけど、承認欲求を満たすために他人は必要。

みんなで一緒に目的地に向かうとしたら、
・一番先頭で地図を見ながら歩く
・一番後ろで全体を俯瞰しながら、抜け落ちたものを拾う
私に合うのはどちらか。列の途中にいられない。
前者が好き、最高に楽しい。後者は得意、こぼれたものは全部拾ろう。

どちらかを選ぶのではなく、本心としてはどちらもやりたい

得意なこと:違和感を捉えるセンサー

違和感やリスクを捉えて「大丈夫ですか?」を永遠に考え続ける人、問い続ける人。それが私。
対処するのが得意ではない。不確実なものを「決められない」。あるべき姿がわかれば近づけることはできる。
壊れたものを治すことは好き。トラブル対応は燃える。
意思決定の選択肢を増やして、保ち続けるは、できそうだけど、どれにするかを選べない。「確実な選択肢」しか選べない。
意思決定を究極的に遅延させた結果、何も選ばない、が私。
ここが私一人ではうまくできない部分で「選べる人」が必要。
ポジティブ、行動力、決断力、そういうものを持っている人と組むと、成果や価値に結びつけやすい。

それができる誰かと一緒に組むことが理想。よりうまく行くように、失敗しないように、磨き上げることは得意だと思う。
ただ、そういう人とは、性格が真逆だから、真っ向から価値観を否定する感じになっちゃうから、人間関係で詰みやすい。ってか詰んでる。

野中先生の言うような「共創」的なことをしたいんだけど、合う相手が見つからない感じ。

私が誰かに合わせられないのはある。
自己中でナルシスト。

極端には「すべてを否定しても、受け入れられる環境と相手がほしい」と思ってる。何贅沢なわがまま言ってんのお前

やりたいこと:壊れたくないものを作りたい

私はソフトウェアのデベロッパーとして、10年以上お仕事してきた。
私は、デベロッパーとしては異端だったようで、アーキテクトにもマネージャにも慣れないと言われてきた。

心の欲求的は「どうやっても壊せないぼくの考えた最強のソフトウェアを芸術家(アーティスト)」が近いかも。
作るのではなくて壊したくて、デザインではなくアート
それが、ソフトウェアデベロッパーとしては、致命的に矛盾する感覚がある。そこから抜けられない。

「壊せない」が創出やデザイン、アーキテクティング・モデリングと矛盾しているように感じる。勉強不足。
単に無能なだけかも。才能がない?知識が足りない?

正解がある問題をゲーム感覚で解くことは好き。正解がないものを求めることは苦手。
壊れたものをあるべき形に戻すことは好き。
トラブルシューティングデバッグは燃える。
原因を見つけることと治すこと、前者は好きで、後者は得意。故障の原因を探すのは、ゲームみたいで楽しい。

私の中で「あるべき姿を描けるか?」はとても大切な気がしている。「あるべき」からの逆算で、どうするか?しか考えられないから。
マイナスをゼロにすることしかできないから、ゼロを極限まで高め続ける、ことをしているんだと思う。
その精度を上げるために、経験と知識を広げたい。

そのために、最近は、横串し(開発プロセスの全工程)のフルスタックを目指すのが近そうに思っているけど、むずかしい。たくさんいろんな経験しなきゃいけない。ビジネス、QA、インフラ、Webオペレーション、プロジェクト管理、プロセス改善、チーミング、セキュリティやなんやかんやに手を出したい。フロントエンドも難しそうだけど、敬遠してるばかりではなくて、手を出せないと。
でも、縦に深掘りするよりはいい気がしているけど、きつい。プライベードで勉強しない派だからかな。

とにかく壊ししたい。「テスティングがなんとかしてシステムを破壊する」であるならば、私がやりたいことはこれ。
「仕組みを知って中から壊す」は、少数派な気はするが、私のアプローチはそれが近い。
私は「最強の壊れないもの」を作りたい。いや、「私に壊せないもの」を作りたいの方が近いかもしれない。

年々、記憶力と集中力が衰えていっている。記憶力を頼りに生きてきたから、危機感は年々増えている。
どうしようもなくなる前に全力を尽くしたい。どこまでできるか試したい。

コミュニケーションの壁

それとは別に、ソフトスキルやコミュニケーションという壁にすぐにぶつかった。
コミュ障だからこの仕事選んだはずなのに、おかしい。コミュニケーションが大切なんて聞いてないよ!騙された!
この数年もがいているけど、この壁を越えられる気がしていない。でも、なんとかするしかない気もしてる。

私が当事者でないことは、比較的見えやすい。
ソフトウェアでもコミュニケーションでも、違和感が見える(気がする)。
ただ、私自身が当事者になった瞬間に視野が狭くなって、見えなくなる。
自己矛盾を起こして、私の得意を相殺している状態にになる。バイアスがかなり違う。

私自身が中心にいると「妥協できなくなる」から、いつまでも完成しない。「コレジャナイ」から抜けられない。私が一人で作ったものは満点でないと、耐えられない。よく見られたい、失敗を見せたくない気持ちが強い

逆に、私がいないモノをみる立場で、全体をみると、うまくいきやすい。
「岡目八目」の体現。
私に責任が及ばないからか、妥協できるようになる。
というか、うーん、ここはうまく言語化できないな。

でも、見える範囲のコミュニケーションの不和は解決したい。

目指す先

私がいてもいなくても変わらないんだけど、私がいると全体が良くなって「一家に一台あると便利、なくてもいいけど、ほしい」になりたい
そんな気軽な立場で承認欲求を満たしたいと心の何処かで思ってる

何か一つの機能やタスクを私が担当するって、ほんとに向いてない。
好きなことではあるから、じっくり時間をかけて、他の人にはメンテナンスできない複雑なピースを無理に組み合わせたパズルを作る。だいたい時間かけすぎる。
仕事として見た時に、評価できない。壊れにくいけど、変化に弱い。
負け戦の経験ばかり。

誰も読まない長文を時間をかけてガーッと書くのは、好きだし、私としては壊れにくく穴が少なく、完璧で最強だとは思っている
相手からしたら怖いだけ
アウトカムは微妙で、理解不能な代物が出来上がる
大抵ダメ

同じところをぐるぐる回っているけど、抜け出せないし、先が見えない
つらい

私に向いてるお仕事ないかなー

向いてないこと

ビジネスや政治は不得意だし、あんまり興味ないから、いいや。
特に、社内政治や社外政治は、関わりたくない。そういうのがない場所で働きたい。大人って大変。

コストや売上に、興味ないなんだよなー。そういう視点の立場で働いてないからかな

ううーん。最高のものを作りたくて、それで満足してしまう。
よくない。仕事向いてない。ずっとゲームで遊んでたい。

違和感を伝えたりレビューをする人になりたい?

コンサルやコーチでもなくて、第三者ではなくて、チームの中にいたい。でも、端っこがいい。
チームと第三者の間かなー。第三者に近いけどチームにいる、感じ。
立ち上がり遅いから、中期くらいがちょうどいい。短期は成果でないと思う。
掛け持ちはありかも?なしかも?悩ましい。

「レビュー」に近いことをしたいんだけど、見て感じる、だけでそれ以上のことは得意ではないんだよなー
「これ大丈夫ですか?」を探し続ける。
そういうセンサーやソナーの役割は向いてる気がする。
コンテキストを理解して「あるべき」を想像できれば、解決まで持っていけると思う。


ああ、私にとってコンテキストの理解は大切。「あるべきを描けない」から。
違和感があって、違和感をなくすためにどうすればいいかを判断できなくなる。
わかってなくても、他の人に聞ければいいんだけど、聞けない..共創向いてない


一発必中ではないから、頭の中でたくさん試行して、ようやく答え?を出せる
数撃てば当たる、なのかな?
できる限りすべての可能性を想像して、大丈夫そうなのを選んでる。あーでもない、こーでもないをずっと考えてる。その結果を「勘だけど多分これ」と行って説明責任果たせない

英雄願望

自己承認欲求を満たしたい
英雄になりたい願望を持ってる
主役を張れるって証明したい
「この物語の主人公さ」

これが正しいって言える勇気があればいい
ただそれだけできれば
英雄さ

https://twitter.com/kobase555/status/1246126740549689344

ハイキュー!!の日向にならって「最強の球拾い」という言葉を思い付いた。
アンテナになって、こぼれ落ちたボールを拾う

心の中の願望はBE BLUESの桜庭になりたいけど、現実的にはGIANT KILLINGの窪田が近いのかもなー。
心から「捨てゴマまかされました!」と思えるチームに出会いたい。
「嬉しい事です。私には誰かに必要とされる力がある。それはエースになれる力じゃないけど。必要とされる……そんなすばらな事はない。」

コミュニケーション

私自身が苦労しているから、コミュニケーションの不和が見えたことに対して「何かしたい」気持ちは強い。
ズレコミュみたいなのをなんとかしたいなーって想いはある
エンジニアのためのコミュニケーションカンファレンスみたいなものがあれば、全力で協力したい
もし、1on1カンファレンスがあるなら関わえいたい

僕は友達が欲しいんだ!
私はアジャイルになりたいんだ!スクラム王に俺はなるんだ!
いや、ほんとは、アジャイルしたい。スクラムしたい。スクラムマスターやりたい。

可能性を感じていること、学びたいこと

オーセンティック、セルフアウェアネスを高めるために学んで実践して身に付けたい。

に可能性を感じている。

最近、私の感情は邪魔であると感じる。冷静な思考を阻害する。自分を殺したい。

自分とは?他人とは?
「他者と働くこと」「みんな違ってみんないい」それはつまりどういうこと?

3ヶ月経って

kobase16.hatenablog.com

行動変容の年にできているか?
少しはできてるかもだけど、全然足りない。

さいごに

迷子の私
私に何かできることがあれば、チャレンジしたい。
全力で何かできるのかを試したい。
なにかしたいなー。

「やったー!」とハイタッチしたい
「最高の仲間と最高の仕事を全力でして、最高に楽しかったー!」ってのをやってみたい

スクラムマスターチェックリスト

ScrumMaster Checklist

あなたはチームのフルタイムのファシリテーター(促進者)ですか?
Part I -- プロダクトオーナーはどのように過ごしていますか?
Part II -- 開発チームの状況はどうでしょうか?
Part III -- 開発プロセスはどうなってますか?
Part IV -- 組織の状況はどうでしょうか?

「ティール組織」を学ぶ用のあとで読む

[イラスト解説]ティール組織――新しい働き方のスタイル

[イラスト解説]ティール組織――新しい働き方のスタイル

inc.tabippo.net

tbest.hatenablog.com