リリースは問題なく完了しました。これをもって私の人生初プロジェクトも完了。来週からは休む間もなく基盤系エンジニアにシフトチェンジします。気持ちを切り替えていかないといけませんね。
新しい環境に気持ちを切り替えて臨むのも大切なことですが、プロジェクトを終えたら大抵の場合はそのプロジェクトについて振り返ることが推奨されています。たぶん、うちの会社に限らず、プロジェクト型の仕事をしている組織はやるんじゃないでしょうかね。その中でも有名なフレームワークがKPT法と呼ばれるものです。
KPT法とは、Keep・Problem・Tryの頭文字を取ったものです。プロジェクトを振り返って、良かったこと・今後も続けていきたいこと(Keep)、悪かったこと・問題点や反省点(Problem)、それらを踏まえ次にやっていきたいこと(Try)に分類し、今後に繋げていくための方法論です。一つの節目となったいい機会なので、個人的に振り返ってみます。なんか問題思い浮かばないですが・・・。
■Keep
・設計書を読み込んだ。
・便利ツールを何個か作った。
・お客さん先で説明、質疑応答をした。
・担当システムを納得いくまで操作した。
・進捗管理ツールを活用した。
・ToDoリストを活用した。
・問題が起こっても範囲を限定化し、暫定対処により対応できた。
・ソースコードを修正した。
・テストケース設計について勉強した。
・試験機器のエラー対処法を理解した。
・未経験の業務を他人から情報を集めて一人で遂行した。
■Problem
・他人への仕事依頼が遅かった。また、依頼の仕方が曖昧なことが多かった。
・設計の際に、曖昧な仕様、設計漏れ、両システム間の整合性エラー、既存仕様の踏襲誤りが目立った。
・試験項目作成時に観点漏れがあった。
・労働時間が長かった。
・ソースコードの品質を担保できていなかった。解読できなかった。
・試験シナリオの効率化が不十分だった。
・仕様に対するこだわりが弱かった。
・朝会があまり機能していなかった。
・スケジュールのリスケが多かった。
・インフラ周りの業務に対するチームの関心が薄かった。
・一人で仕事を抱え込みすぎた。
■Try
・わからないことがあったらまず設計書を読む。
・人手をかける必要のない作業は既存のツールを適用・もしくは自分で作成する。
・エラーと対処法を蓄積するための仕組みを用意しておく。
・チームの関心が薄い作業に対する重要性及びリスクを説明できるようになる。
・他者へ明確な指示(目的→成果物イメージ→方法・条件など)を出す。と同時に他者の結果の正当性チェック観点を検討しておく。
・仕事の依頼のGoサインは素早く、締め切りを明確に。
・既存を安易に踏襲しない。既存と類似の部分、既存と異なる部分を棲みわけた上で参考にする、という姿勢を貫く。
・業務の目的・業務フローを理解した上で仕様を定義する。どれがいいかを多角的に表して選ぶ。
・打ち合わせの目的を理解し、不毛だと感じたら、頻度を減らすか、無くすか相談してみる。(多分無理だけど。)
・試験項目数は品質水準の数値で満足しない。出せるだけ出して、後から削るか検討する。
・小さい作業もスケジュール化・タスク化しておく。
・Rv時にはチェック観点を作っておく。必要な資料もまとめておく。
・協働者任せにせず、わからないことを掘り下げて聞いていく。
まだまだ他にもありますけど、こんなところですかね。まぁ次はプロジェクトの特性とかも変わりますし(そもそも維持だし)、どこまで反省が役に立つかはわからないですが、こういうちょっと抽象化された教訓って案外いろんなとこで役に立つもんです。ダルいですけど、やっといて損はないと思います。
同業者の方はチームとしておそらく実施していると思いますが、チームでやるのは当然として、個人だけでやってみると本音が出せるのでオススメです。(チームでやると、ん!?それ本当にKeepなのか!?みたいな発言も出たりするので。)
ちなみに、KPT法をやっていて思ったんですが、何が良くて何が悪かったのかを後から振り返れるような材料を残しておけるのが理想ですね。チームが良かったと思っていることが本当に良かったのか、チームが悪かったと思っていることが本当に悪かったのか、感覚だけに頼ってしまうと危険ですからね。
まぁ、とりあえずは振り返ってみる、ということが重要だと思ってやってみるといいでしょう。