00:06
6月15日、水曜日ですね。
時刻は朝9時を回りました。
今日の東京はちょっと曇りの電気ですね。
雨が降るかもしれないです。
おはようございます。
株式会社ゆめみのキースことくわはらです。
では本日も朝活を始めていきたいと思います。
また今日もTwitterスペースでレコードするのを忘れていたので、
ここのワンタイムになってしまいますけど、
後ほど流れた部分はスタンドFMにも流すので、
それも聞いてもらえると嬉しいかなと思います。
というわけで今日はですね、
ちょっと技術の話から離れまして、
エンジニアの生産性をどう測るというのはタイトルのとおりですね。
という記事があってですね、SELECTさんの記事があります。
こちらですね、ANDPADさんのインタビューの記事ですね。
ちょっとこれを読んでいこうかなと今日は思います。
最近僕がエンジニアの生産性というところを
仕事としても扱ってたりするので、
この辺をちょっと見ていこうかなというので、
一つ参考記事が出てきたのでこれを見ていこうかなと思います。
上からちょっとダラダラってなっていきますね。
ではどうぞ。
記事については後ほどTwitterで流したいと思います。
じゃあ読んでいきますね。
エンジニアの生産性をどのように測ればいいのだろうかと。
2014年に創業し、建設とか建設現場で使えるクラウド型のプロジェクト管理サービスANDPADを提供している。
株式会社ANDPADさんですね。
の記事になります。
ピタノノドさんいつもありがとうございます。
今日はちょっといつもと趣向を変えたエンジニアの生産性というところの記事を読んでいってます。
大地さんもですね。
おはようございます。ご参加ありがとうございます。
今日はいつもと違ってちょっとあまり技術的な話ではない記事を読んでます。
ANDPADさんの例ですね。
2020年には合計約60億円の資金上達を行って、
2022年4月時点でおよそ600名の従業員を有するなど急成長を続けているのがANDPADさんですね。
同社のアカウント基盤チームではエンジニアのパフォーマンスを解析するSaaSであるFindie Teamsというのを活用して、
組織の生産性というのを可視化するようにしています。
チームの課題を特定した上で複数の施策を実施した結果、
平均プロジェクトとかクローズ時間の指標というのが120時間から23時間まで減少したと。
これはすごいですね。
プロリクエストのクローズ時間が120時間も逆にすごい長いなというのもありますけど、
これが23まで減るのは結構ですね。
この取り組みの中心となったテックリの柴崎さんという方に今回インタビューをしています。
改善を行うにあたり、指標だけではなくチームの観察からボトルネックを特定する。
あえて大きな課題から取り組まない。
自分一人がチームを変えるのでなくチーム全体で変えるといったことを意識していたらしいですね。
また一方で柴崎さんというのは、エンジニアの生産性は生産サイクルのスピードだけに着目するべきではないと。
03:03
顧客に価値を提供できているか、またビジネスとして成り立っているかという視点もやっぱり必要ですよねって言ってます。
これ大事なことですよね、確かに。
エンジニアの開発の効率化とかをどんどんサイクルを良くすること。
それ自体も全然素晴らしいんですけど、やりたいことはそこではなくて、
顧客への価値をどんだけ早くできるか、ビジネスを加速できるかっていうところに技術者目線でどう関われるかっていうのが結構重要だと思うので、
ここの視点は結構大事だなと思いました。
実際に現在は生産サイクルとチームのエンゲージメントスコアのバランスを見ながら、
継続的に顧客価値を提供するためのチーム作りにも挑戦をしていると。
またより高い視点から開発組織全体の改善に取り組もうとしているそうですね。
今回は柴崎さんにインタビューしてますよってことでした。
じゃあ一個一個セクションに入ってきますね。
一つ目のセクションは開発の生産性イコール生産サイクルがうまく回っているかだけではないですよってところでした。
僕は2021年10月にアンドパッドに入社し、今はアカウント基盤チームのテックリードを務めています。
アンドパッドの開発組織には現在100名以上が所属していますけど、
その中でアカウント基盤チームは主に認証部分であったり、
ユーザー側の基盤を整えて、他のチームを助ける役割を担っていますよということですね。
僕は個人的に開発組織の生産性改善にとても興味があって、
前職のハテナでもチーフエンジニアとして生産性の可視化とか、
組織面技術面の双方における生産性の改善に取り組んでいましたよと。
ただ開発の生産性というといろいろなものがごちゃになって話されがちなんですよねと。
僕としては以下のように大まかに3つにカテゴライズできると考えています。
まず生産サイクルがうまく回っているか、要するにすごいスピードで開発できているかというところですね。
そこからもう少し資座を高めると、開発自体が本当に顧客に価値を届けているかということですね。
これはプロダクトマネジメント含めての生産性ですねと。
さらにもう1ステップ先に行きますと、そもそもの事業がうまくいっていて、ビジネスとして成り立っているかどうかというところがありますよと。
この3つですね。
エンジニア視点で生産性を考えると、やっぱり生産サイクルの部分だけを見がちなんですけども、
やっぱり少なくとも生産性をリードする人っていうのはこの3つの観点を取らなければまずいというふうに柴崎さんはおっしゃっていますと。
最近ではですね、ビルドトラップと呼ばれたりもしますけど、生産サイクルはめちゃくちゃ回っていて機能開発は進んでいるんだけれども、
全く顧客価値を生んでいないということがやっぱりあるあるである、いろんな場所であるという発生してますよというふうに言ってますね。
それぞれの観点で見るべき指標がやっぱり異なりますし、事業がうまくいっているかという大きい観点に立つと、
やっぱりメンバー1人当たりの売り上げといったものだったりしますし、顧客価値を作れているかという観点ではサービスのKPIとかKGIに開発が貢献できているかといったものになります。
06:01
一方で生産サイクルに関しては色々な指標があるんですけども、やっぱりよく話題に出るのが4KEYSというものですね。
Googleが提唱した開発パフォーマンスの指標4KEYSというのがあります。
リンク先は英語だし長いので割愛しますけども、その4KEYSの指標を4つ読んでいきますと、
1つ目がディベロップメントフリーケンシーですね。ディベロップメントフリーケンシーですね。
組織による正常な本番環境へのリリースの頻度というのが1つ目です。
2つ目がリードタイムフォーチェンジーズですね。変更のリードタイムというのが2つ目あります。
こちらはそうですね、コミットから本番環境稼働までの所要時間ですね。いわゆるリードタイムです。
続いてタイムリストアサービスですね。変更障害率というやつですね。
デプロイが原因で本番環境で何か障害が発生する割合のことですね。が3つ目。
最後4つ目ですけど、チェンジフェイラーレイトですね。サービスの復元時間です。
組織が本番環境での障害から回復するためにかかる時間。この4つですね。
というところをGoogleが開発パフォーマンスの指標として提唱してますよという感じです。
フォーキーズってやつですね。
元気さんとご参加いただきありがとうございます。
ちょっと今日は技術じゃない生産性の話を読んでます。
そのフォーキーズがあるように生産性といってもいろんな各社で様々な観点があるので、
その観点を基づいてその向上を推進している人、もしくはチームリーダーを務めている人が
それを意識しながら物事を進めていく必要があると思ってますね。
やっぱり分かりやすく開発者の生産性というとやはりリードタイムをどれだけ短くできるかというところに着目しがちです。
最初はそれでいいと思います。導入からは。
それを進める人はそこだけじゃないところを見てくださいということですよね。
また会社として何を生産性とするかというのはしっかり社内で議論をして目標を決めていくことが必要だと思いますね。
次のセクションですけど、定量的な指標とチームの観察を通じて最初に着手する課題を特定しましょう。
とはいえ実際に生産性を改善するときに何から着手するか考えると、
開発全体を眺めたときに一番課題があるところから始めることがやっぱり効果が高そうですよね。
しかし一番課題が大きいところって実はその解決がめちゃくちゃ難しいことも多いんです。
それはすごくわかります。
例えば開発が本当に顧客の方を向いているのかという課題を解決しようとすると、
まずそのチームがやったことの顧客価値を定量化する必要がありますし、
チームが顧客に対して積極的にヒアリングできているかという調査もしなければいけません。
またチームの熟練度が足りていないときにそうした課題を解決しようとしても、
09:02
やっぱりレベル1でラストボスに立ち向かうみたいな話で何もできないこと多いですよね。
それは本当そうだと思いますね。
そうなるとまずはレベル上げと言いますか、自分たちだけでできることから始める方がやっぱり進めやすい。
そこで僕がアカウント基盤チームに来てまず取り組んだのが生産サイクルの改善でした。
具体的には先ほど紹介した4keysの中の変更リードタイプに着目をして、
そのコミットしてからそれがリリースされるまでどれだけ時間がかかっているかというのを
関連する指標から見ていこうと考えました。
基本的に4keysというのは4つ全て見ることが重要ではもちろんあるんですけど、
始めから全部やろうとするとやはり何も進まないのでまず一個一個ですね。
すでに社内に導入されていたファインディーチームズを使って
一貫変更のリードタイムというところを可視化していくことから着手した感じですね。
具体的にはファインディーチームズ上にプルリクエストのクローズ時間という項目があるのでそこを一応見ていた感じですね。
これはプルリクエストが作成されてからマージされるまでの平均時間ですけど、
4keysの変更のリードタイムの中に含まれる数字になるのでこれを見るようにしていましたということでした。
余談ですけど、ファインディーチームズというのはGitHubのオーガニゼーションとかリポジトリをひも付けて
そこから誰がいつ何をコミットしたというのを全部集約していくんですね。
それを数値化してグラフだったりいろんなものに可視化してくれるサービスです。
極端に言ってしまうと別にファインディーチームズを使わなくてこれを自分たちで作ることも可能っちゃ可能なんですけど
結構大変なので、実は弊社も使っているんですけどここは割と僕も助かっているので結構お勧めですね。
やっぱり数値として見てみると結構いろんなものが分かってきてかなり面白いですね。
ちょっと余談でした。
さらにプルリクエストのクローズ時間の中でもやっぱりより分解したいろいろな指標が見られるので
それらを見ながら課題がありそうなところに結構当たりをつけ始めたよということですね。
ただ指標だけを見てもやっぱり具体的な課題が何なのかを特定することは難しいので
合わせてチーム自体を観察することも並行して進めていましたよと。
やっぱりそうですよね。数値と現実がどうなのかっていうところは見ていかなきゃいけないと思うので。
というのも例えばTOEICのような指標であればリーディングスキルはこのくらいですねとか明確に分かるので
何をすればスコアが良くなるかってやっぱり分かりやすいですねと。
なんですけどやっぱり生産性とかエンゲージメントになると
特定の指標が低いからといってすぐに課題が特定できるというわけではないですよと。
これも本当に共感味がありますね。
実際に起こっている課題っていうのはやはりチームを観察しなければわからないと。
そしてその結果最初に見つかったのが何でもかんでもやりすぎているっていうのは課題でしたってことですね。
いろんな人からいろいろな話が来る状況の中で何でもとりあえずやってみようとなりすぎていて
12:02
最重要の課題に取り組めていないなっていうふうに気づいたと。
これもあるあるですね。
現在進行中のタスクが大量にあると一つのタスクが終わらないまま次のタスクに着手するという形になってしまい
一個のタスクが完了するまでの時間が長くなってしまっていると。
実際にファインディーチーム上でもプロリクエストの苦労時間が長いという結果も出ていました。
まずこの状況を改善するために具体的な施策を進めてきましたよということですね。
マルチタスクって人間には無理だな。
無理というかあまり合ってないなっていうのは僕も感じてますし。
やはり超高速にシングルスレッドで物事をバリバリ回転早めて進める方が結果的に一緒に取って進んだりすることが多いですからね。
結局リソースを分散することになってしまうので、複数マルチタスクを持っていると。
結果的に全てのタスクの進捗が遅いみたいなことになりかねないので。
これは結構なんか共感はありますね。
続いてのセクションですけど、アップルリリックスの苦労時間が120から23時間。
副次的な効果もありましたよってところですね。
実際に行った施策っていうのは大きく3つありますよと言ってます。
まず一つ目はですね、やるものとやらないものを決めるためのメンテナンスガイドラインの策定でこれが一番インパクトが大きかったよというふうにおっしゃってました。
なるほどですね。
ガイドラインの内容は、やるやらないやるかどうかを判断を入れるという基準でとりあえず考えましょうと。
それを影響範囲とクリティカル度、高数の3軸で判断しましょうというふうにしたらしいですね。
いいですね、なるほど。
加えて事例集として影響範囲が限定されており、かつ運用でカバーできるものはやらないとか、脆弱性等のインシデントのレベルの不具合というのは即座にやるといった具体的なケースも非常に記載してますよと。
そしてそれをスプリントプランニングの際にこの基準に照らし合わせてどのタスクをやるかやらないかというのをどのチーム内で決めてきましたよということですね。
エンジニアがやりがちなのが一番気になるタスクを優先してしまうことです。
これは僕もエンジニアなのですごくわかるしドキッとしちゃいましたね。
例えば1年に1回ほどの頻度で起こるというとある条件を通るデータが壊れるみたいなケースがあった場合に、そのデータが壊れると言われるとやっぱりやらなきゃいけないというような気持ちになってしまうと。
これは人によって感覚が違うかもしれないですけど、この柴崎さんはそう感じたらしいですね。
ですがガイドラインがあることで一旦引いてみてそれって年に何回起こるんだっけ優先するべきなんだっけというような話がやはりできるようになったということですね。
これは本当にいい話だと思います。
今のが一つ目でした。
二つ目にやったことですね。
二つ目はプルリクエストが作られてからすぐにレビューに取り掛かれるような通知の仕組みを作ることでした。
これは結構やるんじゃないですかね僕らも。
スラックとかでGitHubの連携をしてプルリクエストだったりとかコメントが来たら随時タイムラインに流れるようにするとかよくやるかなと思います。
15:01
三つ目がエンジニア同士のペアを決めて毎日1時間はペアプロしましょうと推奨することで一人でずっと悩んで止まっている状態をなくすことでした。
これ面白いですね。
ルールじゃなくてあくまで推奨なんですね。
こうした取り組みによって定量的な意味ではプルリクエストのクローズ時間の平均が約20から23時間まで減少しましたということですね。
さっきの三つ目のところですね。
とにかく重要なのは一人で悩んで止まっている状態をなんとか解決したいというのが三つ目のやったことだと思うんですけど。
うちだとよくやるやり方だと思うんですけど。
16時か17時くらいとかにスラックボットを勝手に起動して質問ある人とか相談したい人は適当にコメントしてくださいっていうのを投げると意外とみんなコメントしてくれたりするんですよね。
チームミーティングとかで何かありますかとか聞くと意外と喋ってくれないんですけど。
テキストだと結構みんな書いてくれたりするのでそこで本当に細かくてもいいし枝葉の話でもいいので何か喋りたい人っていうのをスラックボットで聞くようにしたり結構コメント来たりするとかですね。
もしくは別のチームだと常にディスコード繋ぎっぱでみんなそこにいるんですよ。
みんなその代わりにミュートにしていてちょっと相談したい時だけそこで話しかけるみたいなことをしているチームもいてそこはそこで結構チームの情勢も副次的にできたのでそこは面白かったなと思います。
参考までにですけどそういうことをやってました。
余談が過ぎたので話戻しますね。
ガイドラインを作ったことによって副次的な効果としてあえて放置できるようになったっていうマインド面の変化もあったのが大きいと思ってます。
面白いですね。あえて放置できるっていうのは面白いですね。
加えて一つ一つのプロリクエストが小さくなったことで生産サイクルが早く回るようになったっていう体感もあります。
なるほどですね。プロリクエストが小さくなったっていうのは結構大きいですね。
プロリクエストを投げればまっすぐにマージされるって感じでいればやっぱり一行コードを書いたら解決するような問題であればまっすぐにプロリクエストを投げるようにみんななってくれたっていう変化を書いてまして
逆にプロリクエストを投げても1日待たされるような状況だとじゃあ気になっている別のものも入れとこうみたいな気持ちになるんですよねと。
あーはいはいはいなるほどですね。
でもそれはあんまり良くないです。プロリクエストはちゃんと分けたほうがいいと思います。
そうするとやっぱりレビューも遅くなりますし実際にユーザーに価値を提供できるまでの時間も長くなってしまうのでレビューを高速化することによって小さいプロリクエストが増えて顧客に早く価値を届けられるというような良い循環もあるようになったかなと思っています。
これはうちでもよくありますね。やっぱりプロレクエストが大きくなるとレビューコースも高くなりますし時間も長くなるんですよね。
結果的にデリバリーしたいことが遅くなってしまうので。
やっぱりプロリクエストは小さく分けるとかやっぱり大きい機能を作るんだったら一個トピックブランチみたいなのを切ってそこにどんどん小さなプロリクエストを積んでいくのでもいいと思っているんですよね。
18:08
次のセクションですけどチームを改善する人にはならないチーム全体の変化を大切にっていうのが書いてありますね。
こうしたチームの改善を実施する上で大切にしていることが3つあります。
1つ目はどのくらい変化を受け入れてもらえるチームかを先に観察することです。
変化を許容しやすいチームっていうのはどんどん提案していけばいいんですけど、
逆に受け入れられないチームに急に変化を促すとやっぱり反発が起きてしまいます。
なのでまずはちょっとした提案をしてみてどのくらいならいけそうかなみたいなのをチームの反応を見ながら対処するようにしています。
幸いなことにアンドパッドの場合は組織が急拡大していることもあって変化に対して抵抗があるメンバーはほとんどいなかった。
とりあえずやってみようという雰囲気があったので第一段階として大丈夫そうというふうに感じました。
これは組織として全体として良い感じですね。
次に小さい変化を通して自分に対しての信頼度を高めるということです。
先ほど具体的な施策としてガイドラインとかすぐにレビューに取り掛かれる仕組みであったりとか
ペア制度っていう3つのやってみたことを挙げたんですけど、
実は最初に取り組んだのはすぐにレビューに取り掛かるための通知の実装だったらしいですね。
やっぱりすぐにできますし通知されたところで困る人は別にいなかったというのも言ってますね。
まずは小さいところ改善して成果が出ることを見せると。
そういった積み重ね意識してます。
そして最後はチームを改善する人にはならないということですね。
チーム改善イコールマネージャーがやるものとなってしまうのがパンチパターンで
本来はある人だけが改善提案するんじゃなくて
いろんな視点でみんなから提案があってどんどんチームが変わっていくことがあるべき姿だと思っています。
そうですよね。みんなでやるものだと思うし。
できるからこそチームが醸成されると思ってますね。
つまり自分がひたすら変化を促すだけではダメで
他の人も含めてチーム全体の意識を変えていく必要がありますよと言ってます。
そのために自分の意見だけではなく他の人の提案も同じようにやってみる。
自分から変化を起こす時にもきちんと提案を作って合意を得るといったことを意識してます。
自分がチームを変えているのではなくて
チームに変化のやり方をインストールしていく。
チームで変えているという感覚で改善を進めていますねと。
めちゃくちゃいい話ですね。
次のセクション。これでラストかな。
ラストのセクションは持続的に価値を提供し続けるチームであるために重要なこととは?
このようにこれまでは生産サイクルに注力をして改善をしてきましたが
一方ではそれだけに目を向けすぎると
短期的にチームが燃え尽きてしまうという問題もあります。
ファインディーチームズというサービスで見られるような指標って
いわゆる頑張れば短期間ですごく向上させることができるんです。
要するにめっちゃ働けば一時的にはプルエクスのクローズ時間も
それはもちろん短くなるじゃないですか。
なんですけどやはりチームが持続的に価値を提供し続けられなかったら
21:00
いくらスピードが上がっても意味がないですよね。
そこで今はチームとしてのバランスをうまくとるために
Weboxというツールを使って
メンバーのエンゲージメントスカウンを見ながら一応改善するようにしていますよと。
これいいですね。
またこれからは生産サイクルだけではなくて
開発が顧客価値を作れているかということもきちんと見ていきたいですね。
これは自分のチームだけでなくて
開発組織全体で高めていくことを考えていきたいと思っていて
まだ明確な課題は見つかっていないんですけども
まずはそのボトルネックを特定するところからやっていきたいかなと思っています。
ということでこの記事は終了になりました。
はい。
エッジの生産性についてのお話でしたが
やっぱりすごく参考になりますね。
なるほどって感じでした。
難しいですね。
なかなか生産性を測るというのはそんな簡単ではないですし
実際に何かアクションを起こしたり
実験したりいろんなことを提案したりやってますけど
それがチームにどれだけ反映されるとか
訴求されるとか
どれだけの効果が生まれるかというのはなかなか難しいので
実際にこれやったからドーンと変化が起きるというのは
やっぱりそんなに多くはないと思うんですよね。
今回のアンドパッタさんの120時間というのは確かに
そもそもがめちゃくちゃ長いので
ちょっと何かやったらすぐに変化起きるぐらいの環境だったというのも
一つは大きいのかもしれないですけど
その大きいところがあるからこそ
小さくてもその小さな成功体験とか
みんながインストールできたというのが結構大きかったんじゃないかなと
読んでて思いました。
はい。
というところですね。
これも参考になったので
これはありがたい気持ちだったなと思います。
では残り時間があと6分あるんですけど
余ったのでもう一個
何を読もうかって悩んだんですけど
僕が個人で趣味でやっている
ジェネラティブアートというのがあるんですけど
それについての
海外の人で同じようにアートをやっている方の
ブログがあるので
それをちょっと読んでいこうかなと思います。
英語なんですけど3分ぐらいで読み終えそうなので
最後なんか読み物的に
読んでいこうかなと思いました。
タイトルは
My Journey with Generative Art
ということですね。
というところを読んでいきます。
ここからちょっと
全然さらに技術の話から
かけ離れてしまうので
ご興味ある人だけ
聞いてくだされば嬉しいなと思います。
では翻訳していきますね。
まず最初ですね。
ジェネラティブアートとの出会いから
入ってますね。
この話に入る前に
私はアーティストでもなければ
優れた作家でもありません。
1週間ほど前に素晴らしい技術に出会った
謙虚な技術をオタクに過ぎない。
自分で謙虚って言うんだから
謙虚かな。
そんなことは去っておき
早速本題に入りましょう。
この特別な旅っていうのは
1週間ほど前の
平凡で退屈な朝に遡ります。
私は突然何かを作りたいという衝動に駆られて
多くの場合丸一日かけて
Photoshopをハックしたバージョンをインストールして
結局何も成し遂げられませんでした。
しかし今回は違う。
24:00
私はAIアートの世界に飛び込むことにしました。
って言ってますね。
で、全然知らないツールですね。
Del2ってものとか
Mid Journeyなどの
AIモデルなんですね。
をハイエンドのコンピューター
GPUを購入することなく
実際に使用することができないかな
という風に考えていたらしいですね。
あるいはもう画像ごとに支払うサブスクリプションに
お金を払うかみたいなことも考えてたらしいですね。
オリジナルアートを作成できるアプリを探すのは
結構大変だったと言ってますね。
で、いろんなものがあって
ウォンボドットアートとか
アートブリーダードットコムとか
ナイトカフェなどのアプリもあったので
それを試してみましたけども
結果はいつももっと欲しいと思わせるものばかりで
やっぱりこの人を満足させるものじゃなかったよ
という風に言ってますね。
で、いろいろ旅していって
どこにたどり着いたんだ
で、どこにたどり着いたかというと
小さな解像度で限られた量の作品を作るのではなくて
高解像度で無限の作品を作れるようになりたいと
自分にとって本物だと思える方法で
クリエイティブに表現したいという
好奇心がすごく強かったと。
で、AIには計算コストがかかるということは
もちろん知っていたんですけど
自分のコンピューターで浮かすことも
不可能ではないことも逆に分かっていたと。
そこで自分のコンピューターで
これらのアルコリズムの一つを実行して
GPUが続けるかどうかというのを
試してみる価値があるかもしれないと思った感じですね。
1日の終わりに私は
NVIDIAというものを持っていまして
これは私の基準ではマイナなGPUではありません
ということを言っていますね。
GPU関連は僕本当に不勉強なので
全然分からないんですけど。
しかし私は2つの今となっては明確な理由のために
実験をやり遂げませんでした。
1つ、読書した結果
10Vに強くないことが明らかになりました。
2つ目がGitHubの一つを読んで
ユーザーがGoogle GPU上で
AIモデルを実行できる
Googleコラボというツールがあることも知りましたよと。
やっぱりあるんですね。
それを使ってみることにしたらしいですね。
続いてGoogleコラボって何ぞというところですね。
このツールというのは
誰でもブラウザを通して
パイソンコードを書いて実行することができて
特に機械学習やデータ分析
教育などに適していますよと言っていました。
AIモデルで遊んでみたいんですけど
そのためのお金やリソースがないんだけど
みたいな問いも結構あるんですけど
それならGoogleコラボはやっぱり
強い見方になりますよと。
これはGoogleが提供する強力なGPU上で
スクリプトを実行できる
オンラインのプラットフォームだからですね。
どういうことかというと
強力なハードウェア上で
最新のAIモデルを実験して
自分のプロジェクトに使うことができるようになります。
実際私はこのツールを使って
さまざまなAIモデルを作って
実際にどのように
27:00
機能するかを
確認できています。
これが素晴らしい学習体験になっていますよということでした。
これまでの
最高の結果ですね。
体験した結果をいくつか紹介しましょうというので
ちょっと画像ですね。いくつかの
作品がバーッと出ていますけど
結構かっこいい画像がバーッと出ていますね。
結構自分たちが思うような作品が作れて
自分が思うような作品が作れた
という感じですね。
もしこの記事を読んで
AIを使ったジェネラティブアートの作り方について
もっと知りたくなったら
ぜひぜひやってくださいし
逆に言うとやった人は教えてくださいと。
もしかしたらハウツーガイドを作るかもしれませんと
言ってますね。
この人の記事は終了ですね。ちょっとライトなものでしたけど
読んでいきました。
ジェネラティブアートをやるための
ツールって本当にたくさんあって
P5JSっていうのを使ったりしてますけど
やっぱり
あれだけじゃなくていろんなツールがあって
表現力の差も出てきたりするし
できることも変わってくるので
現代だとやっぱりNFTアートっていうのは
すごく話題になっているので
改めてジェネラティブアートとか
いわゆるデジタルアートも再評価されたりするので
その辺の技術を触ってみても
いろいろなことができて面白いかもしれないですね。
もしかしたら自分もアーティストになれるかもみたいなところ
全然なれるとは思うんですけど
っていうところを興味持っていただいて
触れると面白いのかなと思ったりはしました。
はい。
時間もいい感じですので
今日の朝回はこちらで以上にしたいかなと思います。
最近また本当にネタに困って
次の記事何読もうかっていう
毎晩ググってから寝るっていう習慣になってしまっているので
何かネタ提供してください
方いたらすごく嬉しいなと思います。
というところで
今日の朝活はこちらで以上にしたいかなと思います。
今日もちょっとダラダラと進めてしまって
もう打ち上げなかったですけど
ご視聴いただいた皆さん本当にありがとうございました。
また明日も何か読んでいきたいと思いますので
お付き合いいただければ幸いだなと思います。
今日も一日頑張っていきましょう。
お疲れ様です。
