If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
アジャイル界隈ではしばしば『許可を求めるな、謝罪せよ』を耳に挟むことがある。チームを成長させたいなら、結果的にメンバに裁量を渡して自律を求めることになる。自分を律して活動するためには、メンバ自身で意思決定して、行動する必要がある。
そうしたことを求めるなら、やることなすこと一々、指示をしたり、やる前に確認をしていては、メンバは許可を与えるリーダに依存することになる。それは、裁量と自律と相反することでしかない。
裁量を与えるということは、自分の頭で考えて、基準に照らしてベターと思う方を実践することを期待しているということの表れなのだから、あれこれと言ってはいけない。
もし、メンバが自分でやったことがリーダの意図相反するのであれば、それはチームの価値観が浸透していないということであり、チームの文化になっていないということである。
リーダのやらねばならないのは、チームの価値観をチーム全員にリマインドすることである。
メンバにとっても、貢献をしたいと思うなら、チームの価値観を踏まえ、エンジニアとして自分で最良と思う選択肢を意思決定して、実践して確かめなければならない。
スピード感を持ち、結果を出したいなら、ことさらである。
やらずにアイデアを説明して理解してもらい、それから手をつけるよりは、やってしまってその結果についてコメントをもらう方が実物があるだけ話が早いし、何より実物があるのだからリーダは意思決定しやすい。
もちろん、小さなロットで、が望ましい。
If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission.
Grace Hopper
（翻訳）それが良いアイデアであれば、先に進んでください。 許可を得るよりも謝罪する方がはるかに簡単です。
Grace HopperはCOBOLの開発者であり、バグを広めた人である。
月刊退職エントリーまとめ（2020年2月）
流石に少ない。
思考と試行のフィードバックループ
これまで何度か失敗のことについて書いてきた。ページの下にある検索窓で『失敗』と入れて検索すれば過去のエントリが出てくる。どれほど失敗好きなのかとも思わなくもないが、人生なんて期待していたような結果になるより、期待していなかったことの方ばかりだ。人生の面白いところは、期待していなかった結果は全てマイナスの結果ばかりではなく、プラスになることも稀にある所だ。
仕事では、失敗はした方がいいということをこれまで何度か書いてきた。それも小さな失敗をして、失敗したやり方を学び、残った選択肢から成功に辿り着こう、と述べてきた。仕事だから失敗をして評価を下げたくないとか、昇進の機会を失いたくないとか、思うかもしれない。それについては誰も否定しないだろうし、結果を選べるなら誰だって成功する方を選ぶだろう。
でも、やっぱり失敗する。これは避けられない。初めてやってみる仕事は失敗の連続でしかない。システムを導入する前には、要件を整理し、運用に機能を適用して実務を設計する。このとき、要件の整理が甘かったり、ボヤケテいると運用自体が間抜けな設計になるし、現実的でない運用を設計すれば使われないシステムが居座るだけである。
そんな失敗にしないために、要件をちゃんとやれとか、運用を設計しろとか言っても正論すぎて、そうですねという感想というか馬耳東風にあしらわれるのが精一杯で、何も産まない。エンジニアであれば誰もがコンサルや第三者から正論ばかり指摘されてうんざりするという経験していると思うが、正論や正義はなんら解決策を産まない。
我々の欲しいものは、価値のある現実解である。その現実解は、労働集約的な要件から思考と試行を必要とする誰も答えを知らない要件に移ってしまった。それにどうアプローチするか、であるがそうした考えは別の人に任せるとして、思考と試行を必要とする要件の現実解を手に入れるためには、次のように取り組むと、試行から思考にフィードバックできるようになり、次に繋げられるので良い。
- 要件は小さくする
- 最小少人数でやる
- 先に、思考する時間枠を決める
- 思考してローンチできるまでを固まった時間でやりきる
要件を小さくするのは小さく失敗をするためである。
最小人数でやるのは、長々と議論をしないとか、意思決定を遅らせないためである。
先に、思考する時間枠を決めるのは、リソースを確保するためである。
ローンチできるまで固った時間でやりきるのは、細切れで断続的に作業をして、失敗がわかるまでの時間を伸ばさないためである。
この他にも、思考するときは紙に描いておしまいにすることも大事だ。清書なんていらない。記録が欲しければスマホで写真を撮って、slackに貼っておけば良い。でも、大事なのは描き残した紙だが、思考の結果があれば、そのまま試行に移れる。間に試作をするのであれば、紙をみて作れば良い。
失敗と気づきと感度の話
人の感度はそれぞれの人ごとにバラバラである。ここで扱う感度とは、事象に対する気づき、受け止め度合い、違和感の感じ方である。
自分の感度について話をするのが良いだろうと思うので自分のことを話すと鈍いと思っている。チームの仲間の発言を聴いて「なるほど」と思ったり、役員の思いの重さを感じて「そこまでプライオリティが高かったの」と考えこんだりする。
逆もある。メンバがスルーするところを止めて「それってスルーでいいのか」と問いかけたりする。特に上手くいかなかったことのリアクションやアクションプランが「それでは再発するだろう」と思うときにそうすることが多い。
専門家ではないので正しいかはかなり怪しいが、それはそうだとして「感度は対象を認知しているか」という度合いで変わるのではないかと経験的に捉えている。
関心を持つことで頭で考える時間が増える。自分で自分に擦り込みし始めることで、今まで視界に入っていても注意を引かなかった対象の輪郭が見えるようになる。例えば今まで欲しいと思っていなかったモノがよく見えると、それまで感じていた以上に身の回りの近いところにあったと気づくようになるのも同じだ。
このことから、仕事で感度を高く持って欲しいとき、ただ感度を上げろと言っても掛け声だけになるのは想定に難くない。掛け声を実現する時間を与えていないからだ。
でもこれでは、どうしてもトリガーを引くのは感度の高い人への依存は変わらない。ここは自分の経験を振り替えるととても難しい。
経験談から言えば、感度が上がる以前と感度が上がった後の間にあるのは、相当の失敗があったからなのだ。その失敗も、責任を負っていたので当時はリカバリに必死であったから、それを二度と繰り返さないようにと敏感になったのである。それを対象ごとにやってられないと思う当たりが感度が低いのかもしれない。それをカバーするのは、経験の機会の小ロットとスピードしかないのかもしれない。
チームは勝手に仲良くならない
チームはいつでも機能しなくなるリスクを持っている。機能しなくなった結果として見える事象は、揉め事を起こしたり、メンバ同士で不仲になったりして、会話が乱暴になったり、当たりがキツくなってきたり、無視をしたり、仕舞いには大きな声を出すこともある。
ここまで進んでしまうと側から見ても何かあったのかなと周囲も気づきはじめるが、すでに手遅れであり、当事者同士の関係の修復は難しい。
こうした揉め事になるで現場のリーダは何を見ているのだろうか。同じワークプレースにいればコミュニケーションは目の前で見ていたはずである。でも、揉め事があるとは認識できずに見過ごしていたことになる。
こうした揉め事の最悪な結果は、関係を修復できずに何方かが、もしくは両方がチームから離れてしまうことである。そこまでにかけたリソースと時間を一瞬に失う。
再発防止の観点で一つ注意しておきたいことがある。それは現場のリーダが起きた事象を事実に基づいて何が起きたかを理解して、何が真因であるかにたどり着けるか、である。
まあ、辿り着けないが。本来であれば現場のリーダも変えた方が良いのだが、リトライしなければ学習する機会もない。
現場のリーダが真因に到達できているかをよく見極めたい。これは、揉め事を起こした当事者とリーダの上司が信頼関係をきづき、当事者に吐露できる環境を作らないと感情的な意見ばかりになってしまう。そうならないようにして、それぞれから見えていた風景を聞き取る。
その上で現場のリーダにどうするつもりかを尋ねる。その対策がコミュニケーションが問題で時間を取るというようなものであったら、リーダは真因に到達していない。そうした勘違いは再び間違いを繰り返す。
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でなぞる必要はないのではないか。
というか、手続きをなぞっていてはいくらシステム更改をしても生産性が上がるのはシステム側の処理の部分だけであって、人の関わる部分は一向に生産性は上がらない。
生産性を向上させたければ、道具を変えて、それに合わせて手続きを減らさなければならない。
この新型コロナウイルスでのリモートワークで現行システムの使いづらさやリモートワークを想定していない業務がわかったはずだ。
そこがシステム更改の糸口だと思っているのだが、実現できるかは中の人次第である。
