「目的（What）と手段（How）を混同してはいけない」—この言葉を耳にしたことがある人は多いだろう。しかし、エンジニアという専門職の性だろうか、課題に直面すると、つい「どのようにコードを書くか」「どのツールを使うか」といった技術的なアプローチに目が向いてしまい、肝心の目的を見失ってしまう瞬間も少なくはない。

ソフトウエア開発会社の経営者でありながら、現役エンジニアの顔を持ち、日頃から“目的も手段も”両方を語る立場にある桑原伸輔さんは「Whatを正しく認識できないエンジニアは自分のスキルやキャリアの幅を狭めてしまう」と指摘する。

では一体、どうすればWhatを意識しながら仕事が進められるようになるのだろうか。そして、Whatを捉える力を養うことでどんな未来が開けるのか。桑原さんのキャリアからその答えを探ってみた。

Whatが欠落すると「システムを作るエンジニア」になれない

――本題に入る前に改めて、エンジニアの仕事において「What」と「How」が何を指すのか、明らかにしたいです。

Whatは「何のためにやるか」、つまり目的です。一方のHowは「どのようにやるか」という手段を意味します。どんな仕事であれ、まず目的を理解した上で、そのゴールに辿り着くための手段を考える力が求められます。

――ただ、「How」に意識が向きがちなエンジニアは少なくないと？

はい。その傾向は少なからずあると思います。例えばシステムに機能を追加するように言われたときも、「どうすれば少ない処理数で、なおかつ不具合を起こさないようにコーディングできるか」といった手段から考え始めるケースが多く見られます。

確かに技術的な手法を考えるのがエンジニアの主な業務ではありますが、いきなり手段から入ると、自分がいかに効率よく仕事をこなすかにとらわれ、発注者であるお客さまが求めるものとはズレたゴールに着地してしまうことが少なくありません。

お客さまとしては、その機能を追加することで担当者の作業負担が減ったり、あるいは自社サービスの利便性が向上して新規ユーザーの獲得につながったりと、何らかの目的があって仕事を発注したはず。でも現場で手を動かすエンジニアは、そこまで思考が至らないケースがほとんどです。

――なぜWhatへの理解が浅いエンジニアが多いのでしょうか？

本人の資質や特性によるところもあるでしょうが、それ以上に置かれている立場や環境が大きく影響するように思います。特に二次請けや三次請けと呼ばれる立ち位置で仕事をする場合は、開発工程のうちプログラミングやテストなど一部のタスクだけを切り出して委託されるケースが大半です。

「設計はしなくていいからプログラミングだけやって」と言われれば、エンジニアも「とにかく言われた通りにコードを書けばいい」という思考になりやすい。与えられるのが作業の指示だけで、プロジェクト全体の目的について説明を受ける機会は少なく、そもそもWhatを理解することの重要性に気付くきっかけがない若手も多いのではないでしょうか。

――もし若手エンジニアがWhatを理解しないままでいると、どんなデメリットや弊害がありますか。

Whatの視点が欠落していると、コーディングができるエンジニアにはなれても、システムを作るエンジニアにはなれない。これはキャリアの観点から見て大きなデメリットです。

発注者側から見れば、システム開発は自社のビジネスや事業を支える手段の一つという位置づけです。よって開発者側は、「このサービスやプロダクトはいつ、誰に、どこで売るのか」「何にどれくらいコストをかけられるか」といったビジネスモデル全体を踏まえた上で、その目的を実現するための手段として有効なシステムを考えなければいけない。それが一般に上流と呼ばれる工程であり、発注者の要望や課題を理解して要件を定義できるのは、Whatを的確に捉える力を備えた目的志向のエンジニアです。

一方、HowだけにフォーカスしてWhatが見えていないエンジニアは、誰かに与えられたタスクを指示通りにこなす立場から抜け出せず、プロジェクト全体の中で歯車の一つとして使われ続ける。本人もやる気が出ないし、仕事の品質や速度も上がらないので、スキルの向上につながる経験則が蓄積されず、なかなかキャリアアップできない負の連鎖に陥ってしまいます。

――「タスクをこなす人」から「システムを作る人」にステップアップするには、「何のためにそれを作るのか？」を突き詰める“What思考”が必須ですね。

　　　　
「いつか社会にインパクトを与えるようなキラーアプリを開発したい」といった夢や目標があるなら、なおさらWhatに強くなる必要があるでしょうね。

サービスやプロダクトが事業としてどれだけスケールできるかは、ビジネスモデルでほぼ決まります。アプリを作るにしても、「どのターゲットに向けて、どんな価値を提供し、どのように収益を上げるのか」というコンセプトを企画立案する力が問われる。ビジネスモデルを意識してシステムを作っているエンジニアなら、こうしたスキルにつながる質の高い経験則が蓄積されていくはずです。

つまり「システムを作る人」になれば、その先に「ビジネスを作る人」になるキャリアも見えてくる。自分がやりたいことを実現するためにも、若手のうちからHowだけでなくWhatに目を向けることが重要です。

「ビジネスを作る力」が事業の成長につながった

――桑原さんはエンジニアとしてキャリアをスタートし、その後転職した会社では、開発部門をマネジメントしたり、新規事業を立ち上げて事業部長を務めたりと、ビジネスサイドでも重要な役割を担ってきました。ご自身はいつ頃からWhatの重要性に気付いたのですか。

最初から意識はしていましたね。システムを作りたくてエンジニアになったのですから、どんな仕事でも「何のために」とか「誰のために」という目的は当たり前のように考えていました。

ただ私が幸運だったのは、若手時代に発注者側と接する機会があったこと。最初に勤めたのは福岡の小さな会社で、東京の大企業向けにデータ変換用のプログラムを作っていたのですが、クライアントの現場エンジニアに納入後の使い方やトラブル対応をレクチャーする役割をなぜか私が任されたのです。

たった一人で東京に送り込まれ、会社が借りたマンスリーマンションに滞在しながら客先に通ったのですが、それが今思えば、自分が作ったものがどんな人たちに使われ、ビジネスとしてどう展開していくのかをリアルに体感する機会になったのかもしれません。

――もともと意識していた「何のために」をよりクリアに認識できる機会があったわけですね。

その後は東京のIT企業に転職し、入社4年目には開発部門の統括役を任されました。この会社は主に名古屋の大手自動車メーカーから請け負った受託開発を手掛けていて、社内は客先に訪問するエンジニアと東京オフィス内でのみ仕事をするエンジニアに分かれていたのですが、今度もなぜか私が名古屋に行かされまして（笑）

でもそのおかげで、クライアントの企画部やSIerの営業と一緒に案件を作ったり、プロジェクトを立ち上げるところから関わるようになり、ビジネスを企画立案する力が鍛えられました。

次の転職先ではアプリケーション事業の立ち上げを任されました。大手SIerと組んで事業を始めたのですが、SIerのエンジニアと発注元担当者の関係性が良くはなかったので、まずは相手との関係性を改善するところから始めなければいけませんでした。

でも最初の案件でこちらが真摯に対応するうちに、先方も私を信頼してくれたようで、その後は継続して追加や変更の発注を頂いたり、さらにはオンプレからクラウドへの移行など大型案件も受注できるようになりました。

――そうした経験を通じてビジネスを作る力を養われていったのでしょうね。

先ほども話したように、事業の成否はビジネスモデルで決まります。例えば私が一緒に仕事をした大手SIerは、大型案件の受注が見込める有力な営業先を多く持っていました。私が在籍していたような小さな会社は相手にされなくても、そのSIerの営業なら話を聞いてもらえるわけです。

そこで私がプリセールスとしてSIerの営業に同行し、アプリケーションを含めたシステム開発を積極的に提案しました。その中には5年間の長期契約につながったものもあります。一度契約すればずっと安定した収益が得られるストックビジネスなら、SIerにとっても私たちにとってもメリットが大きい。ビジネスモデルをうまく構築すれば、立ち上げたばかりの事業でも、優良案件を獲得して収益性を高めることが可能です。

――桑原さんがエンジニアの仕事だけでなく、ビジネスサイドも任されるようになった理由がよく分かりました。

おそらく若手エンジニアの多くは、自分が関わっている事業やプロジェクトがどのように収益を上げているかなんて意識していないでしょう。でも会社が何のためにビジネスをするかといえば、究極的にはお金を儲けるためですよね。

しかも自分の会社だけが儲かればいいわけでなく、発注者であるお客さまやSIerなどのパートナー企業、株主、さらには自社の従業員やその家族など、関わる人たち全員がwin-winになるような仕組みを作るのが理想です。私自身も常に「一人勝ちしないビジネスモデル」を作ることを意識しています。

サービスやプロダクトを作る人になりたいなら、技術のことだけでなく、ビジネスが成り立つ仕組みを考える力がいつか必ず求められる。そのことは知っておくべきだと思います。

技術を追求したい人も「What思考」が必要

――桑原さんはマネジメント職を経て起業し、現在は経営者の立場になりました。エンジニアがWhatを意識することで、将来のキャリアの選択肢は広がると考えていいでしょうか。

少なくとも「誰かの指示に従う立場」から「やりたいことができる立場」にはなれます。「自分がクライアントと一緒に案件を獲得した」とか「自分の提案でプロジェクトを受注できた」と言える働きをすれば、「今回はこの部分だけ自分で実装したいから、あとは他の人がやってくれる？」とお願いできますから。

ただし私は全てのエンジニアがマネジャーを目指すべきだとか、営業力をつけてプリセールスもできるようになるべきだとは思いません。「自分は手を動かすのが好きなので技術を追求したい」という人は、現場のエンジニアとして活躍し続ける選択肢も当然あります。

その場合も、与えられたタスクをこなすだけでは、業務範囲が広がらず使える技術も狭くなってしまう。私は前々職のIT企業に在籍していた頃、自ら希望してフレームワークやライブラリの開発をしていた時期がありますが、これらは通常の案件では扱う機会が少ない技術です。つまり幅広い業務を経験できる機会を自分で作っていかないと、本当の意味で技術を追求することにはなりません。

それに現場でコードを書き続けるとしても、事業やプロジェクト全体の目的を理解し、自分のプログラミングが誰にどのような価値を提供することにつながるのかを意識すれば、得られる経験の質は格段に高まります。わけもわからずひたすら手を動かすより、「何のために」を考えながら取り組むほうがモチベーションは上がるし、結果的に高い成果を出せます。

――これまで目の前の仕事をどうこなすかというHowしか考えてこなかったエンジニアがWhatに強くなるには、何から始めればいいでしょうか。

マネジャーや上司からタスクを与えられた時に、「これは誰が何のためにどうやって使うんですか」と確認する習慣をつけることをお勧めします。目的を説明してくれる人がいない環境なら、自分から質問するしかない。小さな一歩ですが、その積み重ねが意識の変化につながります。

それと他人を理解しようとする意識を持って欲しいですね。先ほども話したように、何のためにビジネスをするかといえば、関係者全員が幸せになるためです。だから自分がして欲しいことを主張するだけでなく、「どうしたらお客さまが喜ぶかな」「こうすれば同じチームのメンバーが仕事を進めやすくなるんじゃないか」と普段から考えていれば、Whatを捉える力も自然と養われるはずです。

――冒頭で若手エンジニアはWhatの重要性に気付く機会が少ないとの指摘がありましたが、そのきっかけを増やすような環境づくりも必要になりそうです。

そうですね。私たちハレソフトは、これから入ってくる若手エンジニアにWhatの重要性に気付くきっかけを提供し、どんなプロジェクトも目的志向で取り組むという価値観を共有したいと考えています。当社のミッションを「デジタル技術を磨き、ビジネス能力を高め、コミュケーションを促進し、社会に貢献する」としたのもそのためです。

これまでIT業界は既存事業の効率化とコスト削減に貢献してきました。しかしChatGPTの登場が社会にまったく新しい価値をもたらしたように、現在は課題解決だけでなく、テクノロジーの力でこれまでにない価値を創造する力が期待されています。

そのためにはデジタル技術の向上はもちろんのこと、市場の変化やビジネスの動向を敏感に捉える力が必要です。また新しい価値を生み出すには、様々な領域の専門家と積極的にコミュニケーションし、自分たちが持つ技術や知見を広げていくことも求められます。

エンジニアであっても技術だけでは社会に貢献できない時代になりつつある中、私たちは「何のためにやるのか」を意識し、プロジェクトの中核を担うエンジニア集団であり続けることを目指します。

>>>ハレソフトの中途採用情報はこちら

取材・文／塚田有香　撮影／桑原美樹　編集／玉城智子（編集部）