エンジニアとして高みを目指す、 利益を生み出す設計の考え方 / design-for-profit

こちらのイベントの登壇資料です。

エンジニアとして高みを目指す、 利益を生み出す設計の考え方
https://hireroo.connpass.com/event/365195/

Transcript

1. © DMM © DMM エンジニアとして高みを目指す 利益を生み出す設計の考え方 2025/09/25(木) 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 DeveloperProductivityGroup DMMプラットフォームの設計を改善し 開発生産性向上を図るのがミッション 2
3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 ITエンジニア本大賞2023技術書部門大賞受賞 台湾版、韓国語版でも翻訳出版 3
4. © DMM 今日話す大事なこと • より高いキャリアを目指すには、利益を意識すること。 • 利益を生み出せるようにITスキルを活用できるようになること。 • 目的−目標−手段の関係性で考えられるようになること。 • 目的−目標−手段の関係が、 ソフトウェアの機能や構造にダイレクトに影響すること。 4 今日はこういうお話をします
5. © DMM 第1部 キャリアと利益
6. © DMM IT企業はなんのために存在していますか？
7. © DMM もう少し抽象的に 企業はなんのために存在していますか？
8. © DMM 企業は利益を得るために存在しています 利益を追求する組織集団です
9. © DMM 食料品を販売したり、衣服を販売したり、 ホテルを経営したり、 商品やサービスを提供して 利益を得ています
10. © DMM ではIT企業は どのように利益を得ていますか？
11. © DMM IT企業は 顧客が利用するソフトウェアを開発して 利益を得ています
12. © DMM ここで給与の話
13. © DMM 給与はどこからやって来ますか？
14. © DMM 企業が得た利益の一部が あなたの給与になります
15. © DMM 利益が増えれば給与が増えます 逆に利益が減ると給与は増えません 当然キャリアアップも難しいでしょう
16. © DMM ここまで全然当たり前の話しかしていません
17. © DMM しかし　しかしですよ
18. © DMM みなさん、 普段から利益のこと考えてますか？ 利益を踏まえた仕事を考えていますか？
19. © DMM コード書くことだけが仕事になっていませんか？
20. © DMM あなたが経営者なら誰に高給を支払いますか？ 1. 利益向上を狙ったシステム要件を策定し、実績を出し続けている人 2. 実績はないけどIT資格を沢山持っている人 3. 開発効率を高めるシステム構造を設計したり、 不具合等による損失を抑制する構成や構造を設計できる人 4. 「私はReact使いたいから、とにかくReact使える開発にアサインして ほしい」と言い続けている人 20
21. © DMM あなたが経営者なら誰に高給を支払いますか？ 1. 利益向上を狙ったシステム要件を策定し、実績を出し続けている人 2. 実績はないけどIT資格を沢山持っている人 3. 開発効率を高めるシステム構造を設計したり、 不具合等による損失を抑制する構成や構造を設計できる人 4. 「私はReact使いたいから、とにかくReact使える開発にアサインして ほしい」と言い続けている人 私なら1と3の人に高給を支払います。 利益に寄与していることが明確だからです。 21
22. © DMM 「そうは言っても 利益はビジネスサイドが考えることでは？」 「自分は技術が専門だし」 こう感じていませんか？
23. © DMM 本当にそうでしょうか
24. © DMM こんなケース、身に覚えがありませんか • せっかく新機能を開発したのにあまり使われないケース • 顧客の要望通りのものを作ったはずなのに 「求めていたのはこんな機能じゃないんだが」と失望されるケース • コードが複雑すぎて実装がなかなか進まず、 いつまで経っても新機能をリリースできないケース • リリースしても不具合が続出し、顧客離れを起こしているケース このような利益創出困難なケースは枚挙に暇がありません 利益はソフトウェア開発のすぐ隣にいます 24
25. © DMM 私たちの専門は技術です 技術力を高めることは大事です ジュニアの間は技術だけ考えていればいいかも知れません しかしそのうち頭打ちになります より高いキャリアを目指すのであれば 「利益向上への寄与」を意識したスキルの獲得＆活用が必須です
26. © DMM 利益ベースに考え方をシフトチェンジしよう 単に「いろんなITスキルを獲得する、技術力を高める」では頭打ちです。 「利益を増やす成果を、再現性を持って出せる」 「利益を生み出すことを意図してITスキルを活用できる」 こういう人材に企業は高い給与を支払います。 また、より高いキャリアにアサインします。 利益を中心に技術を操れるようになりましょう。 ちなみに弊社DMMの私の同僚も ちゃんと利益や投資効果を考えて仕事を組み立てています。 26
27. © DMM ちなみにみなさん、 ご自身の仕事を利益観点で説明できますか？ 職務経歴書に利益観点の記述はありますか？
28. © DMM ミノ駆動の例 今すぐ職務経歴書を見直しましょう。 単なる技術経験の羅列ではなく、 利益観点の実績で説明できないか改善検討しましょう。 28 DMMプラットフォーム全体の変更容易性を向上し、開発速度を高める。 変更容易性に関して設計スキル育成やチーム指導などの設計支援を推進する。 それにより開発コストを抑え、プロダクトが成長しやすい利益体質にする。 変更容易性の向上は不具合の抑制にもつながる。 不具合を抑制するシステム構造へ改善することにより、 不具合による利益損失の未然防止に貢献する。
29. © DMM 第2部 利益向上のための 目的−目標−手段
30. © DMM 目的、目標、手段の定義 30 一般的な定義 目的 目指すべき状態、行動のねらい、目当て 目標 何をもって目的達成とみなすかを示す具体条件 手段 目的を達成するための方法や道具
31. © DMM 目的と手段 私たちの活動には、なんらかの目的があります。 そして目的を達成するための手段（行動や方法）を用います。 あらゆる活動が目的−手段の関係で成り立っています。 31 目的 手段 ダイエットしたい 有酸素運動 美味しいものを食べたい 寿司 髪を乾かしたい ドライヤー
32. © DMM 目的と目標 目的の達成について考えてみます。 たとえば「ダイエットしたい」という目的は、 どうしたら達成したと言えるでしょうか。自己満足して終わりですか？ そうではなく体重や体脂肪率について 具体的な条件や基準を定めるはずです。 この具体条件や基準が目標です。 32 目的 目標 ダイエットしたい ・体重を60kgまで減らすこと ・体脂肪率を17%まで減らすこと
33. © DMM 目的−目標−手段 そして目標を満たすために 適切な手段を用います。 目的、目標、手段の関係が右図となります。 目的、目標、手段の関係を適切に定義する ことで、確実に目的達成できます。 では逆に不適切だったら どうなるでしょうか？ 33 【目的】 ダイエットしたい 【目標】 ・体重60kgまで減らすこと ・体脂肪率を17%まで減らすこと 【手段】 ・有酸素運動 ・バランスの取れた食事
34. © DMM 定義が不適切だと目的達成困難 34 【目的】 ダイエットしたい 【目標】 ・体重40kg以下にすること 【手段】 ・絶食 ・ダイエット番組を見るだけ 身長170cmの人が40kgまで体重を 落とすと明らかに健康に害があります 絶食は健康を害したり、 リバウンドの原因になります ダイエット番組見ただけでは 絶対に痩せません！
35. © DMM 目的、目標、手段は、 私たちが開発するソフトウェアでも同じことが言えます。 顧客の要求（目的）をかなえるための手段として、 私たちはソフトウェアを開発しているのです。 35 目的 手段 商品を売買したい ショッピングサイト 動画を視聴したい 動画投稿サイト 遊びたい ゲームソフト 効率良く勉強したい 学習サイト 私たちは「手段」を開発している
36. © DMM 「目標」は要件や仕様に相当する 36 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 目的を満たすソースコード システムを不具合なく的確に機能させるには、仕 様を決める必要があります。 例えば注文数は負数だと不具合になりますし、 5000兆個といった非現実的な数量も問題があ ります。 出荷業務の都合などを考慮し仕様を決めます。 こうした要件や仕様が目標に相当します。 目標を満たすようにコードを実施します。
37. © DMM 目的、目標、手段は、ソフトウェア開発では次の位置付けと言えます 37 一般的な定義 ソフトウェア開発における位置付け 目的 目指すべき状態、 行動のねらい （顧客の）要求 目標 目的達成の具体条件 機能要件、仕様、制約 手段 目的達成に用いる 方法や道具 ソースコード そしてソフトウェア開発の成功と利益向上のためにも 目的、目標、手段の適切な定義が重要です
38. © DMM 利益、収益、費用の関係 費用：業務遂行にかかる諸々のコスト。 収益：商品やサービスが稼いだお金の総額。費用が差し引かれる前の金額。 利益：収益から費用を差し引いた金額。 38 利益 収益 費用 我々の給料は「費用」ではあるが、費用 に回せる利益が元になっている。
39. © DMM 利益に強く関係する 機能適合性、変更容易性 について説明します
40. © DMM 機能適合性（機能性） • ソフトウェア品質特性のひとつ。機能が顧客ニーズを満たす度合い。 • 機能性が高いと当然収益も上がる。 • 競争優位性のある機能の開発が収益向上する上で重要。 • 優位性のない機能は顧客を満足させることができず、収益が低下。 40 利益 収益 費用 収益↓　利益↓
41. © DMM 【目的】人は自分が欲しいものを知らない 「自動車」という概念が存在しない時代において自動車を欲しがる人はい ません。 ソフトウェア開発も同様に、顧客が自分の本当の目的を知らないことが 往々にしてあります。「◯◯機能を開発してほしい」が「もっと速い馬がほし い」に相当する可能性があります。 本当の目的が何であるかを深く洞察する必要があります。 41 もし顧客に、彼らの望むものを聞いていたら、彼らは「もっと速い馬が欲しい」と答え ていただろう（ヘンリー・フォード氏）
42. © DMM 【目標】より魅力的な仕様を求め続ける ある目的を満たすために、どちらの仕様を選びますか？ より魅力的な仕様ですよね。 ただ仕様を決めればいいというわけではありません。 利益を高めるには、「もっと魅力的な仕様に落とし込めないか」と 意識して考え続けることが重要です。 42 【目的】 顧客要求 【目標】 ありきたりな仕様 【目標】 魅力的な仕様
43. © DMM 【目標】「仕様通りに実装したんです」では頭打ち 前述の図で「ありきたりな仕様」に決まったとします。 あなたが実装担当だとして、大真面目に仕様通りに実装したとします。 結果、その機能で利益が上がるでしょうか。 ついでに言うとあなたの評価は上がるでしょうか。 「仕様通りに実装したんです、評価してください！」 といくら訴えても評価は頭打ちでしょう。 仕様は目標であり、目的を満たすための具体条件です。 仕様が目的達成上本当に妥当なものであるか評価し、 意見したり提案する姿勢が重要です。 43
44. © DMM 変更容易性 • ソフトウェア品質特性のひとつ。 • なるべくバグを埋め込まず素早く正確にコード変更可能な度合い。 • 変更容易性の高い構造であるほど開発コスト（費用）が下がる。 • 逆に複雑で混乱した構造は変更容易性が低く、開発コスト増大。 44 利益 費用 収益 費用↑　利益↓
45. © DMM 45 // 注文明細クラス class OrderItem { int orderItemId; int orderId; int productId; int unitPrice; int quantity; // 注文数 } たとえばショッピングサイトにおける「注文」を考えてみます。 注文明細クラスを次のように実装したとします。 quantityは注文数です。
46. © DMM 46 orderItem.quantity = -1; この構造には問題があります。 マイナス注文数といった不正な値を代入できてしまいます。
47. © DMM 47 class Validator { boolean isValidQuantity(OrderItem orderItem) { return 1 <= orderItem.quantity && orderItem.quantity <= 200; } } 正しい注文数だけを受け付けられるよう、 次のようなバリデーションをどこかに実装するかもしれません。 しかしこの実装では、以下のような問題が生じる可能性があります。 • バリデーションを呼び忘れるとバグになる • 別の箇所に重複したコードが実装される可能性 • 注文数の仕様変更時、あちこち探し回らなければならない
48. © DMM 48 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 OrderItem.quantity 【手段】 Validator.isValidQuantityメソッド 目的に対して手段がバラバラになっているのが原因 家電に例えるとドライヤーがバラバラに提供されているような状態
49. © DMM 49 【目的】 注文数を正しく表現したい 【目標】 注文数は1〜200であること 【手段】 Quantityクラス バラバラにしない 目的を一貫して達成できるようひとまとめにする それがカプセル化
50. © DMM 50 class Quantity { private static final int MIN = 1; private static final int MAX = 200; final int value; Quantity(final int value) { if (value < MIN || MAX < value) { throw new IllegalArgumentException("注文数は1以上200以下で指定してください"); } this.value = value; } Quantity add(final Quantity other) { return new Quantity(value + other.value); } } カプセル化とはデータとそのデータを操作するロジックをひとま とめにすること。これで正しい注文数を確実に表現できる。
51. © DMM 51 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.01); if (isGoldMember) { value += 10000; } } } 会員ランク 年間ポイントボーナス仕様 一般会員 年間購入費の1% ゴールド会員 年間購入費の1% + 10000ポイント ショッピングサイトにおけるポイントボーナスを考えてみます。 この仕様を下記のように実装したとします。
52. © DMM 52 class YearlyPointBonus { int value; YearlyPointBonus(PurchaseHistory purchaseHistory, boolean isGoldMember) { value = (int)(purchaseHistory.yearlyAmount() * 0.02); if (isGoldMember) { value += 10000; } } } 会員ランク 年間ポイントボーナス仕様 一般会員 年間購入費の1% ゴールド会員 年間購入費の2% + 10000ポイント ゴールド会員側の仕様が2%に変わり、0.02に実装修正すると、 一般会員側が正しく計算できなくなります。バグになります！
53. © DMM 53 【目的】 一般会員の年間ポイントボーナスを 計算したい 【目標】 年間購入費の1% 【手段】 YearlyPointBonusクラス 【目的】 ゴールド会員年間ポイントボーナスを 計算したい 【目標】 年間購入費1% + 10000ポイント 手段であるYearlyPointBonusが 異なる目的に使い回されているのが原因
54. © DMM 54 【目的】 一般会員の年間ポイントボーナスを 計算したい 【目標】 年間購入費の1% 【手段】 RegularYearlyPointBonusクラス 【目的】 ゴールド会員年間ポイントボーナスを 計算したい 【目標】 年間購入費1% + 10000ポイント 目的それぞれで手段を分ける これが関心の分離 【手段】 GoldYearlyPointBonusクラス
55. © DMM 55 class RegularYearlyPointBonus { private static final double POINT_RATE = 0.01; final int value; RegularYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE); } } class GoldYearlyPointBonus { private static final double POINT_RATE = 0.01; private static final int FIXED_POINT_BONUS = 10000; final int value; GoldYearlyPointBonus(final PurchaseHistory purchaseHistory) { value = (int)(purchaseHistory.yearlyAmount() * POINT_RATE) + FIXED_POINT_BONUS; } } このように目的ごとに分離することで コード変更影響が生じなくなります。変更に強くなります。
56. © DMM 56 ボールペン のり 付箋 はさみ ホッチキス 修正液 予約注文 クラス 抽選注文 クラス サブスク注文 クラス 普通注文 クラス 別に難しいことを言ってるわけではあ りません。 みなさん、普段道具を目的ごとに収納 していますよね。 同様にクラスも目的ごとに分 けましょうということです。 目的ごとに取り扱うデータや ロジックが違います。
57. © DMM 57 道具箱 フライパン トイレ用ラバーカップ 最悪なのがこういうケース！明らかに異常なのは一目瞭然。 しかしソースコードは味も臭いもしないので、 一緒にして良いものかどうか判断がつきにくい。 コードの目的を見破れるようになりましょう。
58. © DMM 58 【目標（仕様）】 年間購入費の1% 【手段】 YearlyPointBonusクラス 【目標（仕様）】 年間購入費1% + 10000ポイント 目的は認知困難です。 仕様書だけ眺めていても目的は分かりません。 「何のため（目的）の仕様なのか」を考えることが大事です。
59. © DMM まとめ • 私たちは利益を上げるためにソフトウェアを開発しています。 • より高いキャリアを目指すには、利益を意識しましょう。 利益を生み出すことを意図して開発したり、 ITスキルを活用できるようになりましょう。 • 利益向上の基本は、目的達成です。 目的達成には、目的−目標−手段の関係性の整理が必須です。 • 目的−目標−手段の関係は、ソフトウェアの機能や 開発力を高めるためのモジュール構造の設計を大きく左右します。 目的を意識して機能要件を策定したり、 構造設計できるようになりましょう。 59
60. © DMM 【PR】僕と一緒に働きたい人を募集中です 大規模組織のコード品質を改善する仕組み作りがお仕事です。 生成AIをガンガン使います。 多少設計スキルが浅くてもミノ駆動が育成します。 60 ご興味のある方はここにアクセス！ https://dmm-corp.com/recruit/engineer/4735/
61. © DMM ご清聴ありがとうございました