105
58

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

株式会社PRUMのmasaです。

今日は開発現場で大切なプログラミング前後の工程のお話をします。内容はそれらの工程のほんの一部になりますが、主にエンジニア未経験者、駆け出しエンジニアの方々の知見が少しでも広がればと思います。

1. 【プログラミングの前】「何を作るか」の合意がすべて

エンジニアの仕事は、プログラミングする前から始まっています。ここを疎かにすると、どんなに綺麗なコードを書いても、誰にも喜ばれないものを作ることになりかねません。

目に見える機能だけでなく目に見えにくい「品質」を握る

「ユーザー情報を更新するボタン」を作る際、エンジニア初心者の方は「データを保存する機能」という 機能要件 だけを考えがちです。もちろんそれも大事ですが、目に見えにくい 非機能要件 を実装することも大切です。

機能要件(何ができるか)

システムが提供する「機能」そのものです。

例:ログインができる、商品がカートに入る、検索結果が表示される。

いわば「目に見える動き」のことですね。

非機能要件

機能以外の「性能」や「信頼性」のことです。

例:1秒以内に画面が開く(性能)、メンテナンス以外では止まらない(可用性)、ハッカーに攻撃されない(セキュリティ)。

いわば「当たり前を支える品質」のことです。

家づくりで例えると…

  • 機能要件:「キッチンがある」「寝室が2つある」
  • 非機能要件:「震度7でも壊れない(耐震性)」「冬でも暖かい(断熱性)」

いくらキッチンが豪華でも、冬に凍えるほど寒かったら、その家には住みたくないですよね。システムも同じです。

非機能要件を意識しないと結局手戻りに

システム開発において、避けたいのは「やり直し(手戻り)」です。僕自身、仕様の思い込みで3日間かけて書いたコードが、レビューで「エラー時の考慮がゼロだね。これじゃリリースできないよ」と全ボツになったことがあります。

プログラミングはあくまで「手段」です。「仕組みを形にする」前に、リーダーなどの上位者と完成イメージを擦り合わせることが大切です。

私が所属している現場では、プログラミングに着手する前にスクラムチーム(開発チーム)で集まって要件をとことん詰めます。

  • この機能実装をロジック分解するとどうやったら成立するんだっけ?
  • この情報は現状APIから引っ張って来れないから、今回のスプリント(開発期間)ではこの情報で代替できない?

など、プログラマー、スクラムマスター(≒ 開発リーダー)、企画担当でこのような会話が飛び交います。

全ては期限内に要求事項を漏れなく実現した品質の高いアウトプットを出すためです。

2. 【プログラミングの後】「テスト」は自分のコードへの誠実さ

「ローカル環境でなんとなくシステムぽちぽちして動いたから開発完了」

これはアマチュアの思考です。

エンジニアはシステムが壊れないかを確認する「テスト」に関しても注力する必要があります。

テストには主に2つの視点が必要です。

  • ホワイトボックステスト:プログラムの内部構造を見て、潜在的な問題を検出する。
  • ブラックボックステスト:様々な入力に対して期待通りの結果が得られるかを試す。

これらのテストを経て、問題を洗い出し潰していくことで、プロダクト品質をブラッシュアップしていきます。

データの境界にこそエラー因子が潜んでいる

バグは、想定内のデータではなく 「データの変わり目(境界値)」 付近で発生することが多いです。

境界値付近のエラー例

例えば、衣料品のECサイトで限定品のナイキの靴が割引に。ただ購入制限があり、一人当たりカートに入れられる個数が「5個以下」という機能要件があったとします。

以下のコードでユーザーが5個と選択して、カートに入れるボタンを押下するとエラーになり、困惑してしまいます。
つまり機能要件を満たしていないプロダクトになってしまいます。

// ❌ 失敗したコード
// 「5個はOK」のはずが、これだと「5未満」しか通らない
if (inputQuantity < 5) {
  processOrder(); // 5を入力すると、ここを通らずエラーになる
}

// ✅ 正しいコード
// 「5個を含む(以下)」とするのが正解
if (inputQuantity <= 5) {
  processOrder();
}

このように制約条件となる数値の前後でプログラムの記述ミスなどでバグに繋がることがあります。

初心者が意識すべきテストの心得
「自分のコードを信じないこと」。色んな入力パターンを試して、期待通りの結果になるかを確認する。それを繰り返して初めて、自信を持ってリリースできる状態に近づきます。

まとめ

「要件を詰め、徹底的にテストする」という基本の積み重ねをすることが大切です。まずは目の前のコードの先にいるユーザーを意識してみてください。その意識が、「この要件は不要かな、上司/お客様に確認しよう」「このバグ出たらユーザー困るよな、ここもちゃんとテストしよう」という行動につながり、結果的に品質の高いアウトプットができます。


PRUMのエンジニアの95%以上は未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
コーポレートサイト

エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
エンジニアに役立つ記事サイト

105
58
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
105
58

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?