失敗と気づきと感度の話
人の感度はそれぞれの人ごとにバラバラである。ここで扱う感度とは、事象に対する気づき、受け止め度合い、違和感の感じ方である。
自分の感度について話をするのが良いだろうと思うので自分のことを話すと鈍いと思っている。チームの仲間の発言を聴いて「なるほど」と思ったり、役員の思いの重さを感じて「そこまでプライオリティが高かったの」と考えこんだりする。
逆もある。メンバがスルーするところを止めて「それってスルーでいいのか」と問いかけたりする。特に上手くいかなかったことのリアクションやアクションプランが「それでは再発するだろう」と思うときにそうすることが多い。
専門家ではないので正しいかはかなり怪しいが、それはそうだとして「感度は対象を認知しているか」という度合いで変わるのではないかと経験的に捉えている。
関心を持つことで頭で考える時間が増える。自分で自分に擦り込みし始めることで、今まで視界に入っていても注意を引かなかった対象の輪郭が見えるようになる。例えば今まで欲しいと思っていなかったモノがよく見えると、それまで感じていた以上に身の回りの近いところにあったと気づくようになるのも同じだ。
このことから、仕事で感度を高く持って欲しいとき、ただ感度を上げろと言っても掛け声だけになるのは想定に難くない。掛け声を実現する時間を与えていないからだ。
でもこれでは、どうしてもトリガーを引くのは感度の高い人への依存は変わらない。ここは自分の経験を振り替えるととても難しい。
経験談から言えば、感度が上がる以前と感度が上がった後の間にあるのは、相当の失敗があったからなのだ。その失敗も、責任を負っていたので当時はリカバリに必死であったから、それを二度と繰り返さないようにと敏感になったのである。それを対象ごとにやってられないと思う当たりが感度が低いのかもしれない。それをカバーするのは、経験の機会の小ロットとスピードしかないのかもしれない。
チームは勝手に仲良くならない
チームはいつでも機能しなくなるリスクを持っている。機能しなくなった結果として見える事象は、揉め事を起こしたり、メンバ同士で不仲になったりして、会話が乱暴になったり、当たりがキツくなってきたり、無視をしたり、仕舞いには大きな声を出すこともある。
ここまで進んでしまうと側から見ても何かあったのかなと周囲も気づきはじめるが、すでに手遅れであり、当事者同士の関係の修復は難しい。
こうした揉め事になるで現場のリーダは何を見ているのだろうか。同じワークプレースにいればコミュニケーションは目の前で見ていたはずである。でも、揉め事があるとは認識できずに見過ごしていたことになる。
こうした揉め事の最悪な結果は、関係を修復できずに何方かが、もしくは両方がチームから離れてしまうことである。そこまでにかけたリソースと時間を一瞬に失う。
再発防止の観点で一つ注意しておきたいことがある。それは現場のリーダが起きた事象を事実に基づいて何が起きたかを理解して、何が真因であるかにたどり着けるか、である。
まあ、辿り着けないが。本来であれば現場のリーダも変えた方が良いのだが、リトライしなければ学習する機会もない。
現場のリーダが真因に到達できているかをよく見極めたい。これは、揉め事を起こした当事者とリーダの上司が信頼関係をきづき、当事者に吐露できる環境を作らないと感情的な意見ばかりになってしまう。そうならないようにして、それぞれから見えていた風景を聞き取る。
その上で現場のリーダにどうするつもりかを尋ねる。その対策がコミュニケーションが問題で時間を取るというようなものであったら、リーダは真因に到達していない。そうした勘違いは再び間違いを繰り返す。
Zoomを使うときにあるといいマイクスピーカー
掛け声ばかりで実態が進んでいなかった「働き方改革」がCOVIDー19、新型コロナウイルスの余波を受けてスイッチが入った。半ば強制的にリモートワークをせざるを得ない状況になったことで、本来のライフスタイルに沿った働き方を進めるしか選択肢がなくなった。客観的に眺めていると日本人は外部からの制約でしか変われないのだなと思う一方、変わるときには変われるのだとも思う。
それはさておき、webカン、テレビ会議である。日常的にオンラインを含めた（オンオフ両方やオンだけ）会議に慣れているというのもあるのかもしれない。なにぶんにも長くエンジニアをやっているとins+ポリコムで遠隔地3拠点の会議を2000年前後には経験しているので、何だかんだ20年以上テレビ会議をユーザの立場で経験していることになる。
最近Zoomで採用面談をしたときに、とても普通に会話できているなと思ったのが印象に残った。画面を介してるからそこに候補者はいないのだが、距離感が近かった。多分に候補者のキャラ的な部分もあるのだろうが、それでも表情やニュアンスが読み取れるような気がした。
仕事で手近で使えるWebカンのサービスは、hangoutかZoomだろう。このCOVIDー19で急に存在感を感じているのはZoomだ。Zoomは2年くらい前にさわる機会があったが、画質の粗さが気になったのと、そのくらいの画質ならFacebookのミーティングかhangoutでいいじゃんと思って放置してた。まあ、先見の明がなかったわけだ。
もし両方使えるとするなら、今のところはこんな使い分けしたい。画面で資料共有をするならhangoutで会話をするならZoomに。Zoomは低回線でも使える反面、画面がぼやける。リアルタイムで議論をグラフィックして共有するならZoomでもいける。今のところはスプレッドシートやスライドの混み入った資料には向かない。
インタラクティブにミーティングをするならZoomのほうが使いやすい。画面のトップなり、右にサイドバーのように表示できる。hangoutで出席者を上手く表示したいなら、PCのカメラではなく、Lenovoの360度カメラが割といける。マイクはヤマハがクリアに聞こえる。
従来型のシステム更改の終焉
事業会社のIT企画部門のエンジニアもSIerの提案するエンジニアも感じていることだと思うのだが、リプレース案件はなかなか組織の稟議が進まない。考えに考え抜いて、付加価値とコストダウンを混ぜ込み、サポート期限に冷や冷やしながら稟議のスタンプラリーをする。
コストカットも万策尽きたところで金融や政府がawsやgcpに移し始めたので、それを論拠にクラウドに移行して固定費の面だけでもコストカットをしたことにする。
さて、次の更改は何を費用対効果の旗印に稟議を回すのか。
もう、従来型のシステム更改、つまり業務の機械化、OA化の焼き直しはお終いなのだと思う。pcやタブレットをダム端末のように使って、業務の手続きを電子化することは。
ここでdxに発想が置き換わらないといけないのだが、相変わらずプロダクトアウトの説明か業務の機械化の焼き直しにしかならない。
IT企画部門の中のエンジニアもそうだし、ベンダーの提案もそんな感じである。
デバイスの種類は増えたし、情報として処理するデータへのアクセス方法も増えているのではないか。
だったら、いちいち業務の手続きをITでなぞる必要はないのではないか。
というか、手続きをなぞっていてはいくらシステム更改をしても生産性が上がるのはシステム側の処理の部分だけであって、人の関わる部分は一向に生産性は上がらない。
生産性を向上させたければ、道具を変えて、それに合わせて手続きを減らさなければならない。
この新型コロナウイルスでのリモートワークで現行システムの使いづらさやリモートワークを想定していない業務がわかったはずだ。
そこがシステム更改の糸口だと思っているのだが、実現できるかは中の人次第である。
アフター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に必要な予算が足らないことで、確保するために奔走したり、説得するのは本末転倒もいいところである。であれば、スコープの調整を行い、必要最小限の価値のある機能を実現する方にリソースをぶち込んだ方が、より生産的である。
チームはなぜ存在するか、ソフトウェア開発プロジェクトはどうしてそこにあるのかをわかっていない外野は、自己のしがらみを押し付けてくる。しばしばソフトウェアの実現性を歪める。であれば、エンジニアは実現性のない規程は、プロジェクトの実現のために正しくテーラリングできなければならない。
