業務へのアプローチ5ヶ条

自分に課す5つの約束を作りましたが、仕事中必死になるとすぐ忘れてしまうので
今後どこからでも見直せるように備忘録としてアウトプットします。

1. 「完了主義」であること

最初から100%を目指すと必要以上に時間をかけすぎたり、他のタスクが疎かになってしまいます。

仕事を依頼してもらったら

詳細に聞いた上でタスクを分解し （例：メモ帳に箇条書きしてから、パワポで分解）
それぞれに最適なアプローチを精査し （例：社内の技術資料・公式ドキュメント・Qiitaの記事・AIツールへの質問）
仮説・検証を繰り返しつつ進め、2~3割程度の進捗で依頼者へ方向性があっているか確認する

2~3割程度の進捗で、一旦依頼者の意図や方向性をしっかり確認します。
後戻りによる工数増加を防ぐためです。
高速道路と一緒で、出るゲートを一旦間違えると戻るのが大変です。

方向性の修正やフィードバッグを受けた際には「ゴールとなる成果物」をしっかり再確認した上で軌道修正します。

ゴール（着地点）の認識が合っていると確認できたら、引き続き タスクの分解、最適なアプローチの精査、仮説・検証 をしつつ作業を進め
それなりの完成度（7~8割程度）でいいので、一旦タスクを完了させます。

この時点では、コードや資料のチームレビューの際に 「どのような根拠をもってこの形にしたか」を明確に説明できる状態になっている必要があります。

「ここの処理どうなってんの？」と説明を求められたときに
「処理フローとしてはA→B→Cで、出力データはDです。」のように端的に解説できる状態がベストです。

また、あらかじめポンチ図や簡易的なフロー図を用意しておくと心強いと思います。

もちろん、色んな指摘・フィードバックを受けると思います。
それをしっかり受け止め、成果物をブラッシュアップさせていき完成度9~10割を目指すイメージです。

上司の話で興味深いなと思ったのが、 頭の中に自分ともうひとり別の「仕事の精度・正確性にめっちゃ厳しいもう一人の自分」を置く という話です。
仕事中、自分で自分の仕事を指摘しまくるそうです。めっちゃ疲れそうですが、精密さが求められる現場では特に有効と思います。

永遠の課題である「説明」については
伝わる説明を書くスキル

「仮説・検証」については
図解で思考整理（Future Clip by Fujifilm）
上記の記事が参考になると感じました。ぜひご参照ください。

2. 「優しさ」を業務・成果物に反映させること

抽象的ですが、要は 「この資料・説明は相手にとって分かりやすいのか？」「過不足はないか？難解な箇所への補足は足りているか？」を考えてあげるということ です。
コーディングの際にも、チームメンバーの為、もしくは未来の自分の為に丁寧なコメントを残しつつ進めてあげます。

システム図やフローチャートは「丁寧かつ正確に、かつ簡潔に」作成することが求められますが、あまり文字数を増やしても「冗長だ」と言われることがあります。塩梅が難しい話でもあります。
一例としてパワーポイントでの資料作成の場合は、 ページ数が多くなってもいいので1ページの見やすさを重視して作成してあげてください。
自分もフローチャートは1ページ2列までと決めています。

3. 相手のコミュニケーションコストを奪い過ぎないこと

どうしても業務中、分からないことが出てくると思います。

その際、上司や同僚に質問をすると思いますが、 「丁寧に、かつ簡潔に」質問してあげてください。

なぜなら あなたが質問したくなるような上司・同僚は恐らく有能で、有能ゆえに多忙であることがほとんどだからです。
こちらも少し工夫して、彼らの時間を少しでも節約してあげましょう。

自分の場合は

不明点はまず自分で精査する
それでも解決できなかった場合 「不明点・調査結果・調査しても不明だった点」の3つを簡潔にまとめたリストを作成する
上司・同僚にそのリスト + 自分の案をチャットやメールで、できればクローズドクエスチョン形式（Yes/Noで答えられる内容）で質問する

しっかり自分の案や調査結果を提示することで 質疑応答の時間が建設的なものになり、 有能な上司が疑問点をスムーズに解決してくれることを期待できます。

また その行為自体が自分の不明点、調査方法を可視化してくれるため 、不明点がより明確になり調査の精度が上がったり、質問する前にあっさり自己解決することもあります。

4. 業務において主導権を握ること

例として、業務を依頼された際に、既にかなり忙しかった場合。

仕事を振ってくれるというのは信頼されている証でもあるので、つい引き受けてしまいそうですが 「お急ぎでしょうか？今○○の業務で立て込んでいて...」と冷静に今の状況を伝えましょう。

また、 「何が終わったら終わり？」を含意するよう「自ら動く」ようにしましょう。
抽象的ですが、納期を依頼者・依頼される側のお互いがしっかり認識し合えるよう「自ら動く」ということです。
その納期を上司から提示してこない、もしくは無理がある納期の場合、こちらから現実的な納期を提示します。

上記を簡潔にまとめると「業務において主導権を握る」ということになります。

「何を偉そうに」と思われるリスクが微小ながらありますが、 依頼者から見ても業務の抱え込みすぎでパンクされるより数倍マシです。

また、納期等をこちら主体で管理することは、相手のタスク軽減にもなり優しさでもあります。

積極的に（偉そうと思われないギリギリの範囲で）業務の主導権を握りましょう。

納期管理は専用のフォーマット（ひな形）を作っておくと楽です。
コラムにて後述します。

5. 調べグセ・発信グセをつけ、それらを共有すること

つまり 「常に勉強し続けて、アウトプットし続けてね💛」 ということです。

耳にタコができるほど聞かされていると思います。すみません。
自分も業務中に、インプット・アウトプットの足りなさによる未熟さに気づかされる毎日です。

インプットに関しては、この時代色んな学習媒体があります。
プログラミング言語の基礎文法を学びたいといった初学者ならYoutubeやProgate、ドッドインストールとかいいんじゃないでしょうか。

実務レベルの知識のインプットだったら公式ドキュメントや他メンバーの作成した技術資料、Qiitaにいる猛者たちの記事等。

某AI様への質問もなんだかんだで役に立ちます。

ですがやはり座学では限界があり、 実務でトライ＆エラーをしていって、そこでノウハウを吸収していくのが遠回りなようで近道の気もします。

アウトプットも凄く大事です。
その行為自体が記憶の定着に効果的ですし、その資料が他の人の為になるだけでなく、未来の自分への備忘録にもなります。

アウトプットする場所は、Qiita等も適していますが
技術資料やノウハウ集を作成したら、部署内・会社内で共有してみてください。
~~業務効率向上への貢献とみなされ賞与査定もよくなるかもしれません。~~

アウトプットする箇所はノートでも構いませんが、基本的にはインターネット上に残すことをお勧めします。
なぜなら、例えばレシピコードなどは有識者から補足をもらえる可能性があったり、必要になった際コピペで時短を図れるからです。
（ノートに書き記した方が記憶に残るという方は、もちろんそれで全然OKです）

初学者には以下の記事が大変有益です。（ボリュームも凄いです。）
【11万文字越え】プログラミング初心者に贈る即戦力ガイド

コラム5つ

業務効率化に一定の効果がありそうなコラム的なものを5つ記します。

1. 仕事を「Must」と「Want」に分ける

業務が発生した時点で即座に振り分けます。
判断基準は 「そのタスクをやめて困るか否か」「急ぎか否か」 です。
自分はWindows標準搭載の付箋アプリをPC画面右端に常置させ、そこに箇条書きでメモしていつでも確認できるようにしています。

2. 時短・効率化のために時間を使う

例えば「自動で複数のcsvファイルのxx列の平均値を算出するスクリプトを作成する」「知識の幅を広げる（その知識に関して調べる手間の削減を図る）」などです。

専門としている方に頼る（委託する）ことも有効です。

特に時短の為にスキルアップすると、スキルアップに費やした時間なんて簡単にペイできます。

自分のメイン分野に関してはスペシャリストとなり、他の分野は浅く広く持ち合わせる T字型人材 が一つの理想です。

T字型人材に関しては下記記事が参考になります。
私が「つよつよエンジニア」になるまでにした７つの習慣

また インターネット上にある活用できそうな媒体は、徹底的に活用していくべきです。
車輪の再発明ほど勿体ないことはありません。

下記の記事たち（特にチートシート集）が大変参考になります。
【2024年版】エンジニア必見　生産性があがるチートシート集
 【開発効率爆上がり】すべてのエンジニアが必ず見るべき16のウェブサイト

某AI様に頼る場合、 調査内容についてサイドバーのタブ名を細かく分解して後で簡単に見返せるようにしておくと利便性が上がります。

（例）

上記の人（自分）は「プログラミング言語（ライブラリ）」みたいに分けてますね。

3. 自分用のマニュアルを作り、再確認の時間を減らす

資料作成、社外への連絡、コーディング、何が対象でも自分用のマニュアルを作っちゃいましょう。

（例）

#	手順	コツ・ポイント・連絡先など	使用App,DBなど	補足
1	モック作成（初期）	パワポで四角図形使って...	Teams（画面共有）+ PowerPoint	最低限のレイアウトのみ決定、機能等の詳細は別途

すぐにアクセスできるよう場所を分かりやすく名前付け・フォルダ分けします。

また、よく参照するサイトにもすぐアクセスできるようブラウザのタブに駐在させちゃいましょう。
グループ化するとアクセスが容易になるのでおすすめです。

(例)

4. 連絡の優先順位を明確化する

折衝業務がメインの方は、「連絡」する機会が非常に多いと思います。
業種によって異なってくるので一概に言えませんが、基本的な優先順位として

社外への電話連絡
社内他部門への電話連絡 or メール
社内自部門への口頭連絡 or チャット
議事録的なメール

連絡については、内容（エビデンス）確認の為に方法を組み合わせることが基本と思います。
口頭連絡した内容を文書として残すために後日メールを送信する、などが考えられます。

特に要件定義、仕様の詳細決めでは ヒアリング力（曖昧な要望を具体化する力） がとても重要になってきます。
細部まで要求仕様をヒアリングし、 補助的にパワポかなんかに箇条書きでメモしつつ、 内容が合っているか確認する目的も兼ねて画面共有しましょう。

Teams会議ではレコーディング機能もあるので、積極的に活用したいですね。

内容が重複しますが、問い合わせの場合はできるだけ クローズドクエスチョン形式（Yes/Noで答えられる内容） にしてあげます。

上流工程を担当している方に有益そうな記事を以下に貼ります。
要件定義～システム設計ができる人材になれる記事
 要件定義・プロジェクト企画に必要なネゴシエーションをロジカルに学ぶ記事

5. ToDoリストを作る際はやることを明確にし、作業時間を想定する

自分は以下のステップでToDoを作成しています。

タスクの作業内容をより具体的に
⇒ 「資料xxページのポンチ図に説明追加」のように細かく、不得手な分野は特に
作業時間を想定する
⇒ タスクの完了にかかる想定時間を記入する。甘く見積もりすぎないように注意
各作業に優先順位をつける
⇒ 作業の目安時間を決定した後、A~Cの優先順位をつける（A:最優先 B:できれば今日中 C:明日以降でも可など）
上記を納期が早い順にし、予定を仮決定
終業時に「実際にかかった時間」を記入する
⇒ 大きく差異が出た場合は原因究明し、今後の業務効率化・スキルアップの材料にする
※ 場合によっては、納期との兼ね合いを考え業務の進め方を再考慮する

（例）

#	✓	優先順位	タスク	想定時間	実績・振り返り	納期
1	✓	A	△社とTeams会議	45分	45分	-
2	✓	B	△さんに〇の件を返信	15分	10分	今日中
3		C	△向けUIのモック作成	90分	120分（要求通りの配置が困難、要相談）	4/5

Microsoft Officeを使用している方は、OutlookのカレンダーとToDoを併用することで上記のタスク管理が容易にできます。

以下は一例です。

レイアウト設定が豊富な為、自分がやり易い設定を探ってみてください。

上記コラムやアプローチについては、Fujifilmさんの運営する「Future Clip」を大いに参考しています。
とても為になるサイトです。以下にリンクを貼っておきます。