カイゼン・ジャーニー・カンファレンス - プログラマのジャーニー

by h.t.

Slide 1

Slide 1 text

カイゼンジャーニーいたるまでのプログラマのカイゼンジャーニー（プログラマ賛歌）会社員・エンジニア／スクラムマスター ※ 個人の意見であり、所属する会社・組織の意見ではありません

Slide 2

Slide 2 text

カイゼンジャーニー自分のことのように読みました、とても面白かったです！！多謝わたしスクラムマスターもやっていますが、本職はプログラマです。今日は "プログラマ" という、現場の人間が、どうやって「カイゼンジャーニー」の主人公になっていったか。現場では何が起きていて、その結果、なぜ「カイゼン」が生まれていったか。そんなジャーニーをプログラマ視点で語ってみようと思います。もし近い境遇の方いましたら、何か１つでも持ち帰ってもらえるとうれしいと思って話します！！（けっこうややこしい話をしますがついてきてくださいね……汗）

Slide 3

Slide 3 text

はじめに MSX BASIC があったスペース1byte分のメモリも惜しかったただただプログラムが動くことがすべてだった

Slide 4

Slide 4 text

C／C++@お仕事ただ動くだけじゃダメ。プロとして安定した品質・保守性が必要。

Slide 5

Slide 5 text

「なるほど、ソースコードの品質をあげればいいのね？」つまりバグをなくせばいいんでしょ？

Slide 6

Slide 6 text

ソースコードの品質向上のためのソフトウェアテスティング JSTQB取得 ※ JSTQB=Japan Software Testing Qualifications Board 品質工学の勉強ペアワイズ法（直交表）ソフトウェアテストの原則テストの心理学

Slide 7

Slide 7 text

しかしそんな簡単にはいかないバグの発見工程における修正コスト要件設計コーディング単体テスト結合テスト運用後単体テストでバグを見つけるより、コーディングでバグを対処した方が半分くらいのコストで対応が可能

Slide 8

Slide 8 text

ソースコードへのアプローチ静的解析・メトリクス ⇒ ソースコード品質の定量化 McCabe循環的複雑度 CKメトリクス Martinのメトリクス Static Code Analytics Memory Leak Coding Style :

Slide 9

Slide 9 text

しかし潮流は更なる上流重視の流れ要件設計コーディング単体テスト結合テスト運用後コーディングよりも設計段階でバグを見つけた方が早く安く解決できるバグの発見工程における修正コスト

Slide 10

Slide 10 text

ドキュメント重視 ○○設計書 xx株式会社ソースコードよりも設計段階で不具合をつぶしたい "非エンジニア" でも読める "非コード" による設計とレビューの充実 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社 ○○設計書 xx株式会社

Slide 11

Slide 11 text

しかししかし要件設計コーディング単体テスト結合テスト運用後要件段階でバグを見つけた方がもっと早く安く解決できるバグの発見工程における修正コスト

Slide 12

Slide 12 text

SysML REBOK （要求工学）形式手法フォーマルメソッド要件定義で不具合をつぶしたい

Slide 13

Slide 13 text

高度な設定ファイルによるフレームワーク厳密な仕様がそのまま実装に自動変換 UML XMI MOF .java application .xml beans .xml build .xml server .xml web .xml * .xml うんうん大事なのは要件や仕様であって、コードではない

Slide 14

Slide 14 text

厳密・厳格なUML Booch → UML 1.ｘ → 2.0 SysML,BPMN... ユースケースを洗い出すのに1年以上をかけるプロジェクトも class object 厳密・厳格な要件定義大事な要求・仕様の表現のために

Slide 15

Slide 15 text

人の欲求はつきない要件設計コーディング単体テスト結合テスト運用後バグの発見工程における修正コスト ????

Slide 16

Slide 16 text

そもそも、どの工程でも、すべての成果物は "プロセス" の結果でてくるもの。であれば "プロセス" をしっかりすれば全ての成果物は良くなる。インプットプロセスアウトプット

Slide 17

Slide 17 text

Six Sigma PMBOK Project Management Body Of Knowledge CMMI Capability Maturity Model Integration ISO 各社各団体から様々な改善手法の乱立 BPMN SPI

Slide 18

Slide 18 text

上流工程からプロセス通りに作っていけば、安く・品質の高いものが誰でも作れる上流下流のエンジニア指示者えらい給料高いエース作業者しもべ給料低い量産可能 > ※ 外部発注やオフショアで良いという幻想

Slide 19

Slide 19 text

要件定義設計実装テスト保守運用格差格差発注元

Slide 20

Slide 20 text

上流重視プロセス重視の時代が到来 … わたしも、しばらく管理する側の人間に …

Slide 21

Slide 21 text

… けれどプログラマ出身なので知ってた … どれだけプロセス管理しても最後は作る側の人間の問題。本当に誰でも作れる完璧な手順や仕様を考えられますか？プロセスの手順と成果物さえ規定すれば品質は安定しますか？その手順は日本人がやってもインド人がやっても絶対ミスなくできるものですか？大人がやっても子供がやってもできるものですか？手順書の中の日本語はぜったい読み間違いないものですか？その仕様には全ての条件が含まれていますか？すべての例外が含まれていますか？作ってる最中に環境は変わりませんか？すべてのグラフィックデザインが含まれてますか？アイコン1ドット1ドットについて計画済みですか？すべてのエラーメッセージが含まれてますか？その計画にはわたしが風邪で休むこと考えてますか？わたしがスキルアップして作業効率あがること考えてますか？わたしが出すすべてのバグまでがすでに計画されているのですか？

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

PMOのセンセイあらわるセンセイ曰く、「みんな色々言ってるけど、やっぱり現場・現物・現人だよ」 ※ PMO = Project Management Officer

Slide 27

Slide 27 text

センセイ「これをみんなで読んでね、課題図書」個人での働き方いかに効率よくコードを書くか品質をあげるか仕様はコミュニケーションの道具であることドキュメントのことではないチームによって品質をあげること（ピア＝同僚）個人でサバを読まずバッファをチームで持つチームを信頼する消化タスクではなく残りタスクで管理する手法チームの働き方チームの効率の上げかた品質の上げかた

Slide 28

Slide 28 text

Slide 29

Slide 29 text

CMMI … 組織カイゼンのプロセス

Slide 30

Slide 30 text

TSP …チームカイゼンのプロセス Team Software Process CMMI … 組織カイゼンのプロセス

Slide 31

Slide 31 text

PSP Personal Software Process 「ソフトウェア品質の始まりは一人一人の技術者である。組織プロセスは個人プロセスの集まり。自律した技術者なくして組織プロセスのカイゼンは困難。」（たぶんワッツ・ハンフリーさん自身の言葉） TSP …チームカイゼンのプロセス Team Software Process CMMI … 組織カイゼンのプロセス

Slide 32

Slide 32 text

自律した技術者なくして組織プロセスのカイゼンは困難。

Slide 33

Slide 33 text

ほらー！やっぱりエンジニアが大事なんでしょーーーー！！しっかり上流やってプロセスだけ管理すれば物事うまく行くなんてウソばっかりっ (#｀Д´)ﾉﾉ┻┻;:'､･ﾞ

Slide 34

Slide 34 text

ここからの急展開 ※ ここからはほぼカイゼンジャーニーの話 ※

Slide 35

Slide 35 text

ここからの急展開 ※ ここからはほぼカイゼンジャーニーの話 ※ 命題「現場を、一人一人のエンジニアを、大事にするやり方とは？」

Slide 36

Slide 36 text

そう、 "あじゃいる" ですよ

Slide 37

Slide 37 text

Agile XP : Extreme Programming アジャイルサムライ Scrum FDD Crystal Pair Programming インセプションデッキレトロスペクティブリファクタリング The New New Product Development Game KANBAN

Slide 38

Slide 38 text

かなり勉強した。勉強するほど深みがある。「おぉ... Agileすごいなぁ... 叡智がつまってる...」言葉は違えどPMOのセンセイが言ってたのがまさにこれか。「でも、これは、独学じゃ限界あるなぁ…」 "認定Scrum Master" とった。

Slide 39

Slide 39 text

試行錯誤の日々・勉強に次ぐ勉強・周囲への啓もうと説明説得・従来手法とのハイブリッド化・小さなプロジェクトからの実践Try&Error FairじゃないのでWaterfallについても勉強しなおしたその試行錯誤を支えたのは、品質の高い「要件定義～設計～プログラミング～テスト」が出来るという経験と自信「いざとなれば…… 全部自分でやる」という覚悟もともとはネットワークの会社にいたのでインフラもある程度できます…… 組み込みソフト、Windowsアプリも、Webのバックエンドもフロントエンドもできます……

Slide 40

Slide 40 text

アジャイルの実践・グループ内（外）での登壇、仲間づくり・スタンドアップミーティングやKANBANを契機にみんなが集まってきた「あそこ、楽しそうに何やってるの……？」・まわりでもスクラムマスター目指す人が増えた・ Scrumの各種セレモニーの実施・インセプションデッキを使ってのKickoff時の意識合わせ・ LEAN UX的手法でのビジネス/デザイナの巻き込み・ドラッカー風エクササイズ・ KANBAN ・ one teamでのインフラ構築～実装～運用までの実現：さまざまな変化がおきてきた

Slide 41

Slide 41 text

「え！？スクラムマスターなのに、スクラムを捨てたの？」開発から運用に移ってスクラムの柔軟性でも難しくなってきて、 KANBAN だけを残してみたり「うふふ . . 醸成された我がチームに不可能はない！！スクラムマスターは、スクラムの"マスター（支配者）"。 "スレーブ（奴隷）"ではない。スクラムに使われるのではなく、必要なときにスクラムを使うんですよ ( ｰ`дｰ´)ｷﾘｯ」

Slide 42

Slide 42 text

アジャイル万歳、エンジニア万歳、スクラムチーム万歳なんでも作れそう

Slide 43

Slide 43 text

アジャイル万歳、エンジニア万歳、スクラムチーム万歳なんでも作れそう・・・そう「作れと」言われたものはね

Slide 44

Slide 44 text

ん？

Slide 45

Slide 45 text

ん？んんん？ ( ,,`･ω･´)ﾝﾝﾝ？「作れ」と言われたものを作ればいいの？正しいの？けっきょく「作れ」と言われたものがすべてならそれって要件定義を重視してた上流指向のころと変わらないのでは？？ …という気づき…

Slide 46

Slide 46 text

また、ここからの更なる急展開

Slide 47

Slide 47 text

UX よりよいものを作るための挑戦！！越境Challenge

Slide 48

Slide 48 text

マーケティングの勉強よりよいものを作るための挑戦！！越境Challenge アクセス分析の勉強（GAの資格）データを扱うための統計・分析もちろん機械学習もね実現するための組織の勉強も（ティール組織）デザインの勉強も

Slide 49

Slide 49 text

勉強して登壇もした！！

Slide 50

Slide 50 text

見るべきものが変わってきたよソースコードビジネスお客さま

Slide 51

Slide 51 text

見るべきものが変わってきたよソースコードビジネスお客さま

Slide 52

Slide 52 text

見るべきものが変わってきたよソースコードビジネスお客さま

Slide 53

Slide 53 text

役割が変わってきた・変えていった今まではこう伝言ゲームで言われたものを作るのが仕事 Engineer Designer Business

Slide 54

Slide 54 text

Designer Engineer Business 役割が変わってきた・変えていったかかわり方を変えた何を作るかを考えるところから入った

Slide 55

Slide 55 text

Engineer 役割が変わってきた・変えていったバナーも作ったサイトデザインもしたメール文面も考えたサイト文面も考えた Marketer アクセス分析もした AIでのデータ分析もした商品Lineupも考えた Scientist BPR ビジネスプロセス改善 Legal さらに広げた利用規約とか Designer Business SCM Logistic CS

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

閑話休題（それはさておき）これはまた別の話いつかどこかで誰かと話したい！まだ、わたし一人だけの、次のジャーニーの話です

Slide 62

Slide 62 text

スクラムの先生に言われました、アジャイルは、やっている時にはわからない。その時に「アジャイルやってます」とは言えない。振り返ってみて「あの時はアジャイルだった」とわかるもの。 Not doing But being

Slide 63

Slide 63 text

言いたかったことジャーニーは終わらないまとめ

Slide 64

Slide 64 text

カイゼン（≒アジャイル）とは "今よりも良いもの" を目指している状態今が良くなったら、明日はもっとよいものを目指すだけまとめ

Slide 65

Slide 65 text

つまり、カイゼンジャーニーはいつまでたってもおわらない旅まとめ

Slide 66

Slide 66 text

自分？チーム？組織？セコイこと言ってないで世界そのものをカイゼンしていきましょう♪ でもそのための一歩は、現場の一人一人の小さなカイゼン、ひとりのプログラマの1行のソースコードだって大事な最初の一歩まとめ

Slide 67

Slide 67 text

カイゼンジャーニーを読んで「でも、自分はここまで出来ないなぁ…」と思った人がいたら大間違い。実際に価値を作ってるのはわたしたち・あなたたち「法隆寺をたてたのは聖徳太子ではなく、腕のいい大工」がんばれっプログラマ！！胸張って１行のコードを書きましょう！！！そのソースコード１行のこだわりからカイゼンは生まれてきます!！！！まとめ

Slide 68

Slide 68 text

自己紹介プロのプログラマスクラムマスターデザイナ見習い ←最近追加・越境中・カイゼン中

Slide 69

Slide 69 text

補足. 謝罪. すこしだけプレゼン用に面白可笑しく脚色しましたが…… 別にトラディショナルな手法嫌いじゃないんです！！ • ウォーターフォールも悪じゃない。悪く言ってる人がいたら、その人が一体どうやって勉強をしたか聞いてみてください。なんちゃってアジャイルが失敗するのと一緒で、なんちゃってウォーターフォールも当然失敗します。 • ソースコードメトリクスの分析は面白いです。ものすごくエキサイティングな分野です。 • オブジェクト指向は神。基本５原則なんて神。 • 厳格なUMLも知ってほしい！！矢印の使い分けや様々な記法を知っているということはそれだけ頭の中をごまかさずにクリアに整理できるということ。フローチャートもなんちゃってで書かないでね！！ • タグチメソッドやSixSigmaやCMMIやPMBOKやITILもすごい。本当に叡智の塊。知ってて使わないのは良いですが、知らないのはプロとして罪。構成管理やってる？いえいえ、きっとそれは単なるバージョン管理（版管理）です。CMMIを読んで構成管理について考えてみて！！ • ○○に価値があるのを認めつつも、より△△に価値を見出しているだけです。トラディショナルな手法の価値を認めつつ、アジャイルにより価値を見出しているのが今です。 • ちなみに、AI/Machine Learningも、Blockchainも、xRも、IoTも、5Gも、Roboticsも…エンジニアにとって楽しみなことだらけです。今は本当によい時代ですが、きっと未来はもっとよい時代になってます。

Slide 70

Slide 70 text

カイゼンジャーニーとても面白かったです！ご清聴ありがとうございました m__m