00:05
はい、4月3日月曜日ですね。
時刻は朝9時13分になりました。
今日は、すいません。ちなみにこれ僕、記事今読んでるんですけど、
あれですね、最初のキービジュアルの画像がですね、もう傘がブワーッと散ってるやつなんですけど、
僕、傘めちゃめちゃ好きなので、
いや、この画像すごいいいなと思いました。
これそのまま使いたいぐらいですけどね。
はい、すいません、余談です。
じゃあ行きましょう、本題ですね。
こんにちは、プロセスについて大論争をちょっと掘り下げていきたいと思います。
プロセスとは、組織内の混乱を解決するものなのでしょうか?
物事を実現するために優れた規律とオペレーションを適用する方法なんでしょうか?
それともプロセスそのものが問題でオーバーヘッドを増やし、
人々が最高の仕事をするのを邪魔しているんじゃないでしょうか?みたいな問いがありますと。
プロセスのメリットを維持しつつ、デメリットのほとんど排除した管理方法があるということを今回は主張したいと思います。
おそらくこれまでに見たこともないような方法でしょう。
そしてこの方法を導入する方法。
またこの方法で運用するためのルール。
そして驚くべき利点のいくつかを説明していきたいなと思っております。
はいわかりました。
じゃあ一個一個入っていきましょう。
まず一つ目はプロセス is how we work together ですね。
プロセスとは私たちが一緒に働く方法というところですね。
いきますかね。
プロセスについて最初に認識すべきことっていうのは、
あなたが認めるかどうかに関わらずプロセスは既に存在しているということです。
プロセスとは私たちが一緒に仕事をする方法になります。
プロセスは名刺的に書き記すこともできます。
また暗黙の了解としてチームとして特定の方法で仕事をすることに慣れている人が理解できるものであることもあります。
プロセスとはあるグループの人々が一致団結しているものです。
物事がどのように機能するか全員が同意しています。
あるいは人々が本当に同意していないものである場合もあります。
物事がどのように行われるかについて異なる考えを持っているかもしれません。
プロセスとは人々が集団で働くためのものですからプロセスに反対するのは正直無意味なことです。
だからといって人々が挑戦するのはやめることもできません。
しかし本当の問題は私たちが一緒に仕事をする方法をどのように形作り定義するかということになります。
では続いて次の章はプロセス can be problematic ですね。
プロセスに問題がある場合がありますよという話です。
プロセスに対する反対意見の多くはプロセスに対する人々の嫌な体験から来るものです。
これはもちろん当然なことであります。
プロセスはソースコードのようなもので注意を払わないともちろん劣化をし問題を引き起こす可能性ももちろんあります。
プロセスの問題点はプロセス自体に寿命もあることです。
ほーん、プロセスに寿命って意識したことないしそんなワードを考えたことがなかったんで。
これちょっと面白いですね。
例えばあるソフトウェアエンジニアリングチームが新しい仕事だけに集中し
サポートチームから送られてくるバグに全く手をつけていないといたしましょうと。
そのような過程に至ったときに、なぜこのようなことが起こるかと。
もっと深く調べるべきだろうということは無視して
03:02
この問題に対してプロセス対応することにしてみましょうと。
意外とそれができてしまうんですよねっていう話をしています。
今回とりあえず3つステップがあるそうですね。
1つ目はエンジニアリングマネージャーとプロダクトマネージャーに
スプリントごとにいくつかのバグを予定することを決めてもらうと。
2つ目にオンコール担当者がオンコールしている週のバグをチームで行うことを決めますと。
3つ目にバグに関するSLAを追加しましょうと。
どのような決定であれ、あなたは問題を発見し将来その問題に対処するためにチームの行動を変えているんです。
これがプロセスワークですと。
最初にスケジューリングをするって結構難しいというか
エイヤーでやるしかないでしょうけども。
大変だと思いますけどね。
またそういうのをエンジニアリングマネージャーとかプロダクトマネージャーに決定してもらわないといけない。
スプリント中にバグが起きることの可能性を決めてほしいと。
結構難しいし、それの見積もりもなかなか大変ですよね。
とはいえ、その後でさらにどれくらい起きる予想をしておいて
その数字に対してどれくらいコミット、人員を割り当てるかっていうところがまた難しいですよね。
あとはそのSLAを決めていくと。
言ってることはわかるが、今のところ僕は怪異的になってしまったな。
これいけるのかな?
実際この方はそれでやれたって言ってるのからそうなのかもしれないですね。
やったことないものについてどうなんだろうっていうのは僕の中ではNGなんで。
とりあえず今回はこの記者の方の体験を読んでみましょうかね。
そこでエンジニアリングマネージャーとプロダクトマネージャーが
週に一度サポート担当者とミーティングを行って
毎週最も重要なバグに優先順位を受け付けると決めたとします。
ミーティングを設定すると毎週開催されるようになります。
問題は2年後、問題が進化しているかもしれないということです。
2年後はなぜ2年後なのかちょっと置いといて。
そしてそのプロセスを作った人たちもその場にいないかもしれません。
つまり2年後にその会議に関わった人たちは
その会議が解決しようとした問題を理解できていないかもしれないですよと。
2年後の当事者はわからなくなるかもしれないですね。
結果秘伝の谷になったりとかここは正規だみたいなことになりかねないですけど。
プロセスの起源に関するこのような不確実性というのは
人々が物事を変更することに消極的になる可能性があります。
おっしゃる通りです。
特にそのプロセスが重要なものであったり
危険と思われるものであったりする場合は特にそうですよと。
そのためプロセスはそれ自体の生命を持ち
一種のゾンビのように動作することがあります。
そしてたとえそれが悪いことであっても有害であっても
人々はそれに従わなければならないからですよと。
繰り返しますがこれはレガシーコードのようなものです。
動作はするのですけどいつ触っても他の問題を起こす危険性があるのです。
だから大抵の人は触らないようにしていますと。
今のプログラミングの話をたとえに出されていましたけど
いろんな物事のプロセスについては同じことがあるということですよね。
面白いとか興味深いのはこの話とかこの手の問題って
個人的には日本ばっかりなのかなというふうに思ったんですけど
この筆者の方は全然海外の方だし
海外の現場での起きた話を今しているというので
結果やっぱみんな同じようなことをやるんですねっていう感じですかね。
常に決まっているとか今走っているプロセスを変えたりするとか
そこに対してどうなのっていうのを話をすることができなくなってくる。
06:02
当事者がいないからですよね。
っていうのは本当によくある話なんだなっていうので
いやーなかなか興味深いなと思いましたこれは。
だからこそエイヤーで誰かやれる人っていうのは結構大事かもしれないですけどね。
批判も大きいでしょうけどでも変えないより変えた方が
得られるものは大きいと思うんですけどね。
とはいえビジネスインパクトとかあったりするんで
なかなかそのバランスを取るのは難しいかもしれないですけど。
はいじゃあ続いて。続いてはWhat if process were fluid and dynamic?
もしプロセスが流動的もしくはダイナミックだったらどうでしょうか?
というところの話です。
理想的なプロセスではどんなものでしょうか?
っていうのを投げてみたいと。
1,2,3,4、4項目一応書いてますね。
1つ目がまず流動的でダイナミックに感じられるものでしょうと。
組織のニーズにも適応しやすかったりするでしょう。
2つ目には良い文脈を内部に埋め込むことができると。
これによって変更が容易になりますと。
3つ目は明確で簡潔で最新であると。
はいいい話ですね。最新であるというのは本当にいい話だし。
簡潔というのもすごく大事ですよね。
最後4つ目は真実の源であり信頼ができるというところですね。
ああいいですね。情報の信頼性もちゃんと考慮しておくというのは確かにいい話だと思いますね。
まあ確かここまで揃っていれば確かに理想的なプロセスかもしれないですね。
はいでは続いて。
Treat your process like codeですね。
はいまずソースコードのようにプロセスを扱っていきましょうと。
つまりですねさっきの言葉は印象と言い換えてみると
良いプロセスとは良いコードと少し似ていますよというふうにおっしゃってます。
それについて5項目が語られてますね。
1つ目は簡単に更新することができると。はいはいいいですね。
2つ目にバージョン管理ができる。バージョン管理も可能で
時間の経過とともにどのように変化してきたかというのも知ることができる。
履歴情報というのもちゃんと充実していますと。はいこれ2つ目。
3つ目は変更にかかるコストを最小限抑えることができる。
4つ目になぜそのプロセスが存在し何をしようとしているのか
などが分かる良い文脈というのを持っていますと。
ラスト5つ目プロセスとは物事がどのように機能するかを説明するものですね。
はいはいはい。めちゃめちゃソースコードの話をしているように聞こえますね。
こうやって読むと。
いいとこれはプロセスの話で少しコードと似てますと言うけど
全然少しじゃない気がしました。
続いてソリューションですね。オープンソースプロセスと。
そういうのをオープンソースプロセス化してしましょうということですね。
はいじゃあ組織のニーズの変化に対応できる柔軟なプロセスを実現するにはどうすればいいんでしょうかというところですけど
私が見つけた最良の解決策っていうのはプロセスをオープンソース化することになりますと。
自分たちのやり方とかノウハウプロセスっていうのを外に公開してしまうところですね。
でプロセスを書き出し誰でも変更を提案できるようにしましょうと。
会社の運営方法を変えることができると善に伝えましょう。
これは大変な作業ですけど非常に明確なものにもなります。
そして私たちの仕事のやり方が書かれていると言えると力が湧いてきますと。
そして誰でもそれを変更することもできるようになると。
続いて文字文化のメリットですね。
ちゃんとテキストドキュメントで起こしましょうと。
それのメリットですね。
09:00
プロセスを書き出すことっていうのは文字文化のある組織の書くとなる習慣になります。
そして書き留めることは多くの利点がありますと。
主に3つですね。
書くことはより明確な思考である正確さが要求されます。
それは明瞭さを提供することにもなります。
書くことっていうのは非同期でいつでも利用できます。
3つ目、書くことは情報を共有するために会議を必要としないのでよりスケーラブルです。
そんなためにですね、分散したチームっていうのは結構文章作成が適していますし、
いいんじゃないのということですけど、主な欠点はそのドキュメントを維持するのに努力とかコストが必要なことです。
そりゃそうだよね。
欠点っていうかこれはもう不可分なのでやるしかない話ですよね。
ただやったメリットの方が絶対的に大きいのでこれはやった方がいいという感じですね。
明確であることとか非同期でいつでも誰でもアクセスできるようになると。
情報を共有するので、場合によっては会議も必要としなかったりスケーラブルにできるという話ですね。
とてもいい話だと思いました。
続いていきましょう。
How to open source your process on engineering handbookっていうのが次での話ですね。
プロセスをオープンソース化する方法。
エンジニアリングハンドブックっていうタイトルそのままですね。
どのようにすれば文書文化っていうのを構築し、
組織のために柔軟で保守可能なプロセスを作り上げることができるんでしょうかというところですけど、
エンジニアリングハンドブックっていうのを作りましょう。
これはあなたの組織で物事がどのように動くかを示すリポジトリになりますと。
これはプロセスの文書化っていうのはそのまま意味していますよねと。
私はこの作業を何度も何度も行ってきました。
ここでは私が推奨する一般的なステップというのをちょっと紹介していこうと思います。
一個一個いきましょう。
1つ目はChoose the format for your engineering handbook。
まずはその形式ですね。フォーマットを選びましょう。
最初に直面する課題っていうのはプロセス文書をどこに保管するかということになります。
私は完璧に機能するものを見つけたことはありません。
従業員ハンドブックに。
続いて2つ目はBootstrap the contentsですね。
コンテンツをBootstrapしましょうということです。
次にすることはコンテンツの記入を始めることです。
プロセスに遭遇したらいつでも簡単にでも書いてください。
現在どのように動いているのかということ細かく書きましょう。
これは特に組織に参加するときにも有効。いわゆるオンボーディングですね。
この書き込みを利用して物事の仕組みを明確にすることもできます。
自分の書いたものを人に見せてそれが正しいかどうかというのを聞くこともできる。
これで認識の速度を測ることもできる感じですよね。
いい話ですね。
あとは情報の対照性ですよね。
みんなが持っている情報が果たして差があるかどうかというところも是正できたりしますからね。
これを2、3ヶ月続けてからさらに展開することになるかもしれません。
組織的な変更を行う際にはそれを文書化し変更前と変更後のセクションを用意しましょう。
変更した後は変更前のセクションをドキュメントの履歴の部分に入れ、
時間の経過と共に私たちのプロセスがどのように進化していくかを見てもらいましょう。
プロセスドキュメントの旧バージョンがどこに眠っているかということはよくあるかたちですけど、
それら不完全であったりメンテナンスされていなかったりするかもしれません。
12:00
それは往々にしてあるでしょうね。
しかしそれらはこのプロセスの多くをショートカットすることもできます。
それらを整理してメンテナンスを始めましょう。
対話できる十分なコンテンツがあるというのはとても重要なことです。
それはこの練習に、プラクティスに勢いがあり真剣に取り組んでもらえるということを示すものにもなります。
そうすることで人々は自分の時間をそれに投資することができるんですよというので。
はい、なるほどね。コンテンツをブートストラップするという話でした。
では続きましてステップ3ですね。ステップ3はChoose a Maintainerですね。
Choose a Maintainerなんですけど、It's probably youです。
おそらくあなたでしょうねという話ですね。
これらのプロセス文書が真剣に取り組まれていることを確認する人が必要になります。
もちろん更新され、整理されていることを確認するんですよ。
助けを求めることもできますが、最終的にはこの文書に投資してくれる人が必要です。
これは簡単に認定できることではないかもしれません。
理想は経営人全員が真剣に取り組んでいることでモデル化していいから、もっと大勢の人に手伝ってもらうことですと言っています。
こういうのはやっぱり多くの人に手伝ってもらうと本当にいい話だと思います。
いろんな現場の、いろんな文脈の人、いろんなキャップをかぶっている人が関わっているはずなので、
その人たちのちゃんとドキュメントを書くと本当にいい話なので、経営人だけじゃない方が本当にいいと思いますね。
ただ経営人は経営人で、自分たちの意思決定の文脈だったりプロセスだったり、
どういう背景なのかというところをコンテキストとかを伝える必要ももちろんあると思いますけど、
両方がちゃんとそこに取り組んでいきましょうという話ですね。
続いて4つ目。ステップ4は、続いてそれに付随したルールスフォープロセスですね。
プロセスに関する、今度はルールの話ですね。
プロセスドキュメントのルールはどのようになっているでしょうかと。
ここで私が気に入っているものをちょっと紹介してみようということですね。
大きく3つ、4つぐらいですかね。
はいはい。一個一個言っていきましょう。
1つ目はReply with Documentですね。
ドキュメントを添付してまず返信するというのが1つ目でした。
まず共有したいのは、文書で返信するという考え方です。
私は通常エンジニアリングチーム全体とかオールエンジニアリングミーティングとか、
やっぱりいいな。オールエンジニアリングミーティングってやっぱり俺らも欲しいな。
または組織へのニュースレターで共有します。
そして私自身もそれをモデルにしてみますと。
文書で返信するというのはつまりどういうことでしょうかというところでいくと、
誰かがあなたに質問したとき、理想的にはその質問に答えるURLを返信したいものですよと。
まあまあそうね。これ見とけよって感じですよ。
そのためにウィキにアクセスして答えがないことを確認しない場合は追加をします。
そしてそのURLを相手に送ると。一回自分でも確認していくことですね。
これには二つの意味がありますと。
一つ目は将来あなたが回答しなくてもその質問に答えるかできるようにしますということですね。
二つ目は質問者は将来的な質問に対する答えをどこで見つけることができるかというのを学ぶこともできますと。
いいですね。お互いの個数を奪わなくするということですね。
文書で返信することっていうのは人々があなたに尋ねるかもしれない全ての質問の前にキャッシュ層を置くことですと。
ああそうね。あなたの専門知識がより広く利用できるようになるですよということですね。
組織にとって文章で返信することのインパクトっていうのは回答が将来に当たって保証されることになりますと。
質問に100万回答えるのではなくて一回しか答える必要がないようにするのです。
15:00
その場しのぎではなく体系的に問題解決することができるのです。
だからこそドキュメントはマジで重要ですよねということですね。
将来本当に使わなくてよいコストをどんどんどんどん削減できるのでね。
はいでは二つ目ですね。
二つ目のやり方、ルールはですね。
It's not official until it's in the handbookですね。
ハンドブックに掲載されるまでは正式なもんじゃないよという。
はい、口頭とかなんかチャットでやったものは正式なもんじゃないということですね。
これも結構大事なルールですね。
次のルールは私が経営人に対して何度も何度も繰り返していることです。
ハンドブックに載せるまでは正式なもんじゃないと。
私はマネージャーが変革を行うとき、あるいは計画を展開するときには必ずその計画にURLを記載する必要があるというふうに言ってますと。
例えばチームは2週間のスプリントに移行してるんですけど、
それはハンドブックに書かれているはずですけどどうなんですかっていうところですね。
もしくは誰かが別のチームに移動するんですかと。
そのチームの人のリストがハンドブックにもあるはずですよねみたいな。
例えばこういう例ですね。
このルールが重要なのはそうでなければハンドブックが真実の情報源ではなくなってしまうからですね。
要は信頼がなくなるってことですよね。
かつ最新でもないってことですよねこれ。
ってことはこれでいつの情報なの?
これは本当に正しいの?みたいな疑いから入らなきゃいけなくなるってことですね。
そうでなければハンドブックは真実の源でなくなってしまう。
そうするとハンドブックへの信頼が低下し有用な情報源ではなくなってしまいます。
しかしこの制約を加えることでハンドブックに書かれていることが真実となるのです。
プロセスドキュメントを最新の状態に保つことを重視するならばこれは完全に必要なルールです。
いわゆるミーティングとかの場におけるグランドルールですね。
絶対みんなが守るべきルールですというところ。
これを決めるってのは本当に大事ですね。
とにかく正しい情報、正確なもの、正式なものっていうのはドキュメントに書かれているものだけにする。
例えばプロジェクトマネジャーやプロダクトオーナーとかクライアントとかいろんな人たちが話して
ステークホルダーと喋って意思決定したものを下ろしてくると。
下ろすけどお前がドキュメントに書いてなかったらそれは正しくないというふうにみんなを認識して良いというふうにすると思います。
もちろんバッティングが起きるし、でも結果それをやった責任はオーナーとかマネージャーに行くので別に良いと思っています。
これは僕すごく良いルールだと思いました。
ある意味みんながちゃんと統一されたルールの下で動いていくというところがあるので
しっかり意思疎通が取れた組織になるんじゃないかなと思っています。
続いて3つ目のルールです。
3つ目はプロセス文書の編集だけでは変更にならない。
私が共有している3つ目のルールは文書を編集しただけでは人に何かをさせることはできないというルールです。
それは人間の働き方とは違うカラーになります。
しかしそうでなければ多くの人がそれを試みてしまうのでこのルールはもちろん必要になります。
変更の仕組みについて説明するページももちろん必要です。
私は通常仕事のやり方を変える方法のようなものを呼びます。
ちなみにそれを説明しましょう。
大きく4つあります。
1つ目、ハンドブックのメンテナーが誰なんでしょうか。
2つ目、誰でも変更を加えることができるよということですね。
3つ目、ウィキの編集だけで物事がどう動くかを決めることはできないということですね。
例えばコミュニケーションを取ったりとか適切な人たちから賛同を得なければならないとか。
18:01
しかし改善は推奨され、プロセスは流動的であるべきということですね。
最後4つ目、権力のヒエラルキーはまだ存在していること。
誰でも改善を行うことができるが、最終的にはエンジニアリング担当副社長みたいな肩書を持った人が組織全体にこれらの決定を委ねることになります。
これはむしろあった方がいいんだ。ヒエラルキーが存在していることって。
これはオープンソース、OSSではありえないことだと思いますね。
でも組織とか人の行いのところに関してこれを残すな、チェックし何も変更がなかったっていうのをやる、
リリースノートで書くことってすごくいいことだと思いました。
どうせ人間は忘れていける気分ですからね。
続いて4つ目のルールです。
4つ目はプロセスは文脈と歴史を含むべきですよと。
共感しかないなこれ。
プロセスページのテンプレートとして文脈や歴史のセクションを明示的に含むものが必要でしょうと。
これは余分なオーバーヘッドのように感じられるかもしれません。
しかしこれは役に立つんですよと。
実施するプロセスを正当化した状況を明示的に呼び出すことができます。
また時にはこの方法が役に立たなくなった時や、この方法を見直したくなった時にも言及することができます。
その履歴を追加することで、時間の経過とともに変化してきたことを理解することもできます。
いいですね。
このチームはどうやって動いてきたのか、どういう変更があったのかっていうのを見ていくと、
今なんでこんなチームになったか、こういう文化とかになっているのを知ることもできますね。
またこのコンテキストは将来の変更をどのように形成するかを理解するのにも役立ちますよね。
やっぱり歴史を勉強するのってすごく大事なことですよね。
日本史・世界史もそうですけど、やっぱり人って同じことを繰り返したりしますけど、
歴史から何かを学ぶことって本当にたくさんあるんで、
今後はやっぱり僕は日本史・世界史をプライベートで勉強しようかなと思いました。
はい、じゃあ続いて。
Take it to the next levelですね。
次のレベルへ。とりあえず公開しましょう。Make it publicってことですね。
エンジニアリングハンドブックを展開して成功を収めたのであれば、
次の段階として全世界に公開することを検討してみていかがでしょうか。
つまり社内だけで社外へまで公開しましょう。
これ結構求心的なステップであり、おそらく多くの企業では適さないでしょう。
またこのアイデアに賛同してくれる人を集めるのは正直難しいかもしれません。
しかしこれにはいくつかの利点がもちろんありますので、大きく3つ書かれてますね。
1つ目。あなたは自分の組織を世界に向けてマーケティングしているんですよ。
候補者を引き付けることができ、候補者はあなたの組織がいかにうまく運営されているか
っていうのをどのような原則に基づいて組織されているかっていうのを見ることもできます。
いいですね。将来のファンを増やすってことですね。
2つ目。公開された聴取を持つことっていうのは自動的にプロセスの質を高める結果にもなります。
自分のチームのプロセスを全世界の人が見ることができるのであれば、
より良い記事を書くことができるんじゃないでしょうかってことですね。
3つ目。プロセスをオープンにすることは他の人があなたから学ぶことにもつながります。
お互いの学びにもなりそうですよね。これが結構いい話ですよね。
まさにオープンソースってそこにあると思うので。
これを実践している会社として最も注目されているのがGitLabですね。
GitLabのハンドブックは会社の運営マニュアルであり非常によくできてます。
21:02
ちゃんとGitLabハンドブックっていうのもリンク貼られてました。
というところでラスト、サンキューですね。結論ではなくて最後は謝辞で終わりますね。
はい。ニューレリックのプロセスとかGitHubに置くみたいなアイディアと実践を思いつきました。
そのプロセスそのものをGitHubとかに置いたりとか、GitHubのプロセスの意味でのことですね。
ニューレリックのプロセスドキュメントで数年間私のパートナー、
結構ニューレリックのこのプロセスドキュメントがかなりこの方には参考になったらしいですね。
ニューレリックはちなみにそのプロセスドキュメントをGitHubに置いてるっぽいですね。
ちょっとじゃあ後でニューレリックのGitHubリポジトリ、もし見つかるんだったら探してみましょうか。
その中にはエンジニアリングハンドブックだったりとか、実践方法、役割、標準等も公開してるらしいのでちょっと見たくなりましたね。
というところで今回の記事は締められておりました。
いかがだったでしょうか。ちょっとすみません。僕が朝開始が遅かったのでだいぶ後ろ倒しになってしまいましたけど、
今日の朝活はこちらで以上にしたいと思います。
とてもすごく面白い記事でしたね。なかなか読み応えもあるし、本当に評価も多かったし、
物事を進めるというにはやっぱりいろんな準備も必要だし、いろんなものを考えなきゃいけないんですけど、
それが重なってちゃんとチームと組織として回るんだなってことをつくづく感じました。
皆さんも読んでいただければ幸いですというところで、後ほどこれツイートしますので見てみてください。
今日から4月1発目ですね。いろんな会社さんが今日から4月スタートと思いますし、新しい機が始まる会社さんも多いと思います。
また今日から新増社員がガッと入ってくる会社さんもすごく多いと思いますので、本当に既存社員も新入社員も新社会人の方々ですね。
いろんな方が今日からまた新しくスタートを切るというところで、しっかりまた今年1年も頑張っていけたらなと思います。
はい、じゃあこれで終了したいと思います。お疲れ様でした。
