エンジニアのないない疑惑
システムは事業上の課題を解消するためにある部分をシステム化により解決手段を実現するわけですが、どんな要件であるか事業上の課題を持っている事業主体です。情報子会社でもSIerでも事業上の課題は自分のものではないのです。
ここに要件のオーナとそれを受けて要件を実現するベンダと分離されるのですが、要件のオーナ側は実現方法を知らない（ことの方が多いですがソリューションを勉強しているIT部門がない訳ではない）ので「作って」と依頼して、ベンダが実現する構図ができるのですけれど…。
そういう情報技術の投資を行う企業は既存システムがあってそれが制約事項になったり、コンプラや情報セキュリティが足かせになって雁字搦めになりながらもシステム化することになります。
そこに全体を見ながらシステムで解決手段を実現するためのデザインを正しく作ろうと思うエンジニアがアサインされないと手持ちの技術、スキルでできることを実装しようとするんですよね。ここで問題が生じてしまうんです。
正しい技術を適用しない
ひとつは、事業上の課題を解決するためのシステム化なのに最適な技術を適用しない、ということです。
もちろん、先に述べたように既存システムが制約となって最適な技術を適用できないというケースもあるかもしれませんが、あるもので済ませようとする妥協が存在すると動くし、やりたいことはできているようだけどサァ、的なシステムが増えてしまうのです。
色々な解決方法はあるけど、制約を考慮するとこれが（QCDと時間的なものとランニングを含め）適切なシステム化デザインですよ、とならないのです。
実装する技術を持っていない
二つ目は、エンジニアとして事業上の課題を解決するためには本当は別の技術が良いのはわかっているけれど実現する側のエンジニアにそれを実装する技術の持ち合わせがないために本当は選びたい技術を回避する行動をすることが起きてしまうのです。
ないない疑惑
そこに、正しく作ろうと思うエンジニアがいるのか疑惑と実現する技術を持っていない疑惑が潜在的にあるのではないかな、と。
だって、方式設計でどこまで妥協なく適用する技術について考えていますかねぇ、と。あるもの前提というか適用するつもりの技術、それほんとに適切なの、要件を確認した上でさ、とやりとりを見ていると思うことがあるのですよねぇ。
正しい技術を適用しない疑惑と実装する技術を持っていない疑惑のないない疑惑。
積み本
２番目のから読んでみようかなー
自衛隊メンタル教官が教えてきた 自信がある人に変わるたった１つの方法
- 作者: 下園壮太
- 出版社/メーカー: 朝日新聞出版
- 発売日: 2016/02/05
- メディア: Kindle版
- この商品を含むブログを見る
介入とフィードバックは次元が違うよ
あるプロジェクトがあって、プロジェクトはプロマネに任せていたけれど、立場的に顧客との会議は出席しなければならないので必然とプロジェクトチームの仕事ぶりの一部を観察することになるのです。
傍観を決め込む
もちろん、出席する会議は進捗会議です。「やってます」「課題はこれです」「次はこれやりますよ」というのや課題がプロジェクトの問題になってしまいそうです…みたいなことを共有して次のアクションを決めるミーティングですね。
一応、本職はプロマネなのでプロジェクトチームの報告のツッコミどころや気づいていなさそうなリスクについてその場で指摘してもいいのだけれど（よくない）、顧客が気づかなければわざわざ横から矢を射る必要もないので基本的に傍観を決め込みます。
顧客がツッコミを入れたら、プロマネを助けるようにネタふりをしますけど。
それは介入
そうなんですよね。プロジェクトチームが主体的に動いているときに自分で手を出しもせずにあれこれ指示を出すのは介入なんです。出がプロマネなのでつい言いたくなるんですよね。
でも、言ってしまったら、プロジェクトチームはプロジェクトを受け身で捉えちゃうんです。これ、あとあと全部引き受けるつもりならいいのですが、いや、よくないんですけど、立て直しならいいのですけどね。そうじゃない場合はよくないです。
フィードバックのタイミング
会議の後、5分だけ時間をもらって、気づいたことを伝えていましたね。あの課題、期限が明確じゃなかったけどわざとそうしていたのかそれともうっかりなのかとか、こういったケースが起きたらどうするの、とか。
基本的にはこんなことがありそうだけど、気づいているかな、系ですね。
会議の前に見ておけばいいっていうこともありますけど、会議資料の準備で頭に入らないですよね。時間のコントロールできていないですから。
ベテランエンジニアの能力開発
若手や中堅のエンジニアであれば、仕事上スキルを身につけたり、スキルレベルを上げていかないと仕事にならないのである意味、放置していてもどうにかなるんですね。
でも、ベテランになってくると持っているスキルでどうにか仕事をやってしまうケースが多々あって、というか、やっつけてしまったり、アサイン自体がその辺を考慮してしまっているので結局どうにかなってしまうんですね。
そうするとどうなるかというと想像していると思いますが陳腐化するんですね。ええ、技術が。技術は何もコードばかりじゃなくて、問題解決手法とか要件の可視化など上流工程や企画なら必要でしょう、というものも含まれます。
ベテランエンジニアにとって不幸なのはベテランエンジニアのマネージャがワタシだったということです。新しいおもちゃが出るとこれ役にたつかなとか、あるクラスタ界隈で話題になり始める考え方や手法がTLから勝手に入り込んでくるので良さげなものを知っていたり、実際自分で使ってみたりしているわけです。
ミーティングでボトムアップでアホなアプローチしているな、とか、それを始めるにあたってそんな前提でいいのか的なそもそも論ぽい本質のところをつくと、これまた変なアプローチや無理筋な仮説を言い始めるんですね。最初は聞いていますけど。
ベテランエンジニアでも現場に出ている人の中には真面目に自分の関心を持てる技術は勉強している人がいます。ただ、多くはないし、自分が関心を持っている領域に限られるのが玉に瑕です。あと、多い方は家で何か勉強しているかといえば、仕事上必要に迫られないので勉強なんてしていないです。ランチで勝手に話し始める家庭内の出来事を聞いているとそんな感じです。
ベテランエンジニアに勉強させるには
だったらどうしよう。機会を仕事の中で作る他ないじゃない、ということです。仕事の中で時間を取る。業務を都合つけさせて。
どうせ家でなんてやらないと思うことにするのです。体力的にも落ちていますし、家飲みしてるでしょうし。
仕事の中で勉強する機会を作る。そういう時間を勤務時間の中に組み込んでしまうんです。
公平に扱う
平等ではありません。ベテランエンジニアも中堅エンジニアも新人エンジニアいるとして、同じように扱う。ベテランエンジニアだけとか新人エンジニアだけに集中するとなんで俺だけ、と思うんですよ、人は。
だから、同じように仕事を振るんです。勉強する機会を設けた時間の中では。
マネージャは機会を生み、与えるのが仕事です。ですから、同じように機会は与える。エンジニアそれぞれ本来は与える機会の種類は違うものですが、教育として、それも基礎的なコンピテンシがテーマの場合は全員が対象となるので、同じ機会を与えることを考えます。
全員に順番を回す
出席者全員に回るように確保した時間を人数割りして配分時間を決めます。4人なら一人15分。もちろん、ワタシは除いて。
で、PCのタイプなりホワイトボードに描くことを輪番でやってもらう。ペルソナを作っているなら、タイプを順番にしてもらう。とにかく、関わらせて、お前それやったよなという状況を作るのです。
当事者にするということ。
そうでなければ腕を組んで、部外者だからと好き勝手に発言するんですから、ベテランエンジニアなんて。そうでなければ存在意義を主張できないのでしょう。もしくは寝てる。
気を抜かせないように嵌めてしまうのです。
要は面倒臭いことをさせるので、公平にが必要になってくるんです。え、ベテランエンジニアってそんな生き物なのと思うかもしれないけれど、そんなものです。二十歳を過ぎて20年も経っていたら良くも悪くも出来上がっているものです。
それを変えていかないといけない。でも一人だけ吊るして代われといっても変わらないです。出来上がっているので。
でも、全員でやるとなるとじゃあといってくれる存在です。そこをね、上手に使うんです。
育てたようにしかエンジニアは育たない
最初、別なことを書いていたけれど、別なことが頭を過って、そっちの方が書きたくなったので書き書けを気持ちよく消して書き直し。
最近のテレビ番組の凋落ぶりがひどいのは周知の事実で、特にバラエティ番組は一般にしてはいけない、いじめや不快なコンテンツをわざと逆張りでやっている感があるけれど、そのようなコンテンツを流し続ければどうなるかというと、そうしたコンテンツで育つ群衆が出来上がるわけです。つまり、テレビ局はそういった番組を志向するセグメントを自分で生産しているのです。そんなことをしているのに一方では政治や環境といった番組を作っても別のコンテンツを志向するセグメントには関心さえ向けてもらえなくて、政治や環境といったテーマの番組もバラエティ番組化するんですね。そのスパイラルに入ってしまっているからどれを見ても同じになっているんです。
つまり、コンテンツを提供する側が先々を見て策を打っておらず、目先のことばかりやっていると自分で自分の首を絞めることになるのです。これと同じことが、テレビではなく、仕事の育成でも起きています。次世代が育たない、あいつはダメだ、などというマネージャがいるとお前が何もリソースを割いて活動をしていないのに一体どうしてお前が期待する次世代や育成候補者が育つんだよ、と思うのです。自分事じゃないので関わりませんが。逆に、自分事なら関わりますけどね。越権行為に当たることはしないだけです。
エンジニアは勝手に育つというエントリがあったと思います。あれはそうだと思いますが、そうでもないよとも思うのです。本人がこれ楽しいとかやろうとか思うことが一番大事なのですが、それをやれる環境などの支援はマネージャの領分です。マネージャが支援をしなければ成長は実現しない部分が多いのも事実です。一番わかりやすのは仕事のアサイン。やりたいこととドンピシャな仕事があればいいのですけれど、ほとんどなくて、ちょっと違うけれど解釈をちょっとずらせばそれほど外れてもいないケースがほとんどなので、そうした解釈やアサインの意図をアドバイスするのもマネージャの仕事の一部です。こちら（マネージャ）の立場としては育ってもらうのが仕事なのでやるんですけど。
これも結局、目の前の仕事にばかり目をやって、先々を考えて手を打っておかないと必要なとき、つまり3年後や5年後、10年後に人材が育っていないことになるんです。それを部下になすりつけちゃいけない。育てられないのはマネージャのお前が能力不足だったのだから。まあ、そんなマネージャを選んだ経営もまた同じ構造なのですけどね。こうしたマネージャや経営の下に優秀なエンジニアがいるとある程度でやめるかそれの代替になろうとします。辞めるのは愛想をついてだし、代替になろうとするのはルールがわかったので攻略しようとするんです。後者はオペレーションマネージャにしかならないですが。
個人的な感覚で言えば、人材を育てるマネージャは成果で物事を見ていて、評価も成果で判断すると思っています。そういったマネージャは、逆に言えば、時間で縛らないでエビデンスを確認する。だからドライに見えるかもしれないし、マネージャ自身が色々と社内外問わず活動をしている人の方が多いです。そんなマネージャの下で働く方が不条理が少なくていいです。自分の成果を見てもらえるから。
素直に話を聞く価値
仕事をしていて、やっとここ最近は仕事が少しはましにできるようになったと思えるようになったのですが、何を変えたからそう思うようになれたのかというと、素直に周りの人の話を聞くようにしたことを１番に挙げます。
ずいぶん前に、顔見知りの同僚に「武闘派だよね」と言われたことがあって「エェェ」と思ったんですね。そんな喧嘩腰で話していないよって。
あるミーティンではたと気づいたのは、喧嘩腰じゃないけれど力技で押し切ろうとしていた自分がいたんです。それに気づいたの。
ああこれを言っていたんだな、と。
それで、どうして押し切ろうと思っていたんだろうと内省してみたんですね。無理矢理に押し通そうとしたのは、ロジックができていなかった、準備が十分でなかった、などなどこちら側にそこを突かれると痛いから、というウィークポイントがあったんですね。
そのウィークポイントを突かれるとあと作業が増えるし、スケジュールが押してしまうから。確かに議案についてある程度は見切れていたから押し通そうとしたということはありますが。
あと、厳しいコメントをつける彼彼女らはどうしてそれをしてくれるのか、立場を変えて考えてみたのです。彼彼女らは役割を担っていて、立場上言わなければばならないこともありますが、こちらが失敗しないように知見を伝えていることも中にはあると思うったのです。
それで、彼彼女らの言葉を一旦、素直に聞くことにしました。素直に聞く。コメント内容が不明瞭なら具体的に何を指しているのかまで確認しながら聞くようにしました。
その上で、こちらの見解を述べることにしました。自分で気づいていないことを指摘してくれた場合は、まず、肯定するようにしました。なるほど、その観点では見ることができていなかった、良いコメントですね。言い方はその都度、その場面で変わりますが。
指摘が実はこちらの主張に含まれており、解釈、表現上の違いであれば、やはり肯定した上で、実は同じ意味合いですが表現方法が違いますね、より良い表現はどちらかを決めましょうとするようにしたのです。
指摘が明らかに的外れの場合、それは意図を確認した上で反対意見を伝えるようにしました。ただ、リジェクトするわけでもなくて、的外れな指摘に見えて実は大事な観点であることを見落とす危険もあるので、その点が何かは確認しなければなりません。こちらはそれに気づいていませんから。
形式的な指摘については、議題について価値は低いですがそれがレギュレーションである場合も素直に話を聞き、指摘を反映することにしています。これは、それをすることで彼彼女らは共犯になるからです。ルールを守っていて、その他の指摘がないのであれば同意をしているわけです。
コメントがつくケースは色々ありますが、どのような意見がついたとしても一旦、素直に話を聞くようにしました。
ただ、なんでも言われたまま話を聞くわけではありません。意図を確認し、有用かどうかを判断するのはこちらの責任です。言われたことをそのまま受け入れるのは思考を放棄しているのと同じですから。
素直に話を聞くことは実はもう一つの意味合いがあります。仕事が切羽詰まっている時には、思考漏れや前提を誤ることが少なくありません。そうしたことを前述したように素直に話を聞くことで予防するのはもちろんのこと、最短で仕事を完了させることができるのです。
一つは、自分自身の無駄な怒りを起こさないようにできるからです。内心、悶々としていいては仕事に集中できませんし、見落としているところで集中していないためにさらにミスを起こしかねません。冷静に、全体を見渡す余裕がなければミスを自分で引き起こします。
もう一つ。怒らないようにすると、表情に余裕ができます。「あ、その観点ではみていませんでした、いいコメントですね。いただきます（ニッコリ）」と後味よく終わらせられます。
素直に話を聞くとは、意見を聞き、自分の考えと違いを知る。どちらが良い策かを議題の目的ベースで判断する、と言う意味なのです。
チームを成長させるための6つのテーマ
ここ1−2年かな、チームについて色々な取り組みを共有するケースが多い気がするのですが。例えば、心理的安全もその一つだし、このブログでも時々取り上げているような気がするけれど。
多分、それは今まで以上に少人数で、短期間で、より高い成果がチームに求められているからではないかと思うのです。それと、今までのチームでの活動に無理、無駄、不条理などの成果を阻害する負の慣習がこびりついていてそれが成果への阻害要因だと可視化されてきたのではないかなぁ、と。
チームを一つの活動体として捉える場合、何をすればより活動しやすく、成果を得られやすくなるのでしょうか。
チームが経験から学ぶために
チームが経験したことを自分の言葉で表現し直すこと。経験を持っている知識を使ってどのような経験だったかを表現することで経験と知識を紐付け直す。
できた理由を識別する
経験を振り返る際に、期待したようにできたのはどうしてか、その理由を明らかにすること。できなかった理由を知ることは次にそれを回避するために必要なこと。
面白いと感じた経験を知る
辛い経験は繰り返さない。無意識に避けるから。面白いと感じた体験は常習性がある。ゲームと同じ理屈。
育てる力
成長するためには育とうと実行する行動と成長するための環境を用意することの二つを揃えないと続かない。
片方だけでは育たない。
誰が見ても同じ理解ができるToBe
チームメンバの誰もが見ても同じように理解ができる表現で目指す姿を明らかにする。
解釈が違エバ辿り着く場所も辿り方も違ってしまう。
成長に適した場を用意する
機会がなければ成長の養分を得られない。成長に必要な栄養と違う養分であればいくら体験しても価値のある経験にならない。
