研修中に手に入れた、チーム開発を促進させる3つのメタスキル【研修振り返りレポート】

はじめに

皆さんこんにちは、2021年に新卒で入社したソフトウェアエンジニアの稲垣です。

今回、我々新卒メンバーが受けた研修の中にチーム開発があり、自分はそこで多くの知見を得ました。大きく分けると、コーディングスキルとメタスキルを得たのですが、今回はメタスキルについてお伝えしたいと思います。具体的には以下の3つのメタスキルを会得しました。

タスクの終了条件の定義
チームに貢献するための考え方
ポジティブ思考

タスクの終了条件の定義

チームでアプリケーションを作る課題が与えられ、自分は早くコードに書き起こしたい衝動に駆られました。そこで、タスクを洗い出し、優先順位を決め、コードを書き始めました。しかし、問題が発生し、うまくコードに書き起こせませんでした。

うまくコードに書き起こせなかった要因
- チームメンバー内で終了条件の認識のズレがあり、手戻りが発生する
- いつまでたっても実装が終わる見通しが立たない

その理由は、アプリを作るという課題が与えられ、それをそのままチームのタスクの終了条件にしようとしていたからです。

diff --git a/before_after.md b/before_after.md
index 42fc9a4..042e1ff 100644
--- a/before_after.md
+++ b/before_after.md
@@ -1,4 +1,5 @@
 1. チームに課題が与えられる
-2. やるべきタスクを洗い出す
-3. 洗い出したタスクの優先順位を決める
-4. タスクを遂行する
+2. チームとしての終了条件を定義
+3. 終了条件から逆算してやるべきタスクを洗い出す
+4. 洗い出したタスクの優先順位を決める
+5. タスクを遂行する

上記の差分は、チームとしての終了条件を定義と終了条件から逆算してやるべきタスクを洗い出すができていないことを示しています。

最初に、チームとしての終了条件から触れていきたいと思います。

アプリケーションを作成しなければならないのは間違いないですが、どのような基準でアプリケーションの作成を完了したとみなすかには幅があることがわかります。

具体例
- App Storeにリリースが完了している状態
- AWSにデプロイして、どの端末でもアプリケーションを使用できる状態
- ローカル上でデモができる状態

上記の幅によって、やるべきタスクの量や、優先すべきタスクの種類が変わってきます。

自分たちのチームは、期間内にローカル上でデモができる状態までにすることをゴールと定義しました。

定義した理由は、いきなりアプリケーションをリリースしても、それが需要を満たすかわからないため、デモレベルで作成し、それを評価した上でリリースしたほうがよいという方針のもと決まりました。

これにより、チームメンバー内で終了条件の認識のズレがあり、手戻りが発生するについては解消され、チーム内で同じ共通認識を持つことが可能になります。

ゴールを定義した上で、ゴールの条件を満たすために必要な要件を議論します。

例
- アプリケーションに追加したい機能の選定
- ツール選定
- タスクの優先順位の決定

チームとしてのゴールを定義することで、ゴールから逆算してタスクを設定することが可能になります。ゴールから逆算して考えた結果、終了条件を満たす上で必要のないタスクが明確になります。

diff --git a/before_after.md b/before_after.md
index 1654185..d2d3bf5 100644
--- a/before_after.md
+++ b/before_after.md
@@ -1,10 +1,6 @@
 - チームに課されたゴールの終了条件を満たすために必要なタスク
-   - AWSを用いたデプロイ
-   - codecovを用いたカバレッジの取得
-   - 認証/認可
    - dockerを用いた開発環境の構築
    - CIを用いたテスト環境の構築
    - クリーンアーキテクチャを適用した実装

ゴールからの逆算を取り入れた結果、切り捨てたタスク

AWSを用いたデプロイ
- ローカル上でデモをすることを前提としているため、デプロイについては考慮する必要がなくなりました。
codecovを用いたカバレッジの取得
- リリースすることが決まってから導入すれば良いとチーム内で判断したため
認証/認可
- デモをする上では、重視されない要件だとチーム内で判断したため

最初は山積みに見えたタスクも、終了条件を定義することで整理がしやすくなり、優先順位が明確に決まります。優先順位が明確になれば、上記の差分のようにタスクの切り分けを行うことが可能になります。

自分たちは、このタスクの切り分けによって、いつまでたっても実装が終わる見通しが立たない問題を解決しました。このように、終了条件を定義することはチーム開発において多くのメリットを生みます。

チームに貢献するための考え方

チーム開発では様々なタスクをチームから任されます。もちろん任されたタスクをすべてこなすことが理想ですが、様々な要因がタスクの達成を阻害してきます。

タスクの遂行を阻害する様々な要因

初見の技術、領域
インシデント

またソフトウェアを作成する上で期限は存在するため、上記の要因に加え時間的制約という縛りが加わります。

自分は時間的制約に悩まされました。理由としては

時間内に与えられたタスクを達成しなければならないという重圧がかかり、平常時のパフォーマンスが出せない
チームに迷惑をかけているという自己否定

最初、自分は制限時間内に与えられた課題を達成(できた|できなかった)でしか自分を評価することができていませんでした。

与えられた課題を達成する
- チームに貢献できた
与えられた課題を達成できなかった
- チームに貢献できなかった

しかし、チームに貢献するということは、本当に与えられた課題を達成することだけでしょうか？そこで自分の考えを、チームに貢献することから上記で定義したチームとしての終了条件への残りの道のりを短くすることへと改めました。

チームとしての終了条件への残りの道のりを短くするために必要なことの例
- チームから与えられた課題を達成する
- チームに、自分がタスクを遂行する中で会得した情報を共有する
  - ハマリポイントを共有
  - 成功例を共有
- チーム全体の残りの課題の整理
- etc…

自分の中で、チームに貢献するについての認識を改めた上で、自分にできることを再考すると、認識を改める前よりもできることが増えました。それに伴い、最初感じていた自己否定感が薄くなりました。

特に自分は、与えられた課題を遂行する中で、チームにハマリポイントを共有することを強く意識するようにしました。

上記のように、仮に任されたタスクが達成できなくても、足跡をチーム内に残すことで、自分が踏んだ失敗をチームがしなくなります。足跡が多ければ多いほどチームが強くなり、チーム全体で目的を達成する力が強くなります。大切なのは、チーム全体で目的を達成することがゴールであり、任されたタスクを独力で達成することがゴールではないことです。

ポジティブ思考

自分の場合、ネガティブな方向に物事を考えてしまう癖がありました。それ故に、なにか新しいことをチーム内でするかどうかを決めるような議論をするときに、マイナスな発言をしてしまうことが多かったのです。

例えば、開発中のアプリケーションに新機能を追加するか議論していたときに、自分が出した意見の例を示します。

実装が間に合わない可能性がある
バグが発生する可能性がある
誰も実践したことが無いため、工数の計測が難しく、不安である

これらの意見は、自分の既存のスキルで実現可能かどうかという観点から出された意見です。当然、リスクやコストなども考慮することは重要ですが、そればかり考えていては保守的な考えしか構築できず、なにか新しい、新規的なアイデアは生まれません。また、こういった保守的な考えは未知の領域に対して触れ挑戦する機会を自ら減らしてしまっていることを意味します。それだけではなく、チームメンバーが新機能を実装したいと言ったときに、提案されたものにいきなりデメリットの話をすると提案者は否定されていると感じてしまい、チームの士気が下がることもあります。

大事なのは、否定から入るのではなく、リスクやコストを明らかにしつつ、挑戦し、前に進むことです。そこで、今まで自分がリスクと捉えていた物事を前向きな側面から捉え、先に否定的な意見を出さないようにすることを心がけるようにしました。

diff --git a/before_after.md b/before_after.md
index 42fc9a4..042e1ff 100644
--- a/before_after.md
+++ b/before_after.md
@@ -1,4 +1,5 @@
実装が間に合わない可能性がある (negative)
+ 実装が完了すれば、アプリケーションの機能が豊かになり、より良い価値を提供できる (positive)
バグが発生する可能性がある (negative)
+ 発生したバグを潰せば、二度と同じバグにハマることがなくなり、それに伴った経験を他の人に共有できる (positive)
誰も実践したことが無いため、工数の計測が難しく、不安である(negative)
+ 未知の領域に対して挑戦する機会を得、同時に知識を習得できる (positive)

リスクになりうる要因をポジティブに捉えた結果

ポジティブ思考によって物事を良い方向にも捉えるように矯正した結果、挑戦すること自体にメリットがあると感じ、未知の領域への挑戦に対して、自分が前向きな姿勢になりました。むしろ、挑戦する機会を失っていることにもったいなさを感じるようになりました。また、仮に失敗したとしても悪いことばかりではないとわかったことで、失敗に対する重圧が減り、自分が楽になりました。

前向きな考えを持った自分は、相手の提案に対してメリットを引き出すような質問をすることを意識するようになりました。そうすることで、チームの士気が上がり、より深くチーム全体で意見について考察するようになりました。

チームで長い時間をかけて課題を解決することは珍しくありません。長期的になればなるほどモチベーションの維持やメンタルの管理は重要なタスクの一つです。多角的に物事を捉え、いい方向に考えることで、モチベーションの維持や自身のメンタルの管理がしやすくなると思います。

ブログ全体の総括

上記で触れたメタスキルたちは、多くの場面で役立ちます。簡単に身につくものではないですが、自分の中で常に意識することで自然とできるようになり、それが開発の工数の削減や手戻り防止、長期的なモチベーションの維持などに活きてきます。

宣伝項目

この記事を読んで「面白かった」「学びがあった」と思っていただけた方、よろしければ Twitter や facebook、はてなブックマークにてコメントをお願いします！

また DeNA 公式 Twitter アカウント @DeNAxTech では、 Blog記事だけでなく色々な勉強会での登壇資料も発信してます。ぜひフォローして下さい！

Follow @DeNAxTech