アフターCOVID-19の働き方
日本がガラリと変わるのは明治維新や戦後のように外部からの大きな制約を伴ったときにしか起きないのではのと思っている。その点だけにおいて、今回のCOVID-19（新型コロナウイルス）は3回目のスイッチになると考えている。
なぜなら、オンサイトで業務をやってられないし、オンサイトへの移動を制限されるからだ。1-2日目を離しているだけで、韓国やイタリアやイランが日本を抜いている。少し前までは中国、シンガポール、香港、日本の順位だった。
国内でも北海道での罹患者が多く、首都圏も過度な一極集中で潜在的な予備軍は多いだろう。SARSの収束に6ヶ月かかっていたと言われていることから、それを当てはめると2月から7月までは現状のままだ。
その後のアフターCOVID-19の世界はどうなっているのか。COVID-19で変えざるを得なかった働き方は元に戻ってしまうのか。ある意味、働き方改革はCOVID-19で実現されるのかもしれない。
- Zoomの浸透
Zoomに代表されるWebカンファレンス（会議）は参加する場所が事業所から自宅（在宅勤務）まで広がって定着するのだろう。わざわざWebカンためのだけに事業所に通う必要はない。寝起きのままでも、化粧をしなくてもPCやスマホに向かうだけで、カメラをオフにしておけばいい。 - 業務システムのSaaS（クラウド）への転換
例えば稟議の承認を押印でやっているようなところやオンプレでやっているところは、在宅勤務を推進するとなったら、その油断が在宅勤務の障害になることが判明しているはずだ。在宅勤務を推進していながら、押印のために管理職だけは出社を要請しているような組織は、業務フローに自分たちを合わせていると言うような馬鹿げたことをしていることに気づかなければならない。DXを口に出すなら、システムを最短につなげる視点で置き換えなければならない。それを実現しようとすると少なくとも全ての業務システムはクラウド（PaaSでも構わない）上に持っていく必要が出てくる。 - チームのコミュニケーション
在宅勤務になりメンバが物理的に見えなくなる。マネージャが見えないことを不安に思うなら、それはマネージャとメンバの間で何を期待して、何をすることで貢献するかを擦りあっていないと言うことの現れである。常時ハングアウトを上げておくことをマネージャから指示されたら、チームは信頼されていないか、雑談しやすい場をオンラインを介して作ろうとしているかのどちらかである。それを判別するのは、チームに心理的安全性が存在するのかどうかでわかる。 - ご挨拶ミーティングや言った言わない
マネージャを含め、事業所に居なくなるのだから、担当が変わったからとか、ご紹介とかのミーティングもオンラインに切り替わる。それも顧客側が変わったのならその手のミーティングはZoomかslackの場でとなる。特に契約の条件を詰めるようなミーティングであれば、しれっとZoomで録画しておけばいい。逆に提案する側も客バカ度や提案は全て録画しけておけばいい。 - オフィスの見直し
固定席もフリーアドレス席も1/10くらいにできるかもしれない。極端なことを言えば、全員が集まれる大きなフロアと会議室だけで良いかもしれない。 - オンライン研修
集合研修、特に座学での集合研修は馬鹿げていた悪習だったと考えるようになるだろう。ワークショップ型もZoomのルームを使うことで環境は作れるので、後は研修コンテンツの提供側の課題になる。違った見方をすれば、従来の集合研修を提案する研修業者は切るべきで、これを機会に内製にシフトすべきだ。
プロダクトを作る組織にプロジェクトマネジメントは存在しないのか
知り合いと話をしていて、とてもざっくりと括ってしまうのだがプロダクトを作っている組織ではプロジェクトマネジメントのスキルがないと聞いた。
ちょっとそれを聞いたときに頭の上ではてなマークがいくつも生えてきたのだが、本当なのだろうか。
とあるオンラインでの勉強会で質問を受けたときに、スクラムマスターをしている方から、プロジェクトマネジメントも勉強したいと言われていたのを思い出して、どちらが本当なのか、それとも両方とも（後者は直接聞いたことだから前者を含めての意味で）本当のなのだろうか。
仮に、プロダクトを作っている組織でプロジェクトマネジメントの知見は必要なのか、それともプロダクトを作るような事業ではプロジェクトマネジメントのバックグラウンドは不要なのか。
プロジェクトマネジメントは、スコープを扱う。その点でバックログを都度見直して、実現する機能の順番を入れ替え、早いループでリリースするようなアプローチとの相性は合わなそうである。
本来、プロジェクトマネジメントは製造現場と経営を共通の情報を使って、プロジェクトの見通しとリスクを共有するものだ。
それがプロダクトを開発するときのKPIに役割が移っているのだとしたら、そもそもプロジェクトマネジメントに出番はなさそうである。
では、冒頭のプロジェクトマネジメントの知見を得たい人たちは何を得たいと思っているのだろうか。それともインタフェースがKPIになっただけで、KPIでは将来を見通す神通力がないのだろうか。
将来を見通す神通力とは、諸々のアクティビティの中から見つけ出すリスクの識別とコントロールにより制御する行いである。
それをしない代替策こそが短いサイクル、小さなチケット、速いフィードバックループなのではないのだろうか。
進捗は、デイリースタンドアップミーティングで押さえるし、品質はペアプロやTDDで確保するし、HRのリスクは心理的安全性やチームを壊さないなどで担保しているのだし、ステークホルダーマネジメントは開発チームに関係者を最初から巻き込むことでリスクコントロールをする。
だから、プロジェクトマネジメントの知見はいらない、のではなく、散らばしたのだと言うのであれば、それはそれでそう言うアプローチも理解できる（がそれが良いとは言わない）。
さて、プロジェクトマネジメントは不要になったのだろうか。それとも必要な知見のサブセットとしてバラされて、都合よく使われているのだろうか。
ウォーターフォール開発宣言
アジャイルソフトウェア開発宣言というものがある。アジャイル界隈のエンジニアなら何度も読み返していて、暗唱もできるくらいだろう。
実際、この開発宣言は良いことを書いている。『プロセスやツールより 』の下りはソフトウェア開発プロジェクトでは、プロセスやツールは手段であり、達成しなければならないのはプロジェクトの目的の実現なのだから、目的と手段が入れ替わっているようなものだ。
では、これはアジャイル開発だけの洗練な考え方なのかと言えば、そうでもないのでは、と思う。
ソフトウェア開発に気持ちがフォーカスしているエンジニアなら、ウォーターフォールのソフトウェア開発であっても、プロセスやツールに時間を掛けるより、業務オーナの実現したいことに時間を掛けたいと考えているはずだ。
使われないドキュメントより、ソフトウェア開発プロジェクトの目的であるシステムを完成させたいと願っているはずだ。
ただ、プロマネが、声の大きい顧客が言うからと、思考を停止せず、なぜソフトウェア開発プロジェクトがそこに存在するのか、エンジニアとして自分がチームに必要とされているのか、本質を理解しているはずだ。
ソフトウェア開発プロジェクトの目的を理解せず、何で作るかという方に間違った方に走りすぎている周囲のノイズに汚染されてしまっているのではないか。
アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
本来の、ウォーターフォールを適用したソフトウェア開発プロジェクトに立ち戻るためには、エンジニアは次の考えを受け入れなければならないのではないか。
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよいプロジェクトの達成方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。エンジニアの自由や裁量よりも業務オーナと対話を、
使いもしないドキュメントよりも実現に必要なアウトプットを、
リソース調整よりもスコープとの協調を、
実現性のない規程に従うことよりも洗練された作業プロセスのデザインを、価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
『 エンジニアの自由や裁量より』の下りはとても炎上しそうではあるが、アジャイル開発のカンバンで列を区切った瞬間から、作業プロセスはチームで標準化され、それをエンジニアに強制する。
チームで決めた作業プロセスに従わないと言うことはできない。ただ、必要性があるとチームで決めたのなら、作業プロセスの列を変更する自由と裁量はチームに保留されている。
業務オーナとの対話は、要件では表現されない、プログラムでの挙動に落とし込むための情報を確かめるためである。通常、セッション形式で機能を詰めていくのはこのためであり、ここに相応の時間を掛けてToBeの業務で必要な機能仕様を具体化する。
プロジェクトの大小に関わらず、必要なドキュメントは必要であるし、あとあと読も修正もしないドキュメントは作る必要がない。開発のとき、運用で改修するときに必要な中間生産物はネグることはできない。それでも作りたくないなら、エンジニアはそのシステムと心中する覚悟を持つ必要があるが、その代償も大きいことは知っておくべきだ。
QCDSに必要な予算が足らないことで、確保するために奔走したり、説得するのは本末転倒もいいところである。であれば、スコープの調整を行い、必要最小限の価値のある機能を実現する方にリソースをぶち込んだ方が、より生産的である。
チームはなぜ存在するか、ソフトウェア開発プロジェクトはどうしてそこにあるのかをわかっていない外野は、自己のしがらみを押し付けてくる。しばしばソフトウェアの実現性を歪める。であれば、エンジニアは実現性のない規程は、プロジェクトの実現のために正しくテーラリングできなければならない。
リモートワークで炙り出される会議の問題地図
今話題のリモートワークは少し前までテレワークと呼んでいた。そんなことはどうでも良いのだが、リモワになるとますます上手く進まない業務が出てくる。何だかわかるだろうか。会議である。
なんだかんだ20年くらいテレカンやTV会議を経験しているし、2拠点、3拠点もやってきているし、国内にとどまらず海外ともやっているので、遠隔会議のやり辛さは何度も味わっている。
このCOVID-19のお陰で活用されていなかった組織のリモートワークのインフラが日の目を見ることになったのは良いのであるが使い側の経験値がないところに起因する運用の拙さで「やっぱりリモワはダメだ」となるのは不幸でしかない。まあ、うちの組織には影響はしないのだが。
話を戻して、なぜ会議がうまくいかないか。
もともと会議が上手くいっていないだろうと容易に想像がつくという理由はあるのであるが、そうした文化的な背景の上にリモワでのweb会議となると、ファシリテーションも発言者の発言のログも見えるようにしないと何がどうなっているのかわからず迷子になってしまう。さらに、普段からサイレントモードな参加者の存在感はますます無になっていく。
こんなことが事象として起きる。
・今、何を話しているか迷子になりやすい
・オフライン以上に声の大きい発言者の存在感が増す
・内職が進む
・後になってひっくり返りやすくなる
1つ目は、話し手は、常に具体性を持って話さなければ迷子を作りかねない。画面をシェアして資料を説明していても何を話しているかわからなくなる。
なぜなら「ココ、アレ、ソレ」ばかり使って話しているからである。資料のキーワードをポインタで指しながら説明しなければならないし、ファシリテーターは具体性を持って話すように促さなければならない。
2つ目は、参加者は小さい窓に入るか映りもしないのですき勝手にはなすようになる。もともと声の大きい（役職者は）ますます大きく話す。目の前にいないから、注目されているか視線を感じられないのも一因だ。
3つ目は、2つ目に隠れて内職を進める。ミュートしていれば打鍵も聞こえない。
4つ目は、時間で会議から抜けていきやすくなるのと、目配せで意思を促すようなことをしていれば、それもできなくなり、会議のゴールを確認しないで終わりやすくなる。
もともとの会議能力が組織として低いというものがあるのだが。
スピードを優先したソフトウェアで何を得られるか
品質を犠牲にすればソフトウェア開発のスピードは得られるか。
品質を蔑ろにしてスピードは得られるわけがない。品質はその対象が本来備えている特性である。ソフトウェアであれば、要件を構成する機能仕様ではないか。であれば、品質を犠牲にしているソフトウェアには本来備えていなければならない性質が足らないのだから、やることはやらなければならない。
いやいや、犠牲にするとは、その品質として備えていなければならない要件（のうちの機能仕様）の一部を作ることを先送りしているだけ、と言うなら理解できる。ただ、それは機能を犠牲にしているのではなく、機能を段階的に開発しているだけに過ぎず、犠牲は生じていないことになる。
ソフトウェア開発の規模に関わらず品質は、要件のとして存在する。
特に大規模プロジェクト経験したエンジニアは思い出して欲しいのだが、工程の作業プロセスの中にレビューが組み込まれていたはずだ。品質を重視するプロジェクトなら、セルフレビュー、チーム内レビュー、外部レビューなど多段に組み込む。これは作業プロセスの中に品質管理を組み込みことで、作業品質を確保する考えに基づいている。
ついついバグの件数とかに目を奪われがちになるが、本来備えていなければならない要件を機能仕様として備えているかを検証しているのである。言い換えれば、なければならないものを犠牲にすると言う考えはありえない。意思を持って要件から除く以外は。
小さな規模のプロジェクトではどうか。品質を犠牲にしてリリースするとスピードは爆速に得られるか。
要件を備えていないソフトウェアは使われるだろうか。アプリなら、速攻で削除するだろう。あるはずの機能がなくて、使えないのだから。結局、いくら速くリリースできても、使えないものは、直すか捨てるしかない。直すなら、品質を犠牲にして作った時間+直す時間が正味の時間である。捨てるなら、金をドブに捨てたのである。
品質を犠牲にしたソフトウェアで使われ続けたなら、その要件は本来必要とされていなかった要件だ。
新型コロナウイルスで研修事業者は危ないかもしれない
新型コロナウイルスのインパクトで波を打って各種イベントが中止になっている。個人的には、もともと遠隔地で来ることのできない潜在的な参加者予備軍の掘り起こしをするチャンスだと思っている。
どう掘り起こすかは、もともとオフラインで開催しようとしていたイベントをオンラインで流せばいいのである。お手軽にオンラインミーティングの設定と案内をすればいい。
講演者と聴講者が1:Nのオフラインイベントであればそれでいい。あとはsli.deあたりを用意しておいて、QAをやり取りできればオフライン的な運用は実現できる。実際の運用としては、講演者の立場だとリアクションがないから授業のような感じでやりづらいだろう。
技術系イベントでいくつか用意される形態のセッションに（グループ）ワークショップがある。これは如何ともし難い。技術系イベントと同じように組織内研修や外部講師を呼ぶ研修も同じように中止のインパクトを受けるだろう。
特に企業向けに教育を行なっている事業者は、年度末余り予算の掻き入れ時でもあるし、来期の予算化のときでもある。そのタイミングでのこのインパクトは体力にない事業者には辛い。
辛いばかり言ってられないので、実験をしつつオフラインの研修と同じ効果を得られるような研修を仕立てなければならない。
・受講者の顔（リアクション）が見られること
・受講者でグループを組め、共同作業が出来ること
・受講者全体で共有できること
コンテンツがどうであれ、ワークショップをするということは、グループごとに共同でアウトプットさせる作業の経験を体感させたい意図があるはずである。
それをオンラインで実現できる必要性がある。
ここまで考えて、オンラインであるからこそ、NWに依存するという大前提の確認が受講前提になる。オフラインであれば、当日その場にいれば良いが、オンラインでだからネット環境がなければいけない。
在宅となった瞬間に、ハードルが上がるのである。なぜか。家に光やケーブルがなかったり、組織でテザリングできるスマホやwifiを渡していないケースがまだ多いからだ。その意味では、キャリアは最後の需要発掘の機会かもしれない。
シン・ニホン AI×データ時代における日本の再生と人材育成 (NewsPicksパブリッシング)
- 作者:安宅和人
- 出版社/メーカー: NewsPicksパブリッシング
- 発売日: 2020/02/20
- メディア: 単行本
ちょっとした業務要件を決めるステップ
あるバックオフィスの業務チームの定常的な業務を担当したスタッフから、担当した作業がとても大変だったから、次にやるときには改善したいと愚痴をこぼしていたので、じゃあ今度話を聞くからスケジュールを都合のいい所に入れてと。
愚痴をよくよく聞くと、スタッフに業務を依頼した従業員がヒヤリングをして、業務改善をすればいいだけの話であるが、その従業員と話をすると平行線になるのだという。だから、スパッと決めてしまう自分に助けて欲しいという。あまりしがらみも何も考えずに『いいよ』という。
そのスタッフには、1つだけさらりと『その大変だった問題点を手書きでいいから書き出しておいて』とお願いをしておく。
スケジュールの日時に打ち合わせスペースに集まると、そのスタッフは書き出してくれた問題点の紙を全てホワイトボードに張り出してくれた。ここで、先に従業員に釘をさす。『スタッフが問題点を出してくれた。あなたも今回の業務で問題点を感じたに違いない。なぜなら、スタッフに作業指示をしていたからだ。だから、あなたの目線での問題も教えて欲しい』と付箋紙とサインペンを渡す。
まずは、スタッフから『問題点』を全部聞く。ここは相手も質問も後回しに、全部問題点を聞く。なぜなら、一度全部問題点を聞かなければ、ひとつはこの人（自分）もスタッフの不満を聞いてくれないと思うからだ。もう1つは、わざわざ書き出してくれと頼んだのは自分である。
次に従業員の問題点を聞く。前準備をしていないからか、それともかは知らないが、数枚しかない。それも具体性も問題の本質もない。
それはさておき、業務のスタッフであるから、困っていることを切実に話してくれる。どの作業でどう大変だったか、なぜ大変だったかを熱心に語る。
そこまで受け止めて、一番大変で最初に解決したいことは何かを尋ねる。
全部の話を聞いたこと、一番大変な問題は何かを尋ねることで、信頼と実際に解決したいことは何かを一緒に進める気のあることを伝える。
問題点の上がった業務は、実は2つの業務に分かれていて、その片方をなんとかしたいという。
話を聴きながら、ホワイトボードにas isを簡略化したチャートで描く。チャートを描くことで、空中戦をさせない。あと、写真を撮っておくことでスタッフと従業員の間で何を話したかをエビデンスとして残す。
問題点を聞き、チャートに描くと、業務スタッフも従業員も前回のやり方を『正しい・変えられない』と勝手に思い込んでいる。
では、全くの制限を受けない理想の作業はどうであればいいかと質問を出す。
端的に言えば、問題は与えられるデータの不正確性である。それもコントロールできない他チームでそのデータを新規レコードも更新も行われている。as isの話を聞いていると正確なデータをこの業務を行なっているチームでも入手できるし、タイミング的にも問題なさそうである。
ここを確認したのは、業務として改善するときの実現性の裏付けをとったのである。
ここまで話をすると業務改善の要件を出し切っている。
- 問題点
- 実現したい業務
- 関連チームへの申し入れ事項
あとは、これらを業務スタッフか従業員が1枚のピッチに言語化してくれれば、それを持って他チームへ相談すればいい。
- 困っていることをきく。
- 制限のない状態で理想を描く。
- 要件として言語化する。
他にも諸々の問題点があるが、一番に解決したい業務上の問題の要件を決めることにそれほど高度なスキルはいらない。
