製造業の業務にスクラムを適用できるのかという疑問～全てのビジネスモデルにスクラムを適用できるのか？

先日、認定スクラムプロダクトオーナー研修を受けてきた。
その中で最も興味を持ち、そして今も半信半疑で理解できていない話は、「テスラの生産は全てスクラムでやっています」というお話。
ジョー先生から、下記のYoutubeを教えてもらったので見た。
以下、理解できていない初心者のラフなメモ。

【参考】
[日本語と英語] Keynote アジャイルコーチが学んだ「Tesla 真の凄さ」?あなたが学んできたアジャイルとTeslaは何が違うのか? ジョー・ジャスティス - YouTube

認定スクラムプロダクトオーナー研修の感想: プログラマの思索

【日本語訳】A day of Mob Programming Subtitles by Joe Justice [No Audio] - YouTube

なぜ米国企業は90年代に蘇ったのか～日本の手の内は完全に読み取られた～V字回復の経営の感想: プログラマの思索

【1】ジョー先生の認定スクラムプロダクトオーナー研修に出た時に一番興味があり、そして今も完全に理解できていない点は、ジョー先生が話されていたのは、テスラはスクラムで電気自動車を製造しています、という話。

先生曰く、テスラでは調達・計画・製造・品質部門は全てスクラムチームで活動し、すべて生産している。
たとえば、材料や部品を購買するチーム、車体を作るチーム、ブレーキを作るチーム、電池を作るチーム、自動運転ソフトウェアを作るチーム、販売するチームなどがある。
それらスクラムチームをサポートするために、カスタマーサポートのチーム、経理チームなどがあり、他にも、各チームにコーヒーを提供するコーヒーサポートチームもあるらしい。

ジョー先生に、生産計画はどうなっているのか？と聞いたら、そんなものはない。
スクラムチームは生物の細胞（セル）のように自己組織化されているから、と。
各チームはそれぞれの部品を作る責務があり、各チームは他チームに必要な部品や素材を要求するために、各チームのプロダクトオーナーが集まってメタスクラムの中で調整する。
下流工程のスクラムチームから上流工程のスクラムチームへ部品や素材を要求して製造されるので、プル生産になっているので問題ない、と。

他にも色々聞きたかったが、僕が疑問点を言語化できていなかったので、それ以上は質問できなかった。

【2】電気自動車がモジュール化できるだろうと推測できても、本当かなと思うが、たぶん僕が分かっていないだけかなとも思う。
でも、この仕組みで本当に高品質に大量生産できるのか、は別問題と思う。

高品質な規格品を大量生産できる仕組みをどうやってアジャイルに構築して、大量生産できるのか？
単純に考えると、普通の大規模製造業では、相当大規模な資金を使って、工場に設備投資して、生産ラインを作って、部溜まりが安定するくらいに生産ラインの設備機械の稼働率も製造メンバーによる生産プロセスも安定させる必要があるが、それをスクラムで実装できるのか？

一方、ソフトウェア開発は結局、人依存であり、メンバーのスキルや能力に品質が比例するし、技術の習熟度合いも比例する。
ソフトウェア開発には設備は殆どいらない。
ソフトウェア企業での規模の経済は所詮、開発者という人員と拠点となる作業場くらいなので、簡単にスケールできる。
しかし、ハードウェア製品の規格品を作る場合、人だけでなく、膨大かつ大量資金の設備が必要であり、それをすり合わせるのが難しいはず。
テスラが自動運転などのソフトウェア技術が優れているのは理解するが、ハードとして本当に実現できているのか？

【3】製造業の業務にスクラムを本当に適用できるのか？
僕の疑問はこれに尽きる。
この疑問を自分なりに分解してみる。

1つ目は、ジョー先生の話を聞くと、製造業のバリューチェーンにある各機能、つまり機能別組織をそのままスクラムチームに単純にマッピングしただけに思える。
一般に普通のメーカーであれば、仕入→計画→製造→販売という主活動のバリューチェーンがあり、購買部、生産計画部、製造部、販売部のような機能別組織で構成されている。
また、総務・経理・人事・企画などの支援活動のバリューチェーンもあり、総務部、経理部、人事部、企画部という機能別組織が構成されている。
ジョー先生の話を聞くと、機能別組織をスクラムチームに編成するだけで、各チームは自己組織化されるように聞こえるが、それら組織は会社として全体最適化されるのか？

たぶん、普通の会社の機能別組織をそのままスクラムチームにマッピングしても、有機的な触媒が簡単に起きるとは思えず、おそらく何らかの前提条件が数多くあるのではないか、と思う。

2つ目は、製造業の生産ラインで重要な点は、生産プロセスを標準化生産に当てはめて安定化させることだが、スクラムを適用してもそれを実現できるのか？
一般に、トヨタ生産方式でもっとも重要なポイントは、需要の変動をなくして、在庫があまり増減せず一定の範囲に落ち着くように、また、設備の稼働率が大きく変動することなく、設備機械が高い稼働率で安定して動かすために、生産量を標準化するように生産計画を立てる。
そういう生産計画なしで、単に、機能別組織を置き換えたスクラムチームだけで、安定的に生産できるのか？

普通に考えると、各機能の組織は個別最適化するように動いてしまって、ボトルネック工程に数多くの在庫を作り出してしまう罠が発生しがちだ。
なぜなら、生産部門の中で、部品加工を行う部署は、高額な設備機械を持ち、部品加工を効率良く行うための手順を持つので、自分たちの生産性を最大限に上げるように動きがちだから。
スクラムチームは生産プロセスを全体最適化するように自然にバランスを取ってくれる保証はあるのか？
もしそれが実現するならば、どんな原理によって実現されるのか？

おそらく、製造業の業務というビジネスモデルの中でも最も複雑な問題をスクラムで解決できるならば、それなりに何らかのノウハウがあるのではないか、と思う。

【4】とは言え、テスラは自動車業界で最も注目されていて、2022年現在の時価総額がNo.1である。
ジョー先生は、テスラの時価総額は、トヨタなどの日本メーカー、アメリカのビッグスリー、ドイツやフランスや韓国のメーカーの時価総額の合計に等しいくらい大きいです、と言っていた。

注目されている理由は、いくつかあるだろう。
以下は自分の推測。

1つ目は、電気自動車という「移動能力を持ったスマホ」という製品がビジネスとして大きなインパクトと可能性があることだ。
電気自動車というハードウェアを一度所有すれば、自動運転ソフトウェアやユーザインターフェイスがスマホみたいに定期的にバージョンアップされるので、いつでも最新の機能を維持できる。
つまり、従来のメーカーによる製品売り切りではなく、バージョンアップされるソフトウェアのサブスクリプションで売上を確保するようになる。
どこかの話では、アップルやテスラの粗利益率が30％以上もあると聞いていて、その理由は、こういうソフトウェアのバージョンアップというオプション、つまり付加価値がとても大きいからだ、という話を聞いた。
つまり、ビジネスモデルとしては従来の自動車メーカーよりもはるかに財務体質は良いことになる。

テスラが従来の自動車メーカーと異なるところ - Togetter

テスラが従来の自動車メーカーと異なるところは工場までソフトウェア化すること: プログラマの思索

2つ目は、他の自動車メーカーにも大きな影響を与えているように見えることだ。
たとえば、ドイツのフォルクスワーゲンは、自動車のソフトウェア化では、テスラよりも劣っているが、日本のメーカーよりも遥かに先に進んでいると聞いたことがある。
その理由は推測だが、フォルクスワーゲンなどのドイツ自動車メーカーはディーゼルエンジンの不正により大打撃を受けたので、従来のガソリンエンジンは捨てるしかなく、電気自動車に賭けるしかなかった、ということではないか。

また、テスラがベルリンに製造工場を作った事件もドイツ自動車メーカーに影響を与えているのではないか。
なぜなら、ドイツ自動車メーカーの工場の生産性よりもテスラの製造工場の生産性の方が圧倒的に大きかった、と聞いている。
すると、テスラを見習って、単に電気自動車を製造するだけではなく、電気自動車の付加価値を高めるソフトウェア基盤の開発が重要なはずだ、と考えて、その方向に一気にカジを切ったのではないか？

【5】そんなことを考えると、他業界のビジネスモデルにもスクラムを適用できるのではないか？と思える。

製造業という数多のビジネスモデルの中でも最も複雑な業務にスクラムを適用できるならば、小売、卸、サービス業、官公庁の業務にも適用できるはずだ。
単純に連想すると、経営コンサルタント業務のように、高度な専門知識を持った人が集まって、少人数のチームを形成してアウトプットを出す業務には、スクラムはすぐに適用できるはずだ。
なぜなら、ソフトウェア開発チームの特徴にコンサル業務がとてもよく似ているからだ。
設備はほとんど不要で、必要なものは、各メンバーに高度な専門性を持つ技術があるかにかかっているからだ。
つまり、コンサル業務のチームにスクラムをそのまま適用すれば、今の大規模スクラムのノウハウをそのまま適用するだけで、コンサルビジネスもスケールできるはずだろう。

製造業でスクラムを適用できるならば、小売スーパーや飲食店、理髪店やネイル店、旅館などの中小企業が多いサービス業の業務にも簡単にスクラムを適用できるはずだ。
特に労働集約的な業務には、スクラムチームで編成し直して、メンバーの生産性を高めるように持っていけるのではないか。
スクラムチームはプロダクトオーナー、スクラムマスター、チームメンバーの3つの役割だけから構成されていて、少人数なチームで構成されるので、それらのサービス業のメンバーにも適用できるのではないか。

この辺りも単純なアイデアに過ぎないけれど、たぶん既に他の人達がやっているに違いないと思う。
色々事例を探してみたいと思う。

WireSharkの入門動画が分かりやすい

WireSharkの入門動画が分かりやすかったので、自分用にリンクをメモ。

【参考】
【#16 ITニュース】WireSharkを使ってDHCP通信の謎を解く - YouTube

【#16 Wire Sharkを使って見た】セキュリティのお勉強 - YouTube

【#17 Wire Sharkを使って見た 2】HTTPS TLS セキュリティのお勉強 - YouTube

【#19 Cookie 】Wireshark　解析 セキュリティのお勉強 - YouTube

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門はインフラエンジニア向けの良本だ: プログラマの思索

IPアドレッシングの計算方法: プログラマの思索

GNS3上でネットワーク図を作って、pingを色々試せるようになったが、どんなパケットが流れているのか、知るにはWireSharkが必要になる。
GNS3では、WireSharkが付属していて、ルータ間、スイッチ間のパケットを見れる。
しかし、ネットワーク初心者にとってWireSharkは難しい。
理由は、WireSharkで表示されるデータをどのように見ればよいか、分からないからだ。

書籍も色々読んでみたが、実際に動かしていないからイメージもできない。
だが、動画を見て、実際に動くところを見てようやくイメージが湧いてきた。

インフラエンジニアの人に聞くと、スイッチやルータでオンプレのネットワークを作ったとしても、何か障害があれば、WireSharkを見る時が多いらしい。
実際にどんなパケットが流れているのか、見る必要あるらしい。

特に2020年頃から、いろんな分野の解説サイトの動画が出てきて、非常に便利になったと思う。
プログラミングもネットワークも、実際に動かしてみなければ理解しづらい。
そういう意味では、今は動画を見て、手っ取り早く初心者レベルをクリアすればいいのだろう。
基本的な概念さえ押さえれば、後は、書籍や勉強会などでいくらでも知識の幅も深さも広げられる。

テスト管理ツールTestRail、CAT、QualityForwardの感想

テスト管理ツールに触った経験が少しだけあった。
TestRail、CAT、QualityForwardの感想をラフなメモ。

【参考】
テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

CAT | テスト管理ツール | 株式会社SHIFT

テスト管理ツールQualityForward｜ソフトウェアテスト・第三者検証のベリサーブ

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

脱Excel！ TestLinkでアジャイルにテストをする：エンジニアがお薦めする 現場で使えるツール10選 - ＠IT

SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス～日本の品質管理技術を見直そう」

ETWest2009講演資料「TestLinkでアジャイルにテストする」

【1】欧米製のテスト管理ツールと日本製のテスト管理ツールでは、やっぱり発想が全く異なる。

TestRailはドイツ製。
テストケースは全てWeb上で管理する。
Excelのテスト仕様書は完全に廃棄される。

だから、TestRailではWeb上のUIが非常に使いやすい。
テストケースをツリー構造で表したり、Redmineの障害チケットと連携したり、テストケースをフィルタリングするのがやりやすい。
UIはTestLinkよりもはるかに使いやすい。

一方、CATやQualityForwardは日本製。
Excelのテスト仕様書をそのままインポートして、UIもExcel上のテストケースと全く同じ。
たぶん、従来の日本のソフトウェア開発チームならば、普段はExcelでテストケースを管理しているので、運用しやすいだろう。

【2】TestRailとCATやQualityForwardの大きな差は、テスト集計機能の有無にあると思う。

CATでは、SubversionやGitと連携する機能があるのでソースコード行数を保持できる。
だから、テスト密度、バグ密度を表示する機能もある。
また、信頼度成長曲線、PB曲線も表示してくれる。
つまり、日本のSIが品質管理で使いたいと思う機能は、一通り実装されている。

QualityForwardでも、PB曲線は表示される。
またカバレッジパネルという機能もある。
これは、テストケースの項目別集計に対し、テスト結果の割合を表示して、どれくらいテストを消化したのか、バグが多く出ているのか、などを表示する。

一方、TestRailでは、テスト集計機能はほとんどない。
テスト結果の状況を表示するサマリ画面はあるので、テスト状況をさらに細かくドリルダウンすることはできる。
また、バーンダウンチャートもあって、テスト時間を計測すれば、予実で表示されるみたい。
しかし、基本は、REST APIでBIツールに取り込んでもらうか、CSV出力して自分で集計してもらうことが必要。

【3】こういう内容を書くと、日本製のテスト管理ツールの方が良さげに見えるが、僕はTestRailの方が使いやすそうに思えた。

実際に画面に触れてみれば分かるが、TestRailの方がRedmineのようなUIに近い。

TestRailのマイルストーンは、Redmineのバージョンと同じ。
TestRailのテストケースは、Redmineのチケットと同じ。
そうみなせば、Excelのテスト仕様書はいらない。
そもそも、Redmineを使い始めたら、ExcelでWBS管理や課題管理はやらなくなる。
それと同じ。

日本製のテスト管理ツールにはテスト集計機能があるので、色々使えそうと思ったが、罠も多い。

まず、テストケースや障害チケットの粒度を揃えたり、テストケースや障害チケットの分析項目を標準化したり、集計する以前の前処理にすごく手間はかかる。
本来は、テスト作業やテスト成果物は標準化できていればよいが、やはりシステムごと、案件ごとに微妙にカスタマイズされているので、その辺りに規制をかける必要がある。

また、信頼度成長曲線をツール上で表示する時、障害チケットをインポートするタイミング以降でしかグラフを表示してくれない。
つまり、テストを始める前に、テスト管理ツールとRedmineを連携しておく必要がある。
テスト途中でRedmineと連携する設定を行うと、インポートする日以前のバグ発生数のグラフが表示されない事象が発生する。
なぜそんな仕組みなのか分からないが、Redmineチケットのカスタムフィールドをテスト管理ツールに取り込めないケースもあるし、信頼度成長曲線のグラフで表示したい日付情報をチケットのカスタムフィールドで対応できないケースもあるからだろう。

テスト密度やバグ密度も表示されるのは便利だが、結局、そのデータの妥当性を精査する必要があるし、テスト密度やバグ密度が基準範囲から外れていれば、細かく原因分析する必要がある。
よって、ツールで集計されたデータをそのまま鵜呑みにはできない。

そんなことを考えると、テスト管理ツールもRedmineと同じく、テスト管理の予定と実績を蓄積するのに専念し、テスト集計機能はBIツールを使ったり、自分でExcelやRで集計するように、作業を分離した方が良いと考える。
集計して分析する作業はどうしても標準化できないから。

【4】まとめると、TestRailはExcelのテスト仕様書を完全になくしてWeb上で完結する。
Redmineライクな感じ。

一方、CAT、QualityForwardはExcelのテスト仕様書をそのままインポートできるので、ExcelをWeb上で触っている感じ。

たぶん、日本のIT企業のテスト管理や品質管理は機能の網羅性テストを重視していて、欧米のIT企業のテスト管理は機能の充足よりもいちはやくリリースできる品質を担保する観点を重視する、という違いが出ているように思えた。
この辺りに、日本人の品質管理の思想と欧米のアジャイルな品質管理の思想の違いを感じる。

とはいえ、テスト管理ツールは発展途上のツールと思うので今後も見ていく。

認定スクラムプロダクトオーナー研修の感想

認定スクラムプロダクトオーナー研修に参加してきたので感想をメモ。
ラフなメモ。

【1】実は最近は、アジャイルという言葉にずっと違和感を感じていた。
理由は2つある。

1つ目は、アジャイルなソフトウェア開発で実践して経験してます、とアピールしたいならば、実践経験はもちろん、スクラムの認定研修を受けて認定資格を持っておく必要性がある風潮に何となく違和感があったから。

以前なら、XP本を読んで自分なりに解釈していろいろ試してました、FDDやScrumの本や勉強会で刺激を受けて自分なりにいろいろ試しました、みたいな話が多かったように思う。
周囲に実践者が少ないし成功談も少ないので、自分たちで試行錯誤するしかなく、自分自身や自分たちのチームを実験して、自分たちの個別の経験を積めばよかった。
その頃はアジャイルの牧歌的な時代だった。

しかし、アジャイルコーチというプロのアジャイル開発のコンサルタントの職業が一般的になり、彼らがチームを指導してチームが運用に軌道に乗せて、どんどんアジャイルなチームを増やしている。
それは良いことなのだが、プロのアジャイルコーチがいない所で、自分たちでアジャイル開発を試行錯誤して上手くいきました、と言われても、それは本当にアジャイルなの？と言われる。
アジャイルもどきであって、真正のアジャイルではないでしょ、みたいな感じに思われる。
ウォータースクラムフォールではないのか？、それはスクラムのルールを改変しすぎているね、君の思い込みではないかね、とか。

実際に見た案件では、顧客に超高速開発ツールを使ってすぐにデモして見せてます、アジャイルにやってます、と言っていた場面を見たが、単に顧客と机を並べてオンサイトでWF型開発しているだけじゃないの、アジャイルでもなんでも無いでしょと。

超高速開発でアジャイル開発を実現する話に違和感がある: プログラマの思索

AgileTourOsakaでSCRUMMASTER THE BOOKの裏話を聞いた: プログラマの思索

ちょうど、キリスト教が生まれた後、いろんな宗教家が自分たちこそがキリストの真の後継者なのだ、と200年も論争して、三位一体説のキリスト教に収れんされた歴史を連想する。
現代は、アジャイル開発の数多くの流派が生まれて論争された後、スクラムに収れんされていく時代なのかな、と思っている。

捏造された聖書の感想: プログラマの思索

2つ目は、最近のアジャイル開発のニュースが、ソフトウェアのプロセスやソフトウェア工学の観点よりも、DXに向いた組織を作りましょう、組織文化をもっとアジャイルに変えましょう、という組織論の論点に偏っているように感じたから。
もちろん、アジャイルな組織文化は重要だ。
一番流行しているバズワード「心理的安全性」が浸透したチームや組織であれば、アジャイルなソフトウェア開発も事業もやりやすいだろう。

しかし、経営層や組織構造を変えないまま、組織文化をボトムアップで変えようとするのは至難の業だ。
既存事業や既存組織が残ったままになりがちなので、結局、社内に出島を作り、そこでアジャイル開発を成功させて、少しずつ社内に展開していこう、みたいなやり方に落ち着く。

チャンドラーの言葉「組織は戦略に従う」、コンウェイの法則「ソフトウェアは組織に従う」の経験則に従えば、組織文化を規定する組織構造、さらには経営戦略から抜本的に変える必要があると思う。
つまり、ソフトウェア開発を事業の根本に据えて、ソフトウェア開発の事業の向いた組織構造を作るのが一番手っ取り早いと思う。
「大規模スクラム Large-Scale Scrum(LeSS)」でも、「組織構造が組織文化を規定する」と書かれていて、そうだよねと納得した。

SAFeの本質はアジャイルリリーストレイン、LeSSの狙いは組織のスクラム化ではないか、という仮説: プログラマの思索

スクラムは境界を生み出す: プログラマの思索

More Effective Agileは良い本だ: プログラマの思索

だから、組織論の話、特に組織文化の話に持ち込んでも、真の解決にはならないと思っている。
「組織文化は社長が作り出すものだ。社長がもっと汗をかけ！」と以前、中小企業診断士の先生が言われていたのを思い出す。

文化は組織構造に従う: プログラマの思索

諸問題を組織論に持っていくのは目的を手段化していないか: プログラマの思索

【2】とはいえ、実際に認定スクラムプロダクトオーナー研修に参加してみたら、すごく楽しかった。
スクラムマスター研修は以前受けているので内容は大体分かっているけれど、新たな知見もあったし、ゲーム感覚で経験できるのは楽しかった。
アジャイル開発は、こういうゲーム感覚で進められるように整備されている点が上手いな、といつも思う。

プロダクトオーナーが関わるプロセスでは、
Release Goal→Contract→Vision→Personas→User Story→Release Planning→Product Backlog
のループになる。

【3】興味深かったことはいくつかある。

1つ目は、ReleasePlanningでのユーザーストーリーの優先順位付けだ。
ユーザストーリーには、サイズという見積もり情報をフィボナッチ数で見積もる。
S、M、L、XLのカテゴリに3つの数値が分類されるので、フィボナッチ数は1～12番目まで使われる。

さらに、ユーザーストーリーにVlaueという顧客から見た価値、定量化された数値を設定する。
ここでも、S、M、L、XLのカテゴリでフィボナッチ数が使われる。

ここから、ユーザストーリーの優先度＝Value/Sizeを計算して定める。
優先度の大小で、ユーザストーリーはプロダクトバックログに一列に並ぶことになる。

興味深い点は、実際に自分たちで優先度を定めてみると、実は1以上の優先度が少なくて、殆どが1未満の小数点の端数になったことだ。
つまり、優先度の高いストーリーはすぐに決まるが、大半のユーザーストーリーは1未満の優先度なので、あまり大きな差が出ない。
すなわち、価値の高いユーザーストーリーを作ることは非常に難しいことを意味している。

この事象は僕らのチームのユーザーストーリーの作り方が悪かったのかもしれない。
価値あるユーザーストーリーをたくさん作れなかったのだから。

【4】2つ目は、狩野モデルでユーザーストーリーを分類したとき、プロダクトオーナーの観点では意味合いが異なる点だった。
狩野モデルでは、4象限のマトリクスに分類されて、当たり前品質、一元的品質、魅力的品質で分類される。

狩野モデル | UX TIMES

狩野モデルから探る品質のあり方とは | SHIFT ASIA -ソフトウェア品質保証のプロフェッショナル-

プロダクトオーナーの観点では、当たり前品質は最低限の品質を担保する機能を指し、魅力的品質では顧客を驚かせたりワクワクさせるような機能、つまりValueを指すらしい。
そして、一元的品質のある第1象限はできるだけ避けるらしい。

僕にはこういう発想はなかった。
なぜなら、QC検定試験のようないわゆる品質保証の話で出てくる狩野モデルでは、品質と顧客満足度の関係を製品のプロダクトライフサイクルの観点で移り変わるものである、品質は時代によって変化することの方が重要視されていて、こういう発想の説明は聞かなかったから。

【5】3つ目は、ジョー先生から、テスラの事例がやたらと多く話されていたこと。

電気自動車メーカーのテスラの凄さは、中島聡さんのメルマガなどで聞いているが、やはり生の声はとても参考になる。
ジョー先生はテスラにもコンサルで関わっていて、生産ラインというものはなく、メーカーの全てのプロセスは、スクラムチームで形成されている、とのこと。
イメージとしては、車体を作るチーム、タイヤを作るチーム、自動運転のソフトウェアを作るチームなど、部品や機能ごとにチームがあるし、コーヒーチーム、カスタマーサポートチームのような全てのチームを支援するような部署もスクラムチームになっているらしい。

僕は、製造業がソフトウェア企業と異なる点は、規格品を大量生産できるプロセスを整備することであり、そのために生産ラインのような標準的なプロセスや組織が必要と思っていたが、ジョー先生に質問したら、テスラではそんなものはありません、みたいなことを言われた。
テスラの中にあるチームは、細胞組織（セル）のようなもので、それらが必要なものをやり取りして、最終的な製品を作るのです、と。
そういう説明を受けたが、僕はどうしてもその内容を理解できなかった。
メーカーのプロセスを全てスクラムで実現してしまうとしても、どんな点に注意して、スクラムチームを構成すべきなのか、どんなハードルがあるのか、まだイメージできなかった。
たぶん、日本の製造業のイメージが強すぎて、最先端のアジャイル製造業の話を目の前の事実として理解できなかったからだろうと思う。
品質が安定した規格品を大量生産するには、安定した標準ラインよりもアジャイルなチームの方が本当に向いているのか？と。
ジョー先生からは、アジャイル製造業のコミュニティがあるから、ぜひ聞いてみてね、みたいなことも言われたので、聞いてみたいと思う。

【6】4つ目は、プロダクトオーナーは必ずスクラムチームに1人は存在するように、大規模スクラムを実践すべきである、という話があった。
スクラムチームはたくさんあっても、プロダクトオーナーが1人だけに限定される話は、過去の話です。
チーフプロダクトオーナーは作らないのが今のやり方です。
チーフプロダクトオーナーが仕切るのは古いやり方です。
今の大規模スクラムでは、スクラムチームに必ずプロダクトオーナーは1人いる、と。
そして、プロダクトオーナーが定期的に集まって、そこでプロダクトバックログにあるユーザーストーリーを調整します、みたいな話をされていた。
そのミーティングがスクラムオブスクラムですね、昔とは違います、と。
たぶん、大規模スクラムのLess、SAFeの話と比較されているのだろうと思った。

【7】他にも色々興味深い経験ができた。
認定スクラムプロダクトオーナー研修を受けて感じたことは、自分が当初感じていた2つの違和感はまだ残るが、スクラムは本当に上手く作られているな、と改めて感じる。

スクラムの認定資格を持っていないとアジャイルなソフトウェア開発をやっているとは言いにくい風潮も、実際に研修を受けていて、なるほどそういう意味があるのか、と気づくと、その価値に納得する。
また、アジャイルな開発をやるには組織論が重要だ、という話も、スクラムに触れてみると、実際にチームメンバーにはかなりの自由度が任されていて、その専門性を活かせる環境にあるので、自然にそういう文化を受け継ぐし、今の日本のIT業界における多重下請け構造とは違った世界だから、やっぱりスクラムの組織の方がいいよ、みたいな感想を持ってしまう。

まだ経験できた内容は全て言語化できていないので、書き出してみたいと思う。

JavaSilverの感想～Javaはオブジェクト指向と関数型言語の2つの性格を持つ

JavaSilverに合格できたので、気づきをメモ。

【参考】
Java SE 11 Programmer I (1Z0-815-JPN) 試験 | Oracle University

Javaメモ目次(Hishidama's Java Memo)

Java新機能メモ(Hishidama's Java up-to-date)

【1】僕はJavaは好きだ。
Javaを習得した後、オブジェクト指向設計やUML、RUPを知りたくなって、開発プロセスの奥深さを学ぶことができた。
オブジェクト指向の考え方を学ぶならJavaはお勧めだと思う。

一方、Java SE11で書いてみると、Javaはオブジェクト指向言語というよりも関数型言語になろうとしている気がする。
実際、ラムダ式やvar、型推論などは関数型言語の特徴をJavaに取り入れている。
Javaに新しくストリームAPIとは何だろう？と思っていたら、何のことはない、MapReduceのAPIに過ぎない。
つまり、関数型言語の特徴を取り入れて並列処理を意識しているわけだ。

そんなことを思うと、Javaはオブジェクト指向言語と関数型言語の2つの性格を持つように進化したのだろうと思う。

以前のJavaから追加された主な文法、機能をメモしておく。
・ module-info.java (exports パッケージ, requires モジュール)
・ javaコマンドのソースファイルモードで直接実行
・ jmod, jdeps
・ アノテーション
・ ラムダ式
・ インターフェースのdefaultメソッド、privateメソッド
・ var型
・ try-with-resources 構文
・ オートボクシング
・ ジェネリクス
・ 可変長引数
・ 共変戻り値によるオーバーライド
・ ストリームAPI＝MapReduce用API
・拡張for文

Javaで気づいたことをメモしておく。

【2】Javaのvarについて

varを使えば、わざわざ変数の型宣言はしなくていい。
ただし、型が判定できるような初期値でなくてはいけない。

Java varメモ(Hishidama's Java var Memo)

しかし、varを取り入れることで、今までのJavaの文法や考え方が複雑化していると思う。
たとえば、Javaにはジェネリクスがある。
さらに、ダイアモンド演算子によって、ジェネリクスの型宣言を短く書けるようになった。

ダイアモンド演算子は右辺の型引数を省略（推論）するが、varは左辺の型を推論するから、両方を組み合わせるとややこしくなる。

変数の定義方法の変遷　Java varメモ(Hishidama's Java var Memo)

(引用開始)
ダイアモンド演算子は、右辺の型引数を省略（推論）するものである。
一方、varは左辺の型を省略（推論）するものなので、ダイアモンド演算子とは相性が悪い。
つまり「var map = new HashMap<>();」と書いたら、変数が何の型なのか分からない＾＾；
（実際に書くと、HashMapと推論される）
(引用終了)

【3】自動ボクシング

プリミティブ型とラッパークラスを同一視して代入できるようになった。
自動ボクシングのおかげで、プリミティブ型はオブジェクトっぽく考えられるかな。

自動ボクシング　Java型メモ(Hishidama's Java type Memo)

しかし、オーバーライドする時に、int[]という配列はObject型とみなす場合がある時は正直迷った。

【4】拡張for文

RubyやPythonのようなfor文を書くことができる。
ループ処理の文法は、while→for文→拡張for文→List.forEach()へと進化しているが、過去の文法が残っているのでややこしく感じてしまう。

for each（拡張for文）　Java文メモ(Hishidama's Java Statement Memo)

【5】Javaは実行時のインスタンスのメソッドが呼ばれる

Rubyと違って、Javaは実行時のインスタンスのメソッドが呼ばれる。
C++のvirtualメソッドと同じ。

つまり、Javaでは、クラスやインスタンスは、型に強く紐づく。
型は、フライパンのタイヤキの型に例えられる。

実行時のインスタンスのクラスが重要 裏Javaメモ(Hishidama's Java Memo)

この性質を使えば、ポリモルフィズムによって、実行時に動的にインスタンスを切り替えて、同一のメソッドで処理を入れ替えられる。

【6】同一クラス内の同一変数名、同一ローカル変数

(引用開始)
変数名やメソッド名に同じ名前を使える箇所がある。同じ名前が使えない箇所もある。
(引用終了)

重複する名前、同一クラス内の同一変数名、同一ローカル変数　裏Javaメモ(Hishidama's Java Memo)

メソッド内で、フィールドと引数が同じ変数名の場合、thisを使っていないとローカル変数とみなされる。
Eclipseでは、変数名が色付けされるのでフィールドなのか、ローカル変数なのか、区別できるが、エディタ上では判別できない。
普通は、潜在バグになるので、こういう紛らわしい変数名を付けないと思う。

【7】アクセス制御

Javaのアクセス制御は普通の考え方でいい。
注意点は、public/protected/privateのような修飾子がない場合は、同一パッケージ内でしか呼び出しできないこと。

アクセス制御 Javaクラス定義メモ(Hishidama's Java Class define Memo)

下記のような変な書き方もできるが、普通はしないだろう。

スーパークラスを呼ぶだけのオーバーライド 裏Javaメモ(Hishidama's Java Memo)

【8】ラムダ式は無名内部クラス（匿名クラス）を短く記述できる記法

Javaのラムダ式は、Rubyのクロージャを知っていればすぐに理解できるだろう。
一方、Javaの観点では、ラムダ式は無名の内部クラスで冗長に書き換えられる。

Javaラムダ式メモ(Hishidama's Java8 Lambda Expression Memo)

ラムダ式の注意点は、「ラムダ式内部で外側の変数を使う場合は、その変数はfinalもしくは実質的finalでなければならない。」
つまり、「ラムダ式の外側で定義されている変数を、ラムダ式内部から参照することが出来る」が、書き換えは不可。
コンパイルエラーになる。
RubyやPythonのレキシカルスコープとは異なる。

【9】リソース付きtry文

Javaでも、例外をキャッチしたらリソースClose→finallyが簡便に書けるようになった。
Rubyのbegin~rescue~ensureと似てる。

リソース付きtry文 Java文メモ(Hishidama's Java Statement Memo)

リソース付きtry文が無い頃は、finallyの中でさらに、try～catchをわざわざ書いていた。
Release It! 本番用ソフトウェア製品の設計とデプロイのためににも、それを書かなかった場合の本番障害の事例が書かれていた。