個人で完結する業務の改善および、そこに関わる自己のスキル改善を以下の流れで考えてみます。
前提
今回はあくまで個人で完結する業務および自己のスキル改善を対象としています。
多様なステークホルダーが関わり、改善対象に対する理想が把握できても、そこに向けて人を説得し、合意を得るプロセスが発生するような複雑な改善業務は対象としていません。
業務の改善の流れ
観察
自身が担当する業務を観察し、改善可能な箇所があるかどうか検討します。
個々の業務をどれだけ因数分解して認識できるかがポイントになります。
仮説
細分化した要素のなかから、改善が可能そうな箇所を選び、改善を試みます。
書籍での学習や、他者から得た知見、自身の思考力などにより改善可能性を判別しやすくなります。
検証
改善方法が本当に有効か、何らかの手段で試行して有効性を検証します。
実践
試行がうまくいったら、本番に近い形の流れに組み込んで実践で練度をあげます。
この際に失敗しても良いお試し環境があると好ましいです。
適用
実践により練度を上げたら実際の業務に適用します。
確認
業務に適用した結果、想定されていた改善効果が得られたか確認します。
システム開発の例
観察
開発において自身が担当する範囲のそれぞれの工程を因数分解します。
要件定義完了後から、単体テストの実施までが守備範囲だとしたら、その範囲に含まれる要素を細分化します。
仮説
IDEを活用した効率的なプログラミングに関して改善の余地がある、という仮説を立てます。
検証
IDEの公式サイトや、書籍、Tipsの情報をもとに活用方法を調査し、自身が業務で使う範囲の機能で効率化が可能か検証します。
実践
検証で効率化が可能である見込みが見えた対象に対して、実業務に近い前提で試し、練習します。
適用
実業務で検証・実践で手に慣らした手法を組み込んで成果を出します。
確認
業務を通して成果につながっていることを確認します。
まとめ
取り組み対象が異なれ、取り組みの上達・改善は概ねこのような要素の繰り返しではと考えています。
それに際して重要となるのは
- 改善対象をどれだけ詳細に分解して捉えられるか？
- 改善可能性に気づく良質、多様、大量のインプットをできているか？
- この過程による改善・成長を実感できているか？
あたりかなと思います。ここまでくると、あとは継続した改善・成長が楽しくなってきて没頭してくるのではと思います。
