Javaのラムダ式の考え方

Javaのラムダ式の考え方について理解できた内容をラフなメモ。
間違っていたら後で直す。

【参考】
Javaにおけるラムダ式とメソッド参照

徹底解説! Javaのラムダ式はどういうもので、どう使えばいいのか!

javaの内部クラスおさらい - Qiita

staticな内部クラス - 技術メモ

【Java】内部クラス(インナークラス)の使い方(static class) | 侍エンジニアブログ

Javaはオブジェクト指向言語ではなく関数型言語だった～「[増補改訂]関数プログラミング実践入門」はお勧めの本だ: プログラマの思索

JavaSilverの感想～Javaはオブジェクト指向と関数型言語の2つの性格を持つ: プログラマの思索

Java8以後は、オブジェクト指向言語ではなく関数型言語とみなした方がいいと感じた。
理由は、ラムダ式のような関数型言語の特徴を取り入れたAPIを多数取り込んでいるからだ。
マルチスレッド、Optional、Stream、IOなどの新しいAPIに触れてみると、ことごとくラムダ式を使って副作用をなくすような処理でいかに書くのか、を目指しているような気がする。

Javaのラムダ式は、RubyやPythonのクロージャみたいなものだと思う。
ただし、Javaのラムダ式では、ローカル変数は実質finalなので更新しようとするとコンパイルエラーになる。
この特徴は、Rubyのブロック、Pythonのクロージャのようなレキシカルスコープとは異なる。

Javaのラムダ式は2つの理解方法がある。

1つ目は、Javaのラムダ式は、内部クラス（Inner class）や匿名クラス（anonymous class）から生まれたものと思えばいい、
ラムダ式のイメージはこんな感じ。

依存しあったクラスが２つある。
→2つのうち1つのクラスを、内部クラスにして1つのソースファイルに統合する。
→static内部クラスにして、内部クラスのインスタンス化を廃止する。
→static内部クラスをメソッド内に取り込んで、ローカルクラスに置き換える。
→メソッド内のローカルクラスを匿名クラスに置き換える。
→匿名クラスをラムダ式に置き換えると出来上がり。

Javaの内部クラス、局所クラス、匿名クラスのような記法は現場であまり使わないから、どこで使うのだろうか、と思っていたが、ラムダ式を生み出すための前段階の仕組みと思えば自然に思える。

徹底解説! Javaのラムダ式はどういうもので、どう使えばいいのか!

2つ目は、「Javaのラムダ式は、関数型インターフェイスを実装したクラスのインスタンスを、簡単に作るための文法」。
つまり、Javaのラムダ式は関数型インフェーエイスを宣言し、実装したクラスからインスタンスを生成する仕組み。

徹底解説! Javaのラムダ式はどういうもので、どう使えばいいのか!

関数型インフェーエイスは、抽象メソッド1個だけを持つのがミソ。
FunctionalInterfaceアノテーションを付けたインターフェイスでは、自動的に関数型インフェーエイスになるが、抽象メソッドを2つ宣言したり、defaultメソッドで実装すると、関数型インフェーエイスではなくコンパイルエラーになる。

では、なぜラムダ式があると便利なのか？
マルチスレッドやStreamAPIでラムダ式を書いていると、処理の宣言と実装を1箇所に書けるのがメリットのように思う。
いちいち、別クラスを宣言して、インスタンスを生成して、メソッドを呼び出すみたいな面倒な処理をたくさん書かなくていい。

ラムダ式を使うと、Factoryクラスは不要になる。
() -> new A()のようなラムダ式を簡単に埋め込めるからだ。

ラムダ式を使うと、Strategyパターンの行数を減らせる。
ポリモルフィズムを使って、それぞれの処理を実装し、インスタンスを生成する部分をラムダ式で1行にまとめられるからだ。

「関数型インターフェイスには1つしか抽象メソッドがないので、戻り値・引数の型と順番を、関数型インターフェイスの型からJavaコンパイラが推測できます。この仕組みを型推論といいます。 」という指摘から、関数型言語の特徴である型推論をJavaでも実現できる。
Haskellと似ているのかな。

実際のエンタープライズJavaの開発現場では、ラムダ式やストリームAPIは禁止されているコーディングルールが多いかもしれない。
でも、Javaに限らず、現代の殆どのプログラミング言語に関数型言語の特徴が盛り込まれているので、今後もチェックしてみる。

残りは、モナドを理解したい。

人類は海辺から生まれた～水生類人猿説が面白い

人類は海辺から生まれたというアクア説（水生類人猿）を知った。
とても面白かったのでメモ。

アクア説 - Wikipedia

河童や半魚人の祖先か？異端の「アクア説（水生類人猿）」を独自に推理する - まいじつ

禁断のアクア説（水生類人猿説）を再評価する ? 橘玲 公式BLOG

人類はなぜ2足歩行なのか？
その単純でありながら奥深い問題に対し、従来のサバンナ説ではやはり納得しづらい。
猿やチンパンジーが地上に出たとしても自然に二足歩行になったとは思えない。

そこで、アクア説が提唱された。
アクア説、水生類人猿説では、人が類人猿に進化する時に、半水生活に適応して直立二足歩行を始めた、という主張を唱える。
この仮説は化石の証拠がなく、最初は半信半疑なのだが、人間の特徴を色々探ってみると、この仮説が上手く当てはまる場面がすごく多い。

アクア説 - Wikipediaにある「仮説の論拠」の画像がすごく分かりやすい。

人もラッコも海に入ると、垂直に直立する姿勢になる。
「人類は海辺で進化した」本では、ペンギンと人が地上では二足歩行、水中では水平姿勢で泳ぐ絵があって、こんな場面がペンギンと同じなのか！と驚いた。

人は海に入ると、皮下脂肪がついた。
皮下脂肪があると浮きやすいし体温維持になる。
鯨と同じ。
そして人から体毛がなくなったが、頭は水上に出ているので、頭髪は残った。

鼻の穴が下向きなのは、水上で垂直に立った時、水が鼻に入らないようにするため。
猿や他の類人猿は鼻の穴が正面に向いている。

涙が出る、汗が出るのは、塩分排出の症状。
「人類は海辺で進化した」本では、ラッコの母親から子供を取るとラッコが泣くと書かれていて、まるで人間みたいに感じた。

人は対面性交する。
頭から尻まで一直線の姿勢になる。
実はイルカなど水棲哺乳類は、対面性交らしい。
一方、猿や他の動物は後背位を取る。
「人類は海辺で進化した」本では、イルカの対面性交のシーンが書かれていて、まるで人間のように感情を持って恋愛している雰囲気を醸し出していたのが興味深かった。
だから、欧米人はイルカを人間と同じように同一視しているから、日本の和歌山でイルカ漁をしているシーンを非難するのではないかと思った。

人間の女性は処女膜を持つ。
水棲哺乳類の鯨にもあるらしい。
たぶん、海水が体内に入らないようにする仕組みなのだろう。

女性の外性器が隠れているのは、体の表面積を減らして体温維持する方が水中生活に有利だから。

水中出産は楽らしい。
「人類は海辺で進化した」本では、ロシアの産婦人科では、妊婦に水中出産してもらうと痛みがなく、楽だったという記載があった。
赤ん坊を生み出す時、体内から異物も排出されるが、水中で出産すればその汚物も赤ん坊から洗い流してくれる利点がある。

赤ん坊は泳げるらしい。
実は、赤ん坊は生まれた直後は、手でかくような仕草をするらしい。
水生類人猿説では、赤ん坊が水中出産された歴史に由来するらしい。

女性の乳房が垂れ下がるのは、赤ん坊が母親から乳を飲む時に捕まるため。
「人類は海辺で進化した」本では、女性が赤ん坊に乳を吸わせている写真があって、猿の赤ん坊は母親の体毛に捕まることができるが、人間の赤ん坊は母親の体毛がないのでそのままでは落ちてしまう、と書かれていた。
イルカや鯨のような水棲哺乳類も同様らしい。

人間は嗅覚が衰えた。
水中生活では、臭いの感覚は関係ないから。
水中生活から陸上生活に戻った時、ワキガのような部分から体臭を発生させるようになった、とか。

人間は聴覚と発声が発達した。
水中生活では、視覚よりも聴覚や発声が重要らしい。
イルカと同じ。
イルカも会話しているらしい。

人間はバランス感覚が優れていて、柔軟な背骨を持つ。
「人類は海辺で進化した」本では、アシカが鼻にボールを乗せた姿と、その横に人間が鼻にボールを載せた姿を載せていて、非常に同じように見える。
水族館のショーで出てくるアシカ、イルカもボールを操れるように、非常にバランス感覚が優れている。
これは、人間も水中生活で、嗅覚や視覚があまり通用しない環境で、空間の感覚を研ぎ澄ましたから、と書かれていた。

「人類は海辺で進化した」本では、女性が水中でU字型の流線型で泳いでいる絵があって、イルカやアシカと同じだな、と思った。

人間には潜水反射、徐脈の感覚を持つ。
潜水反射とは、水に潜ると心拍数が減少し、体内に送られる血液量が減り、その結果、酸素消費量も減ること。
「人類は海辺で進化した」本では、ラッコ、セイウチ、イルカ、アシカ、鯨のような水棲哺乳類と同じく、人間の絵も載せられている。
人間と他の動物がどれくらいの深さまで水に潜れるか比べると、人間は水に潜らない哺乳類と言われるらしい。

現代人の7％は、今持って手足の指に水かきの跡がある。
これは人間が水中生活していた時の名残り。
ピアニストになるためには、指同士の距離を広げる必要があるから、わざわざ広げるように手術していたことを思い出した。

これだけ状況証拠があるにも関わらず、「アクア説（水生類人猿）」は学会では異端と言われているらしい。

こういう斬新な科学的仮説を読むと、鳥類が恐竜から進化した「前適応」の仮説や、恐竜が隕石衝突で絶滅した事件のことを連想させる。
大量の状況証拠から、仮説を補強するような理論を作り上げて、どんな反論からも耐えられるようにし、最終的には化石や実験によって仮説が証明される、そんな流れを作るのが面白い。

ITの地殻変動はどこで起きているのか？～チケット駆動開発が進むべき道: プログラマの思索

論文作成の技法part2～論文作成の観点: プログラマの思索

Javaはオブジェクト指向言語ではなく関数型言語だった～「[増補改訂]関数プログラミング実践入門」はお勧めの本だ

[増補改訂]関数プログラミング実践入門 ──簡潔で、正しいコードを書くために (WEB+DB PRESS plus) 著者 : 大川徳之 技術評論社 発売日 : 2016-09-24 ブクログでレビューを見る»

Oracle Java Gold SE11　を取得するために
徹底攻略Java SE 11 Gold問題集［1Z0-816］対応 徹底攻略シリーズを解いているが、Javaはオブジェクト指向言語ではなく、Javaは関数型言語であった事実に気づき、「[増補改訂]関数プログラミング実践入門 ──簡潔で、正しいコードを書くために」を借りて読んでいる。
Oracle Java Gold SE11　では、ラムダ式とストリームAPIを習得するのがMust要件だが、実は、JavaのOptionalはHaskellのMaybeモナド、JavaのStreamはHaskellのリストモナドに相当する、という文章を読んで、インスピレーションが動いた。
こういうところまで理解しておかないと、たぶんJavaGoldは歯が立たないのだろうと思う。

この本では、Ruby、Python、Java、C++などのソースとHaskellを比較してくれているので、他言語を知っていたら理解しやすくなると思う。
関数型プログラミング言語を習得したい人にとっては、この本はMustだと思う。
まだ全部理解できていないので、これからじっくり読んで消化していく。

組織を芯からアジャイルにする対談の感想～今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない

組織を芯からアジャイルにする対談で、平鍋さんが話されていた。
感想をラフなメモ。

【参考】
平鍋健児 ? 市谷聡啓 ?組織を芯からアジャイルにする対談? - シン・アジャイル | Doorkeeper

本日のグラレコいただきました！ pic.twitter.com/C2nh8MDDaY

— Kenji Hiranabe (@hiranabe) August 4, 2022

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

平鍋さんの穏やかな口調のお話を聞いていると、そうだよねとうなずくし、勇気づけられた点もあった。

1990年代、2000年代は、プロセスの時代。
仕様に対して、いかに仕様どおりに正しく作るか、品質を担保するか、が問題だった。
そのために、ソフトウェア工場、オブジェクト指向設計、要求工学、ソフトウェア工学などがたくさん出てきた。
そして、アジャイルが出てきて、今までのアプローチは違うのでは、と。
開発者の中でこねくり回すのではなく、顧客と対話したり、市場と対話してシステムを作り上げる。
2010年頃から、リーンスタートアップが出てきたのもその流れではないか、と。

今となっては、アジャイルも日本では普通に認識されるようになってきた。
今の日本では、アジャイルは先カンブリア時代みたいに、たくさんの人達がこれがアジャイルだ、とたくさん実践して公開してきている。
そんな中で、これが本当のアジャイルだ、と言う必要はないと思う。
アジャイル警察はいらない。
もちろん、自分のポジションや意見として、アジャイルはこうだというものはあるけれど、それで対立を煽るような議論はしない。
最近は議論をやめてます、と。

平鍋さんの話を聞いて、何となく救われたような気もした。
僕だけが感じているだけに過ぎないかもしれないが、最近のアジャイルの風潮として、自分はアジャイルをやってますと名乗るには、アジャイル開発の経験だけでなく、スクラムの認定資格を取っているか、認定スクラム資格を持つアジャイルコーチの指導があるのが条件なような気がしていたから。
カジュアルに、アジャイルをやってます、みたいなことが言えない気がしていたから。
顧客とオンサイトで超高速開発ツールを使ってすぐにデモして見せてアジャイルにやってます、みたいな場面があったりして、それは違うのでは、という違和感を感じていたから。

一方、スクラムの研修を受けると、内容は確かによく考えられているし、参考になる概念もすごく多い。
このフレームワークでプロセスの諸問題が解決されるのでは、と思えたりする。
1990年代から2000年代にかけて、たくさんのアジャイルの流派が生まれてきたけれど、2020年代の現在では、それらアジャイルの考え方、プロセスはスクラムへ収斂されていく過程ではないかと思ったりもした。

しかし、平鍋さんの話を聞けば、今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない。
そう思えば、そこまで神経質にならなくてもいいし、自分で経験して理解できたことがあれば、それを普通に表現して、自分なりに解釈してもいい。

他にも気になる話があった。

平鍋さんいわく、市谷さんの書籍は、熱い気持ちや勢いで書いている所があっていいね、と。
自分が思いついたアイデアには旬があり、今ここで書かなければいつ書くのか、みたいなタイミングがある。
特にIT業界の本はそういう傾向がある。
こういうことに気づいて考えたから、今書きたい、という熱いモチベーションがあるうちに一気に書くべき。
平鍋さんが共著で書いた本「アジャイル開発とスクラム~顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」も、今書かなくてどうするんだ、という熱い気持ちで書いた、と。
自分も、年末には書きたい本の目次は壁に貼っておいて、そこから書きはじめる時がある、と。

平鍋さんいわく、市谷さんが提唱した言葉「越境」「向き直り」もいいね、と。
市谷さんはネーミングが上手い。
気づいたアイデアに名前付けしてネーミングすることは重要だ。

平鍋さんがプロジェクトファシリテーションでレトロスペクティブを「ふりかえり」という言葉で概念化したが、過去を振り返るだけでなく未来にも目を向けていることを強調できなかった。
だから天野さんと議論した後で、小野小町の見返り美人もそうでしょ、後ろに顔は向いているけれど、足の方向は前向きだから、とフォローしたんだよ、と。

確かに、何かすごいことを思いついた時、そのアイデアを別の言葉でネーミングすることにより、新しい価値や意味をもたらすことができる。
そういう体験を僕も感じた。
その体験はやると病みつきになる感じ。

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

先日、認定スクラムプロダクトオーナー研修を受けてきた。
その中で最も興味を持ち、そして今も半信半疑で理解できていない話は、「テスラの生産は全てスクラムでやっています」というお話。
ジョー先生から、下記の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つの役割だけから構成されていて、少人数なチームで構成されるので、それらのサービス業のメンバーにも適用できるのではないか。

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