西岡さん、自力でStreamlitアプリ構築できました。お騒がせしました・・・。

返信が遅くなり申し訳ありません。構築できたとのことで良かったです！

コメントありがとうございます。 紛らわしいところですが、estimableであっています！ こちらのサイト(www.agilealliance.org/glossary/invest/) が参考になると思います。 “E” stimable (to a good approximation)

MindMeisterというアプリを使っております！ www.mindmeister.com/

ご指摘ありがとうございます。 そうですね。sklearn.model_selection.RandomizedSearchCV ではなく sklearn.model_selection.GridSearchCV となります。

正確には2^n - 1個のモデルですね。例えば特徴量A, B, Cの三種類あった場合 {A}, {B}, {C}, {A, B}, {B, C}, {C, A}, {A, B, C}の合計7 (2^3 - 1) 個必要となります。 それぞれの特徴量がON, OFFの2通りあると考えていただくと、2^nが出てくる理由がわかるかと思います。

ご返信をありがとうございます。理解することができました。

ご意見いただきありがとうございます。 アジャイル開発は、要件などが曖昧なものには向いているのですが、システム再構築などすでに要件が固まっているものや、マイルストーンが決まっているようなプロジェクトだとむしろ向いていないと思います。 スプリントを回すことは本質的なことではないので、スクラムやアジャイル開発を導入することが目的とせず、どんな開発が適切かチームで考え、結論としてアジャイル開発になればアジャイル開発を使い、そうでなければウォーターフォールの開発をするというが一番だと個人的には思います。

考え方が素敵だよね！

ありがとうございます。更新頻度上げられるよう頑張ります！

明日以降に返信します！

スクラムをやるときはまずはスクラムの型を守ることをオススメします。 スクラムの型を守らないと、多くの場合失敗します (私も失敗しました)。 スクラムの型の中で今回の件と関係するものは、スプリントゴールですね。 スクラムでは、スプリント中はスプリントゴールを達成することが優先されます。 スプリントゴールはスクラムで数少ない約束事の１つで、開発チームで必ず達成すべきものです。 差し込みタスクで、スプリントゴールが達成できないようなスプリントが続くと、スプリントゴールが形だけのものとなってしまい、何に集中して開発すればいいかがわからなくなり、スクラムが機能しなくなります。 スプリントゴールが達成できないような差し込みタスクが入る場合は、スプリントを中止するという判断をプロダクトオーナーにして貰う必要があります。 スプリントを中止するのか、差し込みタスクを次のスプリントに回すのかは、プロダクトオーナーが最終的に意思決定してもらうとよいです。 とは言えども、かたおかさんの状況のように、通常は差し込みタスクが発生しがちです。 なので、差し込みタスクがなぜ発生するかを洗い出すことが重要だと思います。 スプリント中の差し込みタスクが発生することの原因としてよく以下の4つが挙げられます。 1. スプリントプランニングが不十分 2. スプリントが長すぎる 3. 障害が起きた 4. スクラムに関してのステークホルダーの理解が不十分 1の「スプリントプランニングが不十分」であることに関しては、プランニングの時間をしっかり取ることも大事なのですが、チーム内でのスプリントゴールに対する認識を改めることも重要です。 スプリントゴールはプロタクトオーナーと開発チームの約束事で必ず達成するもの、それを達成するためのタスクをきちんとプランニングで考える。 スプリントプランニングを曖昧にすると、関連するタスクがスプリント中に多く発生してくるようになります。 もちろん、実際に作業したあとに新たなタスクが発生することが完全に防げるわけではないですが、プランニングをしっかりやることで、大抵の場合防ぐことができると思います。 2の「スプリントが長すぎる」ことに関してですが、最初差し込みタスクの対応に慣れていないうちは、スプリントを短くしておくのも手だと思います。 スプリントが短いと、差し込みタスクが来たとしても次のスプリントに回しやすくなります。 スプリントが短いと達成できるスプリントゴールは小さくなりますが、プランニングが容易だったり、短い期間での学習が可能になるという利点もありおすすめです。 3の「障害が起きた」場合は、こちらはサービス上以上避けられないものではあるので、スプリントを中止するなどして対応することを検討すると良いと思います。 もちろんスプリントゴールが達成できるのであれば、スプリントを中止せずに差し込みタスクをやッテも大丈夫だと思います。 4の「スクラムに関してのステークホルダーの理解が不十分」に関しては、現場あるあるのはなしだと思います。 ステークホルダーは開発チームがどのようなワークフローに従って働いているかを知りません。 そのため、どのタイミングで依頼をしていいのか分からないため、悪意なく差し込みタスクを依頼しがちです。 ここに関しては、障害などの緊急タスク以外は基本的にスプリント中は差し込めないことをステークホルダーに理解してもらっておく必要があると思います。 そのためには、スクラムマスターによるスクラムに関するティーチングがステークホルダーには必要です。 また、もう一つ差し込みタスクを発生させないためには、チケットの起票をできるようにしておくなど、タスクの受け皿を用意しておくことが重要です。 起票されたチケットがきちんとスプリントが始まるときにさばかれることを伝えておくと、ステークホルダーもより安心してくれると思います。 ざっと色々述べましたが、スプリント中は基本的に障害などの緊急自体以外やることを変更せず、次のスプリントに回すことを徹底することで、プランニングの重要度が増して、よりよいスプリントにできると経験上思っています。 そのためには、どんな差し込みタスクがあって、それが緊急かどうか、仕組みで解決できるものではないかを考えてみるといいと思います。 長くなりましたが、参考になさってください。 もしまた何かあれば、コメントでもメッセでも答えられると思うので、お気軽にご質問ください。

@@kenichiro-nishioka ご丁寧な回答ありがとうございます。 現状、一番多くある差し込みタスクが「顧客からのお問い合わせ」です。 クライアントとの問合せなので、早めに対応した方がいいと考えていましたが、 一歩引いて、ゴールを考えて >それが緊急かどうか、仕組みで解決できるものではないかを考えてみる を行ってみます。 また、4の「スクラムに関してのステークホルダーの理解が不十分」 というのも該当していると感じてきました。 こちらを肝に、よりより運用回せないか考えてみます。 ありがとうございます！！！

参考になったのであればよかったです！ もっとスクラム関連の動画もアップしていきます。

ありがとうございます。もっとたくさん良い情報を発信できるようにがんばります。 プレゼンテーション使っているツールは「Mindmeister」 (www.mindmeister.com/) というツールです。 シンプルで使いやすいのでおすすめです。