2020-02-23

COVID-19とオフラインイベントとリスクマネジメント

先週からの1週間、nCOV（COVID-19）でオフラインイベントが相次いで中止され始めている。所属する組織でも、組織の内外向けに予定していたオフラインイベントの扱いや今後のオフラインイベントについてマネジメントでスピード感を持って議論され、意思決定されている。

COVID-19を起因とする組織内外のイベントの開催の意思決定で、安易に中止に流れているとしたら、その組織にはリスクマネジメントの能力がないのと同時に、ビジネスの機会損失を機能していないマネジメントの寄せ集めである可能性があることに気づかなければならない。

リスクのマネジメント能力がないということは、リスクを捉える能力も、リスクで最悪の自体が起きたときのインパクトも、リスクがプラスに働くことも、想像することも仮説を立てることもエクスボージャを見積もることもできないということなのだろう。

予定していたオフラインイベントがあったとき、取れる選択肢は次のどれかだ。

中止する
オフラインで予定どおり行なう
オンラインに切り替えて行なう

中止はとても楽である。ただし、無償なのであれば。無償のオフラインイベントであれば、

参加者へのお知らせ
会場、外部業者へ費用の負担

だけで済む。

そう思ったら、違う。ビジネスであれば事業上の必要性があるからオンラインイベントを行なっているはずである。それをホイホイと止められるなら、マネジメントは本当に事業上の必要性があるかを問い直さなければいけない。もしかしたら、惰性でやっているのかもしれない。

オフラインで予定どおり行なうのであれば、これはこれでリスクの感度が鈍いかもしれないことを疑わなければならない。

リスクの識別
オフライン開催でのガイドライン
感染症対策のリスト
対策品の手配の可能性
現場スタッフの感度の教育

特に気をつけなければならないのは、現場スタッフの感度の問題である。今まで出席者に対しては、イベントをスムーズに進行することだけしか要請事項としてなかったはずだ。それが、イベント会場において、感染症の対策を出席者に対して例外を作らずに要請しなければならないし、守らない参加者に対しては入場自体断らなければならない。そうしなければ、全てのリスク対策がパーになる。

リスクには次のものが挙げられるだろう。

参加者によるウイルスの持ち込みによるオフライン会場での感染
オフラインイベント主催者へ保健所からの陽性患者がいたことの連絡
スタッフの罹患

前述の事象が起きたとき、どのようなリスクがイベント主催者に対して生じるかを想像できなければならない。間違っても、うちに限って、うちのイベントに来るひとは大丈夫だ、などと思ってはいけない。そんな都合の良いことは起こらない。

予定していたオフラインイベントをオンラインイベントに切り替えられる場合、つまり、オンラインイベントの設備が整っているか、間に合わせることができるならそれに向かって進めればいい。今までオンラインでのイベントの経験が少なければ、相応にリスクを抱えていることを自覚しなければならないし、実際に慣れないことをすると予期せぬ、ではなく予期できないことが起きてイベントを失敗しかねない。

設備の手配
スタッフの訓練
トラブルシュートできる経験者の確保か許容する覚悟

社内のイベントであればいくら失敗しでもいいだろう。それが社外のイベントでも許容されないのだとしたら、相応のコストを掛けて、様々なトラブルケースを想定して訓練しなければ確実にやらかす。

そうしないためにも原理原則と運用設計をできる人が責任者として入らなければならない。その辺にいる一担当に実行させているようであれば…。

ニッソーシーパレックス 600

メディア: その他

2020-02-22

チームを止めるのは価値観をupdateしないエンジニア

on 価値観経験 update エンジニア

エンジニアは経験を重ねて複雑な技術を組み合わせて問題を解決する。それがお仕事である。であるから、当然経験を積み続けなければ、新しい問題を解決できないときがやってくる。そうした新しい問題は、足音を立てず、そっと後ろに佇み、エンジニアが経験を積むことをやめたとき、そのエンジニアに憑依する。

エンジニアは経験で価値観を作り上げる。それは、仕事を手渡されてから自分で完成したと告げるまでの間に、エンジニア自身で行った意思決定の集成のようなものだ。思うように行かなかったことや思いかけず上手くいった結果に繋がった、そうしようと決めたときの気持ちの牙城だ。

その価値観の中身は、エンジニアの経験の証のようなものか、はたまた、単なる思い込みでしかない。エンジニアとして経験したいことは山ほどあるが、自分は一人しかいないから、最初叶わない願いだ。

それをやめてしまうということは、新しい問題を解決できる方法を取り入れないということでしかなく、目の前の年下のエンジニアの価値観を理解も共感もできなくなってしまう。

プロジェクトのチームの中で、それ、つまり、経験で価値観を作り続けることをやめたエンジニアは障害にしかならない。少なくともプロジェクトチームの中で起きる新しい課題を解決する技術を更新しなのだから、そのエンジニアの持っているだけのプアな価値観で解決しようとする。そのとき、チームを止めるのは、経験で価値観を作ることをやめたエンジニアなのである。

困ったことにこうしたエンジニアにはこのくらいの年齢というものがない。管理ばかりやりたがるエンジニアもどきには潜在的に多そうであるが、そうしたエンジニアはどの年代にもいるから注意が必要である。

大概、鏡を見るとそこに写っている。

【Amazon.co.jp限定】みんなで! [2CD + Blu-ray] (Amazon.co.jp限定特典 : [複製]サイン入りデカジャケ付)

アーティスト:沼倉愛美
出版社/メーカー: フライングドッグ
発売日: 2020/02/12
メディア: CD

2020-02-21

スピード感を持って仕事をしたいなら

On スピード自走自分事

スピード感を持って仕事をするとか、自走するとか、仕事を自分事としてやりたいと思うなら、宿題を作らない仕事の仕方を覚えると実現しやすい。

やはり、これは現場の仕事だから現場にやってもらうとか思った瞬間から、スピードも無くなるし、自分で仕事をコントロールできなくなるし、他人事になってしまう。

ミーティングで意思決定をすることが目的なら、意思決定をした後のアクティビティまでざっと出して、期限と担当を決めてしまう。アイデアをディスカッションするなら、方向性、目的を共有までやってしまう。説明をするなら、その場で一緒に作ってしまう。

共通しているのは、ボールを渡さないということである。

ここで求められるコンピテンシは、何か。そこを押さえないと闇雲になってしまうし、場当たりすぎる。

その成し遂げたい仕事のゴールのイメージから逆算してあらすじ、台本を書けるようになりたい。

台本とは、台詞を言う役名の下に台詞がある形態のものだ。言い換えれば、誰にどの仕事をやらせたいかを考え、描いたように行動に影響を与えるものだ。

これには、行動に影響を与える対象に、台本を書いている自分も含まれていることに注意しなければならない。実現したいことは、自分自身から変えないと誰も動いてくれない。

自分も台本の中に入って役者と同じように役を持ち、自分のやることは自分でやるから、それを見て他の役者も同じように踊ってくれるのである。

自分だけ傍観者というわけにはいかない。何せ実現したい仕事の張本人なのだから。

みずほ銀行システム統合、苦闘の19年史　史上最大のITプロジェクト「3度目の正直」

作者:日経コンピュータ,山端宏実,岡部一詩,中田敦,大和田尚孝,谷島宣之
出版社/メーカー: 日経BP
発売日: 2020/02/14
メディア: Kindle版

みずほ銀行システム統合、苦闘の19年史史上最大のITプロジェクト「3度目の正直」

作者:日経コンピュータ,山端宏実,岡部一詩,中田敦,大和田尚孝,谷島宣之
出版社/メーカー: 日経BP
発売日: 2020/02/14
メディア: 単行本

2020-02-20

リモートワークのよろしくないところ

On リモートワーク雑談在宅勤務よくないところ

ときどきリモートワーク、在宅勤務をするのであるが、これがよろしくない。いや、勿論良い面もあるがつづけるとよろしくないような気がする。

まず、通勤がない。おかげで朝食を済ませたら、直ぐに仕事を始められる。まあ、先に日々の日課をするのだが、それはリモートワークかどうかにかかわらずなので無視して良い。

自分は着替えて、電車に乗ることでスイッチが変わる。そう思っていたが、最近はそんなこともなく、仕事を始められるのでただの思い過ごしなようだ。

通勤がなくなったことで失うものがある。通勤時間での移動による運動である。リモートワークになると、ほぼ終日リビングで仕事をするので致命的に運動がゼロによっていく。

これでは意識的に運動をする時間を取らなければならない。通勤をやめたのに運動を代わりにするなんてどうなんだろう。しかし計画的に運動を取り入れたほうが身体の柔軟性や体型維持には良さそうであるがやはり時間を確保するのが面倒である。

通勤時間の正味と運動に割り当てる時間を考えれば、運動に割り当てることは十分可能なのだが。

昼食もいけない。ランチタイムは、勤務地の周辺のお店を開拓するのが面白いのだが、在宅勤務となると家で済ますか（ホント済ます的になる）、近所の知ったお店に行くしかない。

ついつい懇意のお店に行きそうになるのは、チェーン店は安定しているからこそ、普段はチャレンジしてお店を開拓したいのである。ときどき勉強代を払ったなと思うこともあるが、一見のお店に入るときの不安感は楽しい。

リモートワークでは、周囲は繁華街ではないからそうしたお店は限られるし、ランチタイムの時間制限もあるから（自由にすれば良いのだけれど）、のんびりもしてられない。気を抜くといつのまにかミーティングスケジュールが入っていることもある。

ミーティングもオンラインになるとアイコンで済ませられる。仕事着に着替えなくてもいける。これも気を抜くと仕事着は意識しなくなり、いざ出勤するときに着ていく服がない状態になりかねない。

家族が出払っているのでリビングには1人である。ちょっとまずいなと思うのはメンバとの雑談がないのである。意識的にslackで「そう言えば…」と振ればいいのだがまだそれは慣れていない。

KOTOKO's GAME SONG COMPLETE BOX「The Bible」(通常盤 10CD)

アーティスト:（アニメCD）
出版社/メーカー: NBCユニバーサル・エンターテイメントジャパン
発売日: 2020/04/21
メディア: CD

KOTOKO's GAME SONG COMPLETE BOX 「The Bible」(初回限定盤 10CD+Blu-ray)

アーティスト:（アニメCD）
出版社/メーカー: NBCユニバーサル・エンターテイメントジャパン
発売日: 2020/04/21
メディア: CD

2020-02-19

エンジニアの頃とプロマネになってからの意識の違い

on エンジニアプロマネリスクコントロール進捗コスト

プロジェクトマネージャをやるようになってから、エンジニアの頃の意識の違いを感じるようになったのは、計画と進捗の実績の較差だな、と思う。

この計画と実績の較差を知りたいと思うのは、プロジェクトはリスクを識別して、コントロールすることが全てだとわかったからである。

進捗、計画と実績の差と言うと、ほとんどのエンジニアは顔を顰めて背けるかもしれない。何しろ、進捗会議や朝会や夕会などで予定の作業は終わったかとチーム全員の前で、現実の進捗を聞かれるのだから。

自分の若い頃は、ろくにテストが進んでいないのに、どうリカバリするかと詰められたくないから、出来ていないことを自ら懺悔などしたくないと思えば、なかなか進んでいないけどオンスケですかね、などと惚けて自分の首を絞めていた。

こんな杜撰な言い訳で煙に巻けるようなプロマネも大概、パチモノか、なんちゃってでしかない。

計画と実績の較差（格差ではない）は、2つのリスクが隠れている。1つは、スケジュールは納期までに収まるのか。もう1つはコストは計画どおりになるのか。

プロマネをするのは、結局のところ、その2つの観点を見ているだけに過ぎない。PMBOKでEVMSだとかなんだとか計算しているのは、プロマネが現場を把握しきれないからで、それを数字で代替しているだけの話である。

いくらプロマネが現場を把握して予実の較差を知るとか、把握できないから数字で把握しようとしても、（過去の自分のように）出来てもいない架空の実績を実績として報告してしまうと、そうした数字はチームとしていくらでも膨張してしまう。

だから工程設計を標準化して、作業ステップのどの作業を終えた（Doneした）のかとか、ステップを加重して計画値と較差を捉えるとかするわけだ。ただ、SIプロジェクトでこれをわかってやっているプロジェクトに出会ったことは過去にそれほどない。ほとんどは、工程設計の標準化をしていないし、することの意味もわかっていないし、知識を持っているプロまねも少ない。

こうした考え方は、理想に過ぎないとか思うかもしれない。だけれど、工程設計を初めからしてあって、たとえ途中で改善することがあったとしても、全くない状態で工程を始めて工程終了直前でダメ出しをされてて戻りするとか、進捗は実はありませんとかテロのようにしれっと現実を知るよりは、1000万倍ましである。プロマネは、アクティビティの実績がリニアになれば、エンジニアからアクティビティにフォーカスできるようになる。

これはエンジニアにとっても同じ価値がある。何しろ、チーム全員が同じプロセスをすることになるが自分の進捗を取り繕う必要から解放される。嘘をつき、それを破綻しないようにする必要がなくなる。それはエンジニアとして向き合うのではなく、アクティビティで会話できるのである。

もう1つのリスクはコストである。これは進捗の予実に密接に結びつく。化石時代のプロマネは予算消化の推移と進捗の予実の較差を紐付けない。だから進捗がオンスケでもコストオーバーランになる。

これは予定の作業時間内で予定したアウトプットが仕上がらなければ、自動的にコストオーバーだと認識するところから始まる。これのコントロールをアクティビティごとにやり過ぎるとプロマネもエンジニアも苦しくなって窒息死する。

だからプロジェクトの工程単位やマイルストーンで括り、バッファをもつ。ここでCCPMの考え方を使うのであるが、それもリスクコントロールのためである。

この2つ目のリスクも大元を辿れば、進捗の較差に収斂することを気づくことができれば、工程設計をあらかじめしておくこと価値に気づけるはずである。

まあ、精神論な化石時代のプロマネではその発想はできないし、嘘をつくようなエンジニアはチームにはいられないのであるが。