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

2018-08-18 - カイゼン・ジャーニー・カンファレンスでの発表資料。

Transcript

1. カイゼンジャーニーいたるまでの プログラマのカイゼンジャーニー （プログラマ賛歌） 会社員・エンジニア／スクラムマスター ※ 個人の意見であり、所属する会社・組織の意見ではありません
2. カイゼンジャーニー 自分のことのように読みました、とても面白かったです！！ 多謝 わたしスクラムマスターもやっていますが、 本職はプログラマです。 今日は "プログラマ" という、現場の人間が、 どうやって 「カイゼンジャーニー」 の主人公になっていったか。 現場では何が起きていて、その結果、なぜ「カイゼン」が生まれていったか。 そんなジャーニーをプログラマ視点で語ってみようと思います。 もし近い境遇の方いましたら、何か１つでも持ち帰ってもらえるとうれしいと思って話します！！ （けっこうややこしい話をしますがついてきてくださいね……汗）
3. はじめに MSX BASIC があった スペース1byte分のメモリも惜しかった ただただプログラムが動くことがすべてだった
4. C／C++@お仕事 ただ動くだけじゃダメ。 プロとして安定した品質・保守性が必要。
5. 「なるほど、ソースコードの品質をあげればいいのね？」 つまり バグをなくせばいいんでしょ？
6. ソースコードの品質向上のためのソフトウェアテスティング JSTQB取得 ※ JSTQB=Japan Software Testing Qualifications Board 品質工学の勉強 ペアワイズ法（直交表） ソフトウェアテストの原則 テストの心理学
7. しかしそんな簡単にはいかない バグの発見工程における修正コスト 要件 設計 コーディング 単体テスト 結合テスト 運用後 単体テストでバグを見つけるより、 コーディングでバグを対処した方が半分くらいのコストで対応が可能
8. ソースコードへのアプローチ 静的解析・メトリクス ⇒ ソースコード品質の定量化 McCabe循環的複雑度 CKメトリクス Martinのメトリクス Static Code Analytics Memory Leak Coding Style :
9. しかし潮流は更なる上流重視の流れ 要件 設計 コーディング 単体テスト 結合テスト 運用後 コーディングよりも設計段階でバグを見つけた方が早く安く解決できる バグの発見工程における修正コスト
10. ドキュメント重視 ◦◦設計書 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株式会社
11. しかししかし 要件 設計 コーディング 単体テスト 結合テスト 運用後 要件段階でバグを見つけた方がもっと早く安く解決できる バグの発見工程における修正コスト
12. SysML REBOK （要求工学） 形式手法 フォーマルメソッド 要件定義で不具合をつぶしたい
13. 高度な設定ファイルによるフレームワーク 厳密な仕様がそのまま実装に自動変換 UML XMI MOF .java application .xml beans .xml build .xml server .xml web .xml * .xml うんうん 大事なのは要件や仕様であって、コードではない
14. 厳密・厳格なUML Booch → UML 1.ｘ → 2.0 SysML,BPMN... ユースケースを洗い出すのに1年以上をかけるプロジェクトも class object 厳密・厳格な要件定義 大事な要求・仕様の表現のために
15. 人の欲求はつきない 要件 設計 コーディング 単体テスト 結合テスト 運用後 バグの発見工程における修正コスト ????
16. そもそも、どの工程でも、 すべての成果物は "プロセス" の結果でてくるもの。 であれば "プロセス" をしっかりすれば全ての成果物は良くなる。 インプット プロセス アウトプット
17. Six Sigma PMBOK Project Management Body Of Knowledge CMMI Capability Maturity Model Integration ISO 各社各団体から様々な改善手法の乱立 BPMN SPI
18. 上流工程からプロセス通りに作っていけば、 安く・品質の高いものが誰でも作れる 上流 下流のエンジニア 指示者 えらい 給料高い エース 作業者 しもべ 給料低い 量産可能 > ※ 外部発注やオフショアで良い という幻想
19. 要件定義 設計 実装 テスト 保守運用 格差 格差 発注元
20. 上流重視 プロセス重視 の時代が到来 … わたしも、しばらく管理する側の人間に …
21. … けれどプログラマ出身なので知ってた … どれだけプロセス管理しても最後は作る側の人間の問題。 本当に誰でも作れる完璧な手順や仕様を考えられますか？ プロセスの手順と成果物さえ規定すれば品質は安定しますか？ その手順は日本人がやってもインド人がやっても絶対ミス なくできるものですか？ 大人がやっても子供がやってもできるものですか？ 手順書の中の日本語はぜったい読み間違い ないものですか？ その仕様には全ての条件が含まれていますか？ すべての例外が含まれていますか？ 作ってる最中に 環境は変わりませんか？ すべてのグラフィックデザインが含まれてますか？ アイコン1ドット1ドットについて計画済みです か？ すべてのエラーメッセージが含まれてますか？ その計画にはわたしが風邪で休むこと考えてますか？ わたしがスキ ルアップして作業効率あがること考えてますか？ わたしが出すすべてのバグまでがすでに計画されているのですか？
22. … けれどプログラマ出身なので知ってた … どれだけプロセス管理しても最後は作る側の人間の問題。 本当に誰でも作れる完璧な手順や仕様を考えられますか？ プロセスの手順と成果物さえ規定すれば品質は安定しますか？ その手順は日本人がやってもインド人がやっても絶対ミス なくできるものですか？ 大人がやっても子供がやってもできるものですか？ 手順書の中の日本語はぜったい読み間違い ないものですか？ その仕様には全ての条件が含まれていますか？ すべての例外が含まれていますか？ 作ってる最中に 環境は変わりませんか？ すべてのグラフィックデザインが含まれてますか？ アイコン1ドット1ドットについて計画済みです か？ すべてのエラーメッセージが含まれてますか？ その計画にはわたしが風邪で休むこと考えてますか？ わたしがスキ ルアップして作業効率あがること考えてますか？ わたしが出すすべてのバグまでがすでに計画されているのですか？ 作るのは個性をもった人間 未来は予測できない （ソフトウェアみたいな超絶複雑なものを予測できるのはラプラスの悪魔のみ）
23. 外野がワーワー言ったって、現場では無理なものは無理！！ すべてを事前に予測するなんて無理 事前に完璧な計画を作るなんて無理 という現場出身の心の声
24. コードに触れることが出来なかったプログラマの日々 「死んだ魚のような目をしてミーティングしてましたよ」 と言われた日々…
25. そんなある日 「必要な師は、必要な時にあらわれる。」 （どこかの国のことわざ）
26. PMOのセンセイあらわる センセイ曰く、 「みんな色々言ってるけど、 やっぱり 現場・現物・現人 だよ」 ※ PMO = Project Management Officer
27. センセイ 「これをみんなで読んでね、課題図書」 個人での働き方 いかに効率よくコードを書くか 品質をあげるか 仕様はコミュニケーション の道具であること ドキュメントのことではない チームによって 品質をあげること （ピア＝同僚） 個人でサバを読まず バッファをチームで持つ チームを信頼する 消化タスクではなく 残りタスクで管理する手法 チームの働き方 チームの効率の上げかた 品質の上げかた
28. センセイ 「これをみんなで読んでね、課題図書」 個人での働き方 いかに効率よくコードを書くか 品質をあげるか 仕様はコミュニケーション の道具であること ドキュメントのことではない チームによって 品質をあげること （ピア＝同僚） 個人でサバを読まず バッファをチームで持つ チームを信頼する 消化タスクではなく 残りタスクで管理する手法 チームの働き方 チームの効率の上げかた 品質の上げかた !
29. CMMI … 組織カイゼンのプロセス
30. TSP …チームカイゼンのプロセス Team Software Process CMMI … 組織カイゼンのプロセス
31. PSP Personal Software Process 「 ソフトウェア品質の始まりは一人一人の技術者である。 組織プロセスは個人プロセスの集まり。 自律した技術者なくして組織プロセスのカイゼンは困難。 」 （たぶんワッツ・ハンフリーさん自身の言葉） TSP …チームカイゼンのプロセス Team Software Process CMMI … 組織カイゼンのプロセス
32. 自律した技術者なくして組織プロセスのカイゼンは困難。
33. ほらー！ やっぱりエンジニアが大事なんでしょーーーー！！ しっかり上流やってプロセスだけ管理すれば物事うまく行くなんてウソばっかりっ (#｀Д´)ﾉﾉ┻┻;:'､･ﾞ
34. ここからの急展開 ※ ここからはほぼカイゼンジャーニーの話 ※
35. ここからの急展開 ※ ここからはほぼカイゼンジャーニーの話 ※ 命題 「現場を、一人一人のエンジニアを、大事にするやり方とは？」
36. そう、 "あじゃいる" ですよ
37. Agile XP : Extreme Programming アジャイルサムライ Scrum FDD Crystal Pair Programming インセプションデッキ レトロスペクティブ リファクタリング The New New Product Development Game KANBAN
38. かなり勉強した。 勉強するほど深みがある。 「おぉ... Agileすごいなぁ... 叡智がつまってる...」 言葉は違えどPMOのセンセイが言ってたのがまさにこれか。 「でも、これは、独学じゃ限界あるなぁ…」 "認定Scrum Master" とった。
39. 試行錯誤の日々 ・ 勉強に次ぐ勉強 ・ 周囲への啓もうと説明説得 ・ 従来手法とのハイブリッド化 ・ 小さなプロジェクトからの実践Try&Error FairじゃないのでWaterfallについても勉強しなおした その試行錯誤を支えたのは、 品質の高い「要件定義～設計～プログラミング～テスト」が出来るという経験と自信 「いざとなれば…… 全部自分でやる」という覚悟 もともとはネットワークの会社にいたのでインフラもある程度できます…… 組み込みソフト、Windowsアプリも、Webのバックエンドもフロントエンドもできます……
40. アジャイルの実践 ・ グループ内（外）での登壇、仲間づくり ・ スタンドアップミーティングやKANBANを 契機にみんなが集まってきた 「あそこ、楽しそうに何やってるの……？」 ・ まわりでもスクラムマスター目指す人が増えた ・ Scrumの各種セレモニーの実施 ・ インセプションデッキを使ってのKickoff時の意識合わせ ・ LEAN UX的手法でのビジネス/デザイナの巻き込み ・ ドラッカー風エクササイズ ・ KANBAN ・ one teamでのインフラ構築～実装～運用までの実現 ： さまざまな変化がおきてきた
41. 「え！？ スクラムマスターなのに、スクラムを捨てたの？」 開発から運用に移ってスクラムの柔軟性でも難しくなってきて、 KANBAN だけを残してみたり 「うふふ . . 醸成された我がチームに不可能はない！！ スクラムマスターは、スクラムの"マスター（支配者）"。 "スレーブ（奴隷）"ではない。 スクラムに使われるのではなく、 必要なときにスクラムを使うんですよ ( ｰ`дｰ´)ｷﾘｯ」
42. アジャイル万歳、エンジニア万歳、スクラムチーム万歳 なんでも作れそう
43. アジャイル万歳、エンジニア万歳、スクラムチーム万歳 なんでも作れそう ・・・そう「作れと」言われたものはね
44. ん？
45. ん？ んんん？ ( ,,`･ω･´)ﾝﾝﾝ？ 「作れ」と言われたものを作ればいいの？正しいの？ けっきょく「作れ」と言われたものがすべてなら それって要件定義を重視してた上流指向のころと変わらないのでは？？ …という気づき…
46. また、ここからの更なる急展開
47. UX よりよいものを作るための挑戦！！ 越境Challenge
48. マーケティングの勉強 よりよいものを作るための挑戦！！ 越境Challenge アクセス分析の勉強（GAの資格） データを扱うための統計・分析 もちろん機械学習もね 実現するための組織の勉強も（ティール組織） デザインの勉強も
49. 勉強して登壇もした！！
50. 見るべきものが変わってきたよ ソースコード ビジネス お客さま
51. 見るべきものが変わってきたよ ソースコード ビジネス お客さま
52. 見るべきものが変わってきたよ ソースコード ビジネス お客さま
53. 役割が変わってきた・変えていった 今まではこう 伝言ゲームで言われたものを作るのが仕事 Engineer Designer Business
54. Designer Engineer Business 役割が変わってきた・変えていった かかわり方を変えた 何を作るかを考える ところから入った
55. Engineer 役割が変わってきた・変えていった バナーも作った サイトデザインもした メール文面も考えた サイト文面も考えた Marketer アクセス分析もした AIでのデータ分析もした 商品Lineupも考えた Scientist BPR ビジネスプロセス改善 Legal さらに広げた 利用規約とか Designer Business SCM Logistic CS
56. おきゃくさまに価値を届ける、 エンジニアリングが得意なビジネスの一員 殻を破った エンジニアとして出来る限りのことで手を動かした エンジニアとして出来る限りのことに口をだした システムを作る、 エンジニア 大きなパラダイムシフト
57. １つやりきった
58. １つやりきった でも 「 カイゼンとは良くし続けること 何かを達成しておわりじゃない 」
59. となると次は？
60. これは１つの妄想 例えば、 ブリコラージュ と呼ばれるもの エンジニアリングの対極にあるもの 目的にむかって収束していく活動ではなく 木のように育って広がっていく活動
61. 閑話休題 （それはさておき） これはまた別の話 いつかどこかで誰かと話したい！ まだ、わたし一人だけの、次のジャーニーの話です
62. スクラムの先生に言われました、 アジャイルは、やっている時にはわからない。 その時に 「アジャイルやってます」 とは言えない。 振り返ってみて 「あの時はアジャイルだった」 とわかるもの。 Not doing But being
63. 言いたかったこと ジャーニーは終わらない まとめ
64. カイゼン（≒アジャイル）とは "今よりも良いもの" を目指している状態 今が良くなったら、明日はもっとよいものを目指すだけ まとめ
65. つまり、 カイゼンジャーニーはいつまでたってもおわらない旅 まとめ
66. 自分？ チーム？ 組織？ セコイこと言ってないで世界そのものをカイゼンしていきましょう♪ でもそのための一歩は、現場の一人一人の小さなカイゼン、 ひとりのプログラマの1行のソースコードだって大事な最初の一歩 まとめ
67. カイゼンジャーニーを読んで 「でも、自分はここまで出来ないなぁ…」 と思った人がいたら大間違い。 実際に価値を作ってるのはわたしたち・あなたたち 「法隆寺をたてたのは聖徳太子ではなく、腕のいい大工」 がんばれっ プログラマ！！ 胸張って１行のコードを書きましょう！！！ そのソースコード１行のこだわりからカイゼンは生まれてきます!！！！ まとめ
68. 自己紹介 プロのプログラマ スクラムマスター デザイナ見習い ←最近追加・越境中・カイゼン中
69. 補足. 謝罪. すこしだけプレゼン用に面白可笑しく脚色しましたが…… 別にトラディショナルな手法嫌いじゃないんです！！ • ウォーターフォールも悪じゃない。 悪く言ってる人がいたら、その人が一体どうやって勉強をしたか聞いてみて ください。 なんちゃってアジャイルが失敗するのと一緒で、なんちゃってウォーターフォールも当然失敗します。 • ソースコードメトリクスの分析は面白いです。 ものすごくエキサイティングな分野です。 • オブジェクト指向は神。 基本５原則なんて神。 • 厳格なUMLも知ってほしい！！ 矢印の使い分けや様々な記法を知っているということはそれだけ頭の中をごま かさずにクリアに整理できるということ。 フローチャートもなんちゃってで書かないでね！！ • タグチメソッドやSixSigmaやCMMIやPMBOKやITILもすごい。 本当に叡智の塊。 知ってて使わないのは 良いですが、知らないのはプロとして罪。 構成管理やってる？ いえいえ、きっとそれは単なるバージョン管理 （版管理）です。CMMIを読んで構成管理について考えてみて！！ • ◦◦に価値があるのを認めつつも、より△△に価値を見出しているだけです。 トラディショナルな手法の価値 を認めつつ、アジャイルにより価値を見出しているのが今です。 • ちなみに、AI/Machine Learningも、Blockchainも、xRも、IoTも、5Gも、Roboticsも…エンジニアにとって 楽しみなことだらけです。 今は本当によい時代ですが、きっと未来はもっとよい時代になってます。
70. カイゼンジャーニー とても面白かったです！ ご清聴ありがとうございました m__m