シン・ゴジラで学ぶ一言でワンチームに変える方法
先週シン・ゴジラの円盤がリリースされましたね。うちにも、在宅時間指定をしたクロネコさんによって配達された円盤が無事届いていました。
早速その夜に家族に「観る？」と誘ってみたら子どもさんも観たいと特等席を陣取って早速視聴です。
まー、ワタシは近所の映画館や極爆で何度も観ているのですけどね。
巨災対はどのような組織か
そもそもシン・ゴジラが蒲田くんとして上陸したり、品川くんとして上陸してきたりすること自体を考えたりしませんから、リスクマネジメントの範疇外なのですよね。
だから、想定外というか、予測不可能な事象な訳で。
ということから、巨災対は通常のオペレーションの組織ではありませんから、プロジェクトとして捉えることが適切となります。
ずっと東京に居座られても困りますし。
プロジェクトの目的
通常、プロジェクトではプロジェクトの目的を設定するものですが、ゴジラに対する対処方法が未確認の状況ですから目的自体もプロジェクトの中で設定することになります。
駆除や捕獲など出ていましたが、蒲田くんでさえ相当大きいにそんな定置網ある訳ないじゃんとかどんな大きさの船なら網で巻き上げられるんだよ、なんて思いながら観てましたけど。
外野のいうことに耳を貸してはならないという典型的な例ですね。
プロジェクトメンバのアサイメント
プロジェクトの目的も定まっていないプロジェクトのコアメンバにオペレータは不要です。必要なのは少ない情報から分析するスキルとソリューションを組み立てる想像力です。
「了解した。首を斜めに振らない連中を集めて渡すよ」
泉修一保守第一党政調副会長
とはいえ、頑固者でも自分の識別する情報だけで得られる結論にしがみつくので迷惑千万です。
間違っていたとしても論拠から仮説を立てられる思考を持ったメンバが必要です。
さらに、素直であることも必要です。
「ごめんなさい」
安田 文科省研究振興局基礎研究振興課長
なぜなら、論拠を元に立てた仮説が間違っていたり、直感による判断が間違っていたら別の仮説から対策を立てるために素早くピボットできないからです。
心理的安全とワンチーム
そうした資質を持つメンバをアサイメントできたとしても、こうしたプロジェクトでは責任に対するプレッシャーがメンバに重くのし掛かってくるものです。
斜めに首を振らない変わり者であったとしても、メンバの発想を責任という安定していた中でのオペレーションでの思考のままで枠を嵌められては発想が心理的に不自由になってしまうのです。
そうした見えない枠を取り外すためには、責任者若しくはそれに代わる者がそうした心理的な縛りを解き放つ必要があります。
ま、便宜上私が仕切るが、そもそも出世に無縁な霞ヶ関のはぐれ者、一匹狼、変わり者、オタク、問題児、鼻つまみ者、厄介者、学会の異端児、そういった人間の集まりだ。気にせず好きにやってくれ。
森厚労省医政局研究開発振興課長
これでしがらみを最初からないことにして自由な発想ができるように心理的な安全を確保したのです。
さらに出身がバラバラでお互いに素性のしれない者同士を一つのチームに変えてもいるのです。
シン・ゴジラ Blu-ray特別版4K Ultra HD Blu-ray同梱4枚組
- 出版社/メーカー: 東宝
- 発売日: 2017/03/22
- メディア: Blu-ray
- この商品を含むブログ (11件) を見る
エンジニアとして持つ必要のある危機感
多分、30年前くらいのエンジニアなら、ワタシのようなオジサンエンジニアは業務上必要となったことを必要となった時点で、それも業務時間の中でキャッチアップしていればよかったのではないかなぁ、と思うのです。観測範囲で言えば、入社時に周りにいた30代の先輩方のうち技術書を読んでいると識別できた方は10％くらいでしたから。そのた90％の先輩方からそういった自己研鑽的な話を伺ったことはないので。
別な見方をすれば、今の時代というかこの30年、いや、20年でエンジニアの世界では技術改良のスピードが上がり、一つの技術だけではエンジニアとして明日のおまんまも食い上げになってしまったり、コモディティ化により単価が急降下し、やっぱり明日たのおまんまが危ういということに気づけるような環境が揃ったのでしょう。
これはワタシ流の業績評価の考え方ですが、業績評価は年次での昨対でロールのアップグレード若しくは技術領域のエンハンスでどれだけ（プロジェクト）チームに貢献した領域を広げたかをエビデンスで評価します。
まずは、個々に評価基準に従い評価をしますがこれは絶対評価となります。なぜなら、昨対（年次）で目標設定しているからです。この評価を他のチームメンバと比較することは相対評価となり、評価対象の個人のチャレンジングな取り組みを握り潰してしまことになり、成長の芽をマネージャ自身がパーにしてしまうのでやってはいけないことです。
個々の絶対評価の後は、エンジニアのセグメントの中で相対評価をすることで業績を評価する仕組みにします。この相対評価も評価基準を作り、基準によりチームのエンジニアを評価するのです。
なぜ、評価の話を持ち出し方と言えば、絶対評価の中にエンジニアとして持って欲しい危機感を見出すことができるからです。
それは、
業績評価は年次での昨対でロールのアップグレード若しくは技術領域のエンハンスでどれだけ（プロジェクト）チームに貢献した領域を広げたか
という評価基準に現れていますし、エンジニア自身の成長を昨対で比較するという点がポイントとなるのです。
市場では、コモディティ化すれば技術料は低減される力学が働きます。つまり、昨年の値付けで自分自身を売ることができないような環境にエンジニアの都合は構わずに変わっていくということです。
価格優位性のある技術を持っているのであれば、その方程式が成り立っている間はエンジニアとしての改良は不要ですがその中身は、優位性を日々削りながらジリ貧になっていることに気づくことが遅れればやはり近い将来コモディティ化の波に飲み込まれるだけです。
このことから、エンジニアの技術に対する評価は市場で決まると言えると思うのです。
＃だから、そういう評価をしているのですが。
これは評価側の理屈ですが、エンジニアはどう捉えれば良いのでしょうか。
自分の技術料を高く売りたいと思うエンジニアは、自信を専門家として看做していると言えます。専門家であるということは実現する手段を持っていない人の実現したいことを代替するビジネスを担えるからです。
一方、エンジニアとして自分を専門家として扱わない＝技術のビジネス適用を考えられず、技術利用だけに留まっているエンジニアは、自信を作業者としかみていないのです。指示書に記載の範囲で持っている技術を利用するだけであり、これはオペレータに過ぎません。こうしたオペレータに対する市場価格は代替リソースが低いのです。
エンジニアが持たなければならない危機感は市場価格に左右されない技術を維持するために持つ必要があるのです。
大規模になれば足を引っ張るエンジニアが増えていく
「アップルは、600人のエリート社員を動員して2年足らずで『iOS 10』を開発し大成功を収めました。対照的に、マイクロソフトは10,000人もの社員を動員し、5年以上もかけて『Vista』を開発したにもかかわらず、最終的にサポートを終了することになったのです」
マイクロソフトを擁護するつもりはないけれど、これapple to appleの比較になっているのかぁ、と。 作っているのはOSで人員の規模となっているけれど。
なんでもそうだけれど、比較が出てきたら疑ってみることは習慣にしたほうがいいです。
成功の鍵はアサイメント
それで、なぜこの記事を引用しているかというと、プロジェクトチームの要となるロールにはキーパーソンを置けるか置けないかでそのプロジェクトは大体勝負が決まるのです。
言い換えれば、鍵はアサイメントです。
「えっ、当たり前じゃん」と思ったら、今いるチームの要となるロールがどの役割で、ロールにふさわしいエンジニアが配置されているかを思い出してみてください。
現実にはスキル又はスキルレベルのいづれかに不足点があることの方が多いいのです。これはプロジェクトの立ち上げタイミングである需要とエンジニアが前のプロジェクトからリリースされて供給されるタイミングがプロジェクトで必要とするロールのスキルとレベルと一致することは滅多にないことを物語っています。
需要と供給がなぜ一致しないか
いつもデスマとまではいかないけれど不安定なチームでプロジェクトを運営しているとするとどうしてそのような事態になっているかを考える必要があります。
エンジニアの需要はプロジェクトが立ち上がるからです。プロジェクトの目的を達成するために必要なプロジェクトのチームとしてのスキルセットとスキルのレベルが需要全てです。
そうした需要に本来であればチームとしてスキルセットとレベルをチームとして共有しなければなりません。
規模が需給の不一致を増大する
この要求されるチームの規模が大きくなればなるほど、需要側に応えるための難易度は難しくなるのは想像できるでしょうか。
冒頭のアップルの600人でさえiOSのエンジニアを集めるのは容易ではありません。ただ、アップルの社内であるからこそできることです。では、マイクロソフトの10000人の規模ならどうでしょう。優秀なエンジニアを自社で10000人も集めることはマイクロソフトでさえ難しいことは想像できます。
大規模になれば足を引っ張るエンジニアが増えていく
でも、600人だとしたらどうでしょう。10000人の17分の1です。17分の1であれば精鋭だけのチームとなった可能性は高いのです。アップルもマイクロソフトもどちらのエンジニアも優秀だと思うのです。それでもその中で選りすぐりのエンジニアでなければプロジェクトのアウトプットは目指すものとは違うものができてしまうのです。
これはチームとしてのスキルセットとレベルには程遠いエンジニアが混ざり込み、プロダクトのすべての過程においてレベルの低い方で物事の判断が引っ張られてしまっているのです。
この人数で開発できる規模だったらVISTAはどんなOSになっていたでしょうか。それはまた別の話ですね。
Q新しいツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ
Q 現行業務で使用している情報共有ツールがある。1世代前の技術で実装されているため使い勝手がよくない。ツールの入れ替えを提案したところ、採用され新しいツールに置き換えることになった。そのツールは使用したことがないが類似のツールはプライベートでし利用経験がある。
新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。
「 情報共有ツール」は身近なものに置き換えていただいても結構です。例えば、開発ブレームワークがEOLになったときどうするか、と考えてもらってもいいです。
ゴールを確認しよう
新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。
とあるので導入前に片付けておく必要のある事項を列挙すればいいことになります。「導入前に」がどのような状態か、それを想定できるかが鍵ですね。
キーワードを挙げよう
現実にはパッと目次構成を作ってしまってそれそれの目次ごとのデザインを順次ディテールをある程度まで詳細化するように進めているのでこのステップを飛ばしているのですが、こうしたタスクを振られたときは、と考えると１ステップとして踏んだ方がいいでしょう。
キーワード
現行業務 情報共有ツール 使い勝手が悪い 新しいツール 使用したことがない 類似ツール 利用経験はある
作業の範囲
新しい情報共有ツールを業務に導入するにあたり、予め検討しておくべき課題をあげよ。
とあるので、この検討後には導入とあるので運用が可能な状態にすると仮説を立てて良さそうです。導入するとあることで、運用が考慮されていないとすると
Q 現行業務で使用している情報共有ツールがある。1世代前の技術で実装されているため使い勝手がよくない。ツールの入れ替えを提案したところ、採用され新しいツールに置き換えることになった。
情報共通ツールの置き換えが実現できないからです。
業務とツール
ツールは、業務の一部を機械化するものです。つまり、業務を行うリソースの置き換えです。
業務の機能をツールで代替していたのですから、新しいツールに置き換えるのであれば、現行業務の機能を新しいツールでも担えなければなりません。ですから、機能の継続が可能かを確認しておく必要があります。
置き換える理由
置き換えるということは、置き換えなければならない課題があったわけです。それが解消されるかどうかを予め確認する必要があります。
業務フローの見直し
現行業務でツールを使うにしても、業務の関係者と担当作業を業務フローとして整理しているものです。新しいツールに入れ替えたときの新業務フローに現行業務フローを見直す必要があります。
新しいツールを使うことにより、これまでの事前準備の作業や導入後の業務上の操作に関わる役割分担が変わる可能性があります。そのために業務フローを確認しておく必要があるのです。
前提条件・制約条件の整理
上記の各項目を整理する中で新しいツールを使うために考慮しておかなければならない前提条件や制約条件が判明するものです。こうしたことも予め検討する項目に入れておく必要があります。
やりたいビジネスがあるならエンジニアも権力が必要で
20代からできていれば10年は早く手をつけてられたことになるので、10年早く手をつけた分がリターンとして帰って来ていたかもしれないけれど、30歳で気づけたからまだいいのかもしれない。いづれにしても、自分のやって来たことですから。
少し前に、社外のお友達が企画された手頃な人数で飲む機会があって、すっかり顔馴染みだったり、初めましてで名刺交換などをしながら文字通りワイワイと楽しく歓談をしたわけです。
プログラミング言語はみなさん宗派があるというか、一過言ある方ばかりなようで「swfitは」「phytonは」とかお話しされるとプログラミングが得意でないフレンズなワタシはボッチになれるんですよ。ええ。
だんだんと話の行方が分からなくなった頃に
「偉くなりたくない」
とおっしゃる中堅の方がおられてそう主張されるので、思わず、
「エンジニアにも権力は必要だと思うよ」
とそっと優しく返すと、周りの方もそれに同調される事態にことが広がって、偉くなりたくないと言い放ったエンジニアさんは
「えええ。だって企画を上申するときになんども会議を通して、１案件を承認されるまで何週間もかかるんですよ。そんな会議ばかりやってられないじゃないですか」
と頑張っている。
確かに数週間もの間、説明ばかりで、説明をすれば指摘されて資料を修正しての繰り返しで嫌に思えるかもしれないけれど、それはそれで、
「共犯を作るプロセスなんだよ」
とネガティブに取られるかもしれない言葉を差し出しつつ、周りからも権力が必要だという方向になってエンジニアさん、いや、ある意味全員エンジニアなんですけれど、はどうも納得されないご様子で。
誰も説得なんてするつもりもないし、好き勝手に話しているだけですけれどね。
幾層の会議もなく、１回きりの経営者へのプレゼン15分で決めるスピードもいいけれど、それは１回きりであるからこそのギャンブルだという見方もできるのです。
だからと言って、幾層の会議が良いとい言っているわけではないですが。それでは意思決定までのスピードが遅くてまどろっこしいのも事実です。
ただ、組織としては決めたルールに従ってプロセスしている記録を残すことも必要で、それは規模が大きければ大きいほどそうなるのですよね。
そうした組織構造の中で自分のやりたいこと＝実現したいビジネスがあるならそこに影響を与えられる程度まではエンジニアも権力を手に入れるのが必要ですし、そのためには日頃からの実績に基づくアピールが必要です。
評価者であるマネージャに認知され、アピールがこちらからマネージャにリーチしないとやりたいビジネスが進まないんですよ。
仕掛かり中のアウトプットを共有することが見られる耐性を強くする
プロジェクトでも提案でもですが、何かしらのアクティビティを仕掛かると途中であってもアウトプットができます。そのアウトプットは、提案のために集めた情報かもしれませんし、共有されたインプットから作業している設計書かもしれません。いづれにしてもエンジニアが作業とするとアウトプットが生まれます。
習慣的に仕掛かり途中のアウトプットは、PCのローカルディスクに保存します。しますよね。例えファイルサーバがあったとしても。
アウトプットは見られるために作っている
これ、とっても当たり前なのですが、でも明示的に言われないのであえて書きますが、アウトプットはその作業を依頼した人が必要だから作業として切り出して、担当を決めて実施しているのです。ですから、その作業が終わったら依頼した人が回収することになります。
ですから、誰かに必ず見られる特性を持っているのです。
見られるなら早いうちから
他でも書いていますが、完全に出来上がってからアウトプットを見せるやり方はおすすめしません。ちゃぶ台返しが待っています。
アウトプットをするために、それも具体的なイメージがなければないほど、出来上がる前から見せる作戦が功を奏します。
・方向性を合意すること
・マイルストーンやキーファクターなどで区切ること
この２つのポイントを押さえて行動をすると、結果的に出来上がるずっと前から仕掛かり途中のアウトプットを見せることになります。
普段から見せることで出来上がったときは合意済みのアウトプットが出来上がっている次第です。すっかり出来上がったと思ってから「篠沢教授に全部」と言って掛け金を使うようなチャレンジはそれまで掛けてきた時間をギャンブルするようなものです
早く共有することはGithubと同じ
セキュリティが厳しくてとか、旧態依然としているからとか理由は様々ですが、Githubを使えない環境はまだまだ多いです。
どうしてもツールとして使いたいなら、個人的に週末プログラマーでもしてソースを公開して満足してもらうとして、仕事でそれが使えなくても共有する開発環境でもファイルサーバでも自分のローカルから毎日リリースしてしまうことは、仕組みは違います。
でも、関係者にアウトプットを早いうちから見られると云う環境を作ることと実際に見てもらってフィードバックをもらえると云う点においてはGithubも同じです。
見せ合うことで２つのメリットがある
一つ目は、お互いにアウトプットを見ることで、自分がやらないやり方、考え方を知る機会が作れます。例えば、論理図の表現の仕方、情報の整理の仕方、プログラミング。
二つ目は、見られることに対する耐性がつきます。このスキル、見られることに対する耐性が強くなると、何言われても全く気にならなくなります。それより、
「こいつグダグダ言っているけど本質は」
「もっともらしいこと言っているけど中身ゼロ」
などが冷静に見抜けるようになります。
再発防止策には「べからず」集より「開発プロセス」の見直しを
エンジニアに関わらず何か作業ミスがあると、やれなぜなぜをやれだの、再発防止策はどうしただのと、面倒なことばかり要求します。そうしたことを真面目に要求しているなら作業ミスをした真の原因を見極めたり、再発防止策の効果を検証したり効果測定まで求めて再発防止策の有効性を確かめるまでがお仕事になるはずですが、そのあとのモニタリングなんて求めませんから、形だけだけなんだとすぐにわかってしまうのです。だから、策を作る方も…以下略。
「べからず」集で作業プロセスを見直してはいけない
何かの作業ミスがあり、それが甚大な損害を与えてもべからず集で作業プロセスを見直してはいけません。
当たり前です。
例えばコード設計を上流設計でするときに、コード値とコードの意味合いをピンポイントで設計するかという話です。いきなり、「3＝○○エラー」だけを定義するかといえばそんなことはしないです。コードの取りうる値の範囲とそれ以外を定義して、取りうる値を個別に定義するものです。そうでなければ「3」以外のときの対処に困るからです。
「こうしましょう」では強制ができない
べからず集ではケースの抜けがあるなら、「こうしましょう」でいいじゃない、と思うかもしれません。というか、思いましたよね、ね。
「こうしましょう」は例えばチームの中ではどれだけ強制力があるか曖昧です。チームのメンバは必ず守らなければならないものなのでしょうか。それともできる限り守ってね、なのでしょうか。
確かに、ホワイトな職場で仲良くチーム運営をしましょうという方針であれば、ソフトな言葉で言っているだけで実際は守らないとやんわりと窘められるかもしれませんが。
作業プロセスを見直すチャンス！
今、作業ミスをしたために何かしら再発防止策を打たなければならないのであれば、それは現行の作業プロセスを見直すチャンスです。
今までなんでこれをやっていたのか意味がわからなかった作業までひっくるめて再発防止策を大儀に見直せるチャンスなのです。
作業プロセスは少なくとも初期の頃に想定して設計したとしても、実際のプロジェクトが進捗し、メンバの特性がわかってくると細々と運用で回避しているものです。
そうした明確なプロセスとして定義されていないもののうち、作業プロセスに取り込むことで、メンバ全員がそれを実行することを前提とした方がコンテキストを高めてより高い次元から会話を話すことで意思疎通を効率的に進めることもできます。
逆に、メンバの意思疎通が思ったより取れていないくて、作業品質も低ければ作業プロセスを一段と仔細化することで確実に作業のチェックをできるようにゲートウェイを儲けることもできます。それも慣れて確実にできるようになればチェックポイトを一段上げれば（元に戻せば）いいだけです。
