【初心者必見】エンジニアの理想の仕事環境を考察してみた！

2021年6月20日2021年7月3日

こんにちは、はるまきです。エンジニアにとっての理想の仕事環境ってなんでしょうか？

この記事は次の人を対象にしています。

今回は、名著である「科学的な適職」を参考に、エンジニアの理想的な仕事環境を考えました。エンジニアとして3年目のまだまだ若い意見ですが、参考になると幸いです。

この記事を読むと以下のことが分かります。

それでは早速参りましょう。今回は仕事の幸福度を決める7つの項目を参考に考えていきます。7つの項目は以下です。

1,【自由】その仕事に裁量権はあるか？

まず初めにこちらです。その仕事に裁量権はあるのか？これは勤務時間や、作業を実行するスケジュール管理、タスクの内容についてどれほど自分に決定権があるかということです。

エンジニアの仕事に当てはめて考えます。

まず勤務時間については他の職種と変わらず、基本的には勤務時間が決められていることが多いです。自社開発を行なっている企業であればフレックス制を導入しているところが多いかと思います。フリーランスでは成果物によって報酬が支払われる契約であれば好きな時間に働くことができるかもしれません。※ただフリーランスでも実際に出勤して出勤時間が決められている人の方が多いかと思います。

次にスケジュールやタスクの内容について考えます。これらは開発スタイルで比較したいと思います。ウォーターフォール開発と、アジャイル開発の2つで大きく分けたいと思います。私自身、どちらの経験もあります。

ウォーターフォール開発ではタスクがきっちりと決まっている場合が多いです。実装者であれば上流でガッチリ決まった仕様や詳細設計に従ったり、テスターであればガッチリ決まったテスト仕様書に沿ってテストを実施します。フォーターフォール開発の場合、裁量権は若手のうちはほぼないと思います。熟練でもプロパーでない限りはほとんどないかと思います。

それに対してアジャイル開発では機能単位でタスクを振り分けられます。(私は今までこのスタイルを経験)

PM:「どれくらいでできそうですか？〇〇までにお願いします〜」(結構これが辛かったりするんですが….。)

的な感じで作業を始めることになります。なので実際の具体的なタスクは自分で洗い出して見積もったり、どの順番で作業していこうかを考えることになります。ある程度裁量権があると言えるかと思います。アジャイル開発の場合は、意見することが可能で通ることがウォーターフォールに比べると多いです。自分が担当する機能についてはチームの誰よりも自分自身が理解しているので、その機能についての意見であれば発言力が強いかと思います。

スケジュールに関してはウォーターフォール開発もアジャイル開発もあまり変わらないと思います。結局、納品日やリリース日が決まっているので、大幅なリスケジュールはできません。

また、全てのプログラマーに言えることですが、コードのロジックだけは自分に絶対的な裁量権があります。

「プログラマが知るべき97のこと」でよい記事がありましたので紹介します。

ソフトウェア会社で長年働いた経験から、1つわかったことがあります。それは、良いプログラマとそうでないプログラマの違いです。両者の最大の違いは「取り組む姿勢」にあります。良いプログラマの姿勢は、プロフェッショナルという言葉にふさわしいものです。常に、最大限の力を尽くして良いコードを書こうとします。リソースの制約のある中、早く作業を終わらせろと会社が圧力をかけてくる中、それでもできる限り良いコードを書こうと努力をするのです。

プログラマが知るべき97のこと [良いプログラマになるには]

まとめます。

2, 【達成】前に進んでいる感覚は得られるか？

最近の研究では「小さな達成」が仕事のモチベーションを左右することが科学でわかってきたらしいです。

エンジニアは、職業柄、前に進んでいる感じは必然的にする作業だと思います。コーディングはもちろん、UI設計や仕様書作成、テストに至るため、進捗が目に見えやすいです。エンジニアは概ね、常に前に進んでいる感じはあるかと思います。

ただ、何かにハマって問題が解決できない時には注意が必要です。時間だけがすぎ、進捗もないのでモチベーションが下がります。何時間もハマってしまうくらいなら勇気を出して素直に誰かに聞くべきと私は思います。聞く人がすぐ近くにいる環境や、聞きやすい文化は会社やプロジェクトによって変わってくるかと思います。その点は環境選びの際に注意するべきかと思います。

また、チーム全体で今どれくらいの進んでいるのかを可視化できるツールを導入することもモチベーションUPに効果的だと思います。おすすめはTrelloです。

3,【集点】自分のモチベーションタイプにあっているか？

「科学的な適職」では人間のパーソナリティを2タイプ(攻撃型、防御型)に分けて、考えます。

攻撃型：目標を達成して得られる「利益」に焦点を当てて働くタイプ。競争に勝つのが好きで、金や名誉などの外的な報酬強い影響を受ける。常に大きな爪を持っており、仕事を効率的に進める意思が強い。基本的にポジティブだが、そのぶんだけ物事を突き詰めて考えず、準備不足のままことを進めようとするのが難点。作業がうまくいかなと、すぐに気落ちする傾向もある。

防御型：目標を「責任」の一種として捉え、競争に負けないために働くタイプ。自分の義務を果たすのが最終的なゴールで、できるだけ安全な場所に身を置こうとする。失敗を恐れる傾向が強い為、仕事ぶりは正確で注意深く、ゆっくりと着実に物事を進めていく。最悪の事態を想定して動く傾向が強く、時間の余裕のない状況ではストレスが激増する。分析や問題解決力が高い。

皆さんはどちらのタイプですか？

「科学的な適職」ではエンジニアは防御型の傾向があるそうです。確かに、私の周りの「できるエンジニア」の人は防御型の人が多いかなと思います。コーディングは安全に確実に行わないといけませんし、問題も次々に発生するので問題解決力が必要なのかなともいます。「勝負に勝ってやるぜええ！！」みたいな人はあまりいません。笑

ですが、PMはある程度攻撃型でもいいのかなと思います。システムやアプリに導入する機能の選別は、競合他社との比較が必要でしょうし、新しい試みを積極的に行いリードするのもPMの仕事だと思うからです。

個人的な意見ですが、PMが攻撃型すぎると、開発メンバーが苦しむことになります。要求が高すぎたり、スケジュールが曖昧だったりと。。なので転職や違うプロジェクトに入る際はどのようなPMなのかを見てみてもいいかもしれませんね。

4,【明確】なすべきことやビジョン、評価軸ははっきりしているか？

やるべきことは明確ですか？タスクが曖昧だと、何をいつまでに終わらせていいか分かりません。エンジニアの業務に置き換えて考えてみると

「どんな機能をいつまでに作成しなければならないか？」

と言うことだと思います。

これに関してはウォーターフォール開発であればタスクがかなり明確なので、次に何をするべきかが分かりやすいと思います。それに対して、アジャイル開発では次に何をするべきかがわからなくなる時が時々あります。アジャイル開発では密なコミュニケーションが命です。ですがあまりコミュニケーションが取れないときに、次に何をしていいかわからなくなってしまう時があります。この点についてはウォーターフォール開発の方がリスクが少ないと思います。

評価軸ですが、エンジニアの仕事の評価は平等でしょうか？評価の平等性があると、仕事環境は良好らしいです。

評価シートを導入していたりする案件や会社なんかはいいかと思います。

5,【多様】作業内容にバリエーションはあるか？

作業内容にバリエーションはありますか？開発スタイルで分けるなら、アジャイル開発は作業内容の変化が大きいと思います。短いスパンで成果物を作成していくので。それに対してウォーターフォール開発は、作業内容が長期間変わらないこともあるので注意です。特に大規模開発だとその傾向が強いので注意です。また保守担当になると新しい試みは基本的にできないとおもうので、バリエーションを求める人はなるべく避けたいですね。

開発以前の問題で、その会社に、異なるプロジェクトや案件に気軽に移れる文化があることも重要かと思います。転職時に、エンジニアの方に直接聞いてみたらいいと思います。

6,【仲間】組織内に助けてくれる友人はいるか？

エンジニアたるもの1人で黙々と作業しているイメージがあるかもしれません。しかしそれができるのは自分ができる範囲orネットで調べればわかる範囲です。分からないことを長時間悩むよりも、人に聞いた方がいいと思います。

皆さんなら、何かを聞く時、誰にまず聞きますか？私は自分と同じスキル感の人にまず聞きます。なぜなら、同じところで悩んでいる可能性が高いですし、何よりも精神的に聞きやすいからです。同じレベル感の人であれば、おそらく年代も近いですし、強力な頼れる仲間になると思います。信頼関係が築きやすいです。そのような「仲間」が作りやうい環境は、「同じレベルの人がいる職場環境」だと思います。

なので職場は「同じレベルの人がいる職場環境」を選択したほうがいいと思います。

少し話はそれますが、気軽に聞ける人がいないのは非常につらいですよね。私も苦い経験があります。往々にして、ベテランさんへの質問は、質問しても通じないことがあるます。私の伝え方に問題があったかもしれませんが。。質問をすると「いやいや、見たら分かるでしょ！ほらここよ、ここよ。」的なシーンが結構ありました。知見のある人には分かるかもしれませんが、こっちは分からないのですよぉ。。(*´ー｀*)

7,【貢献】どれだけ世の中の役に立つか？

自分の作成しているサービスに心から共感しているエンジニアはどれくらいいるでしょうか？私はSESメインなので、お客様のサービス自体に心から共感したことは一度もありません。技術が好きだったのも黙々と業務に打ち込んでいました。

どうせなら、自分が本当に愛しているサービスの開発に携わりたいですよね。エンジニアリングの最終ゴールは世の中を良くすることだと思いますので。

また、業務を遂行する上で、私なりに意識していることがあります。それは自分がシステムのどこの開発をしているかを把握することです。新しいプロジェクトにアサインしたら、まずは全体像を理解することにしています。全体像を理解していないと自分が担当している仕事が、最終的にどのパーツになっているかが分からないからです。ここをわかっていないとサービスの開発に貢献できている感じが持てないです。貢献感を持つためにも全体像の理解は重要だと思います。

まとめ

今回は、「科学的な適職」を参考に、エンジニアの理想的な仕事環境を考えました。エンジニアとして3年目のまだまだ若いペーペーですが、参考になれば嬉しいです。

もっと科学的な適職を知りたい方は以下をご覧ください。

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