目次
- はじめに
- 心に刻んでおきたい言葉
- 1.自分の中で答えを持って仕事をする
- 2.全体が見えていない作業から取り掛かる
- 3.誰が読むドキュメントなのかを明確にする
- 4.いきなり100点を取ろうとしない
- 5.顧客の要望に応えているだけではダメ
- 6.何かあれば即なぜなぜ分析
- おわりに
はじめに
こんにちは。某スマホアプリのバックエンド開発をしているアラサーエンジニアです。
以前配属されていたプロジェクトに、かなりできるPLの方（Hさん）がいました。
当時の私はプレイングマネージャーとして、Hさんの下で開発チームのリーダーをやっていて、Hさんからビシバシありがたいご指導をいただいていました。
そのおかげもあって、人間的にもエンジニアとしてもかなり成長できたと思うので、その際に言われたことを忘れないように、つらつら書いていこうと思います。
今回は特に要件定義や進捗管理のようなテーマはなく、PLから教わった仕事をする上で大切なことをまとめました！
（当初は５つ言葉の予定でしたが、６つになってしまいました。。）
■これまでに書いた関連する記事↓↓
●１つ目の記事
過去にPLから言われた心に刻んでおきたい５つの言葉【要件定義編】
●２つ目の記事
過去にPLから言われた心に刻んでおきたい５つの言葉【進捗管理編】
●３つ目の記事
過去にPLから言われた心に刻んでおきたい６つの言葉 ←今ココ★
心に刻んでおきたい言葉
1.自分の中で答えを持って仕事をする
１つ目の言葉は「自分の中で答えを持って仕事をする」です！
仕事をしていると、「わからないこと」や「複数の選択肢があり１つに絞らないといけない状況」が必ずあります。
そんな時、ただ「教えてください」や「どっちの選択肢にしましょうか？」と聞くのではなく、まずは自分の中で「答え」と、その答えに至った「根拠」を明確にしましょう。
自分の中で答えのないまま、上記のような当事者意識の無い質問をされると、質問された方は「自分で考える気があるのか？」と思ってしまいます。
それにいつかは、自分が責任を持って決断しなければならないポジションに立つ時が来ます。
その時のための練習の場だと思って普段から、自分の中で答えを持って仕事をしましょう。
その「答え」や「根拠」は間違っていても構いません。一度自分で考えて答えを出すことが重要なのです。
良い質問の例：
「〇〇という理由で□□だと思うのですが、認識は合っていますか？」
「〇〇という理由で□□の選択の方が良いと思いますが、どうでしょうか？」
2.全体が見えていない作業から取り掛かる
２つ目は「全体が見えていない作業から取り掛かる」です！
仕事をする上では、各作業に正しい優先順位をつけることが非常に重要です。
たくさんの作業の中には、全体がまだ見えておらず、どれくらい時間がかかるのかわからない作業もあるかもしれません。
そんな時は、まず全体が見えていない作業から取り掛かるようにしましょう。
別にその作業を最後までやり切る必要はありません。
どれくらいで終わるのか規模感がわかるところまで作業したら、後は再度優先順位を検討して然るべきタイミングで対応すれば良いです。
作業自体の優先度が低いからといって、どれくらいで終わるのかわかっていない作業を最後まで放置しておくのは危険です。
期限まで後２日しか残っていないけど、いざ始めてみたら５日かかる作業でした。。となりかねません。
早い段階で期限に間に合わないことがわかっていれば、いくらでも対処できます。
基本的に優先度が同じなら、早く終わる作業を優先して行なった方が良いですが、それは全ての作業の規模感を把握してからの話です。
まずは全体が見えていない作業に取り掛かり、全ての作業の規模感を明確にすることを最優先にしましょう。
3.誰が読むドキュメントなのかを明確にする
３つ目は「誰が読むドキュメントなのかを明確にする」です！
仕事をしていると、SEでもプログラマでも何かしらのドキュメントを作成することがあると思います。
ドキュメント作成に取り掛かって１番初めに考えることは、このドキュメントを読むのは誰かです。
ここで言っている「読む人」はレビュアーのことではありません。実際にドキュメントを活用する人のことを指しています。
誰が読むのかを明確にすると、ドキュメント内で使用する言葉も自然と変わってくると思います。
極端な話ですが、日本語を読めない外国の方向けのドキュメントを日本語で書いても意味ありません。
テスト仕様書だったら読むのはテスターの方ですし、詳細設計だったら読むのはプログラマの方でしょう。
例えば、テスターの方がテストするアプリケーションについて詳しい人であったら、テスト仕様書内でアプリケーション固有の用語を使ったり、1から100まで説明しなくても理解できますが、そうで無い場合はある程度細かく記載しておかないと、テスト実施中に質問攻めに遭い、自分の作業ができなくなるかもしれません。
まずは誰が読むドキュメントなのかを明確にして、「読む人に伝わる言葉」や「読む人の知識・理解度」を考えながらドキュメントを作成するようにしましょう。
4.いきなり100点を取ろうとしない
４つ目は「いきなり100点を取ろうとしない」です！
ある作業が完了し、成果物をレビューしてもらったら依頼者の思っていたものと違っていた。。という経験はないでしょうか？
自分も昔はよくありました。
いきなり100点を出そうとし、割り当てられた全工数を使って成果物を作成すると、もし成果物が依頼者の求めていたものと全然違っていた場合に手戻りが大きく、リスケするか残業して対応するしかない。。といった状況になります。
それを防ぐためは、こまめにレビューをしてもらうのが一番です。
成果物の大枠や方針を決めたらまずレビューし、全部完成したらまたレビューです！
慣れていない作業の成果物だったり、成果物の規模が大きい場合は、半分くらい進めたら二度目のレビューをしてもらうのも有りかと思います。
レビューを複数回設けることで、「レビュアーの稼働を奪ってしまう」と心配になるかもしれませんが、間違ったまま突き進んで手戻りが発生するよりは断然良いです。
まずは60点くらいを目標に大枠を作成してレビューを受けて、徐々にブラッシュアップして100点を目指していきましょう！
5.顧客の要望に応えているだけではダメ
５つ目は「顧客の要望に応えているだけではダメ」です！
仕事をしていると、顧客から「この機能も欲しい」「あの機能の仕様を変えたい」などの要望が開発のフェーズも関係なしに飛んでくるかと思います。
その要望を何も考えず、顧客の言う通りに「はいはい」と聞いていてはダメです。
顧客だって、深く考えずに思いつきで要望を出している可能性があります。
要望が出たら「本当にその要望が必要なのか」、また仮に「この要望に応えたらどのような影響があるのか」を考えましょう。
思いつきに振り回されて必要のない機能に工数を割いてしまったら、本当に必要な機能にかけられる時間が減ってしまうかもしれません。
またあなたがリーダーだったら尚更、メンバーを守るためにも顧客の突拍子もない要望には「No!」と強く言えなければなりません。
その要望を引き受けることでチームの作業量が増え、メンバーに辛い思いをさせる可能性があります。
中にはマストな要望も勿論あるかと思いますが、ただ何も考えず引き受けるのでは無く自分で必要性を考え、「本当に対応しなければならないか」を判断するようにしましょう。
6.何かあれば即なぜなぜ分析
最後の６つ目は「何かあれば即なぜなぜ分析」です！
なぜなぜ分析については「過去にPLから言われた心に刻んでおきたい５つの言葉【進捗管理編】」でも出てきましたが、やはり仕事をする上では欠かせない思考だと思います。
仕事をしていると上手くいくことばかりではありません。（むしろ失敗の方が多いのでは。。）
一度目の失敗は「しょうがない」で済ませることができるかもしれませんが、二度目の同じ失敗は致命的です。
それを防ぐことができるのがなぜなぜ分析です。
なぜなぜ分析は難しく、私も上手くできている気はしませんが、意識しているポイントをあげたいと思います。
●ポイント
・なぜなぜ分析をする対象の問題が具体的であること
・なぜの回答が簡潔で具体的に書かれていること
・なぜの分岐を１つあげて満足しないこと（複数の視点から考える）
・なぜなぜ分析のツリーを逆方向から「xxだから○○した」と読んでも意味が通じること
・なぜなぜ分析で明確になった根本原因の対策が具体的であること
・特定の個人の問題にしていないこと（個人ではなく組織・仕組みの問題と捉える）
何か問題が発生した場合は勿論のこと、上手く行った場合にもなぜ上手く行ったのかを考えると、自身の成長にも繋がるかと思います。
何かあったら、記憶が新しい内に即なぜなぜ分析をして未来の自分を楽にしてあげましょう！
おわりに
以上が、「過去にPLから言われた心に刻んでおきたい６つの言葉」です。
これまで３つの記事を執筆してきましたが、それぞれの記事で言いたいことを全てまとめることができたと思います。
自分でも定期的にこの３つの記事を読み返して、ずっと忘れないように心に刻んでおくつもりです。
色々なことを教えてくれたPL（Hさん）には本当に感謝しています。
次は自分が他のメンバーや後輩に、これらの教えを伝えていきます！
