今までの振り返り
今までの振り返りという題にしましたが、正確には2024年に入ってからの振り返りをしようと思っています。
その前に私はSI案件にアサインされている関係上、着手できる工数には上限があり、できる限り上限工数内で作業することが求められます。
さらに、お客様や上司から予定工数を聞かれるため、課題に着手するたびに予定工数を見積もらなくてはいけません。
その見積もり予定工数が1課題分ならあまり労力は必要ないかと思いますが、複数課題、かつ1月分の予定工数となるとかなりの労力が必要になります。
そのため、タスクを管理し、ボタンをクリックしただけで工数を計算するテーブルを作成しました。
上記テーブルにより工数見積もりのための工数を大幅に削減することができました。
上記テーブルで業務上のあらゆる情報を管理しようと思い立ち、振り返りのためのテーブルを作成し、定期的に振り返りを実施しようと考えたことが始まりです。
日々の業務の振り返り
といっても、日々の業務の振り返りはとても大変です。この記事を読まれている方の中で業務の振り返りをやっているよという方のほうが少ないかと思います。
そのため、今回の記事では、私自身の業務の振り返りと共に私が使っている「KPT」という振り返りフレームワークについてもご紹介したいと思います。
振り返りの重要性
「振り返り」にはどのような意味(効果)があるでしょうか。私たちは学習を繰り返す生き物です。学習によって自身を成長させ、夢をかなえ、幸福になるのだと考えていますが、学習には「復習」、つまり「振り返り」が必要です。しかし・・・
「振り返り」にはどのような意味があるのか考えたことがあるでしょうか。
私にとって振り返りとは、自身の言動やあり方をかえりみて、改善点を見出すことだと思っています。そして、振り返りの結果をもとに次の行動へつなげることが学生から社会人になった私たちには必要な「学習」だと考えています。
KPT
KPT(ケプト)とはK(Keep：よかったこと), P(Problem：よくなかったこと), T(Try：今後実施すること)を洗い出すフレームワークです。後述のような手順で実施します。
- Keep：今回のタスク(プロジェクト)で成果が出て継続することを検討。
- Problem：今回のタスクで解決するべき課題を検討。
- Try：上記の内容を受け、分析し、具体的な改善策を検討。
KPTはあくまでよかったことと良くなかったことを洗い出し、次の行動への改善策を導き出すフレームワークです。
そのため、KPTを利用する本人が行動を起こさなくてはKPTの効果を発揮しないことに注意してください。
振り返り
さて、KPTについて簡単に紹介をさせていただきました。KPTの詳細については各自で調べていただけますと幸いでございます。
コミュニケーションをとるときの内容
お客様や上司、同僚とテキストや対面でやり取りするときには下記の点に気を付けます。
何を誰に確認・相談したいのか + この後何を行う予定か
お客様を含むステークホルダーに関係する不注意は迅速に対応
お客様を含むステークホルダーに関係する不注意によるミスはお客様からの信頼を損ねる危険性がとても大きいです。そのため、上記のシチュエーションでの不注意によるミスを起こした場合は下記に注意します。
必ず確認を怠らず、ミスが極力内容にする
ミスが発生した場合、上長に「口頭」もしくは「電話」にて緊急な対応を実施する
本番環境での手順は極力コピペで実施
お客様の本番環境(ユーザさんが操作している環境)のリリース作業の手順書を作成する際は下記に気を付けます。
テキストなどは完全コピペで対応でいるような手順書を作成する
ただし、接続文字列やパスワードのようなデータとして残してはいけない情報をのぞきます。
レビュー依頼を出す際には、インプットとアウトプットが大切
上司や先輩、同僚にレビュー依頼を出すときにはレビュアーに余計な負担を与えないために下記を気を付けます。
レビューを出す際にはどのような事象(インプット)に対してどのような対応(アウトプット)を実施したかをレビュアーに伝える
ログイン時、認証が通らないときはむやみに連打しない
あまり意識したことがありませんでしたが、改めてご指摘をいただき「そりゃそうだ」と自分の無能さを思い知った出来事でした。ログイン情報を入力し、ログインボタンをクリックしても拒否された場合は下記に気を付けます。なお、ロックされた場合の影響範囲の大きさから適宜判断します。
そもそも、入力する項目はあっているか(項目に対して正しい入力内容か)
入力されている情報に抜け漏れはないか
最悪の場合、誰かを呼びダブルチェックをする
プロジェクトを進めていく中で「要件(仕様)の決定→実装→テスト→リリース」を意識する
プロジェクトを進めていく中で下記に気を付けます。
前工程での不備(決まり切っていないことなど)がある場合、次の工程へは進まない
プロジェクト全体を通してリスク(不確実性)となる事象を残さない
発表などの際にはまず「聞き手にどうしてほしいのか」を話す
発表やプレゼンテーションの場では、聞き手に発表内容に集中してもらうため、下記に気を付けます。
最初に発表内容から聞き手がどのようなアクションをしてほしいのか話す
ほかメンバーからの意見を求める場合、随時意見を求める
ほかメンバーからの意見を求める場合、プロジェクト終盤に意見を求めるとスケジュールに遅延が発生、もしくはスケジュール内に対応することができないことがあるため、下記に注意します。
ほかメンバーから意見を求める場合、プロジェクト中盤から随時意見を募集する
詳細なスケジュールを作成する
スケジュールがおおざっぱだと並行タスクが多くなり、作業者自身で詳細なスケジュールを作成することとなり、管理が煩雑になってしまうため、下記に注意します。
作業者が管理しやすいようにタスクを可能な限り細分化する
並行タスクをなるべくなくすために細分化したタスクに詳細なスケジュールを設定する
テスト仕様書を作成する際の注意点
テスト仕様書を作成する際には下記に注意します。
テストケースを洗い出すためのマトリクスの利用
テストデータの準備・テスト仕様書への記載
実施内容・確認内容は明確な指示を記載
冗長な文言はどこかにまとめて記載し、参照するように記載
プロジェクトの管理者となった場合の注意事項
現在、社内プロジェクトの管理者となっています。小さなプロジェクトですが、管理者としてプロジェクトを進めている中で気が付いた下記に注意します。
詳細なスケジュール決定
管理する単位
定例会の実施
作業者へのヒアリング
さいごに
今回の記事は外部にというよりは自分のためという要素の多い内容でした。今後は定期的にこのような機会を設け、振り返りを実施したいと思っています。
更に向こうへ！Plus Ultra！！