見出し画像

リモートワークに絶対に必要な力「非同期力」を実現するためにもっとも大事だけど実践がもっとも難しいバリューは「○○○ー○○○」です

リモートワークを、「通勤しなくて楽~♪」な福利厚生であったり、「事務所代を節約できる!」なコスト削減で考えている経営者は無能です。

安易なリモートワークは、間違いなく全社視点での生産性を悪化させます。市場での競争に負け、新たなイノベーションを生み出せず、企業の行く末は真っ暗です。

リモートワークを採用して、市場で勝ち抜き、新たなイノベーションを産み出し、全社視点での生産性を上げるためには、「非同期」で働く文化が重要です。

非同期力についてはコチラを読んで下さい

そんな「非同期な働き方」を実現するために、もっとも大事だけど、もっとも実践が難しいバリュー(企業の価値観)は「イテレーション」です。

参考資料

イテレーションとは

「もっとも実行可能で価値がある最小のものを速やかに提供して、速やかに顧客からフィードバックをえる」ことを重視するのが「イテレーション」です。

難しいぞ!

イテレーションは簡単そうに見えます。実は実践が一番むずかしいバリューです。

いままでの仕事のやり方や考え方を180度考える必要があります。

実際に、世界でも最も進んだリモートワークを採用している企業「GitLab」でも、従業員はイテレーションの壁にぶち当たるそうです。

GitLabに入社する多くの人は、イテレーションはできていると言います。

しかしイテレーションはきちんと理解して取り組むのが最も難しいバリューです。

普通は「完璧で洗練されたものを提供しないと問題が発生する」と教わります。

だから「小さくすすめる」と手戻りがおきてしまう。最初に完成図を把握しないと効率が悪いと思いこみがちです。しかしそれは間違いです。

完成図が見えないまま仕事をしてしまうと、成果が想定外の評価をされてしまうと誤解しがちです。

プロダクトをきちんと完成させたほうが良いと感じてしまいます。

GitLab バリュー / イテレーションより

イテレーションの基本

実践が難しいイテレーションを取り組むためのステップは以下の通りです。

  1. いまプロジェクトの為に使える時間を明確にする(5分なのか?2時間なのか?)

  2. その時間の範囲で、何を完成させて現状を改善できるかを考える

  3. そのために必要なことだけをタスクとして洗い出す

  4. タスクをこなして完成させる

  5. 速やかにリリースをしてフィードバックをえる

イテレーションを実現するために大事なこと

DRI制度の導入

直接責任者(DRI)という仕組みを導入してください。何が成果で誰が担当なのかを明確にしてください。

担当者は誰かに承認を求めずに自分の責任が果たせるように権限を渡してください。

イテレーション:承認待ちをなくせ

DRIを導入して「承認待ち」をなくしてください。

責任を追わせる以上は、意思決定する権限と、必要な経営資源を与えて、承認待ちが発生しないようにしてください。

結果主義:犯人探しをしない問題解決

犯人探しをする文化は、承認を取る文化やリリースをしない文化の原因になります。犯人探しをせずに問題を解決する、犯人探しをせずに仕組みをみなで育てることを大事にしてください。

結果主義:お客さまにとっての結果

プロセスの改善や作業者の審美眼視点ではなく、「お客様にとっての成果を上げる」という文化が重要です。

プロセスや審美眼指向は、リリースしなかったりフィードバックを求めない原因になりがちです。

結果主義:異論を言う、でもコミットする、その後に異論を言う

直接責任者DRIという制度を導入して、承認待ち・決裁待ちはもちろんのこと、コンセンサスを取るとか根回しが必要となる文化を排除してください。

何かをした後に文句を言う「聞いてなかったおじさん」が、みながイテレーションに挑戦する意欲を失わせます。

意見がある人は、DRIに対して好きなだけフィードバックして構いません。しかしながら、DRIにはどのような意見も採用するのもしないのも自由があります。

しかし、DRI以外の人が意見が採用されなかったと文句をいうのはダメです。またDRIとどんなに考えが違ってもDRIの意思決定を尊重してサポートしてください。

効率性:書き出す

DRIが仕事にすべての責任と権限を負います。しかしながらそれは秘密裏にすすめて良いというわけではありません。

すべての経緯や意思決定などはすべて書き出す必要があります。そうすることで、誰もが意見をすることができるようになります。

効率性:自走と自習

承認待ちがダメなのはもちろん、いちいと誰かに質問しながら仕事をすすめるのもダメです。

全員が自走するようにしてください。

ただしこれは精神論の話ではありません。全員が自走できるように、すべての情報をきちんと共有すること、必要な権限を当たることが大事です。

イテレーション:意思決定はひっくりかえして良い

一度決めことは、二度とひっくり返してはいけないという考え方が、イテレーションを阻む原因です。

効率性:枯れた解決策

モダンな技術を使うとか、オーバーエンジニアリングのような、専門家の暴走を防いでください。

まずは顧客の与える価値を重視すること。そのための問題を明確にすること。問題を解決できるもっとも「退屈で枯れた」解決策をチョイスすることが大事です。

イテレーション:できるだけ少ないユーザーに影響を与えることから始める

いきなり全員にまとめて影響を与えるような仕事をせずに、まずは一部の顧客や一部の部門を対象にテストをしてみて、フィードバックをえるなどの工夫をしてください。

イテレーション:最小限の改善 ミニマム・バイアブル・チェンジ (MVC)

とにかく可能な限りもっとも小さな変更案を考えてください。ただ小さければいい訳ではありません。顧客に価値を与えられるもっとも小さな変更案を考えてください。

「せっかくだったら〇〇までやっておきたい」という誘惑に負けないでください。

イテレーション:まとめてやろうとするな

イテレーションではない12のこと

イテレーションと「雑に手を抜いて仕事をする」は180度違うものです。

  1. 品質を下げる

  2. ドキュメントを書かない・サボる

  3. セキュリティで手を抜く

  4. 推奨された手順でも既定の手順でもない手順で何かを提供する

  5. 価値がないものを提供する

  6. 重要でない項目に注力するための口実

  7. ゴールポストの位置を変える、ゴールのレベルを下げる

  8. デリバリーのない修正

  9. 非現実的な厳しいスケジュールを押し付ける口実

  10. 計画を立てないための言い訳

  11. 長時間労働を強いる

  12. 自分の仕事を他の人が直してくれることを期待する

エンジニアに仕事を頼む側は、イテレーションという言葉で、③セキュリティーで手を抜かせたり・⑦仕様をころころ変えたり・⑨無理な納期や⑩長時間残業を押し付けてはいけません。

エンジニアであれば、イテレーションを言い訳に、②ドキュメントを書かなかったり・⑤顧客への価値提供につながらない作業を優先したり・⑧修正するだけでデリバリーをしなかったりなどの手を抜いてはいけません。

この記事が気に入ったらサポートをしてみませんか?