株式会社メタップスホールディングスの釣りバカVPoE、阿夛（@ataboy86）です。

現在は、「re:shine」というフリーランスのマッチングプラットフォームの事業責任者をやりつつ、VPoEとして開発部門の統括をしています。

今回は、エンジニアの方々に向けて、「いつもの」開発を少し楽しくする4つの思考術をまとめました。

日々エンジニアが取り組む開発業務は、時に単調で疲れることもあると思います。
しかし、単調な開発でもそれを実現すべき背景があり、その完成を待ってる人がいます。
完成することでどこに影響し、貢献できるのか。そういった思考を持つことで日々の単調な開発にも意味や意義を理解出来るだけでも「作業」から「仕事」になっていくものだと私は考えます。
今の開発業務に対して、楽しいと感じている人もそうでない人もプラスαで「いつもの」開発を楽しくするヒントになればと思います。

信頼獲得のための「目的思考」

システム開発の最終目的は、会社や組織の利益を生み出すことにあります。
しかし、その過程で重要なのは「誰に何を届けるか」という視点を持つことです。

システム開発は、単に技術を駆使して何かを作ることではなく、それを使う人々のニーズに応え、問題を解決する手段です。

作ること自体が目的ではなく、使う人のイメージや使われ方を理解しようとすることで、「気の利いた」アウトプットがしやすく、逆にそこが抜け落ちると「使いづらい」ものになってしまいます。

例えば、運用管理画面などで、ページを作って欲しいという依頼でも、作って終わりだと、ただデータを表示しただけの画面になりますよね。

何を目的とするかによってまちまちですが、ユーザー詳細などのページでは、「関連する情報は、詳細ページへのリンクを付けることで便利になる」のか、それとも「詳細までその画面に出したほうが良いのか」など、使う人の用途を理解することで、依頼した人はプラスαの価値を感じ、信頼される人になれることでしょう。

開発者は、ユーザーの視点に立ち、ユースケースを理解することで、より使いやすく、価値のある製品を生み出すことができます。
この「目的思考」は、信頼される開発者になるための第一歩です。

信頼されるエンジニアになれると、意見や提案の出しやすさも上がりますし、より大きな仕事、より大きな役割を与えられるきっかけにもなることでしょう。

自分や仲間が「楽をする思考」

「誰かの楽は組織の利益」に繋がります。
日常の開発作業中に、「あれ、ここちょっと不便かも？」と思うことはありませんか？実はそう感じた瞬間は、チャンスです。

多くの場合、その感覚は正しく、長く使っているとその感覚が薄れていくものです。
その不便かもはちょっとしたことでも改善できると、周りは思い出したように「そうそう！ここ不便だったんだよ！」となる事が多いです。

不便であることは日々の効率をほんの少し下げてしまいます。

上の例のように、小さな不便を解消することで、長期にわたり大きな時間の節約となり、それは組織全体の効率向上に貢献します。

自分や仲間が楽をする、という状態を作れると、自分を含めた作業効率を上げたり、便利なものを作るというのは組織にとって確実に利益になります。（しかもほぼ永続的に）

作りたいものを作るための「時間を作る思考」

エンジニアになった動機は色々あると思いますが、「自分で何か作りたい」と思ってエンジニアになった方も多くいらっしゃると思います。
日々の忙しさの中でその思いを忘れている方もいないでしょうか。

「これが終わったら、こんなものを作るんだ！」という思いは重要です。
前段で、誰かの10分を確保できましたね。今度はそれを自分に当てはめてみましょう。

日々の業務でこんなこと思ったことはありませんか？

エンジニアの皆さんは毎日の作業に追われていることでしょう。しかし、「今度、落ち着いたら・・・」と待っていると、多くの場合は一生取りかかれません。
「時間を作る」という行動は、何より優先して投資すべきです。

日々の業務に追われていても、小さな時間を見つけてはそれを自分のアイデアや改善に充てることで、新しい価値を生み出すことができます。

今日の作業に区切りがついたら、1時間だけ、そのツールや改善に当ててみませんか？
※決して残業推奨をしたいわけではなく、あくまで、思考の話です。

考えたものを実際に自分の手で開発できるエンジニアだからこその価値です。

日々の業務に追われて終わる状態から少しでも自分の作りたいものや、興味のある分野に割ける時間を意図的に作ることでインプットが増え、もう一歩上のエンジニアとして活躍出来ることが期待できます。

目的達成のための「検証思考」

開発においては、「こういう背景があって、こういう機能がほしい」という要望がよくあります。しかし、その要望を一度疑ってみましょう。
機能開発の一部では背景と合致しておらず、顧客の要望をそのまま機能に落としているものがあり、それでは根本解決に繋がらないというケースがあります。

運用中の機能であれば、特に数字での検証が可能です。
作成した機能が果たしてどの程度使われているかを検証し、顧客ニーズを満たしていれば使われる機能になっているはずです。

改めて数字を見ることで、想定していた数より多ければニーズが満たせていると言えますし、想定したより明らかに低い数字になっていると再度改善の余地がありそうです。

想定以下であれば、本当のニーズが何なのか仮説の再定義の提案や議論をすることも必要ですね。

数字を追い、今回の機能改修や機能開発でどの程度効果があったのかが検証できることで、顧客のニーズ理解に繋がり、顧客のニーズがわかることで改善へつなげられるといったサイクルが回ります。
このサイクルが回ると、日々の開発にもより深く意味を持つことが出来るようになるため、単調な作業でも「価値」を理解できると思います。

まとめ

事業を理解し、組織課題を見つけ、開発目的を明確にする。
自分の作りたいものを見つけ、作るものに根拠を持ち、検証する習慣を身につける。
この思考ができると、事業の改善や顧客の満足度向上にも繋がりますし、何よりやっていて楽しいと思える「機能開発」から「事業開発」に携われる機会にもなると思います。
ぜひ、「これは自分に合いそう！」と思うものから試してみてください。