AI上司の部下になったら
ところで昨日とか仕事を邪魔する上司的なタイトルの記事を見かけたので、いい上司と仕事をしたことが何のだなと可哀想な気持ちになりつつも、であればそろそろAIに理想の上司とやらをやってもらうサービスを作ったらいいじゃないかと思ったりするのだがどちらかのServicerで提供してみてはどうだろうか。
AI上司ならいつも笑顔で、ポジティブで、能力を引き出してくれるだろう。
その代わり、AI上司は部下を観察して必要なアドバイスをするた情報を多く必要とするだろうから、常時カメラ、マイク、行動ログなどあらゆる業務上のログをとるかもしれない。
でも、人間の上司にはうんざりしているなら拒否権はない。
それとAIが上司のポジションになるのだから、エンジニアはずっとエンジニアで管理職になるキャリアパスは閉ざされる。残るはエンジニアのプロとしてのキャリアパスだけだ。
経営者→AI上司→｜（超えられな壁）｜→エンジニア。
こんな組織体制図になるのだ。
5年も持たないだろう、こんな組織は。
そうそう、業績評価も楽しみだ。
今まで定性的な自己評価でも通って評価されていたとしたら、AI上司には通じない。定量的で成果を数字で、論理的に貢献度を説明しなければ、理解できないと突っ返されてしまう。
なにぶん、理想の上司としてAIに学習させるのであるから、理想ばかり要求する上司になることは確実だ。
さてダメな上司とAI上司とどちらがマシなのだろう。
【2019年ビジネス書大賞 大賞】AI vs. 教科書が読めない子どもたち
- 作者: 新井紀子
- 出版社/メーカー: 東洋経済新報社
- 発売日: 2018/02/02
- メディア: 単行本
- この商品を含むブログ (32件) を見る
プロマネになる資質を持っているかどうかを判別する問いかけ
あるメンバが割とレベルの高い業務改善のリーダをやっている。客観的に見ていて、少し不安を感じている。
基本的には本人はwillを持っているし、多分できるだろうと楽観的に言っているので介入をするつもりはないのである。文化的にwillを持つエンジニアにはプロジェクトをリードを委ねる。
とは言え、不安を感じているのでそのモヤモヤ感を払拭したく、帰り際に声を掛けて雑談ぽく会話をする。
雑談の狙いは業務改善の実現可能性である。
では何でそれを検証するかと言えば、頭の中にどれだけ段取りや中間生産物を含むアウトプットのディティールを持っているかを確かめられれば個人的には『まあ、できるんではないかな』と思える。
見切れるかと言う観点で感触を得ることは大事なのである。
それで会話をするのであるが、全くもってスッキリしない。段取りは考えているが一つひとつの段取りのディティールやアウトプットがモヤっとしている。
例えば調査をするためのアプローチを決め打ちしているようなのだが、アプローチは他にもある。それぞれのメリデメを踏まえた上で意思決定しなければ、やり直しになる。
付き合わされる方のコストやマインドを考えることも必要である。
なんとなく雑談をしていて、エンジニアは想定していなかったアプローチを選択することによる導入コスト、つまりヒヤリングする対象者へのちょっとした教育コストを嫌がっているのではないかと思えてきた。
他にもある。段取りのディティールがモヤっとしていることは結局、解消できなかった。こうやろうと思っていると言うこれもwillと言えばwillなのだが、どう聞いても何度か聞き直しても手戻り前提、作業を詰め切るところは先送りにしか聞こえない。
プロマネをやると言うことは、目的の成果を期日までに完成させると言うことだ。
- 目的の完成イメージを共有できないエンジニアはプロマネは向いているだろうか
- 目的を構成するはずのパーツを段階的に作るなら、パーツをいつまでに作ると言う意志を説明できないエンジニアにプロマネは向いているだろうか
- パーツの作り方をわかっていないエンジニアにプロマネは向いているだろうか
表現を変えればプロジェクトの組み立て、アーキテクチャをデザインできるかどうかが判別のキーなのではないかと思うのであるがおかしなことを言っているだろうか。
他者と働く──「わかりあえなさ」から始める組織論 (NewsPicksパブリッシング)
- 作者: 宇田川元一
- 出版社/メーカー: NewsPicksパブリッシング
- 発売日: 2019/10/04
- メディア: 単行本
- この商品を含むブログを見る
プロジェクト・チキンレース
プロジェクトマネージャをやり始めたころの経験談を少し違う切り口で。
要点
- 遅れているとは言いたくない
- プロマネ自身でスケジュールをクラッシュさせる
エンジニアが進捗を遅れていると言いたくないのと同じようにプロマネも進捗を遅れているとは言いたくない。
エンジニアはプロマネに進捗の予実を報告するが、そこであるがままに報告されないと認知できないから、結果的に予実の較差を孕んだままプロジェクト全体として報告する。
プロマネは顧客にプロジェクトの進捗と遅れていれば対策を示す。大切なことは、予実を把握していて、プロマネが対策を打ってあると顧客にあれこれ言われる前に宣言することである。
先手必勝。
遅れている、何もしていないとわかると、誰でもが思うように、対策をしないのか、どうして起きたのか、横並びでプロジェクト内の点検は必要ないか、など後ろ向きな指摘が出て、そこにリソースを割かざるを得ない状況になってしまう。
プロマネが遅れていないと言いたくないのは、余計なことをしたくないからであるし、実際、余計なことをやれるリソースもない。そんなリソースがあるなら他に回したい。
プロマネも人の子であるから、いい格好をしたい。
プロジェクトをやっていれば、顧客と毎週のように進捗や課題を確認していれば、あれこれちょっとしたことをやって欲しいとお願いされる。
最初に、要望を受け入れるときのプロセスを明示しておいて、要望を双方で吟味し、それに係る全ての費用を請求するようにしておくことがプロマネの仕事でもある。
追加でない、もともと顧客の分担の仕事の進捗遅れもままある。
実はこれもリスクである。
「いつまで待ってもらえますか」
と聞かれるとプロマネなので即答しなければ全体の進捗を押さえていないと思われてたらどうしようと頭をよぎる。
つい、もう１週間なら、などと約束してしまう。
これもプロマネがいい格好をしようとしたからである。
プロマネは内心、行けるかな、行けるよな、とスケジュールの限界に挑戦するチキンレースを始めてしまうのだ。
結果、何が起きるかといえば、エンジニアのスケジュールを前から潰してしまう。
これも冷静に考えれば、エンジニアのスケジュールを確保すべく、後続工程の作業の一部をバーターするかプロジェクト費用の追加を打診すべきである。
柔軟な対応としては、1-2日までなら良いがそれ以上は無理だと言うべきことである。
良い格好をしようとするとプロマネ自身でスケジュールをクラッシュさせて壊してしまう。
チャオ (CIAO) 猫用おやつ ちゅ~る とりささみ 海鮮ミックス味 14g×20本入
- 出版社/メーカー: いなばペットフード
- 発売日: 2014/09/15
- メディア: その他
- この商品を含むブログを見る
ガーっと全部作ってしまう
もし仕事で（仕事でなくてもいい）アウトプットをぼんやりとしかイメージをできておらず、どう手をつけるか悩んでいるなら、最後まで勢いでガーっと全部作ってしまうのがいい。
どうせ進捗していないのだから、細かいことは気にしない。どうせディティールなんてわかっていないのだから、それは飛ばして最後まで作ってしまう。
ポイントは、ガーっと、全部、最後まで。
一度書いてみれば、それが欲しいものか、欲しいものでないか自分で判断できる。
最後まで作ったものが頼まれたものなら、これが欲しかったかを現物で確かめられる。
ほら、なんかそんなシステム開発手法があった気がするけど、それ。
細々とあちらこちら気にしていたら進みは遅くなる。
いつまで経っても手に入れられない。
だから、ガーっと全部作る。
細かいことはあと。
一度、全部作って、眺める。
早い。
マネージャとしてやっている10のコミュニケーション
プロマネをやったり、マネージャをやったりしていて、経験的にか本か何かで知ったこともあるかもしれないが、無意識にやっている10のコミュニケーション。
- 笑顔で応える（スマイルはプライスレス）
- 話を聞く（聞いてから相談のポイントに沿って考える）
- 理解できなことは教えてもらう（自分の専門以外できる人は専門家）
- willを持っていれば裁量を渡す（基本は全面的に渡しヤバそうなときは助ける）
- 段取りを教えてもらう（作業の抜け漏れを知る）
- 基準を教えてもらう（開始基準、完了基準などを知る）
- マイルストーンが設定されちるか見る（期限に終わるリソースを揃えているかを見る）
- 出来たら一緒に喜ぶ（嬉しいー）
- 犯人探しをしない（トラブルの原因は作業プロセスのデザインにある）
- 自分で知りたいことは自分から聞きに行く（呼びつけない）
毎日ブログを書くことの弊害
今いま、かなりプロジェクトの佳境に入っている。御多分に洩れず、数多の担当業務に対してプライオリティ、優先順位づけをして自分のリソースを割り当てているため、フォーカスしない業務は劣後する。ときどき誰か、上司か同僚が劣後した担当業務を思い出すのできっぱりと『それは後』と返すことで納期の延伸を図っている（現状、それで回避はうまくいっている）。
当然であるが、佳境のプロジェクトは大きな問題もなく進捗している。大きな問題もないが、そのプロジェクトとルーチンワークと差し込みのワークとがあるため、常時リソースは天井に張り付いているような状況である。
ところで、ずっと気にかけていることがあり、自分の仕事としてやらなければと思っていることがある。これは前述の数多の担当業務というよりはポジション的にしなければならないことだと認識している。しているが結果、数多の担当業務と同じように劣後している。
その代償は、いわゆる社員満足度調査の数字に現れている。
マネージャとして担当業務を持つこと自体、事業会社であれば当然である。ただチームの仕事の予実を数字や報告で眺めるのが仕事ではない。ではないが、チームに対するいくつかのことに対してリソースを割かなければならない。
その意味では、マネージャの仕事をしているかというと担当となってしまっているのでマネージャの仕事の一部をしていないことになる。
これまで、エンジニアは自分のリソースを全部作業で埋めてはいけないと書き残してきた。なぜなら、作業に落とし込む前の考える時間を取らないとクリエイティビティなアイデアを考え出すことも、新しいアプローチを考えることも、それを実践することもできないからである。
このブログは30分スプリントのイメージで時間枠を少しだけ気にして書いている。書き始めるまでの題材を決めるのに時間を取られるのが従来からの問題であることに変わりはないが、そのくらいの時間を枠に書いている。
なぜ書き続けるかというと、当初は書くことに対する素振り的な位置付けであった。その目的は達成されたのであるが、習慣として身についたのでこれをやめる勇気を持てない。やめてしまうと書けなくなってしまわないかとか、つまらないことだが連続記録を止めてしまうということも割と大きい。
さてさて、どうしたものか。
進捗の邪魔にしかならないエンジニア
チームにいると困るというか進捗の邪魔にしかならないエンジニアのタイプ。
- 原理主義者
- 完璧主義者
- 頑固者
- 嫌い
原理主義者
例えばスクラム原理主義者が世の中に存在するとして、スクラムガイドどおりにやっていないと重箱の隅をつつくエンジニア。他には組織内のルール、標準どおりにやっていないと細々と指摘するケース。
無知で間違っているケースはもちろんあるので、その場合は好きなだけ指摘すればいい。
ただ経験者の場合もあるで、テーラリングであえて崩しているとか省略しているとか確認してからで良いのではないだろうか。
原理やプラクティスは成功事例（その逆もあるかもしれない）を集約してエッセンスとしたものであるから生きた現場でフィットするわけがない。
必ず現場合わせが必要になることをわかっていないし、運用可能な開発プロセスを設計できる能力を持っていない。
原理主義者がチームにいるとチームのメンバと揉める。
完璧主義者
ここでいう完璧主義者とは、自己満足するための、である。それは完了基準を自分にしているため、プロジェクトの完了基準、納期を重要視しない。
結果、当然ながら納期に間に合うことはない。
こうしたエンジニアは他のメンバにも自分の価値観を押し付ける。
もちろん、プロジェクトの基準を遵守し、品質を保持し、プロジェクトの納期にピタリと終わらせられるエンジニアは完璧である。
頑固者
プロフェッショナルの意味合いで、信念を念持として仕事をしているのとは違う。自分の成功体験でしか判断をできない。
自分の成功体験が全てで、それに基づいて行動するからたの話に聞く耳を持たない。
聞くフリをしてても、シャットダウンしている。
嫌い
このエンジニアも自分の好みの感情である嫌いで人を判断する。
割と周囲の評判を鵜呑みにしていることが多い。
嫌いだと思ったらとことん嫌う。
仕事なのだから成果だけフォーカスすればいいものを、それより感情が優先するのは成人が済んでいないエンジニアである。
Nintendo Switch 本体 (ニンテンドースイッチ) Joy-Con(L) ネオンブルー/(R) ネオンレッド(バッテリー持続時間が長くなったモデル)
- 出版社/メーカー: 任天堂
- 発売日: 2019/08/30
- メディア: Video Game
- この商品を含むブログを見る
