エンジニアの色眼鏡
このサイトのPV数は物静か故に、エントリで素振りをしている。どういうわけか、ごく稀にホッテントリとかなんちゃら砲でスパイクが立つこともある。スパイクが立つと平常のPV数と単位が変わるからスパイクが画面から消えるまでアクセス数のグラフは役に立たなくなる。スパイクが立つくらいなら続けと思うのだが、物静かなPVこそ平常なので仕方がない。
ところで、次に引用するエントリで若干ピークがあった。何で気を引いたのかはわからないが、このエントリで言いたいところは、最後の文章である。
だから手間が掛かってもアップサイドへ導かないといけないのである。
ところで、エンジニアに限らないが、ものすごく思い込みをしながら情報を読もうとする。サンプルは自分であり、会話をしてきた様々な人である。
思い込み＝バイアス、と受け取っても良い。
例えば、上述のエントリでは、しれっとホスピタリティの高いエンジニアのペルソナを次のように設定している。
こんな頼れるエンジニアを探すとどこの組織でも中堅エンジニアとして実在すると思うし、思った以上に割と多いのではないかと思うがどうだろう。
邪な考えをすると、ホスピタリティの高いエンジニアは使い勝手が良い。なぜなら、意欲があり、仕事に満足度も高い、一方、アップサイドへの取り組みを忙しさで劣後して自己評価を低くするため、仕事を評価して欲しいという思いをコンピテンシレベルという絶対評価で行うことで着地点を見出しやすいからである。
言い方を変えれば、いくら評価して欲しいと思ってもホスピタリティの高いエンジニアはステップアップしたコンピテンシレベルのエビデンスを出すことはできない。
だから、上述の最初の引用が必要になるのだ。
その上で、ホスピタリティの高いエンジニアのコンピテンシレベルを恣意的に滞留させかねない背後にあるものを、マネージャの邪な気持ちとしてあげている。
・マネージャが便利に使う（塩漬けする）
マネージャが邪になるのは、マネージャ自身が狡猾なこともあるがマネージャは組織の意思決定の一部でもあるから、組織の意思決定の背後にあるカルチャーであることを踏まえて述べている。
そう邪にならないように、ある意味マネージャなら戒めに、ホスピタリティの高いエンジニアだと自覚するなら、いつまでもぬるま湯に使っていては危ないという戒めにしたい。
さて、ここまでは前説である。
エンジニアに限らず、人は思い込みで他人の話を聞く。聞くというよりは、都合よく情報を取り込む。聴き手の自分の都合に合わない考えには、イラっとする。その合わなさ加減がドンピシャだとあっという間に頭のてっぺんから湯気が出る。
自分を客観的に見れば、流石に湯気を噴出するお年頃ではないし、イラっとすることもないが、イラは違和感に変わった。誰かの物言いを聞いて違和感を感じたとき、それは自分とは違う思想か、自分ではやらない切り口か、新しい知識の場合だと受け入れ、認識できるようになった。
話を戻して、思い込みである。
前振りの引用したエントリをお読みになり、そんなことはないとか、それはおかしいと思っても全く構わない。お思いの考えの背後にある考えがお有りなら。
自分もそういうときがままあるので、そう感じたとき、手間であるがもう一度、脊髄反射しそうになった箇所の前後を読むことにしている。そうすることで理解や意味の捉え方が違うことに気づくことがある。
これは自分の知っている知識で、目の前のものにバイアスを掛けて情報を取り込もうとするのだ。昭和の例えで言えば、色眼鏡で見る、という状態なのである。
と思っているから、逆にこちらの意図とは違ったリアクションをされても、あーバイアスがかかっているな、と思うので、あとは相手の関係性でそのバイアスの真意を尋ねたり、スルーできるのである。
FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣
- 作者:ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド
- 出版社/メーカー: 日経BP
- 発売日: 2019/01/11
- メディア: 単行本
エンジニアの作る壁
次の条件下でシステム開発に携わるとき、いったいどれだけ壁ができるだろうか。
- プロジェクトチームのメンバ
- 担当エンジニア（アプリエンジニアでもインフラエンジニアでも構わない）
- B2C、B2B、社内システムのどれでも良い
- システム開発手法はウォーターフォール、アジャイル開発のどちらでも良い
- チームは自社と外注業者
アクティビティを機能的にアサイメントされるか、意志で選ぶかに問わず、チームのメンバである時点で自分の作業にフォーカスしてしまう。この現象に開発手法は影響を及ぼさない。ウォーターフォールであれば予定完了日でトレースされ、アジャイル開発ならデイリースタンドアップミーティングで実績を共有するため、どちらも完了予定は意識せざるを得なくなる。能力や開発スピードなどに左右されるが、期待されている日までにアクティビティを終わらせようとすると、リソースを全振りするため、プロジェクト全体を俯瞰する動機付け自体エンジニア自身に生まれない。
エンジニアの専門を指定されると機能分担のバイアスが強くなる。機能分担は分掌に対しての責任を意識しやすい。結果的に担当の責務を果たそうとするのでプロジェクトチームの階層構造が3つ以上かチームメンバが10人を超えるようになると、機能分担がより強くなる。その結果、タコツボ化が始まり、灰色のボールは間に落ち、影と同化して見つけにくくなる。
ビジネスモデルというか、システムの使われ方というよりは、エンドユーザに到達するまでどれだけの役割（エンドユーザに到達するまでに介在するヘルプデスク、IT部門、営業、PM、リーダなど）により、エンドユーザへの意識は希薄化する。機能分担も相まって、階層が増えれば増えるほど、仕事への関心はエンドユーザからアクティビティにエンジニアの関心は依存する。エンドユーザの顔が見えないのにペルソナを設定しても全く意味はなさない。
システム開発手法は、どちらを採用していても、エンドユーザへ接しないのであれば大した差はない。顔の見えていないB2Cよりは、社内システムのエンドユーザの方が格段に近い。システムの使われ方で距離も会うまでに介する人の少ない方がユーザビリティへの関心は高くなる。ただし、エンドユーザに会うことがなければ期待できない。
チームの人的リソースが、自社と外注業者の組み合わせの場合、自社のエンジニアの方から外注業者の監督者か契約形態によっては直接作業を相談されるから、仕事は線を引かれる。指示をする側は、指示をする範囲全てを把握することになるが、指示を受ける側は契約の範囲にフォーカスする。（完成責任を負うかは契約によるが）完成させたいと責任感を強く感じると作業にフォーカスしてしまう。
ホスピタリティの高いエンジニアは実在するか
「実行力を持っていて、頼まれごとは嫌な顔をせず、やり切ってくれる。困りごとはきいてくれるし、何よりホスピタリティがとても高い」
こんな頼れるエンジニアを探すとどこの組織でも中堅エンジニアとして実在すると思うし、思った以上に割と多いのではないかと思うがどうだろう。それとも、前述のようなホスピタリティのたかい「非実在エンジニア」は存在しないのだろうか。
自分のこれまで一緒に働いてきたエンジニアを思い浮かべると何人か思い出せるから、非実在ということもないのだろう。
実は、このホスピタリティの高いエンジニアは中堅で成長が止まってしまう。コンピテンシレベルを上げる（昇給にもなる）ために、自身の育成プランを考えてもらっても、やり直しになる。アプローチを説明して、それをペースにして、やっとお互いに作っても、設定したアップサイドのプランは実行されない。いや、手は付くが中途半端で、自己評価は低く終わってしまう。
普段の仕事では、ホスピタリティの高さ故、自身の目標は劣後する（頼まれごとを優先する）。ジリジリと遅れ出す。ポーリングしたり話を聞いたりすると、そのときはリマインドがかかるのだが、また元に戻ってしまう。
観察していると、ホスピタリティの高いエンジニアはこんな風にみえている。
・成長したいwillはある
・成果を出したいwillはある
・仕事は向こうからやってくる
・ホスピタリティの高さゆえに仕事が切れない
・実際仕事量はおおい
・実践知で仕事を乗り切る
・手法、方法論、技法などを背景に説明しない（できない）
・実践知に頼るため引き出しが少ない
・実は頑固（実践知ベースゆえ）
・際限なく割り込みしてくる仕事にリソースを使う
・willと自分に期待している結果で自己評価は低い
・仕事は外から舞い込んでくるから専門性の軸を聞いても考え込む
・専門性の軸がないからToBeのイメージ像を持っていないか、解像度がとても低い
ブレークスルーさせないと、次のアップサイドにステップアップできない。だから結果的に中堅エンジニアのポジションに長期に渡って滞留する。
滞留する原因は他にもあり、これがとても宜しくない。
・マネージャが便利に使う（塩漬けする）
・ホスピタリティの高いエンジニア自身の仕事への満足度は高い（仕事量は多いし感謝されるので）
その仕事はいつかなくなるか、担当が変わるか、配置転換が起きる。そのとき困るのはホスピタリティの高いエンジニアなのである。
だから手間が掛かってもアップサイドへ導かないといけないのである。
エンジニアとしての自己肯定感との付き合い方
自己肯定感のエントリがあり興味を持って読んだが、自己肯定は行動と役割で自信を持てるから自己肯定感は低くてもいいという趣旨のものだった。
自己肯定についてイメージでしか知識を持っていないので調べてみると諸説あって、「現在の自分を自分であると認める感覚。」と「自分自身のあり方を肯定する気持ちであり、自分のことを好きである気持ち。」などがある。
自分の自己肯定感は前者までで、後者の定義はない。ないというよりは、知ってはいるが、自己肯定感と呼ばれる自己肯定はそこまで、という意味合いである。
他の人のことはわからないが、前者の「自分を自分であると認める」感覚を持てるようになるまで相当の時間がかかった。
自己肯定感を持てないエンジニアもいくらかは存在するのだと思うが、何かを無理にして自己肯定感を持とうなんてする必要もないと思う。
過去エントリに書いてきたように、経験年数的に中堅エンジニアに差し掛かるまではエンジニアとして力量不足を痛感していた。今となれば知識もろくにないのに、ありのままの自分を受け入れられるわけがない。
他人と比較すれば劣る自分がいて、評価もされなければ、自己肯定をする材料は何一つない。
だから、自己肯定をすることを止めた。それ自体をやめた。
どれだけ自分を認めたくても認めるものがなければ認めようがない。だったら、その行為自体をやめることにした。
結果、ありのままの自分はこんなものだ、と受け入れることにした。その受け入れには、定義の後者の自分を好きだとかそれ以外の嫌いだと言った感情は一切ない。
前者の定義、純粋にそれだけだ。
そう捉えるとこれまである意味、自己を低く評価していた自分から解放された。今の自分は上にも下にもなくて、そこにいるままなのだと。
その感覚には、行動の結果や役割での他者からの期待はない。あくまでも今の自分が自分なのだから、しゃあねぇな、この自分と付き合うか、程度の認識でしかない。
自分を好きで過剰に評価したり、嫌いで自己評価を貶めるようなことはしない。鏡に映った自分が自分なのだ、と。
この自己肯定感（前者の）を持ててから、よかったことは、自分のコンピテンシをニュートラルに評価できるようになったことである。
自分を過剰評価してできもしないやったこともないコンピテンシをやれると思わないし、エビデンスがあり繰り返し同じレベルでパフォーマンスできるものはコンピテンシを持っているを自信を持って言える。
エンジニアにとって必要な自己肯定感は、前者の定義だけでよく、それが持てるだけで、as isを適切に捉えられるから、結果的に成長につながるのである。
ただ、サンプル数は1だが。
お腹の空いていないエンジニアの食指を動かすには
手慣れたもので、自分の育成課題はひょいひょいと設定できる。ToBeと今の自分のギャップを理解して伸ばすコンピテンシを決められるからだ。
サクッと設定できるためには（別にサクッと設定できなくても時間がかかるだけだが）いくつかの要点を押さえていなければならない。
・今の自分のコンピテンシレベルの理解
・ToBeのコンピテンシのqualify
・伸長するコンピテンシの意思決定
育成なんて、行きたい方向に行ってみればいいのだから、行きたい方向に進めるスキルを選んでやってみたらいい。
実際やるかはさておき、パッと選んでおく。やらなかったとしたら、暗黙に自分には必要性は低かったのだろう。必要性を感じていたら優先順位を上げてやっていただろうから。
実は自分のことはどうでもいい。
チームのメンバの育成になるとそうはいかなくなる。期待に応えてくれるエンジニアとしていくらでも育って欲しい。
勝手に育って、勝手に昇給してくれれば言うことはない。
現実はそうはいかない。
自分で育成できないエンジニアには、仕事をやったという認識しか持てない。やった、その裏にある適用したコンピテンシレベルの紐付けがない。自分の持っているコンピテンシの何をどのレベルで活かして成果となったかを説明できない。
理由は、現状のコンピテンシレベルを把握できていないからだ。
2つめのqualifyで要求されるコンピテンシとレベルを設定できないと課題も設定できない。
3つめになると、ToBeを持てていないから（持てていたとしても漠然としていて役に立たない）自分で決められない。
こんな風なエンジニアは割と多い。だからマネージャが育成をサポートするのだが、手綱を引こうが、方向を指差そうが、やらないエンジニアはやらない。
経験値的に裏付けされている。
いくら栄養（コンピテンシレベルを上げられる）と言っても、お腹が空いていなければ食指は動かない。
そうすると、いかにお腹を空かせるかが鍵になる。
自分は空腹になりやすいのだが、膨満感なエンジニアが多いらしい。
・危機感
・後がない
・後ろから若手が抜いていく
・（今のペースでいたときの）将来の天井感
などは思いつくが、どれもエンジニア自身でヤバいと思うことがトリガーだ。
でも本当に危機感がトリガーなのだろうか。
やったらできた、の方が報酬があって良いのではないか。
インセンティブになる擬似体験を体験させることができれば、全てがプラス方向（危機感はマイナスから伸ばすことになる）にいくから圧迫もストレスも皆無だ。
やっぱりモブワークか。
エンジニアのお腹はどうしたら空くのですかね。
![anan(アンアン) 2020/02/05号 No.2186 [最新版ダイエットの新常識/Sexy Zone]](https://images-fe.ssl-images-amazon.com/images/I/51DytBNmoGL._SL160_.jpg "anan(アンアン) 2020/02/05号 No.2186 [最新版ダイエットの新常識/Sexy Zone]")
エンジニアがウォーターフォールを嫌いな理由
アジャイル開発の手法というよりは、カンバンが好きなのはこんな理由からだ。
・作業プロセスを常時見られる
・アクティビティのステータスを見られる
・作業プロセスの改善をしやすい
・アクティビティのオーナシップがエンジニアになる
パッと思いつくだけをあげても4つある。
作業プロセスを常時見られるというのは、プロジェクトチームのエンジニアに作業プロセスのガイドを作り、研修する手間が省ける。研修が面倒というより、その場で理解しないで実践になって、ガイドを見ずに進めて、指摘されて初めてガイドの存在を認識するエンジニアもいる。最初から目の前にあり、ほかのエンジニアがそれでやっていれば、習うことがなくても門前のなんとかでやれる。作業プロセスがどうしてそうなっているかの背景は理解されなくても、作業品質は一定確保される。
アクティビティのステータスは、そのままだ。モニタリングしたい作業の粒度でカンバンの列を分解するのでどこまで進んでいるかが一目できる。進捗のきになるアクティビティを都度エンジニアに聞きに行かなくてもデイリースタンドアップミーティングで共有されるから、エンジニアの時間を煩わすこともない。
カンバンの作業プロセスはモニタリングしたい粒度を損なうことがなければチームに改善を委譲するからエンジニアの目線で改善しやすい。
カンバンの作業プロセスの改善をエンジニア自身でしやすくなるということは、アクティビティのオーナシップがエンジニアに移る。
これがWBSのレベル1をPMが作り、エンジニアリーダとエンジニアにアクティビティの分解とスケジューリングを頼むとやらされ感はいがめない。
カンバンの方がエンジニアに主導権がある。
トラブれば、手続きが多くてもタイムボックスの中でスピード感を持ってリリースするのだから、ウォーターフォールだろうがなんだろうが、開発スピードは（持続できるかは別として）確保できる。所詮、作業をするということは、作業プロセスを回すということなのだから、開発手法云々にはならない。
ウォーターフォールは目的最適化して目的を実現するアプローチをするから機能分解する。分解して再構成する作業ファーストの価値観だからエンジニアはそれを実現するアトリビュートでしかない。
なんかね、エンジニアはそれが嫌なんじゃないかと思う。ウォーターフォールで失敗プロジェクトが数多あるのは別問題だが、エンジニアが二の次に扱われるのが息苦しいのではないか。
とは言え、デイリーで全員の前でトレースされるプレッシャもあるが。
プロマネから見れば、アクティビティにする時点でアクティビティのアウトプットは決まるから、スコープが確定しているプロジェクトだろうが、都度決めるプロジェクトだろうがカンバンの使い勝手は変わらない。
