#はじめに
エンジニアになって4年ほどになり、自分がチームを引っ張ることも多くなってきました。
最近ではいっちょマエにアドバイスなんかすることもありますが、自分だって右も左も分からないところからエンジニアとして仕事をしつつ成長してきて今ここにいます。
そんな中で、「こうするともっと仕事がうまくできるよ」というノウハウやマインドセット的なものを自分なりにアウトプットしておきたいなと思ったので、つらつらと書いていきます。
##前提
私はエンジニアになってからずっとWeb業界の小規模スタートアップで開発をしてきた人間です。2社経験していますが、2社ともスクラムによる開発手法を取っていました。ここに記す内容もこの環境や手法に影響を受けたものが多いです。
#おしながき
1.マインドセット
2.仕事の進め方
3.どうにもならないとき
#1.マインドセット
##大局を見渡す
自分が着手しているタスクについて、なぜこれをやる必要があるのか、これをやり遂げた結果誰がどうなるからハッピーなのか、やる意義を常に考えましょう。
issueを作成するときにユーザーストーリーというものを書いているチームも多いかと思いますが、ユーザーストーリーはこの部分を明確にしたいから書いているのです。
日々山のように降り掛かってくるタスクで精一杯になってしまい「何のためにこのタスクをやっているのか」をおろそかにしがちになったとき、一度俯瞰でタスクを見る癖をつけましょう。
大局を見渡すと何が嬉しいのか、「LPを作成する」というissueを例にとって考えてみましょう。
このissueについて考えてみると、「issueをやり遂げた結果ユーザーがサービスについてより深く理解できるようになる」からハッピーになると分かりました。
しかしもっと考えてみると、サービスについての理解を深めるためであれば、「実際にサービスを使っている画面をキャプチャして動画にしたほうがユーザーにとっては分かりやすいかもしれない」と気づきました。工数も動画のほうが小さいので、手っ取り早く検証するにはこちらのほうが良さそうです。
大局を見渡した結果、達成したいことはそのままによりコストを落とした方法で素早く効果検証ができることに気づけました。実際は解決策を洗い出すのは個人ではなくチーム全体ですが、常にチーム全体がタスクのやる意義について考えられる状態だと有効な解決策が出て来やすいです。
##自分の仕事で会社の利益UP->給料UP
自分がやる仕事について、**これをすることで会社にとってはこんな形で利益につながる、ということは自分の給料もUP！**と捉えてすすめるようにしましょう。
「エンジニアは気高い存在。モチベを高く保って仕事をしろ」と言われることがあります。まぁその通りといえばその通りなのですが、実際のところモチベを常に高く保つにはエネルギーが必要です。
ではこのエネルギーとは何でしょう？2つあって、1つ目はユーザー(社会)の幸せ、2つ目は自分の給料です。先程の大局を見渡すことが1つのエネルギーをコスパよく手に入れるものだとすれば、こちらは2つめのエネルギーを手に入れるための考え方です。
分かりやすいもので、給料が上がれば人間素直にハッピーになります。だとすれば、今やっている仕事がどう会社の利益に結びつき自分の給料につながるのかを考えると、自ずと思考や仕事のアウトプットが洗練されてきます。だって自分の利益にならないことはやりたくないのが人間ですから。
#2.仕事の進め方
##次のアクションを常に持つ
タスクが終わったときに手が空いたまま宙ぶらりんになったり、指示をずっと待ったりしていては時間がもったいないですよね。次のアクションとして自分がやるべきことを把握しておいて、1つ終わったら次にすぐ移れるようにしておきましょう。
また次のアクションのために今のタスクでやっておくことがあるならば、それもしっかりと把握しておきましょう。
例えば何かを調査するタスクであった場合、タスクのネクストアクションは「調査の結果分かったことを判断材料として意思決定権者に渡し、決定してもらうこと」です。調査したけどよく分かりませんでした、では判断材料になりません。
タスクが終わった後何をする必要があるのか、次のアクションのために今何をしておく必要があるのかを常に考えておきましょう。
##作業単位の基準は「単体でリリースできるかどうか」
開発は、「どこで切ってもリリースできる単位」でできるだけ分けて進めるようにしましょう。
アジャイル開発の形態として、スプリントという単位で期間を区切って開発し、スプリントの終わりにプロダクトオーナーのレビューを通してリリース、というものがあります。これは極端な例ですが、スプリント内で行う全てのタスクを1つのプルリクエストにまとめてしまっていた場合、1つのタスクのレビューが通らなかったらほか全てのタスクもリリースできない事態に陥ります。
定期的にユーザーへ価値提供 = リリースをするためには、リリースできるものがまとまっている必要があります。逆に言うと、リリースできないものが混じらないようにする必要があるということです。
なるべく多くの価値提供をするためには、リリースできる最小単位で作業を行い、レビューが通り次第リリースブランチに入れてデプロイなりビルドなりをするべきです。
初心者のうちは、作業しているうちに気づいた点をまとめて直してしまおうと思いがちですが、面倒でも1つ1つ別作業として分けることで後々の自分を救うことができます。
##自分からファシリテートを取っていく
開発メンバー内でミーティングをする際は、進んでファシリテートを取っていきましょう。
といってもここで言う「ファシリテートを取る」とは司会役をやるという意味ではなく、他のメンバーの発言を理解し噛み砕いて説明し直し、その認識で合っているかを確認するという意味です。
世の中で言われているファシリテーション能力の一部分だけ(ここではとくに合意形成、相互理解のサポートの部分)に特化していますが、これには今話し合われている内容のポイント、課題を整理し全体の方針がどうなっているかを把握する能力が必要です。要約力ともいえますね。「大局を見渡す」にも通じるものがあります。
一朝一夕で身につくものではないので、早いうちからファシリテートを取る役を買って出て、要約力を磨いていきましょう。メンバーに説明して合っているか確認することで、フィードバックがもらえてより効率よく力をつけられます。
#3.どうにもならないとき
##チームメイトに聞く
悩んでしまって手が止まっているなと感じたときは、チームメイトに相談しましょう。たとえ新人の同期であっても、自分とは違う得意分野があって解決策が分かるかもしれません。
学校の課題や個人開発と違い、会社における開発は1人でやることはあまりありません(超小規模スタートアップを除く)。あなたの抱えているタスクが終わらないということは、あなたの所属するチームが抱えているタスクが終わらないのと同義です。困ったら早めにアラートを上げて、チームメイト全員で解決にあたるようにしましょう。
あなたがこの先1時間かけても分からなかったであろうことが、他の4人に聞くことで10分で解決したなら、それは5人のチーム全体としては50分以上のコストを掛けずに済んだということになります。主語はチーム全体。困ったら聞きましょう。
##コーヒーブレイク☕️
別にコーヒー休憩以外でもいいのですが、一度別のタスクをやるなりリフレッシュするなりして目の前のタスクから離れてみましょう。分からなかったことのヒントが突然浮かんでくるかもしれません。
これには残念ながら何の根拠もないのですが、自分の経験上、はたまた他のエンジニア友達から聞いた話でもそうだったのですが、詰まったタスクから一度離れてみると「あっ」となる瞬間があるんです。視野が狭くなりすぎているのかもしれません。俯瞰は大事です。
##寝る🛌
休憩の究極系ですね。疲れを溜めてはいいアウトプットは出せません。忙しいを言い訳にせず、ちゃんと寝ましょう。
もちろん勤務時間が決まっている人は、遅刻しないようにちゃんと起きましょう。エンジニアである以前に、社会人として最低限のルールです。
#おわりに
なんにせよ、特に意識なんか持たずとも月日は過ぎてしまいます。同じタスクをこなしていても、なんらかの意識をもってあたるのとそうでないのとではタスクから得るものが格段に違ってきます。どうせやるならよりパワーアップするやり方が良いですよね！正しく意識して努力を積み重ねていきましょう！
「努力する人は希望を語り、怠ける人は不満を語る」
小説家の井上靖さんの言葉です。希望を多く語る、ステキなエンジニアであり続けましょう！