はじめに
この記事では、競技プログラミングからプログラミングを始めた「なんちゃってエンジニア」が、エンジニアとして給与を頂く「駆け出しエンジニア」にステップアップする過程で学んだ「仕事の進め方」を、エンジニアらしくアンチパターンで紹介したいと思います。
ただし、この記事の「仕事の進め方」は、「質問の仕方」や「公式ドキュメントの読み方」といった小手先のテクニックではありません。
もっと重要な「仕事への向き合い方」を整理したうえで、具体的なアンチパターンを紹介します。
「仕事への向き合い方」とは、「何のために働くのか」「どうやって働きたいか」「仕事への熱量」といった複合的な観点から定義される、仕事に対するマインドや態度のことです。
仕事を円滑に進めるためのテクニックを紹介する本などは、この観点と断絶してテクニックを紹介していますが、この記事ではこの部分から共有します。
そもそも、なぜ世の中には小手先のテクニックについてまとめたコンテンツが溢れているのでしょうか？
それは、「ベストプラクティスがない」からですね。ではなぜ、「ベストプラクティスがない」のか？
それは、テクニック以前の部分、「仕事への向き合い方」が千差万別だからです。
「仕事への向き合い方」が違えば、その人なりの「質問の仕方」、「マネジメントのやり方」も当然違ってくるはずです。
例えば、皆さんの友達に、いつも冷静で思慮深い、部下想いの人がいたとします。
この友達が「部下のマネジメントは叱ってナンボ」という内容のテクニックを学んで実行するとしたら、どう思いますか？
「ちょ、待てよ！」と、キムタクばりのツッコミをカマしたくなりますよね？
ということで、この記事では、もっと抽象的な、仕事に対するマインド、向き合い方から提示したうえで、抽象度を下げていくことで「仕事の進め方」を考えてみたいと思います。
ぜひ、この記事を通じて自身の持つそれらについて再考するきっかけにして貰えれば幸いです。
私の「仕事への向き合い方」
この章では、私がどのようなマインドで仕事にあたっていたか、という大前提の部分を整理しておきたいと思います。
存在理由
「なぜ自分がこの会社にいるのか」という部分です。これは、自分の理由と、会社側の理由の2つがあり、働き手としては給与を「報酬」として頂いている以上、会社側の理由も汲みとるべきでしょう。
私にとっての存在理由は「上司のマネジメント能力と技術力が高く、成長できる環境だから」ですが、会社側はなぜ自分を雇用したのでしょうか。
それは、おそらく私が「投入したコストに対して見合ったアウトプットを出す見込みがあるから」ではないかと思っています。
なぜなら、会社は何かしらの成果をだして、その対価を誰かからもらって売上を生み、成果を生むためのコストとの差分が利益となります。
その成果を出す際のコストとして、私を雇用している、と考えるのが妥当だからです。
そして、「アウトプットを出す」ということは、任される事業・PJを前へ進めることに他なりません。
以上の経緯から、私は「事業・PJを少しでも前に進めるため」に雇われていると考えています。
心構え
次に、私の心構えを説明します。
先輩・上司に対して
基本的に自分からする質問や仕様確認といった連絡は、上司・先輩にとって時間の無駄以外の何物でもないと思っています（案件に慣れてくると齟齬を指摘できたりもするので、「基本的に」）。
心に刻んでいるのがこの小島教授のツイートです。
学生さんの質問とか研究の話し合いとか、企業などアカデミア外の方からの相談などもちろん歓迎です。でも無駄な事務作業や会合のための会合とかには憎悪を持って接します。僕の時間を３０分使ったら３０分だけ世界の科学の進歩を遅れさせているということを認識して欲しい。
— Fuhito Kojima (@fkojima79) March 7, 2024
要するに私は、先輩や上司の時間を自分の連絡で時間を取ることは、その時間だけ案件の進行を遅らせることに直結している、という認識を持っています。
そのため、私が上司・先輩と連絡するときはとにかく相手に時間を取らせないことを念頭においてコミュニケーションを取っています。
自分自身に対して
案件にアサインされてすぐは特に、「自分は使えない足手まといだ」と言い聞かせていました。
それでも給与は頂いているので、少しでもPJを前へ進めるために、どんな手でも使おう、という態度です。
具体的に取ったアクションを紹介すると、実装面やAWS周りのわからないことは、同じPJにアサインされていないが、話しやすい上司・先輩を捕まえて質問したり、細かい質問はChatGPTに聞いたりして時短を図りました。
理想像を捨てる
案件へのアサイン当初は、「ああ、今日も十分なアウトプットが出せていない…」と、自分自身に失望することが多々ありました。
しかし、私は、「私」ではなく、「ぼくの考えた最強のエンジニア」が出せるアウトプット量を理想とし、高すぎる理想と現実のギャップにもがいていました。
イチロー選手の名言で、こんなのがあります。
人より頑張るなんて事はとてもできないんですよね。
あくまでも秤(はかり)は自分の中にある。それで自分なりに、その秤を使いながら、自分の限界を見ながら、ちょっと超えていく。ということを繰り返していく。そうするといつの日かこんな自分になっているんだっていう状態になって。だから少しずつの積み重ねが、それでしか自分を超えていけないと思っているんですよね。
一気に高みにいこうとすると、今の自分の状態とギャップがありすぎて、それを続けられないと僕は考えているので。地道に進むしかない。進むだけではないですね、後退もしながら。ある時は後退しかしない時期もあると思うので。でも自分がやると決めたことを信じてやっていく。引用：https://www.nikkansports.com/baseball/mlb/news/201903220000431.html
もちろん、高い目標・理想を描くことも大切ですが、自分の力量を正確に把握し、それを超えられる範囲で超えていくことが堅実で、唯一の道であると解釈しました。
なので今では、自分のできることを見極め、着実に目の前のことをこなしていくことを意識しています。
「仕事の進め方」アンチパターン
私の「仕事への向き合い方」を整理できる範囲でまとめてみました。
ここからは具体的なアンチパターンを紹介していきます！
コミュニケーションの取り方
まず、エンジニアである以前にビジネスマンとして、「ホウレンソウ」のアンチパターンを見ていきたいと思います。
前提として、上司は自分よりもできること・知っていることが多いです。ひよっこの自分からすると神様です。
なので、とにかく上司の心理的・物理的コストを最小化することに重点をおいたコミュニケーションをします。
進捗報告
ゴキブリと同じで、上司が一度進捗確認をするとき、少なくとも100回は進捗が気になっています（自分調べ）。
そして、その進捗が気になるのは雑念以外の何物でもありません。進捗管理で上司の心理的リソースを消費しないようにしたいです。
そのため、タスクが振られた段階で、その概要と道筋を可及的速やかに見通し、どのくらいで完了するか、見込みを報告するようにしましょう。
はっきりと見通しが建てられないときは、タスクの内容整理を自分なりに行ったうえで上司に確認してから、見込みを報告します。
連絡
自分の中で難しいと思っているのはコレです。相手の知りたいであろう情報とセットで回答する、まさに言うは易く行うは難しです。
1つ大きな気付きだったのは、即レスは必ずしも正義ではないということです。
一瞬で上司の質問に回答できても、上司が知りたい情報を追加で質問してきて、回答して、というループが続いていたら、結果的に物理的なコストは大きいです。
それよりは、多少回答まで時間をかけても、適切な背景情報を追加して回答できると、信頼関係の構築にも繋がり、上司が自分に連絡する際の心理的コストを減少させる効果も見込めます。
相談（イレギュラーが起きた時）
上司と認識合わせをしていても、外部サービスの仕様などで想定外が発生することはままあります。
こうしたとき、当初の予定よりもタスクの完了が遅くなる場合も考慮しなければなりません。
直面した問題の大きさを推定し、見込みよりも時間がかかりそうな場合は、想定外の内容と対応方針を記述したうえで、修正した終了見込み時間を報告しましょう。
報告のメッセージを書いていたら頭の中が整理されて、より良い方針を思いついたりもするので、塞ぎ込み過ぎないことが大切です。
例のように、恐る恐る報告してみたら、簡単に解決できたりもします。上司しか勝たん。
実装の進め方
続いて、実装の進め方にまつわるアンチパターンを紹介します。
大原則は「揃える」です。
参考リポジトリや既存コードの特徴（ファイル名の付け方、ディレクトリ構成など）を正確に把握することが大切です。
コーディング
既存のコードを参考にしていない
例えば、既存のコードが以下のようになっていたとします。
def generate_product_data_replace_monthly_query(month: str) -> str:
"""
Generate SQL query to replace product data for a given month.
:param month: The month in 'YYYY-MM' format for which the data should be replaced.
:return: SQL query string
"""
sql_query = f"""
DELETE FROM product_data
WHERE month = '{month}';
INSERT INTO product_data (month, product_id, quantity, price)
SELECT month, product_id, quantity, price
FROM product_data_staging
WHERE month = '{month}';
"""
return sql_query
これに対し、作成したコードが以下のようになっていたら、どうでしょうか。
def create_monthly_user_update_query(target_month: str) -> str:
delete_query = f"DELETE FROM users WHERE month = '{target_month}';"
insert_query = f"""
INSERT INTO users (month, user_id, actions, points)
SELECT month, user_id, actions, points
FROM users_staging
WHERE month = '{target_month}';
"""
return f"{delete_query}\n{insert_query}"
（参考コードの善し悪しは別として）ファイル名の付け方に加え、コメントはついてない、クエリもバラバラになっている、引数名も違う、、、蕁麻疹が出そうですね。
一人で開発をしているわけではないので、コードの統一性を持つように心がけましょう。特に、ファイル名や引数・変数名の付け方にはこだわりましょう。
コードの統一性を意識し、既存のコードを参考にする。
もう一つ、コーディングの際に気をつける点があります。それは、時間をかけすぎないことです。
特に、エンジニアとして日が浅いと、どこをこだわるべきか、という箇所がわかりにくいこともあります。
そのため、完璧を目指して細部にこだわりすぎると、時間がかかりすぎてしまうことがあります。
重要なのは、プロジェクト全体の進行を見失わずに、適切なタイミングで細部の修正や最適化を行うことです。
結論として、アウトプット先行で進め、細部は随時埋めていくのがベターです。
GitHub（ソースコード管理ツール）
PJ・事業特有の固有のルールを尊重しない
GitHubを使用するときも、「揃える」ことを意識して使います。
特に、ブランチ名やコミットメッセージ、プルリクエストの概要の書き方などは、案件によって固有のルールがあったりします。
例えば、ブランチ名のプレフィックスのあとはタスクの番号をつけたり、コミットメッセージは必ず英語で記述する、などが想定されます。
GitHub周りはリモートにPushしてしまうとかなり面倒なことになるので、事前に確認しておくことが極めて大切です。
固有のルールを事前に把握し、その通りに使用する
ChatGPT（生成AI）
ChatGPTをなんのために使うのか明確にせず、使用する
未経験からエンジニアになった私にとって、ChatGPTは大きな助けとなりました。世間では、「初心者は使うべきではない」と言う人もいれば、「初心者こそ使うべきだ」と言う人もいます。
私の結論は、使うことで仕事が進むなら使ってOKです。ChatGPTを使わないより、使ったほうが早く実装が進み、プロジェクトも前に進むのであれば、積極的に使うべきです。ただし、逆に使いすぎてしまうと、実装のロジックが理解できなくなったり、予期せぬエラーが発生したりすることもあります。そういった場合には、使うのを控えるべきだと思います。
なぜなら、私が雇われているのは、プロジェクトを前進させるためであり、この目的達成のために使えるものは活用すべきだと考えているからです。
目的意識を持って使う。
発展編
「面倒を見る」側に回ったら
案件が進んでいくと、自分よりも後にアサインされる人もいます。こうしたとき、どのように対応していたかについて、発展編として紹介します。
調子に乗らない
（画像は調子に乗っていますが）最も意識するべきことは、プロジェクトに早くアサインされてドメイン知識が少しついているだけだと常に自分に言い聞かせ、決して偉そうな態度を取らないようにすることです。
偉そうな態度や、高圧的な態度は、後輩を萎縮させることに直結します。
一方で、事業・PJを前進させるためには、後輩にできる限りのアウトプットを出して貰う必要があります。
そのうえで、調子に乗ってしまうと、後輩の円滑なキャッチアップ、ひいてはタスクの実行が滞ってしまいます。
後輩には、感謝と慈愛の心を持って接しましょう。
タスクは抽象度を下げて渡す
後からアサインされた人に期待しすぎる
後輩が自分と同じ熱量やモチベーションで仕事に取り組むことを期待するのではなく、それぞれの仕事への向き合い方が異なることを前提に、始めのうちは必要以上と思われるくらいのサポートを行うべきです。後輩の仕事が予定通りに進まない場合は、振っているタスクの難易度や振り方を再考する必要があると言えます。
具体的なアクションとして、後輩にタスクを渡す際は、上司から自分にタスクが回ってきた時点で、その内容をしっかりと噛み砕き、抽象度を下げるサポートを行う事ができます。仮にタスクが直接回ってこなかったとしても、自分から積極的に関与し、後輩が理解しやすい形に変えれば、上司と後輩の意思疎通のための時間的コストを軽減できます。
自分が上司と後輩の間に立つ立場であるからこそ、上司に対して行っていたよりも細かい質問や不明点を後輩から受け取れる事ができます。この立場を活かして、後輩が安心して質問できる環境を作り、より粒度の細かいフィードバックやサポートを提供することが重要です。
上司の仕事を奪う意識を持つ
ずっと同じ仕事をしている
後輩ができてくると、細部の仕事（コーディングなど）は次第にアウトソーシングできるようになっていきます。そのため、より抽象度の高いタスク、つまり上司や先輩が担当していたタスクを積極的に取りにいく意識を持つことが大切です。最終的には、案件の統括まで視野に入れ、自分がその役割を担うことを目指します。
こうすることで、自分より優秀な上司がより上流の仕事に集中する時間が増え、結果として会社や事業の成長にも繋がります。
おわりに
「仕事への向き合い方」から始める「仕事の進め方」はいかがだったでしょうか？
仕事に取り組む際に、まず自分自身の向き合い方を見つめ直すことで、進め方にも新たな発見が生まれることがあります。また、単にタスクをこなすのではなく、どのように向き合うかを考えることで、仕事に対するアプローチが変わり、結果的に効率や質が向上することもあると思います。
皆さんもぜひ、「向き合い方」から始めて、自分にあったスタイルの「仕事の進め方」を見つけてみてください！
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。
また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。