Пікірлер

• 
  @ogurahiroto9591Ай бұрын

  発見的なチェックリストのところで1番目のドメイン知識があるのかというのは、この機械学習モデル対象とするビジネス領域などに関して、モデル構築者が知識を持っているかどうかということでしょうか？

• 
  @ogurahiroto9591Ай бұрын

  0:35

• 
  @kazutnb4 ай бұрын

  西岡さん、いつも素晴らしい動画をご提供していただきありがとうございます。（今回の動画もGoodでした） 私もLangChain＋Agent＋Streamlitでアプリを作っていますが、今回ご紹介いただいた「複数のAgentを同時に使い分ける」ということをまさにやりたかったので、本当に有意義でした。 もとにされた記事はあるのはわかったのですが、もし、可能であれば実際にStreamlit化したソースコードを拝見したいです。どこかで公開していただけると嬉しいです。 これからも動画楽しみにしています。（機械学習の社会実装勉強会の方も毎回見ています）

• 
  @kazutnb4 ай бұрын

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

• 
  @kenichiro-nishioka4 ай бұрын

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

• 
  @AIxCE9 ай бұрын

  難しい論文をわかりやすく解説いただきありがとうございます！！！ 早速、試してみようと思います！！

• 
  @mayer11512 Жыл бұрын

  面白かったです！

• 
  @kenyoshimura7468 Жыл бұрын

  "Estimable" ではなく "Estimatable" じゃないでしょうか？

• 
  @kenichiro-nishioka Жыл бұрын

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

• 
  @bankeisan9951 Жыл бұрын

  倫理学に計算ね～。まあ、一つ言いたい事は絶対善はあると言う事だ。それは「みんなの為」と言う根拠だ。つまりあらゆる道徳的に正しい事（答え）は「みんなの為」と言う根拠になる、適う、合致する答が常に正しい答えと言うことだ。殺人もそれが「みんなの為」ならば正しい行為であり、人権もその人権が「みんなの為」にならないならば正しくないと言えるのだ。 正しい政治とは「国民みんなの為」になる政治だ。みんなに関する問題はその問題に関係している「みんなの為」になる答えこそが常に正しいと言える。これに対して矛盾があると言うならば「みんなの為」にならない答えが正しいと言う答えを何か一つでも示してごらんなさい。そんなもの絶対にないからね。常に正しい答えは絶対善である「みんなの為」になる、適う、合致する答なのだ。絶対善＝みんなの為だ。もうすでに絶対善は発見しているのだよ。詳しくは私のブログを見てね。 ameblo.jp/shinwood/entry-12277885699.html?frm=theme ameblo.jp/shinwood/entry-12278155746.html?frm=theme

• 
  @user-lu2dx5kw1f Жыл бұрын

  発送がとても ユニークです

• 
  @cuongnguyen-ex3gx Жыл бұрын

  講座は最高でした。 様々案件に適用させて頂きます。

• 
  @ohsawakoji2340 Жыл бұрын

  大変参考になります。ありがとうございます！　もし差し支えなければプレゼンを作成しているソフトウェアを教えていたけないでしょうか？

• 
  @kenichiro-nishioka Жыл бұрын

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

• 
  @kusu-2 жыл бұрын

  1:34で映っているスライドのGrid Searchに使われるライブラリの例は、間違いですよね。Radom Searchのものと同じになってしまっています。

• 
  @kenichiro-nishioka2 жыл бұрын

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

• 
  @tkym198219822 жыл бұрын

  分かりやすい動画をありがとうございます。すみません、質問させてください。 8:36 あたりで「2^n個のモデルが必要」と記載されているのですが、なぜ2^n個なのでしょうか？ 特徴量が3個の場合、6パターンだったのでnの階乗だと理解していました。

• 
  @kenichiro-nishioka2 жыл бұрын

  正確には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が出てくる理由がわかるかと思います。

• 
  @tkym198219822 жыл бұрын

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

• 
  @pin-taro2 жыл бұрын

  おもしろいお話でした。

• 
  @ryota88882 жыл бұрын

  これまで大規模なウォーターフォール開発案件に携わってきたうえで、今回たまたまアジャイルを取り入れた案件に参画する事になり、アジャイル開発手法を経験した事があまりなく「アジャイルとは」というところから理解する必要があった為、いろいろな資料や動画などいくつか拝見しているのですが、結局のところやはり自分には理解できなそうです。。。笑 まず、大規模な初期開発やシステムの再構築などには向いていない手法という印象で、今回参画する現場も3年がかりの大規模開発であり、アジャイルを取り入れている事によって、かなり苦戦している様な印象を持ちました。 本来開発といった緻密で繊細な業務を進めるうえで、しっかりと統制のとれた体制であったり設計や試験、また計画の根幹である見積が行われなければならない部分を適当に行なっている様に感じます。スプリント形式にしてしまう事で、本来要望を取り入れやすくする為のイテレーションが回らず、ボトルネックになってしまっていたり、ウォーターフォールであれば差し込みの要望も取り込みやすいのになぜこの様な手法をとるのかといった疑問を払拭できません アジャイル開発の参考資料では、綺麗事というか根性論で語られている部分が多く、本質的に重要な根幹の部分を解いている参考資料が見つかりませんでした。結果的にのちに大きな問題に発展してしまいそうな開発手法だなという印象と、短いサイクルで取り込むと謳ってはいるものの、スプリントに縛られ柔軟性に欠け、効率が悪く、むしろ逆に非効率な開発手法である改めて思いました。 しいて言えば、アジャイル開発に向いている開発としては、ウォーターフォールでしっかりとした初期段階の開発が行われ、すでにベースが整っている状態から一度リリースされ、PDCAサイクルが回せるタイミングで機能の改善を行う場合にのみ適用できるのではないかと思います。

• 
  @kenichiro-nishioka2 жыл бұрын

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

• 
  @tuananhngo19002 жыл бұрын

  めっちゃ良いですね。 弊社内に紹介させていただきます。

• 
  @masamune04242 жыл бұрын

  とても分かりやすかったです！ 勉強になりました！

• 
  @chkuribayashi2 жыл бұрын

  めちゃくちゃ面白かったです！カッコ良すぎる人生... 現象論のあたりの話がとても興味深かったです。

• 
  @kenichiro-nishioka2 жыл бұрын

  考え方が素敵だよね！

• 
  @user-fh3yh8mn4q2 жыл бұрын

  すごいなー 視座が高い

• 
  @user-fh3yh8mn4q2 жыл бұрын

  面白い！

• 
  @gon74563 жыл бұрын

  機械学習初心者ですが、いつも論文解説シリーズ興味深く見させていただいています！ このような動画は他にないので、これからも楽しみにしております！

• 
  @kenichiro-nishioka3 жыл бұрын

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

• 
  @yutokataoka15693 жыл бұрын

  為になる動画ありがとうございます！！！ 今の会社では、アジャイル開発ですが、スクラムほどしっかりした枠組みで回せて居ないのが現状です。 スクラム開発の「各々がタスクに集中できる」という部分に特に魅力を感じました。 ただ、一方で現在や運用や一部問合せ対応も行なっている為、 どうしても計画時に出てこないタスクが頻繁に途中で生まれている状況です。 そういうチームでスクラムを回すとすると 飛び込みの運用タスクに対して どういった解決策が考えられるでしょうか? 運用タスクは、別枠で時間を設けて対応する。 (スクラムには入れない)などでしょうか? 何か、実践例や、アドバイスありましたらお教えください。

• 
  @kenichiro-nishioka3 жыл бұрын

  明日以降に返信します！

• 
  @kenichiro-nishioka3 жыл бұрын

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

• 
  @yutokataoka15693 жыл бұрын

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

• 
  @Shoudousan3 жыл бұрын

  スプリントゴールがいまいち具体的なレベルをイメージできなかったのでよく分かりました！

• 
  @kenichiro-nishioka3 жыл бұрын

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

• 
  @sa62483 жыл бұрын

  非常に分かりやすい解説ありがとうございます。題意とは逸れますが、プレゼンテーションで使っているツールは何というサービスでしょうか？非常に見やすいので真似したいと思いました。

• 
  @kenichiro-nishioka3 жыл бұрын

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