こんにちは suganoo です。
ミーティング中に自分のタスクを説明してる時に、自分なりの説明の型ができてきたなと感じました。
SESの形態で働いていると、技術的なところ以外はけっこう口伝で教わってるなと気づきました。
たまたまむかつくつ上司についたときに、いろいろと考え方やドキュメントの書き方を盗んだんですが意外と今にも生きてることに気づきました。
そこでちょっとした仕事の進め方のTipsを紹介したいと思います。
作業の目的理解に集中
まず作業や仕事をたのまれたら、いきなり手を動かさないことです。
- なぜこれをやるのか？
- なぜそういう状況になっているのか？
- どうなるといいのか？
など、頼まれた仕事の経緯をよく理解することが重要です。
昔の自分に言いたいのですが、中途半端な理解で作業をすすめると手戻りが発生して痛い目にあいます。
その上信頼も失う...。
どういう経緯でそれが起こったのかがとても大事です。
例えば分析用にデータを用意してほしいと言われて、すぐに出すよりも
誰がこのデータを見て判断するのかなどを考えると、もしかしたら実は違うデータを用意した方が説得力が増すかもしれません。
仕事の全体感をつかんで、自分はどの位置にいるのかを把握してから仕事を進めた方が一貫性もあり手戻りもすくないです。
あと作業目的の理解ができたらドキュメントの冒頭に書いておきましょうね。
仕事は必ず似たようなことを頼まれます。
その時に見返して、なんの目的でこれやってたんだっけ？とよく思いますから、未来の自分に役立ちます。
1か月前の自分は他人です。
説明資料の骨格を作る
上述で作業目的の理解が重要だと言いましたが、次にやることは、説明資料の作成です。
なんもしてないのにもう報告のことを考えるの？と思うかもしれません。
いやいやもう最初にどんな報告するか考えておくのがとても大事です。
仕事を頼まれたら説明責任を伴う。これ重要です。
もちろん簡単な作業だったらいらないですが、説明資料を作るのは心がけましょう。
今だとエクセルじゃなくてconfluenceなどの便利なサービスがあっていいですね。
ドキュメントの骨格として段落タイトルだけでもいいので構成を書きます。
自分のやり方をざっと書いてみます。
まず冒頭に作業の目的を書きましょう。
その後にどうやってその作業をやるか、作業方法を書きます。
そんで作業を実施したらちゃんとその効果がでてるよ、という確認方法を書きます。
ほらね大丈夫でしょ？っと担保するためです。
シンプルにそんなところかな。
機能検証や性能検証の場合は、比較する表も作りましょうね。
でここがポイントなんですが、この時点でリーダーか誰かにレビューしてもらっちゃいましょう。
「まだなにもしてないのに？」っと思うんですが、そもそもあなたが頼まれた作業のやりかたはほんとに正しいですか？
間違ったやり方してないか？やり方に無駄は無いか？検証だったら抜けてる観点はないか？など、それを確認してもらいましょう。
書いてるうちに説明資料として、これを入れた方がいいな、納得してもらうにはこっちの順番がいいなと修正していきます。
そうするとドキュメントの説得力が増してきます。
それをもって初めて作業に取り掛かるのです。
けっこうやることがはっきりしてスムースにいくかと思います。
抜け漏れが減るので説明資料に説得力が増しますし、この時点でドキュメント構成を書いてるので説明が楽になります。
あとこのレビューのいいところとして、もう一つあるんですが
関係者を連帯責任にできる、ってことがありますw
自分一人で明後日な作業をしてたら、「お前なに無駄なことしてんだよ！」っと怒られると思いますが、レビューしてからだと「やり方についてそういう合意がありましたよね？」っと責任を何割かまぬかれることもできますよw
そしてここで初めて細かい技術的なことを考え始めるのです。
最初から細部を考えてはいけません。
まず全体感を考えて͡コトを始めるのです。
こんな風にして自分は作業タスクとドキュメントを作っています。
ちょっとした工夫ですが何をするかの解像度が上がるんで、有効です。
またほかにいいやり方があれば記事にしてみようかと思います。
