【解説】カイゼン・ジャーニー | 誰でもできる仕事改革術
こんにちは、もぐめっとです。
最近33になりました。でもおでこのシワは減らず増えていく一方です。
突然ですが、
あなたは何をしている人ですか?
今回はそんな自分を再度見つめ直す機会になるようなカイゼン・ジャーニーという本と出会ったのでその紹介をします。
この本ではストーリー仕立てでわかりやすく主人公が徐々に成長して周りを巻き込んで仕事をこなしていく過程がのっています。
とってもあるあるな内容で、つい先がきになって一気に読み進めてしまう本なので是非皆さんもお手にとってみてください。
一人から始める
一人からでも始められる仕事の改革術について紹介します。こちらに関しては結構アジャイルの初歩的なところもあるので実践してる方は多いのではないかとは思います。
■外を見る
皆さん、お仕事していてもやもやしてませんか？
そんな皆さんにまずおすすめなのが、外に出てみることです。
同じ場所にいると、考え方ややり方の傾向が揃ってきてしまうことが多く、それで問題解決ができている間は良いが、今までのやり方では解決できないことに直面したり、仕事のカイゼンが進まなくなったりすることも出てくる。
外に出ることによって異なった考えや経験した人が溢れているのでそこから新たなカイゼンや解決策に巡り合うことができます。
これに関しては以前私が紹介した下記のnoteについても同じようなアクションプランがあります。
外に出ることによって実際のカイゼン法、解決策だけでなく、人との出会いによって、出会った人が実際に助けてくれるということも遭遇しえます。
外に出るというのはいい事だらけです。（今はちょっと出づらい世の中ですが）
■仕事の見える化をする
状態の善し悪しが見えてないとカイゼンの効果を期待するのは難しいので、タスクマネジメント、タスクボード、朝会、ふりかえりを使うことによって仕事の見える化を何よりも先にします。
①タスクマネジメント
まずは仕事の背景や目的を理解しましょう。目的を履き違えるといくらやっても無駄になります。
そしてタスクは小さく分割しましょう。
もぐめっとの見解では基本的には1日以上かかるタスクはでかすぎです。なるべく半日以下のタスクサイズにしましょう。
そして、タスクを出し切れたら計画を立てましょう！
計画を建てることでタスクの順番、リソース不足やスケジュールの問題なども見えてきます。
計画を建てずに進めるといつまでに何が出来上がるのかというのも報告することができず、会社の上司たちからみると「君たち今何やってるの？いつ物ができるの？」となって、最悪プロジェクトの頓挫になりかねません。（経験者談）
まずは計画を立てて全体を俯瞰できるようにしましょう。
②タスクボード
タスクボード（通称カンバン）を使うことでタスクがあとどれくらいあるかがわかります。
やり方は簡単。TODO/DOING/DONEと、レーンを引いてそこに1タスク1付箋を貼っていくだけです。
付箋を作る際のタスク名の書き方は名詞＋動詞で書き、どうしたらこのタスクは終わるのかをはっきりさせるようにしておきましょう。名詞だけなどだと何をするタスクなのかわかりにくかったりします。気をつけましょう。
タスクの状況を逐一見ることで問題を早期に発見して早めに手を打てるようになります。
例えばAさんのタスクが遅れていて、Bさんが早々におわっているのであればBさんがAさんのタスクを助けに行くなど、チームの仲間が助けることもできるようになります。
最初はアナログがおすすめですが、今はコロナの状況でオンラインが絶賛ブーム中なので、miroなどのオンライン付箋サービスを使うといいと思います。
慣れてきたらJIRAなどを使うとよりstorypointなどの計測やレポートなどもできるのでおすすです！
③朝会
昨日何ををやったか、今日やること、今日することや計画を達成する上で困ってる事を話し合います。計画とのズレを検出して再計画するきっかけを作ることができます。
朝会ではリズムが大事で、例えば朝にメンバーが遅れてるならそのメンバーに何かが起きている兆しと分かります。
もぐめっと的アドバイスとしては、朝会はダラダラとやらず15分くらいでさっと終わらすのがコツです。
もし話が長くなるようでしたら別に話は切り出して関係者のみで話し合うようにしましょう。
④ふりかえり
やり方や結果を棚卸しして次の仕事に活かすために改善します。
ふりかえりがないと仕事をよりよくカイゼンする機会がなくなってしまうのでふりかえりが消滅しないように気をつけましょう。
■1on1の意義
もぐめっとがこの本で一番響いたポイントが1on1についての記載です。
1on1は信頼関係を築いてその人の成長のためにやるものです。基本的に上司が一方的に話す場所ではないので、上司の皆さん、基本的に聞き専でいてください。メンバーは話を聞いてくれると感じたところから信頼関係はうまれて初めてそこからいろんな話が聞けます。
1on1を通してメンバーの状況をカイゼンしたり、成長する機会を与える場にもなるのでとても大事なものです。
そして、「1on1やる意味あるの？」とか、「1on1の時間ない」などと苦言しているリーダーに申したい言葉が、本書には記載されていたので掲載させていただきます。
そもそも仕事や会議に追われてメンバーと話す時間やタイミングもないという言い訳も聞こえてきそうだな。でも、本当に「メンバーと共にする時間」よりも大事なことばかりなのか、問うてみて欲しい。月1回、30分でもメンバーのために時間を取れないだろうか。もし、本当にその時間が取れないなら、上司やリーダーという立ち位置から降りたほうが良いかもしれない。
会社やチームとしてプロダクトを作っていく以上、仲間というのはとても大事な存在です。
仲間を疎かにする上司・リーダー・社長に果たして人はついていくでしょうか。
この辺に関してははじめてのリーダー論についても言及されてる内容ではあるので、もしよかったらこちらも御覧ください。
チームで始める
■ユーザに届けるものの認識を合わせる
プロダクトオーナーはスプリントで達成すべきゴールをマーケットや要求を踏まえて優先度をもとに決め、バックログをスプリントが始まる前までにつくっておきましょう！
スプリントが始まってからタスクの精査を一緒に始めるチームなどもありますが、もぐめっと的には関係ないメンバーの時間も奪っている事もあってMOTTAINAIので、予め精査は関係者だけで終わらせてタスク精査や作るものの認識をスプリントまでに終わらせておくべきと考えています。
なので、大体スプリントの1時間前とかにみんなに声を掛けてスプリントの時間を短くし、なるべくチームの稼働時間を上げる工夫をしたりしています。
■WorkingAgreementを作ろう
ふりかえりをして良かったことなどはそのまま何もせずよかったね〜で終わらせず、今後も続けられるようにWorkingAgreementというものに記載していきましょう。そして書いただけで終わらせず、形骸化させないために振り返りごとにアップデートしていきましょう。
もぐめっともできてないところではあるので、やらなきゃと思い戒めの思いでピックアップさせて頂きました。
WorkingAgreementを記載しておけば途中から入った人にも文化のマインドセットもしやすくなると思うので作っておくとジョインしやすくなると思います。
■チームの期待のギャップを埋める
不確定要素が多くて難易度が高いほど期待に対するマネジメントをしないといけない。インセプションデッキは内側（チームにおける期待）と外側の期待（プロジェクト関係者における期待）の両方に効果があるが、今回もぐめっとが注目したのは内側の期待マネジメントのためにやるドラッカー風エクササイズに注目しました。
詳細は以前こんなnoteを書いたのでご参照ください。
■ファイブフィンガーで危険兆候を察知
メンバーがうまく仕事をこなせていない状態で、他の人から見ても明らかなのに朝会に困っていることとして挙げられてない場合がございます。その時に使えるテクニックがファイブフィンガーです。
やり方としては今の仕事のうまくやっていけてるかの状態を5本指で表します。うまくいってなかったら一本みたいな感じですね。
より危険察知をしてメンバー同士で助け合えるようにするために使えるテクニックだと思いました。
■そうだ合宿、行こう
カイゼン・ジャーニーにも合宿についての記載がありました。
ネガティブな状況にチームが陥っていたり、方向性を見失っている場合は生産性があがりません。そこで空気や雰囲気をかえて集中した時間を作り出すのが合宿です。
合宿は余計な差し込みが入らずにチーム全体で議論ができます。
合宿については是非下記のnoteも御覧ください。
今回は書籍に紹介されていたアンチパターンを紹介します。
①いつもと同じ場所
②目的・ゴールがあいまい
③詰め込みアジェンダ
④アクションプランを設定しない
⑤必要な人がいない
そして、、、
⑥まずい食事
食事がまずいとせっかくの合宿もテンション下がっちゃいますよね。食は人間の生きる活力なんで食事はうまいとこで満足感たっぷりな合宿で終えられるようにしていきましょう！
■新メンバーを迎えるにあたってあるといいもの
新メンバーを迎えるにあたりあるといいものが星取表（スキルマップ）とモブプログラミングです。
スキルマップはそれぞれのメンバーが何ができるのかというのをスキルの一覧化をすることで何を誰に任せられるのか、誰に何の支援が必要なのか、チームとして足りない要素、強化したいスキルなどを明確化することができます。
ただしここで注意が必要なのが人事評価には使わないようにしましょう。正直なことが言えなくなります。
ちなみに三種の神器として、インセプションデッキ、ドラッカー風エクササイズ、スキルマップは初期段階であるといいらしいです。
スキルマップは特に最初にチームにジョインすると誰に何を聞けばいいのかとかよく迷ったりすることが多いのでこういった表を見ることによってより質問がしやすくなってジョインする速度が速まると思います。
もぐめっとも作らなきゃと固く感じています。
みんなを巻き込んで始める
チームが出来上がってきたところでさらにチーム外も巻き込んでプロダクトを作っていく勘所を紹介します。
■スケジュールの勘所
上層部やステークホルダーがプロジェクトを遂行する中で常に気になるところは、期日にリリースできるのか、コストはどれくらいかかるのか、といったところでしょう。スケジューリングの際、これらの懸念点を考慮しながらマイルストーンの計画づくりをします。（リリースプランニング）スケジューリングの際、これらの懸念点を考慮しながらマイルストーンの計画づくりをします。（リリースプランニング）また、計画変更を後向きなスタンスとして捉えることは終わりにして、短いスパンで繰り返し、足りないタスクは計画に追加し、誤った見積もりは修正していきます。
継続的な学びを知識とし、プロジェクトに適応させ続けることが重要です。
もぐめっと的には、運用フェーズに入ると期日やコスト以外にも、実際試作を実施して、その結果どうなったのかという具体的な数値を出すことが大事と考えています。
ただモノを作って終わりというのをゴールにせず、作った結果ユーザにどう影響与えられたのかというのを常に考えながら作る必要があると思いました。
■外部チームとやり方を向き直る
Y（やったこと）、W（わかったこと）、T（次にやること）を考えるYWTフレームワークがあります。これを使うことで進むべき先を捉えることができます。
他部署と話をすすめる時に部署ごとに部署の都合しか考えないことが出たりしますが、そういう場合にこういったフレームワークを使うことで本来すべきことは何なのかというのを向き直ることができます。
また、スクラムオブスクラムという方法が本書には紹介されており、デイリースクラムを、複数のスクラムチームから代表を集めて実施するミーティングを開催し、
・他のチームに関係する作業の情報
・チーム内だけでは解決できない障害
を共有します。
こうすることによって他部署との課題をすり合わせられ、会社全体としてのベロシティも上がると思います。
■ユーザーストーリー
ユーザーストーリーは
ユーザーとして（Who)
何をしたい（What)
なぜなら〜だからだ（Why）
といった表現で達成したい要求を見極め、その理由がビジネス評価につながるように物語を語るようにしたものです。
例えば、もぐめっとが最近感じてることとしては、
30代の会社経営者として
家事の時間を減らしたい
なぜなら事業以外のことに時間を割きたくないからだ
といったような例題があげられます。
（※そういった背景から私はcasyやuber eatsをよく多用しています。）
ユーザが達成したい要求を見極め、その理由がビジネス価値につながるように物語を語ります。その際に方法論やソリューション(How)ではなく、ユーザの望み（Why)である目的を明確にすることが重要です。
顧客の片付けたい用事（What）を解決できるのかが明確にわからないのであればストーリーの深堀りが足りないので、Whatが煮詰まった時はWhyを先に考えてみましょう！その後Whatが再定義できるようになります。
顧客の課題に気づくために「お金を払ってでも片付けたい用事」とは何かを考えると効果的です。
ユーザーストーリーについては作者によって書かれてるのでご参照いただければと存じます。
開発をしているとよく方向を見失いがちなので、こういったユーザー視点で考えて開発をしていくというのは非常に大事だと思います。
何から始める？
私が印象に残ったことを紹介してきましたが、ここからは私が考える「まずはこれはやろう」といったアクションプランを紹介します。
■仕事を見える化
仕事をノリでやったりとか、割り込みタスクを何もせず黙々とこなしていく人も沢山いらっしゃいますが、とりあえず看板にタスクは全部書きだそう。自分の仕事を見える化をしないといつまでも残業続きから抜け出すことはできません。
また、チーム内で朝会を是非しましょう。そこから日々のタスク修正をすることができるので無駄な仕事を減らしたり、早く仕事を終えられたりすることができたりします。（経験者談）
■自分から1on1
私がフリーランスで常駐してた先ではよく三ヶ月に一度くらいに上司の人と自分から1on1を行ってフィードバックなどを受けていました。
フィードバックの機会を作るのは大事で一人じゃ割と見えないことが多いです。指摘されて人は成長するので、是非1on1を実施してみてください。
また、リーダー業務をやってる方々は是非メンバーの方と1on1をしてください。仲間との信頼関係を築くことによって仕事は円滑に進められます。
1on1ができないならリーダーを交代したほうがよいです。
■ユーザ視点を忘れない
開発者が作るものはユーザがあってこそです。そのユーザをおざなりにしてはいいものは作れません。
道に迷った時はユーザ視点で考えて、より良いものを作っていきましょう。
まとめと書評
ということでまとめです！
・仕事を見える化する
・1on1を通して仲間との信頼を築く
・ドラッガー風エクササイズや合宿、WorkingAgreementなどを通してチームを成熟させていこう
・ユーザの課題を解決するように考えいいものを作る
書評としてはストーリーとしてもとてもおもしろく、伏線回収もあったりして結構熱い展開もあったりします。めちゃめちゃ面白く読みやすいです。
この本を読み終わったときには「あなたは何をしている人ですか?」という質問に関してきっとまた違う答えが出てくるのではないかと思います。
おすすめの本の一つです！
ご精読ありがとうございました！