はじめに
私はこれまで「チームをもっと良くしたい」という気持ちはありつつも、今の自分の立場でどこまで意見を出してよいのか、どう伝えれば前向きに受け取ってもらえるのかなど、改善提案の仕方に悩んだり、思うように進められず苦労した経験があります。
この記事では、今までの経験を踏まえて、開発チーム内で改善提案をするときに自分が気をつけていることを5つにまとめてみました。
私自身、チームでは若手の部類で経験豊富というわけではありませんが、
同じようにチームを良くしたいけれど、うまく提案できずに悩んでいる方の参考になれば嬉しいです。
目次
- 1.「自分はこれがいい」を添える
- 2. 既存のやり方を雑に否定しない
- 3.「そもそも、なくせないか」から考える
- 4.「それは今やるべきか」を考える
- 5. 新しい運用ルールは小さく試して、見直す前提で始める
1. 「自分はこれがいい」を添える
チームへ改善提案を進めようとすると議論が広がるだけで、結局何も決まらないこともあります。
こうした経験から、チームに改善提案をするときは、課題を整理して共有するだけでなく「自分はこれがいい」まで添えるようにしています。
これは、“提案”のレベルを上げる-Konifar's ZATSUで書かれているレベル2を意識したものです。
引用：https://speakerdeck.com/konifar/ti-an-noreberuwoshang-geru-number-qiitaconference?slide=13
以前は、選択肢となる改善案を整理して共有できれば、それで十分だと考えていました。
ただ、それだけだと最後の判断を相手に委ねる形になっていること、相手の立場になれていないことで物事が前に進みにくいことに当ブログを見て気づかされました。
もちろん、自分の案が必ず正しいとは限りません。
それでも自分なりの考えをまとめてみると、考慮すべき点が見つかったり、議論のたたき台ができたりします。
その結果、チームとして次のアクションを決めやすくなると感じているため、改善提案をするときは自分なりの考えまで添えることを意識しています。
2. 既存のやり方を雑に否定しない
「もっとこうしたほうがいいのでは🤔」
「なぜこのやり方をしているのだろう😔」
転職や異動、チームが変わった直後は、どうしても前の職場やチームのやり方と比べてしまうことがあります。
新しく入ったからこそ気づける違和感は大切だと思うものの、今見えている範囲だけで既存のやり方を否定してしまうと、受け取る側にとってはあまり気持ちのいいものではないかもしれません。
今のやり方には何かしら理由があることも多いです。
過去に議論した結果だったり、一度試してうまくいかなかった経緯があったり、当時の制約の中で選ばれた形だったりします。
だからこそ、いきなり「このやり方は良くない」と決めつけるのではなく、背景を慎重に確認することや、まずは目の前の仕事に向き合いながら、チームの中で信頼を積み重ねることには気をつけるようにしています。
3. 「そもそも、なくせないか」から考える
改善の方向を考えるとき、参考にしているのがECRSという考え方です。
もともとは製造業の業務改善で使われている4つの視点で、E・C・R・Sの順に検討していくものです。
| 順番 | ECRSステップ | 問いかけ |
|---|---|---|
| 1 | Eliminate / 排除 | そもそも、なくせないか |
| 2 | Combine / 結合 | まとめられないか |
| 3 | Rearrange / 入替え | 順番や場所を入れ替えられないか |
| 4 | Simplify / 簡素化 | もっと単純にできないか |
↓たとえば「会議が多く、開発時間が取りづらい」を改善する場合は、次の順番で考えます
私は定常業務の効率化を考える際にはよく、「どう自動化しようか」「どう仕組み化しようか」と、手段から考えてしまうことが多く、振り返ると「そもそもやめてよかった作業」を、わざわざ頑張って自動化していたこともありました。
そういった経験もあり、業務改善や効率化を考えるときは、ECRSの順番を意識して改善案を考えるようにしています。
4. 「それは今やるべきか」を考える
私自身、効率を求めているうちにいつのまにか"改善すること"自体が目的になってしまうことがありました。
たとえば、"30分の作業を効率化するために2時間かけてしまう"というようなことです。
改善の優先度はそこまで高くないと頭ではわかっていても、課題が明確になったり、便利そうな仕組みを知ったりすると、つい改善に取り組みたくなってしまうことがあります。
だからこそ、「やったほうが良さそう〜」に見えることでも、本当に今やるべきなのか、かけるコストに見合うのかは一度立ち止まって考えるようにしています。
改善はチームやユーザーに価値を届けるための手段であって、それ自体が目的ではないです。通常の開発業務もありますし、チームには他にも取り組むべきことがあります。
限られた時間の中でより価値のあることに集中するためにも、「改善したい」という気持ちだけで進めないように意識しています。
5. 新しい運用ルールは小さく試して、見直す前提で始める
開発をしていると、コーディング規約、テスト方針、レビュー基準など、開発チーム内の品質をそろえるために、運用ルールを決めることがあります。
ただ、ルールが増えるほど、判断や行動の自由度が下がったり、時間が経つにつれて導入した背景や目的が分からなくなりがちです。その結果、一部の人だけが守る形になったり、形骸化したまま運用され続けたりしてしまうことがあります。
そのため、新しい運用ルールを導入するときは、最初から完成形を目指すのではなく、まずは小さく試すこと、定期的に見直す仕組みを作ることを意識しています。
👇チームでの実際のやり取り
実際に決めたルールを運用してみると、事前には見えていなかった課題が出てくることがあります。
だからこそ、ルールは一度決めたら終わりではなく、本当に役に立っているかを見ながら、チームに合わせて見直していくものとして扱うよう心がけています。
おわりに
開発チーム内で改善提案をするときに、自分が気をつけていることを書いてみました。
改善に取り組みたいと思うのは、今いるチームをもっとよくしたいと思うからです。
私は、自分たちの小さな改善が、結果として事業やユーザーへの価値につながっていく、そういう実感があるほうが、働いていて楽しいなと感じます。
だからこそ、改善を提案するだけでなく、チームやプロダクトを実際に前に進められる人でありたいなと思っています。
もちろん、毎回うまくできているわけではありませんし、今でもたくさん失敗しています。
まだまだ試行錯誤中なので、「自分はこうしている」「ここはこう考えたほうがいい」などの意見があれば、教えてもらえると嬉しいです🙏
最後まで読んでいただきありがとうございました！
KIYOラーニング株式会社について
当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。
プロダクト
- スタディング：「学びやすく・わかりやすく・続けやすい」オンライン資格対策講座
- スタディングキャリア：資格取得者の仕事探しやキャリア形成を支援する転職サービス
- AirCourse：受け放題の動画研修がついたeラーニングシステム（LMS）
KIYOラーニング株式会社では一緒に働く仲間を募集しています