「Developers Summit 2019 FUKUOKA」（デブサミ福岡）に参加してきました

今日は、「Developers Summit 2019 FUKUOKA」（通称：デブサミ福岡）に参加してきましたー(゜д゜)ﾉ
event.shoeisha.jp

朝、10時半の開始から行きましたよ。
とても勉強になったなってやつだけを載せておきます。

CI/CDを使い倒して数段上のソフトウェア開発をしよう！

今のプロジェクトでもCI/CD環境があるのですが、改めて重要性がわかりました。

特に印象に残っている言葉が、

• 使われていない自動化は壊れていく
• CIとCDならばCDを先にやるべき
• CIはDockerなどのコンテナと相性が良い
• テストについて、単体テストよりもビジネステストの方を優先にやるべき
• 最初からクライマックス

今のプロジェクトでは私が参画したときから、AWS環境に対してJenkinsでデプロイし、自動テストを実施するという形で存在していたのですが、１から作るとなると大変だろうな。。。っと、それでもまず初めにやるべきという事を教えていただきました。
CircleCI使うとその辺が楽になるのかなぁ。ここら辺についてはあまり述べられてませんでした。

モバイルゲーム運営における、認知資源をより有効活用していくための取り組み

「認知資源」という言葉を初めて知りましたが、心理学用語で、注意、集中など、脳が活動をするときに使うリソース＝「頭の余裕」を表したものだそうです。

そういった資源を使う仕事を見つけ出し、自動化したという話でした。
自動化する優先度を「認知資源」がどの程度使われているかに着目したのですね！

具体的には、「プルリク後の周知へのリマインダ」「ゲームのメンテナンススケジュール時間計算」「アップデートモジュールの計算」「ブランチ間のマージ補助」を自動化することで楽になったという話でした。

「認知資源」という言葉。今後使えそうですｗ

ECにおけるAR・VRの今後

家具を販売する際に、ARを使って自分の部屋にCGの家具を置いてみて色合いとかを確かめるためのアプリの紹介でした。

これ、すごかったですよ！もう写真かCGか分からないレベル！
そんなレベルで、買う前に確かめてみれるのがとてもいいですね。

（※掲載OKみたいなこと言ってたので載せます）

その他

セミナールームの外では、企業ブースがありまして、商品説明を聞けるのですが、そこで、、、

「sansan」さんから、お米を貰いました（笑）

この会社の提供している名刺で繋がるSNS「Eight」というのに興味持ったんで、アプリをDLして登録してみました。（ちなみに、無料アプリです。）

初めに自分の名刺から読み込ませて登録するのですが、前に私が渡した名刺を登録してくれてた方が居て、その方々と早速繋がりましたｗ面白いですねーこれーｗ

「Circle CI」さんからは、Facebookで繋がることで、Tシャツ貰いました

勉強になったことも多々あり、とても楽しいイベントでしたー🎶

「ふくおかスクラム vol.3」に参加してきました。

先週末は、「ふくおかスクラム vol.3」に参加してきました。

fukuoka-scrum.connpass.com

今回の講師もOdd-eの江端さんです。

各グループで６人以上になること

はじまっていきなりで、参加者全員に対して、「各グループで６人以上になっていないところが無いようにしてください」との依頼。

状態として、３グループが５人となっており、残り４グループくらいが６人という状態でした。
軽く話し合いの上、一番前に居た５人となっていた１グループが他グループに移動して、全グループとも６人という状態を作りました。

ここで、すかさず、江端さんからの問い。。。

「『各グループ、６人以上になっていない』という問題については対処できたが、それのせいで他の問題が出てきてないか？例えば、１番前を開けてしまったわけだが、それが本当に良い状態なのか？」
「目の前の問題だけを解決させることに注力してしまい、他の問題を出してしまってないか？」

なるほど。。。
どうすべきだったのかを、グループで相談。

出てきた意見としては、
「『各グループを６人以上にする』ことの意味や、『このあとに続く講義の内容』を江端さんから聞き出して上で、どういう状態が最良かを検討した上で、どのグループが移動するのが妥当であるかを決めるべき」

という話になりました。
　
（仰ることはとても良くわかるのですが、しかし、ほぼ初対面の人たちだらけの教室で、そこまではちょっと敷居が高いなぁっと ^^;;;）

生産性を示す指標

次に話題になったのが、「生産性を示す指標」について、
以下の条件で作る。というお題です。

• A / B のような割り算の計算式となること
• 分母Bは単純な「時間」的要素ではないこと

（※分母を「時間」的な要素にしてしまうと、サボっているわけではないメンバーにとっては、これ以上頑張りようがないためだそうです。メンバーが工夫することによって生産性を上げれるような指標であるべきだ。とのことでした。）

これは難しい。。。
私のグループでは、[良いこと] / [悪いこと]　という漠然とした状態をベースとして考えて、

[客が利用した機能の数] / [客から１度も利用されなかった機能の数] というのを出して見ましたが、、^^;

江端さんからは、「これは、現在、スクラムをやっている人にとっての大きな課題であり、ベストな計算式というものが無いのが現状。しかし何らかの指標を作って、メンバーの方向性をつけるべき」とのことでした。
ってなわけで、他のグループの議論の結果や、江端さん自身の今もっている「指標」についても聞けず。。そこは残念。。

江端さんからは、ヒントとして、１つの指標ではなく、３つ以上の指標を組み合わせる感じで互いに監視（補間）しあえるような指標にすべき。とのことでした。
φ(..)ふむふむ

「分母Bは単純な「時間」的要素ではないこと」ということは、今、「生産性の指標」として使っていたベロシティは使うべきではないという事ですよ。。確かに、サボっているわけではないのに上げるための工夫と言われてもって感じですよね。別の指標（「今後の予測」とか、、）としてはこれまで通り使えそうですが、、

グループワーク「ペーパープロトタイピング」

各グループで、真っ白な紙をたくさん置かれており、それを組み合わせて、高さを競うというゲーム

1. はじめに計画を立て、明文化する。
2. その計画通りに組み立てる
3. 計画は何度行ってもよい
4. 制限時間は１０分
5. 組み立てながら、計画を立てるのはNG

我々のチームでは、組み立て出すまでの時間が早かったこともあり、はじめは他チームと比べて、高く積み上がっていたのですが、足場が不安定だったことが大きな原因となり、これ以上は無理という結論となり、行き詰まるという結果に。。他チームでは、天井近くまで積み上げてたチームも居ました。おおお。。。

反省点として、「天井まで積み上げるぞ！」とかいう明確な目標感が無いまま、暫定的な計画を立てて、組み上げをスタートさせてしまったことだと思います。

次にもし、同じようなことやる機会があったら、グループ内でまずは目標感を立てたいですね！

今回もいろいろと勉強になりました。
特に「生産性を示す指標」については、これからなんらか考え、捻り出して、チームの開発メンバーが生産性についてディスカッションを行う際の観点にしたいものです。

今日から、福岡（天神）でエンジニアカフェがオープンしたらしいです

どうも、今日から、福岡市の天神で、エンジニアカフェというものがオープンしたらしいので、近いうち行ってみたいっす！

engineercafe.jp

場所も割と会社から近いので、ちょくちょく行けるかもです( ' ᵕ ' )

エンジニア系のイベントなんかもあるようで、楽しみすねー

Amazonで「スクラム」で検索してヒットした書籍のうち、評価の高い３書籍のイントロ部分だけを読んでみた感想

ども、絶賛１０連休中のひぐちぇです(゜д゜)ﾉ

家族サービスの合間を縫って、ちょっとは自己研鑽しておりまして、、
今回は、「スクラム」について、Amazonで検索した結果で、評価の高い３冊の書籍のイントロ部分だけを読んでみて、主に「アジャイル（スクラム）開発をやる意味」として書かれている箇所だけを理解してまとめてみました。

書籍からの引用もありますが、基本、私自身がその書籍を読んで理解した内容を端的に書いております。

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

ソフトウェアを作る上で本当に大事なことは、「出来上がったソフトウェアを使って実際の利用者が便利になったり、お金を稼いだりといった成果をあげれること」です。そのソフトウェアの作成過程で、当初つくろうと思っていたものよりも良いアイデアが出てくれば、目的を達成するためにそれを受け入れながら、つくるものを変えていく。そうすることでその成果を最大化できるようになる。

アジャイル開発とは、
・関係者は目的の達成のためにお互いに協力し合いながら進める。
・利用者の反応や関係者からのフィードバックを継続的に得ながら、計画を調整する。
・一度にまとめてではなく、少しずつつくる。そして、出来上がったものが求めているものと合っているかを頻繁に確認する。

スクラム開発とはアジャイル開発手法の１つで、以下の特徴がある
・要求を常に順番に並べ替えて、その順にプロダクトを作ることで成果を最大化します。
・スクラムでは実現される価値やリスクや必要性を基準にします。固定の短い時間に区切って作業を進めます。この期間のことをタイムボックスと呼びます。
・現在の状況や問題点を常に明らかにします。これを透明性と呼びます。
・定期的に進捗状況や作っているプロダクトが正しいのか、仕事の進め方に問題がないかどうかを確認（これを「検査」と呼ぶ）します。
・やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを替えます（これを「適応」と呼ぶ）。

これらを継続的に実施してプロジェクトを進めていくのがスクラムです。

【感想】
とてもシンプルでわかり易いですねー。「アジャイル開発とは」「スクラム開発とは」といった部分も元々から知っていることばかりでしたが、復習になります。全体的にシンプルに書かれており、とてもわかり易かったです。

エッセンシャルスクラム

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)

「複雑な領域」「込み入った領域」「単純な領域」「カオスな領域」「無秩序」「割り込み駆動の作業」の６つに分類しており、この中の「複雑な領域」にこそ、スクラムは合うという事を書かれていました。
「複雑な領域」というのは、「わかっていることよりも、わからないことの方が多い」といった状態で、探索して（調査）、理解し（検査）、反応する（適応）しながら業務を進めていくことになるので、こういったときにスクラムが合うということのようです。

【ちょっと補足】
「複雑な領域」「込み入った領域」「単純な領域」「カオスな領域」「無秩序」という分類はクネビンフレームワーク（Cynefin Framework）という世の中で発生しうる問題を分類したものです。
successpoint.co.jp

【感想】
情報量多くって、結論が分かりづらくなんか読みづらいなって感じでしたが、根気よく読み解いていくと、私が知らなかったことも書かれており、勉強になりました。こういった分類のやり方について調べてみると、「クネビンフレームワーク」というキーワードに行き着き、それに基づいてアジャイルの必要性を語っている資料なども見つかり、とても勉強になりました。

初めてのアジャイル開発 ～スクラム、XP、UP、Evoで学ぶ反復型開発の進め方～

初めてのアジャイル開発　?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?

製造には、２種類あって、１つ目は、携帯電話のような新しいことや変化がほとんどなく、全く同じか殆ど同じ製造を高速に繰り返すことができるという「大量生産」・「予測可能な製造」と、２つ目は、注文住宅を構築するときのように真新しさや創造性が求められ、変化が大きく、見積もりやスケジュールのベースとなる前例がないような「新製品開発」・「創造的プロジェクト」であり、ソフトウェア開発プロジェクトが抱える問題は、後者の「新製品開発」・「創造的プロジェクト」である。

「ウォーターフォール」的に仕様や見積もりや計画を大規模に作成する方法は、予測可能な製造にのみ適用すべきだが、後者の「新製品開発」・「創造的プロジェクト」にも適用されてしまっている。

事前に仕様を作成できない要因として、以下があると述べている。

・クライアントやユーザーが自分の望んでいることをきちんと把握していない
・クライアントやユーザーが自分の望んでいることや知っていることを上手く伝えられない
・クライアントやユーザーの要望の細かい部分は、開発してみないと明らかにならない
・細かい部分が複雑すぎて理解しづらい
・開発途中の製品を見て、クライアントやユーザーの気が変わる
・外からの影響（競合の製品やサービスなど）によって要求が変わったり増えたりする

『ソフトウェア構築とは、複雑で、変化の度合いの大きい新製品開発であり、予測可能な製造ではない。その認識こそがアジャイルな反復型手法を導入する理由の核心である』と述べられていました。

【感想】
↑の「・」の１つ目～４つ目までは、クライアントやユーザーを対象とした認識違いの『リスク』を示したものです。
この書籍だと、ウォーターフォールなど既存の開発手法がこの辺のリスクに対応できていないように書かれているのですが、なんだかなぁっと思いました。既存の開発手法でもこの辺のリスクについては色んな人が懸念しており、様々なナレッジや手法が試されているはずですよねぇ。
「・」の５つ目と６つ目の内容こそが、『不確実性』と呼ばれるもので、これについては既存の開発手法では無視されてきているものであり、アジャイル（スクラム）開発をやる大きな意味だと理解しています。

まとめ

今回、３つの書籍のイントロだけ読んでみて、「アジャイル（スクラム）開発をやる意味」について、理解を深めてみましたが、私としては、クネビンフレームワーク（問題領域の分類化）から、「アジャイル（スクラム）開発をやる意味」を説明していくやり方についてはちょっと無理があるのではないかと感じています。理由は、「複雑な領域」でもウォーターフォールの開発手法をとった方が良い場合もあると思っているからです。その理由は↓過去の記事読んで頂ければわかると思います。
junhiguchi.hatenablog.jp

やっぱ、「リスク」と「不確実性」の話から、「アジャイル（スクラム）開発をやる意味」を説明していく方がわかり易そうだなって思いました。。。

「働き方」「働かせ方」について

どもー。お盆休みで絶賛10連休中（8/10〜8/19まで）のひぐちぇですι(˙◁˙ )/

まぁ、妻と子供の相手しててへとへとなんですがね（笑）

さて、今日は「働き方」「働かせ方」について、考えてみました。

まずは、「働き方」について、

私、システムエンジニア（以外、SE）やりだして、15年くらいが経ちました。昔は、もう毎日の残業は当たり前、土日出勤も、さらには自宅での仕事強要、職場にIDカードを通さずに入室して記録上は休みにした上での勤務を強いられるなど、もうめちゃめちゃやりたい放題という状態でした。割と体力には自身のある方だったので、どんなに辛い状況でも仕事を終わらせるまで頑張り続けてたものです。しかし、体力には自身あったとはいえ、ずっと休みなく働くのもなかなか精神的にもキツイもので、なんどか折れそうになったものです。。。

しかし、こういった状況が一変しました。
過労自殺が問題視され、「働き方改革」とかいう言葉がでてきてからは、強制的に月に4日間は休暇をとらなければならないとか、月の残業時間に制限もでき、自宅での仕事や、記録上は休みにして職場で働く事も不可とかなってくれたおかげで、上から業務調整してくれるようになり、私のような下っ端社員にとっては、とてもとても助かる状態となったという経験がありました。

プロジェクト開始当初は、お客様との調整とかの理由でなかなか進めれなくって、割と暇も多く、やれることを前倒しでやっておこうみたいな段階で、すぐ帰れたりするのですが、詳細設計やプログラム実装段階から、やたらと仕様変更やら仕様追加やらされて、炎上プロジェクトのようになっていくんですよね(´・ω・｀)なんなんだろぅ。。

次、「働かせ方」について、

めちゃんこ働かされてた時期に、誰だったか覚えてないのですが、↓の言葉が、印象的でした。

「部下やパートナーさんに、キツイ働かせ方させれる人間が出世する」

なんかそれ聞いて、ああ自分には出世は無理だなって思いましたね。他人にキツイ働かせ方させて恨まれるくらいなら、自分が仕事してキツくなった方がマシですもんね。

「センゴク」っていう戦国時代の豊臣秀吉の家臣が出世していくマンガがあって、織田信長のセリフでこういうのがありました。
なんとなく、これに似てるなって思いましたよ。。

戦国時代では、死ねと命令できる人間が出世するという事ですよねー(´・ω・｀)ああーこわー

私が目指したい「働き方」「働かせ方」

私が目指したいと思っている働き方は、「自分の『働き方』は自分で決めたい」、「部下やパートナーさんも自分の『働き方』を自分自身で決めさせてあげたい」なのです。

勝手に見積もり立ててきたり、勝手に仕様変えたり追加させられ、それで期間も伸ばして貰えるわけでもなく、ただただ仕事押し付けられ、納期を守るための強制労働を強いられるという現状をずっと打破したかったのです。
今やっと、「働き方改革」だとか、「働かせ方改革」だとかの政策のおかげで、会社側が労働者に対して強制的に休暇をさせなければならなくなりました。しかし、今度はこの中で会社としてお客様に対して成果を出せるやり方を見つけ出さなければなりません。

そういった中で出会えたのが、スクラム（アジャイル）開発でした。この開発手法は、私が求めていた「自分の『働き方』は自分で決めたい」、「部下やパートナーさんも自分の『働き方』を自分自身で決めさせてあげたい」ことが出来るものです。さらには、スプリントレビューのタイミングで、開発メンバーとお客様側とのより良い関係性も作れるわけで、勝手に仕様変更や仕様追加され、一方的に期限が決められてしまうということも無いでしょう。この関係性が良好であれば、例え、お客様側都合で期限付きの緊急対応が入ってきたとしても、開発メンバーは協力的な姿勢で対応に励んでくれると思うのです。

私はスクラム（アジャイル）開発にとても期待しています。これをお客様に対しても、開発メンバーに対してもより良いものにするために、いろんな経験や知識を付け、更に、部内・社内で認められるものにしていきたいと思っているのです。

書籍「キングダム 最強のチームと自分をつくる」の感想です。

「キングダム 最強のチームと自分をつくる」を読み終えたので感想書いときます。

キングダム 最強のチームと自分をつくる (神ビジ)

キングダムという漫画は大好きで、毎週木曜、日付変わったタイミングで、ヤンジャンアプリで60円払って、最新話を読み続けてるくらい大好きなんですよｗ
この本、キングダムファンとしては、前々から読んでみたいって思ってた1冊でしたが、やっと読みましたー。

キングダムのキャラクターが発したセリフを1つずつ（全41のセリフ）挙げ、それぞれで、「その言葉がなぜ響くのか？」を解説した上で、「ビジネスにおいても同じことが言える。」そして、「筆者の経験談」、、といった流れでサクサク読めました。

内容としては、よくあるビジネス書籍で書かれているような内容が多く、新しい発見というより、改めて思い返される事の方が多かったという印象でした。

特に、以下のところです。

思いは言葉で伝える

お前は同じ伍で魏戦を戦った仲間としてとっくにもう俺の百人隊の頭数に入ってんだからな！！だから次の戦までに絶対戻って来いよ（信 10巻「夜語り」）

リーダーとして、仲間（チームメンバー）には、できる限りはっきりとした『言葉』で伝える事が大事だと思っています。「自分がメンバーに期待している事」「自分がメンバーに感謝している事」をです。私は、これは社交辞令とか変な思惑で言うのではなく、１人の人間としての感情で率直に伝えるようにしています。改善点がないわけではないですが、今のところ上手くいってると思っていて、信頼関係も深まってきてると思います。これからも続けて行きたいと思っている１つですね。

ワンチームとなり、１つの目的に立ち向かう

俺たちが力を束ねればどんな敵にも立ち向かえる！（信 11巻「馬陽」）

「個の力の総和＝チームの力」ではない。１つの目的のために協力し合い、「個の力の総和」以上の成果をだせるようにしたいのです。。。が、、私もそれを目指しているのですが、なかなかそうは行かない。。。
どうすればそうなるのか、、いつも考えているところなのですよね。
スクラムではコレができないといけないって思っています。しかしねー。んー。(´・ω・`)

可能な限り１対１で向き合い、たくさん対話しよう

明日の夜も語らうぞ！（政 32巻「巡回の夜」）

できる限り１対１での対話を増やす事で、信頼関係を強化していこうという話がありましたが、これは私がやれてない事ですね。。契約の関係もあり、チームメンバー全員とそれぞれ１対１で話したという事はないのですよね。必要だと思ったタイミングでその人とピンポイントで話すくらいですね。
毎週、定期的にやることでこれが信頼関係の強化に繋がりそうだという事は理解していますが、どうも、そこまでやろうとは思わないという。選択肢として頭の中に入れてはおこうと思っているくらいです。

ロジックで整理するのが「振り返り」、感情で整理するのが「打ち上げ」

つらさを乗り越える一番いい方法を俺たちは知っているみんなで共有して薄めてバカ騒ぎして吹っ飛ばすのさ（信 23巻「飛信隊軍師」）

たまに、「振り返り」は出席するのに、「打ち上げ（飲み会）」には参加しないというメンバーがいます。こういったメンバーが居た場合、半強制でも打ち上げにも出席させるべきでしょう！ワンチームになるためには、感情の方の整理もおろそかにすべきではないという事ですね。

とまぁ、こんな感じです。

大好きな漫画のセリフをビジネスシーンと絡めて語られているので、とてもわかり易くて楽しく読めましたね。
こういったのあったら、また読みたいです。

似たようなのですが、次は↓を読む予定なのですｗ

『キングダム』で学ぶ 乱世のリーダーシップ

スクラム開発が向くプロジェクト、向かないプロジェクト

ども、ひぐちぇです(=ﾟωﾟ)ﾉ

今日は、スクラムに向くプロジェクト、向かないプロジェクトって何だろうってことについて考えてみました。

以前、CSM（認定スクラムマスター）のトレーニングを受けた際、トレーナーの方は、『スクラムに向かないプロジェクト』として、

• 開発対象がコモディティ化された商品
• 開発期間が3ヶ月未満

を挙げられ、逆にこれ以外はスクラムでやることで成果が出るとおっしゃられておりました。

実は、昨日、少し会社の先輩とアジャイルやスクラムについて雑談する機会がありまして、その中でアジャイル開発（スクラム開発）の向き、不向きのプロジェクトについて語り、上記に挙げた事以外でもあるんじゃないか！？っと、改めて考えさせられたのです。

アジャイル（スクラム）開発のメリット・デメリット

アジャイル（スクラム）の他の開発手法と比べた際のメリット・デメリットについて、私のこれまでの知識と経験を思い返しながら、考え直してみました。

こんな感じになると思うのです。

開発手法	メリット	デメリット	注意点
アジャイル （スクラム）	・仕様の変更を受け入れ易い ・素早く開発してすぐにリリースが可能 ・トライ&エラーで実験的な繰り返し開発が可能 ・開発メンバーが働き易い環境になり易い	・チーム内のメンバーの増減/変更に弱い ・チーム数が多くなるとPO 1人の負担が増大してしまう（POは1人が推奨されており、チームの数分のPBI管理を1人で行わなければならないため） ・客、上司、メンバーが正しく手法を理解する必要がある ・高い生産性と高い技術品質を担保したチームを作り上げるまでに時間が掛かる	・他チームとのコミュニケーション ・統一したアーキテクチャ/技術品質の担保 ・やり方に対する指示出しにならないように注意が必要 ・客側の理解と協力関係が必要
ウォーターホールなどの開発手法	・分かりやすい ・開発メンバーは指示に従うだけで良い ・統一したアーキテクチャや技術品質が一定レベルになり易い	・仕様変更に対応しづらい ・想定外の事態に対応しづらい	・手戻りが起きないよう注意が必要 ・開発メンバーの残業や休日出勤が多くなり過ぎないよう注意が必要

スクラムは大規模開発に向かないのではないか？

これ、よく言われることですよね。。
CSMのトレーナーの方は、これについては強く否定しておりました。実際、ロケットを打ち上げる大規模プロジェクトでスクラム開発が使われ成功したという例があるとの事をあげておりました。

しかし、私はこの質問に対しては、ある意味、Yesであると思っています。

スクラムというのは「チームを長い目で見て育てないといけない」こと、「チーム数（または人数）が多すぎるとPOやステークホルダーレビューの負担も大きくなり、現実的に維持が難しくなる」という特徴があります。

つまり、大規模開発でも、長期的かつチーム（各チーム 7±2人程度で）数が多すぎない形でやっていけるプロジェクトにおいてはスクラムが有効であり、逆に短期的で多くのチーム数（大人数）になってしまう場合にはスクラムは辞めておいた方がよいという判断になるのではないでしょうか、、

アジャイル開発の向き不向きは、システムの目的や特性によるのでは？

最近、システムの目的や特性による分類として、『SoE（System of Engagement）：繋がりのためのシステム』と『SoR（System of Records）：記録のためのシステム』に分けることができるみたいなことが言われるのですが、そういった分類によって、アジャイル開発の向き不向きが判断可能なのかを考えてみました。

私は一概に、その切り口での判断は出来ないかなって思っています。

確かに、SoEだと、ユーザーなど人を対象にした繋がるためのシステムとなるわけで、UI的な拘りも後から出てくる可能性もあり、さらに、トライ&エラーでやってみたい場合も出てくるかもしれません。しかし、必ずしもそうだとは限らないと思ってます。
また、SoRだといっても、その内容が決まっていない（決めれない）場合もあるかもしれません、その場合はアジャイル開発の方が良いという選択になるかもしれません。

結局のところ、スクラム開発が向くプロジェクトって何だろう？

私が思うに、スクラム開発が向くプロジェクトというのは、まず前提として、『①長期的にチームを維持できる見込みがある』ということが必須になります。（CSMのトレーナーの方は、この期間を3ヶ月と言っていたわけですが、正直、私は3ヶ月で成果を出せる自信はないですね(´・ω・｀)最低でも1年はチームを維持できる見込みのあるプロジェクトでやりたいですね。。）

さらに、『②チーム数が、PO 1人で管理（PBIの完了条件の定義や、成果物受入れ、ステークホルダーレビュー的な意味で）出来る数である』ということも必須条件となるでしょう。

その前提を踏まえた上で、

③トライ&エラーで試しながらやりたい事があるか
④不確実性（市場の変化や会社の状況や政策など）の影響を受け易いか
⑤今は決めれない事があるか

のいずれかに該当する場合には、スクラム開発でやることで大きな成果が期待できると思っています。

つまり、論理式で書くと、

① & ② &（③ or ④ or ⑤）

といったところです。
今後の経験によって、私のこの考えが変わったり、ブラッシュアップされていくのだと思います。

まぁ、まずはこれを仮設として、今後の経験を積みながら検証していってみたいなっておもいます。

最後に

今私が考えてるのが、大規模開発などの場合とかで、ウォーターホール部隊と、スクラム開発部隊を作って、これまでに書いたことを注意しつつ、それぞれ同時に開発勧めるということは出来ないものだろうか。。さらに、スクラム開発部隊には、そのチームのまま開発後の保守をしてもらう事で、長期的なチームの維持を計るというのもいいかなって思うのです。

こんなことを漠然とですが考えてます。

そのスクラムチームは、不確実性への対応コストとして、メイン開発の見積もりとは別コストで捻出して貰いたいものなのですが、、現実的に難しいかなぁ。。。

まぁ、そういった事、提案する機会が、もしかしたらあるかもしれないので、そのためにもその体制で有効に運用するアイデアを考えて起きたいものですねぇ。。