目的思考について株式会社Speeeのインターンシップで学んだこと

# はじめに

[株式会社Speee](https://speee.jp/)での12日間のエンジニアインターンシップで学んだことを書きます。技術的なことではなく、何かを成し遂げるにあたって意識するといいことについてです。

インターンシップの概要はこんな感じでした。

- ワーク内容
    - 3, 4人１チーム
    - 課題定義から実装までのサービスの立ち上げ
    - 合計3回社員の方にプレゼンテーション&フィードバック
- サポート体制
    - 1チームごとにビジネスメンターとエンジニアメンター各1人
    - 人事の方と面談 + 毎日メンターの方と1on1面談
- フレームワーク
    - [Ruby on Rails](https://railstutorial.jp/)

KPT[^1]・YWT[^2]などのフレームワークを使い、自分やチームの課題を見つけ、目標を立て、実行する、というサイクルを回し続けました。

12日間本当に色々な学びがありましたが、その中でも最も大きな学びの一つである「**目的思考**」について書きます。目的思考とは（私の解釈では）「目的の達成を一番に考えること」「手段を目的化しないこと」です。これだとまだふわっとしているので、さらに具体的な以下の4つの項目に分けて「目的思考」に関する学びを共有します。

- [優先順位をつける](#優先順位をつける)
- [他人の意見に寄り添いすぎない](#他人の意見に寄り添いすぎない)
- [成長を目的化しない](#成長を目的化しない)
- [目的達成のためにあらゆる手を尽くす](#目的達成のためにあらゆる手を尽くす)

「[その他の学び](#その他の学び)」ではこれら以外の大切な学びについてサラッと書きます。

[^1]: Keep Problem Try
[^2]: やったこと、わかったこと、つぎやること

# 優先順位をつける

**目的思考のおかげでタスクの優先順位づけが楽になり**、逆に、**優先順位づけのおかげで目的思考が体に染み付きます**。

目的思考でプロダクトを開発すると、自ずと「やるべきこと」の優先順位が決まり、作業がしやすくなります。例えば、ユーザーに価値を届けることを目的とする場合、ユーザー以外（システム管理者など）のための機能は相対的に優先順位が低くなるはずです。

逆に、優先順位をつけることを意識することで目的思考が体に染みつきます。なぜなら、優先度の判断軸は「目的の達成のために必要か」であるためです。さまざまなタスクに優先順位をつけようとすれば、その度に目的思考を意識することになります。もちろん、優先順位をつけるにあたって他の判断軸がある場合もあると思いますが、少なくとも、「目的の達成のために必要か」という判断軸は有効です。

今回のインターンでは、開発時に持ち上がる追加タスクに関しても優先順位づけをきちんと行うことで、本当に必要な機能から開発を進めることができました。開発の途中で、ある機能が必要であることに気がつくと、（さらにその機能の実装がそんなに大変そうでない時は特に、）ついその場で実装に取り掛かりたくなってしまう人は少なくないと思います。しかし一度サブタスクを始めるとサブタスクがサブタスクを呼び、永遠にメインのタスクが終わりません。
「あ、これやらなきゃ」と思ったらまず、本当にそれは今やる必要があるのかを自問し、そうでなければ別タスクとして切り出して後に回すことが大切です。当たり前のようですが、大切な学びでした。

# 他人の意見に寄り添いすぎない

目的思考を大切にすると、**他人の意見に寄り添いすぎない方が良い場合がある**ことに気がつきます。私はメンターの方との面談の中でこれに気づくことができました。

「他人の意見に寄り添う」とは、チームでの話し合いなどで他人の意見についてしっかり議論し、チームとしての意見に組み込んでいくことです。チームでの作業ではメンバー全員が共通認識を持ち、意思決定に際して合意形成することがとても重要なので、自ずと他人に寄り添うことも重要になってきます。

しかし、ここに落とし穴があります。

他人の意見に耳を傾けるあまり、意思決定までに必要以上に時間を費やしてしまうことがあるのです。時間という制約がある中で目的を達成するためには効率的な議論が必要です。もっというと、目の前の意見を尊重するよりも、目的の達成の方がはるかに大切です。
目の前の他人の意見を尊重することは、目的を達成するための手段の一つであり、そこに時間をかけすぎて目的が達成できないのでは本末転倒です。

従って、**時には自分の意見を主張し、多少強引にでも意思決定してしまうことが、結果としてチームとしての成果を最大化する（目的を達成する）ことにつながる**ことも多いはずです。

ここからはやや個人的な話にはなりますが、なぜ他人の意見に寄り添いすぎてしまうかというと、意思決定から逃げたいからだと思います。自分では目的達成のために話し合いをし、他人の意見を聞き入れているつもりでも、本当は自分の意見を強く主張してチームの方向性を決定することに不安があって、その責任を分散させたいがために話し合っている場合があると思います。
みんなで話し合う前に、「その問題・議題は本当にみんなで話し合う必要があるのか？」「目的を達成するために時間をかけて議論すべきなのか？」を問うことが重要です。

# 成長を目的化しない

**自分が成長することは目的達成のための手段にすぎない**ということを忘れてはいけません。

私はまだエンジニアではなく学生ですが、エンジニアには技術的成長が欠かせないと思っています。そのために、業務時間外で勉強をしたり、業務中も新たな技術を使ってみたりして学ぶことが大切だと考えています。

しかし、成長のためにやったことがチームとしての目的にそぐわないようでは意味がありません。自分が使ったことのない技術を使って、かえって開発が遅れたり変に複雑になりすぎてしまっては元も子もありません。意思決定をする際、「目的を達成するための判断なのか？」「ただ自分が成長したいだけではないか？」を問う必要があります。

今回も成長できそうなタイミングが多々ありました。例えば、認証機能の実装に使ったことのないライブラリ（devise）を使おうとしていました。しかし、チームの中で1人もそのライブラリの使用経験者がいなかったことや、そもそも全員Rails初心者だったこと、さらに認証機能はユーザに価値を届ける（=目的を達成する）ためにそれほど重要ではなかったことなどから、学習コストを考慮して使用することをやめました。
最終発表までの実装がギリギリだったことを考えると、ここで無理に時間を割いて勉強せず、既に知っている方法で実装したことは正解だったと思っています。

# 目的達成のためにあらゆる手を尽くす

**目的を達成するために、あらゆる手を尽くしましょう**。

ここまでつらつら書いてきましたが、結局これに集約される気がします。目的を達成するために考え、工夫し、あらゆる手を尽くすこと、そしてその気概を持つことが何よりも大切です。

意識しているつもりでも、実はそれほど実行に移せていない人もいると思います。自分の場合はまさにそうで、目的を達成するために目標を立てても、時間内に目標が達成できそうにないとわかると諦めてしまうことが少なくありませんでした。時間内に終わらない原因を「見積もりが甘かった」ということにして、予定がずれ込み続けることが多かったです。

しかし、自分に足りなかったのは正確な見積もり能力ではなく、「どんな手を使ってでも絶対に目的を達成するぞ」という気概でした。このことに気づけたのは、その姿勢で一緒にワークに取り組んでくれたメンターの方のおかげです。たとえあるタスクが予定時間内に終わらなくても、残りの時間で残りのタスクを終わらせるにはどうすべきかを考えなくてはなりません。分担の仕方を見直したり、優先度の低いタスクにかける時間を短縮したり、工夫できることは山ほどあるはずです。
あらゆる手を尽くし、それでも目標が達成できなかった時に初めて見積もりのせいにする権利が与えられます。

目的を達成するために考え抜き、工夫すること、それらを通してなんとしてでも目的を達成するという意思を貫くことが重要です。

# その他の学び

目的思考以外にも色々な学びを得ることができました。これで全てではありませんが、雑多に書き連ねていきます。

## 見積もり前のお試し期間を設ける

自分が経験したことのないタスクを見積もることは難しいです。経験がないので何にどれぐらいの時間を要するか検討もつきません。そんな時は一度ざっと見積もった後に時間制限ありで試しにタスクをこなしてみるのが効果的です。これによってどの程度の時間でどの程度の量をこなせるかというデータが取れるので、それを元にすると見積もりの精度が上がります。ここで大事なのは時間制限を設けるということです。終わりを設定しないといつまでもお試し期間のままで一向に見積もりが始まりません。

## サポートしすぎは時に成長を妨げる

組織のリーダーとして、あるいはエンジニアとして誰かの成長をサポートする際に、手を差し伸べすぎるとかえってその人の成長を妨げてしまうことがあります。答えを教えるのではなく、どうやったら答えに辿り着けるのかを教えることで、その人が自分自身で成長することができます。また、相手の性格などにもよりますが、時には厳しい要求を出して突き放すことも必要です。

## 常に達成してほしい水準を示し続ける

自分がエキスパートではない別の領域で活躍する人を導く立場になったときに大切なことです。その人に達成してほしい水準を常に示し続け、その水準に達する方法はその人に任せるということです。

## 上の立場の人・経験豊富な人を頼る

ある人の言動が目的思考に背くものであったり、間違っていると感じた場合、指摘することはとても重要です。しかし実際、年上だったり自分より立場が上だったりと、言いにくい状況が存在するのも確かです。そんな時はその「物申したい人」よりも上の立場の人や、その人より経験の豊富な人に「○○さんのこういうところが良くないと思うのですが、どう思いますか」と聞いてみるといいです。自分の考えが間違っていれば学びになりますし、正しければその人からその「物申したい人」に指摘してもらえたりもします。

## 計画を実行に移す文化を作る

毎日その日の振り返りをし、翌日の行動計画（目標）を立てても、実行しなければ意味がありません。ただ、個人で意識するだけだとどうしても計画を忘れてしまうことがあります。そのために、決めたことをすぐ実行に移す文化をチーム内で作ることが重要です。誰かが計画を実行に移せば、それを見て自分も自分の目標や行動計画のことを思い出すことができます。今回のインターンでは自然とこうした文化がチーム内で醸成されていき、そのおげで毎日反省を活かした行動ができました。

# 最後に

Speeeでのインターンシップは毎日多くの学びがあり、とても貴重で有意義な1２日間でした。この記事では将来ためになりそうな学びに焦点を絞って書いたのであっさりして見えるかもしれませんが、インターン中はもっとアツく感動さえするような体験をさせていただきました。インターンを企画・運営していただいた人事の方はもちろん、12日間一緒に駆け抜けてくださったメンターの方々や同じチームのメンバー、他のチームのメンバーにとても感謝しています。ありがとうございました。

現場で働かれている社員の方と多くの時間を共にしたことで、働くとはどういうことかがとても鮮明になりました。また、毎日時間を割いて1on1面談を行なっていただいたことで、自分の長所や短所、これからのキャリアについて深く考えることができました。面談の中で思考が整理され、自分でも気がつかなかった学びや成長を感じることができました。
12日間でこれだけ成長でき、さらにその成長を実感できることはそうそうないと思います。ここで明らかになった自分の課題を乗り越えるべく、これからも頑張りたいと思います。（書いているうちになんだか偉そうな感じになってしまいましたが、この記事の内容もまだまだ意識していかないといけないことばかりです。）

ちなみに、Qiitaの記事を書くきっかけを与えてくれたという意味でも、Speeeの方々にはとても感謝しています。これから少しずつ、学びをアウトプットしていけたらなと思います。