エンジニアがフルリモートで働く時の心得

こんにちは、抱えている案件にやっと終わりが見えてきていて、ちょっとテンションが上がってます。

そして、今回の案件が、フルリモート環境になって初めての大規模開発でした。

色んな壁にぶつかったけど、めっちゃ色んなことを学びました。

そこで、

・実際にフルリモートで大規模開発を行って学んだこと
・もっとこうした方が良かった

という反省点から

「フルリモートワークエンジニアの心得」としてまとめてみました！

フリーランスエンジニアになりたい方、フルリモートワークで働きたい方は是非参考にして下さい。

心得①コードレビュー前に実装内容を徹底的に共有する

コードレビューって時間が掛かる要因になりやすいんです、、、。

特に、フルリモートの場合だと、レビュワーと直接話す機会も限られてきます。

そのため、

・レビュワーからレビューが返ってくる時間
・レビューを修正する時間

これが、コードが多くなればなるほど長くなります。

このコードレビューの時間を短くする方法として

「コードレビュー前に実装内容を徹底的に共有する」方法があります。

コードレビューは、コードの量にもよりますが、

レビュワー：「これは何のための機能？」

レビュー依頼者：「これは〇〇するための機能です」

という機能説明にかなり時間を割きます。

そして1番恐ろしいことが、レビュー合格後、運用してみて全く違う機能を開発していた。

ということです。(私は無いですが、知り合いにはちょいちょいある様子)

この2つの原因の解決策は

「コードレビュー前に実装内容を徹底的に共有する」ことです。

そうすると、機能説明の時間やレビュー後の修正量を減らすことができます。

さらに、開発ミーティングにレビュワーの方と参加したり、早い段階から開発の相談をすることによって、

開発後の勘違いを防ぐことができます。

開発の鍵はコードレビュー前に決まるのかもしれません。

心得②メンバーのポジションを把握する

フルリモートの場合、質問はスラックやチャットワークなどのコミュニケーションツールで行うことが多いです。

その時に、

「これ誰に質問すると良いんだっけ？」状態になることがあります。

一度質問をして、コメントを待つやり方もいいのですが、

新しくメンバーに加わって間もない時に質問する時などは、これが意外に質問する時の障壁となんです。

そこで、「事前にメンバーのポジションを把握しておく」ことが重要になってきます。

例えば、案件で

①システム文言やエラーメッセージの修正
②新しい機能を追加するために新しいテーブルを追加する

この2つを実装する場合

①の場合は比較的軽微な修正で、コードレビューも1人で十分な想定。

しかし、②の場合はシステム全体に影響する大規模な開発になる。

そのため、コードレビューも実装内容も複数人を巻き込んで開発する必要がある。

と予想できます。

ざっとポジションを分けると

①＝開発メンバーで手が空いている人
②＝プロジェクトマネージャーや技術顧問などの熟年エンジニア

といったところでしょう。

ここで、全体の開発メンバーのポジションを理解できていれば、

チャットのDMやメンションをある程度絞って質問することができます。

また、開発メンバーに加わって間もない時、担当ポジションが曖昧な時には、

「〇〇さんに質問する内容とは思いますが」など、ある程度自分で担当を予想した文面を付け足すといいかもしれません。

その方が、この質問を機に担当を教えてもらいやすくなるので。

些細なことではありますが、知っておくとかなり仕事がスムーズに進むので、メンバーのポジション把握は重要です。

心得③「課題化は最速に」を心がける

フルリモートになると、特にタスク管理ツールの活用方法が超重要。

タスク管理ツールにはバックログやノーションなど、様々なツールがあります。

細かい使い方はツールによってバラバラだが、共通して言えることがあります。

それは、「課題化は最速にする」ことを心がけた方がいいということ。

ミーティングやメッセージなどで開発の相談や調査依頼が来た時、当然それを進めます。

しかし、「できたらやる」の認識だったら、進まないことが多いんです、、、。

特に、「相談」や「ちょっと大規模な改修・機能追加」などは、「できたらやる」の認識になって、ツンツンと突かれないと進捗を進めない状況になりがちです。

だいたい、この原因は

・ゴールが見えにくい
・どこに手を付けていいか分からない

ことがほとんど。

例えば、

「いつか〇〇機能を追加したくて、その時に影響がないか」という相談があった場合。

どこまでがゴールかイメージしにくい。

そして、そのまま放置状態になり、「あの件どうですか？」と聞かれた時に大慌てする運命に。。

そこで、重要なことが「課題化」です。

「いつか〇〇機能を追加したくて、その時に影響がないか」という相談があった時点で、一度タスク管理ツールで課題化します。
(タイトル：「〇〇機能に伴う影響範囲」)

すると、「影響範囲を伝えたらいいか伝えた時点で完了」というゴールが見えてくるはず。

そこからは、

・機能が実装される予定を把握
　　→実装ロジック、画面

・既存の機能に対する影響範囲の調査
　   →テーブル追加、カラム修正はあるか？
　　  不都合が生じる部分はあるか？(画面エラー、ロジックが対応できていない)
　  →コードのリファクタリング

ざっと分けてこれくらいの作業が細分化できます。

あとは、作業に応じてさらに子課題を設定してもいいと思います。

しかし、課題を追加する際は課題管理の担当者に許可を得てからがいいでしょう。

この「課題化」することによって、「ゴールする意識」が生まれるはずです！

心得④開発の「概念」を聞いておく

リモートワーク限定ではないが、開発を行う上で

・システム開発が早くなる
・勘違いによる開発事故の防止

に繋がる心得があります。

それは、開発の「概念」を聞いておくこと。

開発環境、エリア環境、開発作業など

「なぜ、このように設計したのか」

「なぜ、このような開発作業を行っているのか」

という概念が存在します。

しかし、小規模の開発や作業(主にgit関係)は概念を理解していなくても作業できてしまいます。

簡単で影響範囲が少ない場合はそれで問題ないでしょう。

しかし、開発規模が大きくなるに連れて概念を理解していないと、見当違いのシステムを開発してしまう可能性があります。

特に怖いのがgitなどのバージョン管理つーるを行う時です。

gitの操作は簡単で、コマンドを覚えてくと作業ができます。

しかし、gitなどのバージョン管理ツールは、開発環境だけでなく本番環境のソースコード管理にも使われます。

そして、難しいのが「gitのコマンドは限られているが、選択肢は案件ごとに違う」ことです。

もしも本番環境や開発環境に対してgit作業中に予期せぬエラーが発生したとしましょう。

その時に、開発環境や本番環境の概念を理解していないと、

「どの作業を行ったら良いか分からない」という状況になりやすいんです、、、。

「概念」の話になると、環境構築や設計の高い知識が必要なため、理解するのは難しいと思います。

しかし、概念を聞いて「なんとかくこうかなぁ」と予想を立てておくだけで、開発の質はかなり向上するでしょう。

そのため、日頃から開発の概念を考えることはかなり重要です。

フルリモートは自分で工夫することが大事

フルリモートエンジニアになって数ヶ月が経ちました。

案件に参画する前は、

「自分のスキルは大丈夫か？」

「フルリモート環境でやっていけるか」

など、漠然とした不安を抱いてました。

しかし、実際にやってみるとかなり楽しい環境でした。

そして、気づいたことがフルリモート環境では「自分で働き方を工夫することが大事」だということ。

確かに、エンジニアとしてのスキルは大事ですが、

相談や開発の協力をお願いする時には、開発スキルとは違った工夫が必要です。

さらに、フルリモートの働き方を採用している企業が少ない今日この頃。

「この進め方が自分には合っている」という進め方に出会うまでは、ある程度試行錯誤が必要です。

「自分で工夫する」というと、大変なイメージを持ちますが、実際にやってみるとかなり楽しいです。

だって、働き方を工夫するなんてなかなかできない体験だから！

今回の記事がどなたかのお役に立てば幸いです。

最後まで読んでいただきありがとうございました。