IT業務効率化

新卒の運用担当者がカイゼン・ジャーニーを読んだら

カイゼン・ジャーニー

はじめに

カイゼン・ジャーニーとは

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

市谷 聡啓さん新井 剛さんの著作です。

開発を回していくために、個人やチームにはどんな努力が必要なのか、実践的に書かれているアジャイル開発の本です。

この記事は私の読書感想文です

ソフトウェア開発者向けに書かれた本ですが、私は開発者ではなく新卒の運用・ヘルプデスク担当です。

ただ、本書はチームで働く全ての人に通ずる内容が書かれており、開発者じゃなくても参考になった箇所はいくつもありました。

それを自分とチームに落とし込むにはどうしたらいいか、と考えた感想文です。

自己紹介

記事を読むべきか皆様にご判断いただくためにも、僭越ながら自己紹介をさせてください。

hirayuki
hirayuki
社会人・エンジニア歴共に3年目。今の会社のシステム運用業務・ヘルプデスクに就き1年。大学まで物理しかやってこなかったため、新しい世界で奮闘中。会社はベンチャーマインドが強いため、置いて行かれない様に、仕事には常に体当たり。

こんな筆者の誓いの記事でございます。

挑戦するために

It’s easier to ask forgiveness than it is to get permission.(Grace Hopper p.18, l.3)

最初に少し、気持ちの話になります。

そもそも改善活動をしていくことは勇気が必要だと思います。新しい試みのもと失敗なんかしたらどうなってしまうのか、という不安が付きまといます。

それでも改善を進めていくため、勇気の言葉を本書では取り上げていました。

許可を求めるな謝罪せよ

この言葉は色々な和訳がありますが、許可を求めるよりも失敗してしまって謝る方が簡単であるということです。すごくクリティカルな部分に関わる様ならダメですが、

良くしようとして失敗しちゃった。ごめん!

という気持ちで取り組んでいき!ということです。勇気!

しろくまエンジニア読む前
読んだ後

それではこの勇気の元、実際にやってみたこと、これから進めたいことが以下です。

1人で始めて周りを巻き込むには

1人で始めた見える化が周囲を巻き込む(p.57, l.1)

本書の構成は「1人で始めるカイゼン」、「チームでのカイゼン」、「みんなを巻き込むカイゼン」の3部構成です。上の引用は「1人で始めるカイゼン」の後半の一文です。

本書では周りを巻き込むために、見える化を1つの例としてあげており、タスクボードの見える化を具体的に書いていました。TODO、DOING、DONEのエリアに分けたタスクボードを活用して自身のタスクの進捗を自分のために見える化する。そしてを周りにも見える化していく。その結果、1人で始めたカイゼンが仲間を集め、共用のタスクボードへと進化していくという話です。

私も自分のカイゼンを仲間に共有して、一緒にカイゼンしたい!

とりあえず普通の日報の共有から始める

  • 昨日を踏まえた今日の改善
  • TODO
  • できたらNICE
  • 悪かった点
  • よかった点
  • 明日以降の改善

という内容の日報です。結構よくあるタイプです。

私はこれを上司・同僚問わず、関係している人に共有することから始めました。俺はもっと業務をよくしていきたい、こんな工夫を考えている、というのを見せていこうとしています。

なぜ日報なのか

日報のいいところは、

  • 形式が自由であるため、続けやすい
  • チームに共有する前に、1人で小さく始められる

ということです。

形式が自由であるため続けやすい

素晴らしい本に出会うたび、新しい思考のフレームワークを学びますが、大概すぐには使いこなせません。体系的に作られているほど、自分の環境に落とし込むには時間がかかると思います。さらに悪いことに、そのフォーマットに沿って考ることが目的にすり替わり、本題から外れていくことも多いです。(みなさんもありませんか・・・?)

そのため、思考のフレームワークを一旦忘れて、自由形式の日報を大切にします。その中に徐々に本書の考え方や、メソッドを取り入れていく。そうすることで、今の自分の目の前の問題を正しく捉えることができますし、フレームワークを使いこなせず挫折して三日坊主になることもありません。

改善を毎日続けることができます。

1人で小さく始められる

この後触れるドラッカー風エクササイズや、ユーザーストーリーといった考え方のフレームワークも、すぐにチームメイトに共有したくなってしまいますが、一旦ストップする様にしています。本を一冊読み切るとあたかもフレームワークを理解した様な気になってしまうことがあるからです。実際は理解し切れておらず、中途半端な知識でチームに持っていってしまうと、そこで破綻してしまいます。

そうならないように、まず自分1人でやってみるようにしています。そのための場として、日報を利用しているのです。

思い出したのはminimum variable product

minimum variable productとは、提供したいサービスを作っていく時に、突然理想形を作り始めるのではなく、その機能を備えた小さなものから提供していく考え方です。

この考え方をもっともよく表している車を例にした図があるので、こちらをご覧ください。

https://medium.com/swlh/the-mvp-is-dead-long-life-to-the-map-minimum-awesome-product-404df90fef7f

車を最初から作るのではなく、スケボーから初めて、自転車、バイクを提供していき、最後には車を作ります。そうすることで、サービスの方向性を見誤ることなく、事業を成長させていけるという考え方です。(そう私は解釈しています。)

この考えを新人の改善にも当てはめることができます。

  • 小さく現場が変わっていくことで、上司に効果を気づいてもらえる。
  • 改善の方向性を示すことができるので、仲間が集まる。

チームとして働くために

個人個人が完結して仕事をこなし、その総量がチームのアウトプットになっているようではまだチームとは呼べへんな。(p.100, l.2)

私はチームで働くためには、チームで働いていないとはどういう状態かを知り、それを日々意識することから始めようと思いました。

本書を手に取るまでは、チームという意識すらなく、家に帰ってコードの勉強ばかりしていました。それではうまく行かないことに気づけたので、本書にはとても感謝しています。

その中でも、特にその重要性に気づかせてくれた、リードタイムとプロセスタイムの話を自分なりに紹介したいと思います。

リードタイムとプロセスタイムの話

プロセスタイム:事実上そのプロセスが実行している作業時間
リードタイム:プロセスが次のプロセスに移行するまでの所要時間(p.146, l.23-24)

私はこれを聞いた時に陸上部だった頃を思い出しました。本書では「病院で患者が受付から診察して薬をもらって帰るまで」を事例として上げておりました。私はここであえて陸上のリレーの話をさせてください。

カイゼン・ジャーニー

リレーのタイムを速めるためには、バトンの受け渡しを速くしなくてはいけません。そのため個人が速く走ることよりも、バトンを渡す練習を重点的に行います。私は会社で働くということは、これに似ていると思います。会社では自分のタスクを抱え込むことなく、常に適切な人とバトンを受け渡しながら進めていく技術が大切だと気付けたのです。

それまで私は5番の状態に陥っていました。だってバトンを渡す練習って面倒臭いし、システム的な技術を学ぶ方が面白い、そう無意識に考えていたのだと思います。

しかしそれが自分の仕事の妨げになっていることに気が付けました。

もっとチームとして活動するために、以下のことを今後実践していこうと思います。(まずは)

調査記録をフォーマット化して、引き継ぎ体制を強化する
誰に任せたらいいか、社歴の長い人に教えてもらえる様に相談しておく

チームのスキルを俯瞰で見る星取表

誰がどのスキルをレベルアップさせるのか、誰がサポート役に就くのか俯瞰できると意思決定がしやすい。(p.133, l.12-14)

これは今のチームで元々あったのですが、その重要さを再確認しました。

特に教育の観点で非常に役に立っています。弊社の運用・ヘルプデスクの特性上、依頼が来ることで仕事が発生します。依頼が来ないと教えられないため、順序よく教育していくことができず、

今どこまでできるんだっけ?
新人さん
新人さん
えと、、どこまでと言われましても。。。
確かにそうだねぇ。。。

私は教育プログラムを作ろうとして、ここで挫折しそうになりました。

でもスキルマップを作っておけば一目瞭然です!個人の強み弱みを確認し、穴を埋める様に教育プランを立てることができました。本書の中でさらに参考にしたのは習得希望を意味する「↑」マークです。誰がどのスキルを伸ばそうとしているか可視化できるのは大変参考になりました。

スキルマップ

この仕事は必要なのか、1人で考えることから始める

機能をただ作ることだけに目線がいってしまうと、目的を見失ってしまいます。目的は、ユーザーストーリーの対象者に価値をもたらすことです。

私の場合はタスクをただこなすことに目線が行ってしまいがちでした。しかし増えていく仕事量に対して、私の解決速度は追いついていません。こんな時には、どの仕事を片付けるかという軸を持たなくてはいけない、そう考えられる様になりました。

私も判断軸が欲しい

そんな時本書のユーザーストーリーという考え方が非常に参考になりました。「何故その仕事をやるか」に立ち返ることで、本当にやるべき課題を的確に捉えるフレームワークです。

私はこれを仕事に応用し、徐々にタスクの海の中から、優先順位をつけて作業を選択できる様になりました。もしかしたら、どこかで順位を間違えているかもしれません。しかし、顧客にとって何故必要なのかを考えてから取り組んでいるので、迷いがなくなり集中力が上がりました

終わりに

本書を手に取って1週間、すでに効果が少しだけ出た話をします。

本書を全て読み切って、感じたことの1つに、働く人との仲の良さが如何に重要かということも感じました。たまに飲み会を開催したり、社員の親睦を深める活動をしており、それも重要なのですが、仕事で仲を深めていくことも非常に重要で、また別の取り組みだと思ったのです。

なので関係を深めよう、もっと話そう、と思い仕事中に普段の悩みを率直にそのまま上司に相談しました。仕事の範囲がわからなくて、何も終わらずに困っている、と。すると、私が担当領域を超えたことまでやっていたことを教えてくれました。

しろくまエンジニア

週に10時間くらいは時間を割いていたので、かなり影響が大きかったです。シンプルなことですが、時々話してみるって大事ですね。

注意書き

  • このブログは、本書の伝えたいメッセージの要約ではなく、私の主観で書かかれた感想文です。
  • 私は新卒であり、本書を読んで1週間です。
    そのため本書の実践を始めるためには、そして続けるためには、ということを重点的に書きましたが、本書に比べて内容に偏りがあります。
    本書にはより深くチームで協力するための知識が詰まっております。
上記ご注意ください!お読みいただきありがとうございました。詳しい内容は本書をぜひお取りください。

 

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
ABOUT ME
hirayuki
今年で社会人3年目になります。 日々体当たりで仕事を覚えています。 テーマはIT・教育です。 少しでも技術に親しんでもらえるよう、noteで4コマ漫画も書いています。 https://note.mu/hirayuki