00:01
はい、みなさんこんにちは。TRY-CATCH FM第55回です。お願いします。
最近、自分がポッドキャストをいろいろ始めるようになってから、他のポッドキャストとかも聞いたりはし始めるようになっているんだけど、
ポッドキャストアプリ、サービスとかで言うと、国産だったらスタンドFMとかボイシーとかあるじゃないですか。
ありますね。
他のポッドキャストサービスとかも見てても、結構いろんなサービスでマネタイズ方法がどんどん出てきてるなと思ってて。
やっぱり一番メジャーなのは、そのポッドキャストについてスポンサーがついてくれるみたいなことがある。
ポッドキャストを投稿する側の話?
ポッドキャストを投稿する側の話?
そう、ごめんね。
プラットフォーム運営じゃなくて。
プラットフォーム運営じゃなくて、ポッドキャスト配信者のマネタイズの話ね。
マネタイズする方法としては、そのポッドキャスト配信に対してスポンサーがつくみたいな。
ボイシーとかだと、結構やっぱり、ボイシーってそもそもある程度有名な人じゃないとチャンネル持てないかな、確か。
審査があるのかな、わかんないけど。
で、その人がポッドキャストの冒頭らへんに、このポッドキャストは何々の提供でお送りしますみたいな。
要はコマーシャル入る前みたいな。
あれね、ラジオでもよくやってるやつだよね。
そうだね、それを言うだけみたいな感じのものが、ボイシーとかだと結構あったりするかな。聞いてる感じ。
で、コスターなんか聞いてる?ポッドキャストチャンネル。
あんまり固定で聞いたことないからね、どんなのがこうだよねみたいな話はあんまりできないな。
ボイシーとかだと、ニュースピックスのデイリーブリーフィングみたいなチャンネルがあって、その日のニュースで一個取り上げて解説しますよみたいなやつがあるから、それ結構面白いよ。
聞いてみようかな。
あと、スマニューのPDMの太郎さんっていう人がいるんだけど、その人はボイシーで、いろんなITのニュースとかに関する解説を配信してて結構面白い。
03:12
それ結構オススメです。
ちょっと話されちゃったけど、マネタイザーの話でいうと、スタンドFMは最近なのかな?いつから気づいたらあったんだけど、
なんかそのポッドキャスト配信の続きを聞くには課金みたいな、ノートあるじゃない?プログサービスのあれと同じような形の課金方法が入ってたな。
へー、面白いね、確かに。だいごが似たようなことやってたね。
そうだね、ニコニコ動画に誘導してってやつでしょ?それ昔か。
今はどうか知らないけど、YouTubeでもニコ動でも配信やって、ここから先はニコ動の有料登録者だけよっていうのに誘導するやつね。
あれと同じですね。
まあそれ結構自然だよね。
そうね、価値を示さないといきなりお金払ってもらうの難しいしな。
まあでも、今俺が見て聞いてた中でこういうのがあるんだと思ったのはその2つかな、基本的には。
ポッドキャストってまだまだ全然マネタイズ方法が確立されてないフェーズではあるんだろうね。
そうだね、通信もガンガンできるようになったおかげで動画の広告が増えてるじゃない。
だから音のみの広告ってちょっと減っちゃってるだろうから、YouTubeみたいに広告入れてマネタイズとかもまだ難しいのかな。
なるほど、なんかね、俺前ポッドキャストのマネタイズ方法ちょっと調べてて面白いなと思ったのは、
ポッドキャスト内のCMって動画のCMとかより頭に残る率が高いらしい。
あー、へーなんだろう、想像の余地が残るからなんだ。
潜在意識に擦り込まれるのかな、わかんないけど、ポッドキャストって結構長らぎきとかしてる人が多いから、その過程でいつの間にか擦り込まれるみたいな。
動画とか見てると、もう動画に集中してるから、これはもう広告だってなって、多分意図的に排除してるのかな、自分の脳から。
そうだね、同じテンションで、ほんちゃんの番組を聞いてるのと割と同じテンションで聞けるのかもしれないね。
そうそうそう、だからそういう意味では、ポッドキャストCMの成長余地ってまだまだあるよね、みたいなことを言ってる記事を読んだ気がするね。
確かにね、店の店内BGMとかもそうだけど、耳に残しにくるやつとかあるじゃん。
06:03
そうそうそうそう。
そこに全力注ぐから、音楽が強いやつ使うかもね、音楽とかキャッチフレーズとかね。
あと確かに、俺がさっき言ったスマアニブの太郎さんってほぼ毎日ポッドキャスト配信してるのよ。
で、俺結構ランチに行くときにそのポッドキャストを聞くみたいなルーティン化してて、そこで毎日転職サイトグリーンの宣伝をしてるのね。
へー。
だから、ルーティンの中にそのグリーンっていう名前が聞くのがすり込まれてるみたいな状態になってて。
なるほどねー。
だから、YouTubeだと広告ってようはそんな毎日聞くってことはあまりないよね。
そうだね。しかもYouTubeってさ、何かの動画を見てるときに流れるだから、テレビのCMもそうだけど、その番組を見てるときはこんなCMあったなって思い出すけど、そのときだけじゃん。
でも、今のだと生活に溶け込んでるから昼飯を食うときに思い出すんだよね、きっとね。
そうそうそうそう。
っていうのが強いかもしれない。
そういうとこなんだろうなーって思ったね。
確かに。
僕らはまだまだ全然マネタイズなんて程遠い話ですけど、
複数が広がっていけばね。
あるんだなーと思ったんでした。
今日の本題がですね、こすだ持ち込みネタですね。
そうですね。仕事で書いてる設計書、どんな感じで書いてるっていうのをちょっと比べてみたいなと思いましてですね。
そうだね。
もともと僕らは同じ会社にいたので、会社系のITコンサルというかね、僕らがやってたことは実際にも近い。
みやっちはコンサル寄りみたいなことをやってて、
一時期僕とみやっちが一緒にいたプロジェクトは比較的緩めだったから、
ちょっとふんわりした設計書でもよかったんだけど、
割と多くの金融とかのところがね、結構かっちりかっちり書いてて、
もうだいぶ要件定義書の段階から細かい定義があって、それに応じた内部設計書、基本設計書があって、
さらにそれを詳細化した外部設計書、詳細設計書があって、
インフラとかソリューションアーキテクチャ的なやつとか、そういう部分も結構ガッツリ書いてある。
データは何年に1回アーカイブしてどうこうとかね、いろんなことが書いてあるというのがあるんだけど、
しかもそれが結構WordとかExcelとかで道々に図とかをつけたりして、表がびっちりついてて、みたいな感じで書いてます。
09:04
っていう感じだったんだけど、宮地が今いるWeb系メガベンチャーみたいなところだと、Excelとかでガチガチ書くってことはしてなさそうだなと思ってね。
それは確かにExcelで設計書はほぼしないから、最初に要件の認識合わせ、設計の認識合わせをするときにExcelを使うっていうことはあるかもしれないけど、
基本的にはExcelで残すってことはしないね。
どれくらいのレベル間で設計書を作るかっていうところで言うと、
外部設計書、UIとかに関するようなところでは作ったりします。
デザイナーさんがFigmaなりAdobeのデザインソフトとかで画面を作って、
その絵を、うちの会社ConfluenceっていうアトラシアンのWikiツールみたいなのを使ってるんだけど、
それにペッて貼って、その横にここをクリックしたらこういう挙動になる、みたいなのを文章で書いていくっていうのが外部設計書になってるかな。
この段階聞いちゃおうかな。
ぜひ。
外部、わりとSIRとかが書くやつって、そのタイミングでステータスごとにこんな動きをしてみたいなのが結構細かく書いてあって、
それがそのままテストに落ちるみたいなことがあるイメージなんだけど、そこまで細かく書いてる?
結構書いてるよ、細かく。
内部設計書はあんまり作んないから、その分ちゃんとUIでどういう挙動をするかっていうのはこと細かに書いてるかな。
なるほど、なるほど。
内部設計は、これもちょっといろんなパターンあると思うけど、まずAPI設計書は結構作ってたりします。
これを内部設計書というのかな、わかんないけど。
どっちだろうね、プロジェクトによるね、どっちかは。
そのAPI設計はスワッガーとかで自動生成してるっていうか、
違うな、設計書からコードを自動生成してるのかな。
12:01
先に組むんだと思ってちょっと気ぃしたけど。
だからスワッガーっていうツールがあって、そこにこういうAPIのエンドポイントがあって、
それぞれどういうモデルというかオブジェクトが返ってくるかみたいなのを、
YAML形式なりJSON形式なりで定義して、それを型ファイルに書き起こす。
プラス、スワッガーUIってやつがあるから、設計書っぽく見れるようなものに落とし込んでるっていうのが、
よくあるやり方だよね。
そうねー。
自動生成してるっていう感じ。
めんどくささもないし、人的ミスがそこで出ないからいいよな。
それ自体がテストにもなったりするしね。
あとはインフラ設計書というか、アーキテクチャーズみたいなのはもちろん作りますよ。
例えばGCPのクラウドストレージを使っててとか、それと何が通信しててとか、
VPCがどうのとかそういうよくあるやつ。
ああいうものはもちろん作ります。
ちなみに要件の段階というか、こんなことがやりたくて、こういう操作ができる、できない、できるべきです、できるんですみたいなのが最初の時点のやつで、
誰かが決めて何かのファイルの形に起こすの?
うーん、そうね、俺がよくやってるのは最初UIのMockを作る感じかな。
Mock自体はDrawIOっていうラフなパワポみたいなツールですよ。
いろんなオブジェクトを置いたりできて、URLとか置けるよね。
それで簡単なUI作って、ここここがこういう動きしますみたいなのもその横にテキストで書いてある。
だから外部設計書のプロトタイプみたいなの作るのかな。
そのユースケースとか、この人がこういうことができるみたいなのがそこに書かれるの?
そこで結構関係者と合意を取るみたいな感じだね、今のところは。
それは最適なやり方かどうかわかんないけど。
でもやっぱり実際にUIがある方がすごい議論しやすいかなと思う。
15:02
なるほど、ウェブ系っていうところの強さみたいなものがそこにはありそうな気がするな。
あと実際にHTML、CSSで組んじゃって話すっていうのもたまにあったりするかな。
ある程度イメージが固まってるんだね。
やっぱりだいぶ違うね、SIR的な進め方っていうのと。
俺も新卒1年目のときの一番最初の金融プロジェクトさ、プログラミングの処理をExcelとかで書いてたもん。
ここに資料が入ってるみたいな。
詳細設計とかね。
そうそう。
すごいよね、だってあれもう何だったらJavaで書いてそれ起こしたことないよね。
それ書けないからもうコード書けよって思っちゃうよね。
で、そこでプログラミングとして頭の能大コンパイルをミスってたので設計書から書き直しになるじゃん。
恐ろしい話だよな。
あれは恐ろしい話だよ、本当に。
でもやっぱりSIRとかだとお客さんがこのリュードで書けみたいなことを要求してるパターンがあるからね。
そうね、フェーズを進むのに承認をしないといけなくて、承認をして合意を取ったらそれ通りに作るよねっていうのを一回決めるから。
決めるっていう動きを取ってるからそうやるし、そうなったら手戻りが大変ってなるからお互い苦労してるよね、あれね。
今話して思ったけど、そういう意味ではうちは結構作ってから設計書にするみたいなパターン、まあまああるなやっぱ。
僕とみやちが一緒にいた最後の方のプロジェクトさ、みやちの。あそこも地味にそれに近い。
そういう経路あったりするね。
とりあえず作ってから考えるぞみたいな。
もちろん大枠では例えばAPIこういうエンドポイントが必要ですとか、こういうモデル開発みたいな大枠でのあれは最初に作るんだけど、それを実装するための処理は個々のエンジニアに委ねられるみたいな感じ。
僕も夜間動作のAIチームというかね、バックエンド分析チーム同じプロジェクトでやったけど、そこもお客さんとこういう分析をしてこういう示唆を得ましょうみたいなのとかはパフォーマンスでやってたんだけど、
実際実装とかは個々に委ねられててその後に書くみたいなのがあったもんね。
18:05
実際書いてみないと何とも言えないからね。
そうだよね。UIも書いてみないと分からないし、分析も書いてみないと分からないからね。
それで書いてみて、やっぱりこっちの書き方の方が良かったな、そこでもうすぐ変えるんじゃなくて、一旦設計書に立ち戻ってここを修正してまた戻ってくるみたいな超無駄じゃない?
多重下請け構造じゃないとやらないよな、それは。
だからやっぱり書いてみて、この実装方法がベストだなってなったやつを最後にドキュメントとして、それがイコール設計書になると思うんだけど、書き起こす。
むしろ全ての処理が書き起こされてるんじゃなくて、ちょっと複雑なところだけウィキとしてドキュメント化されるみたいなパターンが多いような気がするな。
逆にシンプルなところとか、自動で全部出てくれればいいのになって感じがするよ。
シンプルなんだからっていう。
やっぱり結構違いはありますね、SIアートウェブ系メガベンチャーはね。
個人的にあんま詳細のやつはそこまで意味ないような気がするけどね。
急に人がいなくなった時とかにどうやるんだっていうところとか、過去のことを忘れてしまった時に、行動を読んで思い出しづらい単位とかね。
さっき言った複雑なここと絡んでるんですよみたいなところとかは残しておきたいけど、そこの基準が人によって曖昧になるのが怖いなっていうところだよね。
俺の経験がないだけなんかわかんないけど、設計書だけ見て理解したことってほぼない気がするんだけど。
結局設計読んでこんなことをやりたいんだろうな、デコード読んでなってなって。
おかしいぞってなって人に聞いて、なるほどってなるときと間違ってるやんけ、デコードが。
それ単品でどうにかなるっていうのは見たことないね。
そうだね、だからどこまでを設計に書くか、でどこまでをコードで見ればええやんにするかみたいなのは、やっぱりある程度ベストプラクティス的なの欲しいよなっていう思いがあるよね。
そういう本とかもたくさんありそうだけどね、これ全然読んでないけど。
宗教戦争とかケースバイケースのアレになりそうで何とも言えないけどね、ちょっとなんか自分の中での基準とかね作っていけるといいですか。
まあでもこれは本当に永遠の問題ですよね、そのシステム開発チームにおける。
21:03
そうね、今の。
読めんこらない設計書を見て。
コーディングをプログラミングっていう形でやっていく、コーディングっていう形でやっていくともう絶対に起きることだよね正直ね。
なんかそこからめちゃめちゃすごい設計書を完璧に起こせるようなAIとか作ったらまた話が別。
そうじゃないんだったらもう最初からコーディングの形、プログラミングの形が変わる。
もう設計に落とせる前提のなんかもうノー構造みたいな感じで出すがどっちかだよね。
じゃないと今のやり方だと絶対無理だよねっていう感じがする。
最初に全てね、今後実装するものを書き起こすってまあ難しいよな。
そうね、あれは契約形態の歪みによって発生しているものであって、あれがプロジェクトを進める上でいいやり方ってわけじゃないからね。
契約上そうやらざるを得ないだけっていうか。
だからPDCAでやろうとかっていう話になるんだよね。
あらかじめそこで契約しすんのやめようぜ、歪むからっていうね。
そこらへんも常にベストな方法を模索しながらやっていきたいですね。
そうですね、またなんかいい方法とか見つけたらお互いに報告しましょう。
はい、じゃあ今日はこんな感じで終わりましょうか。
はい。
ありがとうございました。
ありがとうございました。またね。
