AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity

by MinoDriven

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© DMM AIによる自動化と不安ソフトウェア開発は「AIに実装させて人間がレビューする」という方法にどんどんシフトしてきています。こうしたAIへ仕事が置き換わっていく状況に「AIに仕事を奪われるのでは」「私たちの仕事はこれからどうなっていくのか」「機械がオラたちの仕事を奪うだ！ネオラッダイト運動だあああ！！」という不安を覚える人は少なくないと思います。特に新卒や若年エンジニアにこうした不安が多いと聞きます。 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© DMM あなたならどうする！？！？？現状、日本企業のAI導入率は41%程度（他の先進国より低い）、その中でもAIオールインは一握りだと言われています。 AI技術は日進月歩で、AI導入のハードルはどんどん下がってきています。開発のAI化が業界的に当たり前になってきたとき、「あなたはどうするか」という状況に遅かれ早かれ直面することになります。さあ、あなたならどうする！？！？？（めっちゃ煽ります） 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

© DMM 技術観点に留まった考え方「どんな問題を解決するためにその仕事をしていますか？」と問われたとき、技術観点でしか回答できないケース。 ● 「APIを正しく動作させるためです」 ● 「パフォーマンス要件を満たすためです」 ● 「そのカラムがNULLだと困るからです」 ● 「仕様を満たすためです」これはこれで正しいかも知れませんが、それによって顧客のどんな問題が解決されるかまで言及していません。 26

Slide 27

Slide 27 text

© DMM 技術的な言葉による対話の弊害顧客要求やビジネスの議論をしている際、即座に技術用語に置き換えて話し始めるケース。 ● 「ああ、それは◯◯テーブルの▲▲カラムのことですね」 ● 「そういう問題であれば◯◯Infoにフラグ追加すればいけますよ」エンジニア本人は問題解決の方法を提案しているつもりかも知れません。しかし使っている言葉が違っているために、意思疎通が困難になります。そもそも解きたい問題は何かについて目線が合わなくなります。 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

© DMM 30 スキーマ理論自分が知っている知識や過去の経験に当てはめて物事を解釈しようとする脳の性質。「ジャングルの原住民を都会に連れて行ったらどんな反応をするか」というテレビ番組が昔ありました。原住民は電車を指して「なんて巨大なヘビなんだ」と言いました。電車を見たことがないのでヘビと解釈したのです。エンジニアは技術のことで頭がいっぱいです。そのため、顧客要求などビジネスサイドの話も、技術という枠組み（スキーマ）で解釈しようとするクセが働きます。無意識に。

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

© DMM 具体と抽象を行き来するスキル抽象化の定義には諸説ありますが、システムは目的達成手段なので、この定義に則った抽象化を考えを本資料では採用します。この定義に基づくと、「目的」という切り口で具体と抽象を行き来し、物事を整理する必要があります。 35 対象物に付随する様々な特徴のうち、ある目的に合致した特徴のみを抜き出すこと。 (『「具体⇄抽象」トレーニング思考力が飛躍的にアップする 29問』著:細谷功, PHPビジネス新書, p.97)

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© DMM 「目標」は要件や仕様に相当する 43 【目的】注文数を正しく表現したい【目標】注文数は1〜200であること【手段】目的を満たすソースコードシステムを不具合なく的確に機能させるには、仕様を決める必要があります。例えば注文数が負数だと不具合になりますし、 5000兆個といった非現実的な数量も問題があります。注文数については出荷業務の都合などを考慮し仕様を決めます。こうした要件や仕様が目標に相当します。目標を満たすようにコードを実装します。

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© DMM 認知バイアスを意識した正確な顧客要求の理解認知バイアスに陥ると問題を正しく把握できなくなります。認知バイアスを意識して正確な事象把握に努めましょう。【スキーマ理論】自分の知識や経験に当てはめて物事を解釈しようとする脳の性質。枠組み（スキーマ）の違いを意識して意思疎通することが肝要。【言語ゲーム】言葉の意味は単独では決まらず、文脈によって決まるとする哲学の考え。同じ「犬」でも「山田さんちの犬」「権力の犬」では意味がまるで違う。文脈を意識し、顧客要求を正確に理解するよう努めることが肝要。 49

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© DMM ソフトウェア開発＝品質特性の作り込み 54 品質特性説明品質副特性機能適合性機能がニーズを満たす度合い機能完全性、機能正確性、機能適切性性能効率性リソース効率や性能の度合い時間効率性、資源効率性、容量満足性互換性他のシステムと情報共有、交換できる度合い共存性、相互運用性使用性利用者がシステムを満足に利用できる度合い適切度認識性、習得性、運用操作性、ユーザーエラー防止性、ユーザーインターフェイス快美性、アクセシビリティ信頼性必要なときに機能実行できる度合い成熟性、可用性、障害許容性、回復性セキュリティ不正利用から保護する度合い機密性、インテグリティ、否認防止性、責任追跡性、真正性保守性システムを修正する有効性や効率の度合いモジュール性、再利用性、解析性、修正性、試験性移植性他の実行環境に移植できる度合い適応性、設置性、置換性

Slide 55

Slide 55 text

© DMM ソフトウェアアーキテクチャとはソフトウェアとはただ作っても品質特性が向上するものではなく、なんらかの品質特性を促進するために意図をもってアーキテクチャを設計する必要がある、ということですね。 55 望まれる品質特性やその他の性質を促進するためにソフトウェアをどう構成するかに対する、重要な設計判断が集まったもの『Design It!』著:Michael Keeling,訳:島田浩二,2019年刊行,オライリー・ジャパン,p.8より引用

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

© DMM 61 プロダクト価値最大化を目的に、ソフトウェア品質特性の戦略的全体最適化を担う職種開発リソースは有限。全ての品質特性を最大にすることはできません。また、品質特性どうしがトレードオフになるものもあります。したがって、どの品質特性に対してコストをかけて向上させるか、取捨選択する戦略的判断（何かを取り何かを捨てる）が必要になります。そして、その戦略的判断の軸になるのがプロダクトの価値です。プロダクト価値が最大化するように、重要な品質特性にはコストをかけ、それ以外の品質特性にはコストをかけない、という判断をします。

Slide 62

Slide 62 text

© DMM 62 プロダクト価値最大化を目的に、ソフトウェア品質特性の戦略的全体最適化を担う職種品質特性には良し悪しがあります。良し悪しを判断するには、判断可能な知識が必要です。その知識とは、品質特性の理想状態です。理想と比較して初めて良いか悪いかギャップを観測できます。また、品質改善には改善するための技術知識が必要です。例えば変更容易性については、「変更容易性の高い構造とはどういう構造か」を知る必要があります。また、変更容易性を高めるための技法やテクニック（DDD、リファクタリング、テストコードetc）を知る必要があります。