株式会社PRUMのmasaです。
今回は プログラミング初学者の方が見落としがちなプロダクトを見る視点 についてお伝えします。
最初は目の前のプログラムに向き合って、純粋なプログラミングの面白さや苦悩を体験することは大切です。
一方で、現場で求められている、より視座高くプロダクトを見る視点を持つことも、プロダクト品質を上げ、将来的に自分の市場価値を向上させる上で大切だと思っています。
今回はその点について、IT業界の開発現場入りを目指して勉強中のプログラミング初学者の方向けに自分の知識とポイントごとの簡単なアドバイスを述べさせていただきました。興味のある方は見ていただけると嬉しいです。
1. システムを「要件」でみる視点
一つ目は要件という視点です。
お客様が求める要件には大きく分けて 機能要件 と 非機能要件 があります。
-
機能要件 ：システムを作る「目的」となる具体的な役割（メッセージを送れる、決済を完了させるなど）。
-
非機能要件 ：システムを使い続けるための「信頼感」（画面が0.5秒で開くサクサク感、個人情報が漏れない安心感、災害時でもデータが消えない強さなど）。
機能要件はわかりやすくて実装のイメージもつきやすいですが、非機能要件はプログラミング初学者の方にとってはイメージしづらいですよね。
それはITの知見があまりないお客様も同じなんですね。お客様の多くは機能要件については要望を上げていただけても、非機能要件に関しては意識されない、できないことが多いです。むしろ実装されていて当然と思われる方も少なくないです。
実は大きなトラブルはこの「非機能要件」の詰めの甘さが原因になることが多いです。
そのため、機能要件だけでなく、非機能要件に関しても意識を働かせて要件に漏れがないかを確認できるようになることも大切です。
以下を持つことで漏れなく非機能要件を実装し、お客様に喜ばれるプロダクトを作れるエンジニアに近づきます。
-
プログラミング以外の知識（ネットワークやセキュリティなど）や経験値
-
どれくらいの人が同時に使っても耐えられるか？などの想像する習慣
初学者の方へのアドバイス
日常使いしているサービスに「なぜ？」と問う癖をつけてみましょう
普段使っているSNSや通販サイトが「なぜサクサク動くのか」「なぜアクセスが集中しても落ちないのか」を想像してみてください。
例えば、
この読み込みの速さはキャッシュを使っているのかな？
このエラー表示画面のデザインはユーザーを不安にさせない工夫かな？
と、エンジニア視点で観察する習慣が、漏れのない要件の洗い出しにつながります。
2. システムの種類を「変化のペース」で見る視点
「要件」の視点はシステム単体の視点でした。ここではもう少し視座を高くして見た視点をご紹介します。
実務の世界では、システムを 変化のペース という物さしで分類して考える方法があります。
その代表的な考え方が、ガートナー社が提唱した ペース・レイヤー です。
-
SoR (System of Record)：
「記録のためのシステム」。会計や人事管理など、 正確さが命 です。ここでは「カッコいいUI」よりも「ミスが起きない、堅実で効率的な設計」が求められます。- 身近な例： 銀行の勘定系システム、企業の給与計算ソフト、在庫管理台帳。
- 変化のペース： 低速（5〜10年単位）。法令遵守や安定性が最優先され、一度構築すると長期間維持されます。
-
SoD (System of Differentiation)：
「差別化のためのシステム」。自社独自のビジネスプロセスや強みを支えるためのものです。業界標準ではなく、競合他社との違いを生み出す独自のロジックが求められます。- 身近な例： Amazonのレコメンドエンジン、独自の配送ルート最適化システム、会員ランク別の優待判定ロジック。
- 変化のペース： 中速（1〜3年単位）。自社の戦略や競合の動向に合わせて、数年ごとに進化・改善させます。
-
SoI (System of Innovation)：
「革新のためのシステム」。新しいビジネスモデルやアイデアを試すための、 実験的なシステム です。- 身近な例： 生成AIを活用した対話型接客の試作版、期間限定のバーチャル店舗、社内のアイデアコンテストから生まれたプロトタイプ。
- 変化のペース： 高速（数日〜数週間単位）。成功か失敗かを素早く判断し、必要なら即座に作り直す、あるいは撤退する機動力が必要です。
この考え方を知ることで、システムの目的・将来像から開発ペースの大枠をイメージしやすくなり、今プログラミング中のプロダクトに対して現場で求められる開発のスピード感をイメージしやすくなると思います。
例：SoRにおけるUI刷新の失敗
SoRのシステムなのに目的とは異なる対応をしたことによる例ですね。
-
施策の内容
社内の経費精算システム（SoR）の改修において、デザイン性を重視し、独断で入力項目の削減やアニメーションの多用を伴う「モダンなUI」への刷新を実施。 -
本来の意図
UIを今風にオシャレにすることで、ユーザー体験（UX）の向上を図る。 -
結果
経理部門などのメインユーザーから「入力ミスが増えた」「以前のシステムのUIの方がシンプルでわかりやすく効率的に仕事ができた」といった不評を招く結果となった。 -
得られる教訓
業務効率や正確性が最優先されるSoR（System of Record）においては、現場を無視した見た目重視のデザイン変更は、かえって生産性を低下させるリスクがある。
初学者の方へのアドバイス
自分が今書いているコードが「絶対に間違えてはいけない類のプロダクト（SoR）」なのか、「ユーザーをワクワクさせる挑戦系プロダクト（SoI）」なのかをイメージしてみてください。そこから世に出ている同種のプロダクトの開発ペースをイメージしやすくなります。
さいごに
システムを形にするのは僕たちエンジニアです。技術は手段に過ぎません。「何のために使うのか」という目的意識を持つことで、プログラミングがより良い未来を創る仕事に変わります。
未経験から始めた僕も、最初は失敗ばかりでした。でも、一つずつ「なぜ？」と疑問をもち、泥臭く理解に努めたことで、今の自分があります。エンジニア未経験、初学者の方々の挑戦を心から応援しています！
PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ コーポレートサイト
エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト