こんにちは、Arkth代表の新屋です。
この記事では、私が大切にしている「技術と価値」の話を書きます。

エンジニアとして働いていると、「良いコード」や「きれいな設計」、あるいは「速さや堅牢性」を追いかけること自体が目的になってしまう瞬間があります。
ただ、実際に価値や信頼が生まれるのは、成果物そのものではなく、その先で誰かの課題が解決されたときです。

極端に言うと、価値があるのはコードやアーキテクチャそのものではなく、その先の課題解決です。
技術はそのための手段であって、目的ではありません。

もちろん、技術的なスキルが不要という話ではありません。
ただ、技術的なスキルは「使ったこと」では価値になりません。課題が解決され、状況が良くなったときに、はじめて価値になります。

なぜエンジニアに“ビジネスの理解”が必要なのか

営業、企画、人事、総務、法務など、会社には様々な職種があります。
その中でも特にエンジニアは、ビジネスから少し距離があってもいい、という空気があるように感じます。

そしてこれは開発エンジニアに限りません。
インフラエンジニアでも、セキュリティエンジニアでも、同じように「技術の話だけしていればよい」となりやすい場面があります。

ただ、私の経験上、エンジニアが価値を届ける仕事をするなら、ビジネスの理解は「あると助かる」程度では済まない場面が多いと感じています。

理由はシンプルで、課題解決は「何を作るか」だけでは決まらず、
ビジネスの上で、誰が価値を受け取り、誰が運用し、誰が意思決定するのか、そしてどのような条件のもとで進めるのかによって、作り方そのものが変わるからです。

同じ機能でも、予算や納期、体制、求められる説明責任が違えば、最適な技術選定や進め方も変わってきます。

誰の課題を、どんな条件で解くかで、作り方は変わる

同じプロジェクトでも、状況によって正解は変わります。
これは技術の話というより、課題と条件の話です。

たとえば、開発の進め方ひとつ取っても、次のような判断があります。

• 全体の進捗をこまめに見せたほうが良いのか
• UIはラフでも、肝になる機能の精度を優先すべきなのか
• 見かけの進捗よりも、アーキテクチャを積み上げることを優先してよいのか

こうした判断は、コードの書き方だけでは決まりません。
誰が価値を受け取り、誰が運用し、どんな制約の中で成立させるのかによって、最適な作り方が変わるからです。

さらに言えば、性能の正解も状況で変わります。

• レイテンシーを最優先すべきなのか
• それとも一晩かかってでも精度を優先すべきなのか
• 7：3で割り切るのか
• 両方とも取りに行く“ウルトラC”はないのか

そして、その判断の裏には必ず、ヒト・モノ・カネの優先順位や、許容できるリスクがあります。

だから私は、技術の話をする前に「ステークホルダーの構造」と「制約条件」を把握したくなります。
ここが見えると、開発の優先順位も、設計も、技術選定も、ぶれにくくなるからです。

受託開発でも私は、まず前提を確認します

この感覚は、受託開発をしていると特に分かりやすいかもしれません。

受託開発でも私は、まず「誰の課題を解くのか」を確認します。
言い換えると、エンドユーザーのペルソナや利用シーンを最初に押さえたいです。

同じ機能でも、使う人のITリテラシーや業務フロー、導入の温度感が違えば、必要なUIも、運用設計も、教育コストも変わります。
ここがズレたまま作ってしまうと、どれだけ技術的に正しくても「使われない」ことが起きます。

そのうえで、次のような前提も確認します。

• エンドユーザーのペルソナ / 利用シーン / ITリテラシー
• 全体予算
• 全体規模
• 大きなマイルストーン
• ステークホルダーの構成（意思決定・運用・サポートの役割）
• 考えうるリスク（セキュリティ、運用、移行、障害時の影響など）

これは売上を背負うためというより、価値を届けるために必要だからです。

• 誰が価値を受け取るのか
• 誰が運用するのか
• どんな制約の中で成立させるのか

その条件が見えると、「作り方」が決まります。
そして「作り方」が決まれば、技術は選べるようになります。

“ビジネス情報”は、課題解決のための材料です

では、具体的にどんな情報が必要なのか。
私が確認するのは、数字を追うためではなく、課題解決の条件を揃えるためです。

たとえば、次のようなことを確認します。

• 予算取りのスパンはどれくらいか
  → 単年度の発注か、複数年の投資かで設計の正解は変わります
• 誰が、どんな視点で意思決定するか
  → 求められるものが変わります（速度、堅牢性、説明可能性など）
• エンドユーザーのITリテラシーはどの程度か
  → UI/UX、エラー処理、運用設計の難易度が変わります
• 有償サービスの場合の単価はどれくらいか
  → 求められる品質やサポート、運用コストの考え方が変わります
• 初期導入でどの程度、我慢して使ってもらえそうか
  → MVPで許される粗さを見誤ると信用を失いやすくなります
• 競合は誰で、何が強いのか
  → 勝ち筋が変わります（UX、導入の軽さ、業界の深さなど）

こうした情報が揃うと、技術選定は「好み」ではなく「目的」になりやすくなります。
「この課題を、この条件で解くなら、これが最適です」といった判断がしやすくなります。

技術選定に“唯一の正解”はありません

よく「最も良いプログラミング言語は何か」という比較がされます。
ただ、技術選定に“唯一の正解”があることは、ほとんどありません。

極端に言えば、スピードだけを見るなら低レイヤーで書くのが合理的ですし、要件を割り切ればフロント中心に寄せて実装をシンプルにすることもできます。

しかし実際は、スピード以外の条件が必ず入ってきます。
保守性、運用、セキュリティ、チームの体制、説明責任などです。

さらに言えば、その技術を扱える人材の採用難易度やコスト感、メンバーが入れ替わっても回る設計にできるかといった現実も無視できません。

だからこそ、価値の条件が揃わないまま技術だけを選ぶと、選定がブレやすいと感じています。
技術選定は、条件を満たして課題を解くための手段に過ぎないからです。

競合を見ずに技術だけを選ぶと、途中でズレやすい

たとえば競合が、Salesforceやfreee、SmartHRのように、すでに信頼があるプロダクトだった場合、同じ土俵で正面から勝負するのは簡単ではありません。

勝ち筋はどこか。

• UXなのか
• 導入の軽さなのか
• 現場に刺さる細部なのか
• 特定業界への深さなのか

ここが曖昧なまま技術だけを選ぶと、途中で期待とズレが生まれます。
だから私は最初に、競合を見て、勝ち方を考えたくなります。

これはビジネスの話に見えて、実は設計と技術選定の話でもあります。

課題を知るために、ドメイン知識は学びに行く

課題解決をするには、当然ですが「課題」を知らなければなりません。
そのために私がやっているのは、ドメイン知識を学びに行くことです。

YouTubeでも、本でも構いません。
必要ならショールームに行って、実物を触り、現場の方の話を聞きます。

東京なら無料の勉強会や展示会もたくさんあります。
現場の空気を少しでも知るだけで、仕様書の読み方や、設計の勘所が変わってきます。

そしてこの「課題が分かる」状態になると、何を作るべきかが見え、技術を選ぶ基準もはっきりしてきます。

最後に：エンジニアの価値は、課題解決にある

技術的なスキルは強力な道具です。
ただし道具は、それ単体では価値になりません。

価値になるのは、その道具で課題を解き、誰かの時間を節約し、状況を良くしたときです。
だからこそ、エンジニアが強くなるためには「コードが書ける」「物を作れる」だけでは足りないと感じています。

“なぜそれを、どう作るのか”まで言語化できると、仕事の質が大きく変わります。

私たちが大切にしていること

私たちは、エンジニアが「作ること」だけに閉じず、価値の現場に近い場所で開発できることを大切にしています。

仕様やチケットだけを渡して終わりではなく、「誰のどんな課題なのか」「なぜ今それが必要なのか」といった背景も、できるだけ共有するようにしています。

それはエンジニアにビジネスを押し付けたいからではありません。
課題の構造が見えているほうが、設計も技術選定も優先順位も、より良い判断ができるからです。

そして何より、そういう視点で考えるエンジニアが周りにいる環境だと、自然と会話の水準が上がります。
「この機能は何を解きたいのか」「誰が使い、誰が運用するのか」「どこが勝ち筋か」――そういう話が当たり前に出てくる。

その中で働くこと自体が、エンジニアの成長につながると考えています。