Data Analystのメモ帳

機械学習とかデータ分析とかしているData Analystのメモ帳です

KPIの更新頻度

1000文字くらいで思いついたことを書く

 

一言でいうと、自分たちのイテレーションサイクルに対して更新頻度が低いと振り返りができないのでマネジメントの役に立たないという話です。

 

KPIって簡単にいうと、それを使って自分たちの行動した結果を振り返ったりしながらその数字を目標値まで進捗させるためにあります。

なので、自分たちの行動した結果が反映されてほしいのですが数値に更新頻度が低いと結果がでるまで時間がかかってしまうので自分たちの振る舞いが良かったのか悪かったのかわかんないので困るんですよね。

こうなると良かったのか悪かったのかわからないまま数値に反映されるというか結果がでるまで行動し続けるしかないんですよ。

で、実は意味がなかったのにずっと施策を打ち続けていたとか悲しいことが起きてしまう。

これは数字で管理しているメリットがあんまりなくなってしまう。

そういう事態を防ぐために指標の更新頻度が高いということは地味だけどオペレーションの中で重要になってきます。

じゃあ毎日ならいいのか毎時ならいいのかとかでてくるんですけど、早ければ早いほど嬉しいのはそうなんだけどそれを維持するコストも上がってくることが多いのでちょうどいいくらいを探すことになります。

何と比べてちょうどいいくらいを探すのかというと自分たちのイテレーションサイクルのスピードです。

開発だったらリリースとかスプリントとか何かしらのまとまりです。

振り返りから振り返りまでの間隔と考えてもよさそう。

このサイクルよりは更新頻度が高くないと定例の会議で「今週は数字が更新されていないのでこのまま施策を続けましょう」みたいな間抜けな状態になってしまいます。

とはいえ「それはわかるけど欲しい指標の更新は月に1回だけなんだ」とかどうしてもあるわけですよね。

月次課金だから離脱率がわかるのは月に1回だけなんだ、みたいなことはサービスの性質からどうしても起きてしまうと思います。

そういうときに、じゃあ諦めて月に1回の数値の更新を受け入れるのかというとそれはやっぱり運用上よくないので代替としてどうするかというと何らかのサブのKPIを立てて追いかける方針が良いのかなとおもいます。

本当に欲しい指標そのものではないけど関連性が高く更新頻度の高い先行指標です。

離脱率の先行指標としてヘルススコアなんて言ってログイン頻度とか機能の利用率をみるのはそういう意味もあります。

 

という感じで更新頻度の低い数値が更新されるのをずっと眺めているよりも更新頻度の高い有用な指標を探索して自分たちのイテレーションを改善すると良いのではないでしょうか、という話でした。

問題を解決する人と時間を確保していない振り返りにガス抜き以上の意味がない

1000文字くらいで思いついたことを書くコーナー

 

そろそろ年末ということでチームの振り返りをやる人たちは多いとおもうんですが、振り返りをやってるのになんか全然改善しないなあみたいなことあるんじゃないでしょうか。

KPTとかいろいろな振り返りの手法があっていろいろ調べてやってみてその場はめっちゃ盛り上がってこれで良い組織になる!なんてことをやっているときには感じるのですが次の年になっても全然変わって無くてあの振り返りはなんだったのか、みたいな状況。

こういうのが常態化すると全然改善されないことに無力感が生まれるので組織として健全じゃないですよね。

この現象が起きる原因の1つとして「振り返りで発覚した問題を解決する人と時間を確保していないから」というものがあるんじゃないかなとおもいました。

どんなフォーマットでもいいのですが振り返り会をしたらよかったところと悪いところがでてきて次から悪いところを治そう!ってなるとおもうんですが、実際にこの悪いところを治すための工数が確保されていないんですよね。

問題がでてきたときにそれを解決するためのオーナーを指定して実施を命じるとこまでやんないと改善されないんですよ。

これは当然のことでみんな何かしら仕事があるなかで改善活動とかやる余裕が無いわけで、それを業務の1つとしてやらないと進まないんですよ。

KPTとかそういうの記入してワイワイするのは30分とか1時間もあれば終わりますが、そこから解決のために使う時間はその何倍もかかるわけですよね。

さらに一人で解決するなら本人のモチベーション次第ですけど誰か他の人やチームを巻き込む必要があったり予算が必要となったらそれはもうタスクとして取り組まないと解決されなくなります。

とまあ、こういうことを言っていると「振り返り会のときはなんで問題が解決した気持ちになるのだろう?」ということが気になるのですが、これはたぶん完全に気の所為なんだとおもいます。

不満とかを口にして共有されたのでストレスが解消されたから問題として解決するモチベーションを維持し続けることができなくなっちゃうのかなーと。

でも解決されたわけではないので後からじわじわと課題意識が生まれてまた爆発するっていう。

こうなると振り返り会がただのガス抜きの意味しかなくなってしまうので、本当に課題を解決したいのならば課題が生まれたら解決する人と時間を確保して業務としてあたってもらうまで1セットでやるしかないのだろうとおもいます。

これをワークフローとしないで個人に任せているといつまでも進展しない組織になっちゃうし、そういうとこは優秀な人から抜けていくでしょうね。

改行が必要な長文をslackで送るべきではない

 

slackはチャットツールなので長くなる文章はdocsとか別の場所に書こうという話を世界のどこかではなしたので文章にしてみる。

 

そもそものはなしなんですが、slackはチャットツールであって口頭で話すようにチャットをするように情報が言ったり来たりするやり取りすることに向いているんだけど、一方で、1つの塊になった話題を共有することには不向きなツールです。

これは読みにくいとか書きにくいとか検索しにくい保存しにくい…etcあたりが理由で、もちろん機能としてはここ数年でリッチなテキストが書けるようにはなっているんだけど、それはそれとしてやっぱり使いにくいです。

特に検索したり保存する機能がかなり貧弱なのでslackに議事録とか書かれたら後から議事録を探せないなんてことになります。これは非常に困る。

なので議事録とか設計とか仕様書なんかをslackに書いたりすることは原則として避けた方がよいということになります。

まあ、さすがに議事録とか設計みたいなものは専用のドキュメントを用意する人が多いのですけれど、実際としてよく困るのが、ちょっと背景が長くなるくらいの問い合わせは「わざわざドキュメントにするのも面倒だから長いけどslackで送っちゃえ」というパターンは結構あります。

こういうの開発チームの内部に閉じているとPull RequestとかJIRAとかチケットツール上でコミュニケーションするように決まっている場合が多いんだけど、他のチームとのやりとりとなると途端にslackに全部流れてしまうことがあります。

そういうチケット上でのやりとりに慣れていない人なんかは特にそういうやり方をすることが多くてslackで長文投稿するパターンが多いんだけど、そうなるとコミュニケーションが全くあとから追跡できないなんて問題が起きます。

あとから誰かにタスク渡したいけど背景とか全部slackに散在していて全然引き継げないとか。覚えがある人いるんじゃないだろうか。

つまるところ、slackはチャットのように散発的なコミュニケーションには向いているんだけど背景や要件を伝えるようなリッチなコミュニケーションには相性が悪いのでなるべく別の場所でやったほうがいいです。

じゃあ、どこまでslackでどこからslack以外でやるんだよみたいな話になるとおもうんですが、これは個人的な基準として「改行が必要な長文をslackで送るな」というルールが明確でいいんじゃないかなーと思います。

コードとか何か外部から引用するときは例外ですけど、改行が必要になるようなまとまりが要求されるコミュニケーションはドキュメントを作るなりチケットを切るなりされるべきだということです。

特に箇条書きという機能にあるせいで整理された情報がslackに取り残されるという状態は本当にもったいないとおもっています。

「自分は忙しいからドキュメントなんて作っている暇なんてない」なんて考えの人がもしかしたらいるかもしれませんが、間違いなくそのコミュニケーションでは伝わっていない情報があって、誰かが時間をかけて助けてくれているとおもいます。

 


久しぶりのメモ帳らしいメモを書いてみた。個人の感想です。

ダッシュボードとかKPIを作るときにやっていること

普段やっていることをメモしてみる。

概要

すごくザックリ言うと考えるフェーズと作るフェーズがある。 最初の考えるフェーズはダッシュボードとかKPIを使う人(以下、決裁者)からヒアリングしたり基盤やサービスを調査して実現性を考えるフェーズ。 作るフェーズは実際にクエリ書いたりBIツールをアレコレするフェーズ。 個人的に重要だと思っているのは考えるフェーズと作るフェーズをなるべく疎にすること。

考えるフェーズ

ここでやることは3つです。上から着手はしますがお互いに関係するので同時並行に進めることが多いです。

  1. 決裁者から目的や要件を聞き出す
  2. データ基盤やシステムを調査して実装に必要なものを洗い出す
  3. 類似のダッシュボードやKPIを探して比較検討する

まず1番はいわゆる要件定義です。 決裁者が数字を見てやろうとしていることや条件なんかを聞き出します。 最終的なアウトプットが役に立つかどうかはここにかかっているので精緻にやることが求められます。 基本的にはドキュメントに条件とかを書き出して問題ないが確認してもらいます。 口頭とかチャットだと漏れや認識のズレが発生するので最終的なアウトプットはドキュメントにします。 言った・言わなかったみたいな事故は防ぎましょう。

2番は要件をもとにそれが実装可能なのか調べたり、追加で必要な開発を洗い出します。 要件で求められたデータや条件を既存のもので表現できなかったら当然追加で開発したり、場合によっては今は抽出できませんとか返す必要があります。 なので実装に入る前の調査フェーズでそもそも実現可能なのか調べます。 ここはチーム内で確認したり開発チームなんかに相談することが多いです。 重要なのは妄想ではなくファクトを取ること。

3番は似たような案件を探します。 当然、似たようなものがあれば流用したり参考にしたりできます。 また、類似のダッシュボードがある場合はそれと平行して見たいとか、そういう意図があるケースも多いので見せ方としてどうしたほうがいいのか考えたりします。 類似のケースがある場合はなるべく類似ケースを理解したほうが良いです。 少なくともそれの担当者に軽く話を聞くくらいはするべきでしょう。

ここまでやることで何を作るのか、どうやって作るのか、過去の例があるのか調査が完了します。 これらを踏まえたドキュメントを作成しチーム内や決裁者、他の関係者にレビューしてもらい概ね問題がないことが認められたら実装へ移ります。

作るフェーズ

これに関しては粛々と実装するだけなのであんまり言うことはないです。 考えるフェーズでアーキテクチャや細かい条件と実装は考えられているはずなので実装で考えることはそんなにないです。 良いコード、詳細な設計となるように心がけましょう。 逆に、この段階であちこちに相談したりするようならば、それは事前準備が甘かったという意味なので次への反省とします。

とはいえ、実装途中に「聞いてた話と違う」とか「よく考えたら間違ってた」ということは起きます。 変更・追加が発生したら前述のドキュメントに変更を追記しましょう。 なるべくドキュメントと成果物は対応しているようにします。

あと、実装段階に入ったあと要件の追加を依頼されても基本的には断ります。 よほど重要であったり簡単かつ少量であれば受付けますが、そうでなければバックログとして次の開発案件として積むだけにとどめます。 どちらにせよ次回から考えるフェーズで出すように先方にお願いしておきましょう。

実装が終わったらチーム内で確認を決裁者にレビューしてもらいOKがでたら作業完了です。 念の為、実装とドキュメントを比較して相違がないか確認して、チケットをdoneにします。

なぜ明確にフェーズを分けるのか

一番の目的はステークホルダーを減らすためです。 分析は多くのステークホルダーが存在するため調査と実装を同時でやると情報が錯綜して非常に厳しい状態になります。 また、調査と実装を並行すると要件定義がダラダラとしがちです。 これによりダラダラと追加の要件が生まれたりします。 なので要件はバシッと決めてそれ以降の追加については断れるような体制をつくります。 こうしないと無限に要件が追加され一生完成しないけど誰も見ていない数字がならぶダッシュボードが生まれます。

ドキュメントについて

私は案件ごとに簡易的なドキュメントを作成するやり方が好きです。 要件や実装の方法、セキュリティなど留意点をならべたものです。 これはDesignDocという手法を真似しています。 この方法の良いところは、作るために必要な情報が集まっておりドキュメントを見れば誰もが理解できる点です。 これはレビューを容易にし成果物のクオリティを高めます。

スライドや付箋、ワイヤーフレームなど様々な表現方法はありますが私は箇条書きでドキュメントにするのを好みます。 前者のような方法は一見は見やすくわかったように感じますが一方で網羅的に表現したり細かい追記をすることが難しいです。 箇条書きであれば細部まで必要に応じて記入することが可能です。 またGoogle Docsであればコメント機能を使うことで追記や確認を依頼したり留意事項を残すことが簡単で非常に便利です。

おわりに

あらためて俯瞰してみると脳みそを使う部分として自分は考えるフェーズをすごい意識しているのだと実感しました。 作るときがケースバイケースすぎて書けないというのもありますが。

この記事でなにが言いたかったのかというと、みんなドキュメントを書こう。

フリーランスのデータアナリストがどんな感じなのか

Twitterで興味あるって言われたんで、フリーランスのアナリストという働き方についていろいろ書いてみます。 いろいろぼやかしている部分があるのであくまでも参考程度に。

ちなみにこういう話はYouTubeでちょくちょく話しているので細かいところは配信みたほうがいいとおもうよ。

youtu.be

youtu.be

仕事の獲得・営業

私の場合は営業活動というほどのことをしていません。 フリーランスになる初期で速攻で仕事が決まった and 私の契約が長期で新しい仕事を探す必要がほとんどなかったという理由に起因します。 なので特に話すこともないのですが、初期に速攻で仕事が決まったときにどんな流れだったのか書いてみましょう。

まず、一般に業務委託の仕事を探す方法はいくつかあります。 代表的なものを列挙すると、

  • 個人のつながり(いわゆるコネ)で紹介してもらう
  • 業務委託募集で応募する
  • エージェント経由で紹介してもらう
  • 企業へ営業して獲得する

こんな感じです。 私の場合は個人的なつながりとスカウトで業務委託の仕事を得ました。

スカウト経由というのを説明すると、エンジニアなどで副業をしたことがある方なら想像がつきやすいかと思いますが、転職スカウト系のサービスに登録していると副業も含めたスカウトが飛んでくることがあります。 私は仕事を辞めてフリーランスを考えているタイミングでそのようなスカウトをもらったので「会社辞めるから副業というかフリーランスとして業務委託はどうでしょう?」と相談して仕事を獲得しました。

まあ、ここまで読めばわかると思いますが、私のフリーランスのやり方は副業をちょっとガチったという雰囲気が強いです。 たぶん、こういうフリーランスのやり方はレアケースで、エージェントを経由して仕事をもらうというのが一般的だとおもいます。 データアナリストの業務委託にどんな仕事があるのかって話はそのうちどっかでやります。

契約

契約の進め方としては最初は数ヶ月の契約で始まって適当な期間で更新するという形が多いですね。 あと、トライアルが最初に入るケースもあります。

トライアルは短期間働いてみてマッチングを確認するというものです。 社員のそれと同じものだとおもって問題ないです。 トライアル完了後に面談して本契約に入ります。 このときに場合によっては価格の再交渉が入ったりします。 トライアルはちょっと安めで入って本契約からちゃんといただくっていうのはよくあります。

契約の更新はわりとこちらの希望を聞いてくれることが多いです。 大体は3ヶ月とか半年の契約でそれ以降は自動更新とか、問題がなければ再度契約を更新する、っていうパターンですね。 私は適当な期間で契約を結んで以後は自動で毎月更新という形が好きです。 これはお互いに合わないとおもったらサッサと契約を解除したほうが良いという考えだからです。 仕事を安定させるなら、本当はなるべく長期の契約を結んだほうがいいですけど。

お金

たぶんみんなが一番興味があるポイントだとおもいます。

私個人の話でいくと、月の売上としては基本的に生活水準を落とさないくらいに稼いでいます。 逆にいうと仕事量はそれを満たすくらいに調整しています。 これは個人的に仕事をしないで好きなことをやる時間を増やしたいからです。

具体的な単価ですが、発注する企業や担当者、こちらの交渉力、タイミング、仕事内容などでかなりかわります。 なので一概に言うことは難しいですがこのリンクが参考になるかとおもいます。 体感とも大きくはずれてはいません。

prtimes.jp

一般的な傾向として開発や分析など現場で手を動かす仕事は長期契約になり安定しますが単価に限界があります。 一方で、コンサルティングや顧問のような契約の方が時間あたりの単価はあがりますが月あたりに得られる金額は限界がありますし契約解除のリスクも高くなります。 これは単純な例ですが1つの仕事の値段だけみてもしょうがないというところがフリーランスにはあります。

長期的な将来の収益性を考えて仕事をする必要があるので値段でみるよりもポートフォリオを組んでいくという感覚に近いです。 キャリアビジョンがもっと切実に生活へ影響をあたえる感じです。 まあ、それが事業計画ってものなんでしょう。

業務の内容と進め方

これは契約や企業により全く変わると思いますが、あくまで私の経験を例にはなします。

基本的に、私のクライアントはいわゆるweb系ベンチャー企業で彼らが提供しているサービスのデータ分析や開発が仕事になります。 その中で関わり方とししては、完全にプロジェクト単位で仕事をする場合とメンバーの1人として仕事をする2パターンにわかれます。

プロジェクト単位で仕事をするケースはわかりやすく業務委託って感じです。 アナリストよりも開発案件が多いかな。 特定の開発プロジェクトにアサインされて開発者としてPoCから開発に関わっていくというパターンです。 PoCが上手くいったら運用に乗せて引き継ぎをするまで仕事が続きますし、PoCがダメだったらプロジェクト終了と同時に契約も終わりです。 データの整理や前処理、モデリング、サービスの開発、ドキュメンテーションと開発に関わることは大体やってます。 (個人的にはあんまり得意じゃないので将来的にはやらないでいきたいんですけども)

メンバーとして仕事をするケースは見かけは一般の社員と同じように動く状況です。 アナリストとしての仕事はこちらのパターンが多いです。 私に裁量があり、会社のためにやるべきことを考えて仕事をしていきます。 データ分析はweb系ベンチャーでアナリストをやっている方と同じでKPIを建てたり効果検証したりって感じです。 特別なことはあんまりないですね。 他社から来た中途と同じように、私が持っている知見をとおして会社を良くすることが求められています。 なので分析以外にもいろいろ首突っ込んで改善したりとかしてます。 継続的に関わることになるので契約も自動更新という場合が多いです。 なにか失敗したからといって契約解除になることはないですが、それなりの成果を出し続けることを期待されるようなプレッシャーはあります。

クライアント(決済者)とのお付き合い

実は特に書くべきこともないくらいクライアントとなにか特別なやりとりは無いです。

定期的に決済者(役員とか事業部長とか)と面談をしますが世間話と業務に関する相談をするくらいですね。 話した内容の如何によって金額が下がるとか契約解除とかってことは余程やらかさない限りはないかな。 これは社員として偉い人と面談するときの雰囲気を想定していただければたぶんあってます。

なんか昭和のような付き合いで偉い人に呼び出されて飲んだりとかゴルフしたりってことはやったことないし求められたこともないです。 まあ、今の社会情勢でそれをする会社がそもそもどうかと思いますけどね。 一緒に仕事をしているチームやステークホルダーの方々と真摯にやり取りしていれば問題はありませんし、問題がなければ契約は更新されます。

あとがき

とりあえず思いついた限りでみんなが知りたそうなことを書きました。 他にも聞きたいことがあったら質問箱に送ってくれ!

YouTubeのチャンネル登録もよろしく!

www.youtube.com

フリーランスのデータアナリストを1年やってみて

これはただの備忘録です。 前に配信で話したことも話してないことも。

youtu.be

背景

今年の春くらいから会社員を辞めてフリーランスになりました。 なったときの背景は前の記事を参照。

grahamian.hatenablog.com

仕事内容

仕事内容としては受託で分析者としての仕事をするものが多くて、あとはアルゴリズムを書いたりといわゆるデータサイエンティスト的な仕事かな。 ふつうに社員がやる仕事を業務委託として受けたという感じです。 普段の業務としては社員だった頃とあんまり変わってないです。 いろんな会社と関わるという点が違うくらい。

仕事あるの?

フリーランスになってから無限に聞かれることとして「仕事というか案件あるの?」って聞かれます。 これは完全に主観になりますが「自分が食べるくらいは余裕である」というが回答です。

まず、大前提としてデータアナリストとしての案件はそれほど多くありません。 そもそもデータアナリストというポジションとしての仕事自体が少なく、さらに業務委託でも可能としている会社は少ないです。 なので案件の数自体はたとえばエンジニアと比べると非常に少ないのが現状でしょう。 とはいえ、案件は少ないですが受託できる人材も少ないので需要と供給のバランスでいうと供給が不足している状態ですので、個人として仕事を探す分には苦労しませんでした。 また、継続的に関わる案件が多く、そもそも仕事を探す機会がそれほどなかったという部分もあります。

収入は?

収入についても無限に聞かれるんですが「ぼちぼちでんな」としか答えないことにしてます。 とりあえず生活水準があがったり下がったりはしていません。 それくらいになるように仕事を調整しているので当たり前なんですけども。

今年の反省

1年弱ですがフリーランスをやってみた感想としては、フリーランスになる前に想定したくらいの状態にはなったかな、という感じです。 収入や忙しさ・仕事の安定さなどを考えて、フリーランスになる前に「このくらいになろう」と考えていた状態に落ち着いてます。 良くも悪くも予定どおりって感じで、これは目標どおり達成出来たという意味で喜ばしいです。

来年の目標

2021年は業務委託として分析の案件を受ける仕事に終始していました。 2022年は次のステップとしてなにかしらの事業をしてしたいですね。 安牌な受託の分析仕事に限らずリスクを負って事業をやりたいと思った背景として、単純に分析の仕事に飽きてきた・レバレッジを効かせる仕事をしてみたい...etc いろいろ理由はありますが、単純におもしろそうというのが理由かもしれません。 自分でも理由はよくわかってませんが、まあアナリストになるときもそれくらいの気分で転職したのでなんとかなるでしょう。 ダメだったらそれはそれで別のことをがんばればなんとかなるよ。

まとめ

来年も楽しく人生を送れるよう頑張らない程度にがんばっていきます。 関係者各位、1年お疲れさまでした and ありがとうございました。 来年もよろしくお願いします。

Grahamianチャンネル 2021年12月の配信環境

自分の配信環境のメモです。

前提と背景

去年の今頃から自分のYouTubeチャンネルを立ち上げて今年の春くらいから配信をメインに活動しています。

www.youtube.com

このメモは特に配信で使っている機材を記載します。
動画だとカメラとかいろいろ必要なんですけど音声メインの配信なので機材はほぼ音響まわりだけになります。
ポッドキャストやりたい人なんかは参考になるかも。
あと、自分の持っていた機材を流用しているところが多いので、そういうの無い人がゼロから揃えるならもっと安価な機材で十分だと思います。 そういう点は付記していきます。

機材の構成

f:id:Grahamian:20211218203443p:plain

音声配信だけだし音質が重要なものでもないので機材構成はシンプルです。 マイク → オーディオインターフェイス → OBS → YouTubeですね。
映像も移したいならカメラをUSBでつないで映像入力としてOBSに追加すればOKです。

音響まわり

マイク

マイクはAKGのD7です。

https://www.soundhouse.co.jp/products/detail/item/132552/

これは完全に手元にあったから使っているだけですね。 もっと安いやつで十分だしダイナミックマイクよりもコンデンサマイクの方が喋り声には向いていると思います。

今はUSB接続できるコンデンサマイクがたくさんあるのでPCにつなげる前提ならそちらの方がいいかな。 機材の数も減らせるし、それで十分だと思います。 5000~10000円くらい。 音響は高いもの買ったからといって音がよくなるわけではない、というか下手すると音が悪くなるのでこれくらいの価格帯にしたほうがいいです。

マイクを選ぶときは定番メーカのうち単一指向性がありマイクスタンドやアームと接続できるものを選ぶのをおすすめします。 単一指向性とは音を拾う角度のことで、簡単にいうと単一指向性は周りのノイズを拾いにくくなる。 良いマイクを使うとわかりますが、部屋はエアコンや車、パソコンのファン...etcとノイズだらけです。 聞いている側はかなり気になるのでノイズ対策は気をつけた方がよいですね。

あと、マイクスタンドに繋げられる方が便利。 机に直接置くと机に手がぶつかったときの音とかキーボードの打鍵音をめちゃくちゃ拾います。 これがかなりうるさい。 なのでマイクスタンドにつなげたくなるのですが、ネジがあったりクリップで挟める構造になっていないとできないので、そこを見越して買う方が良いです。

マイクスタンド

マイクスタンドというかアームを使っています。 スタンドだと机に置くとキーボードの音を拾うし床におけるほど部屋が広くないので消去法で机にアームで固定することになりました。 アームはRoycelというメーカが安かったので何も考えずに使っています。 同じ安いものでいいならサウンドハウスClassic Proを使うほうが品質は良いと思う。

https://www.soundhouse.co.jp/products/detail/item/173214/

ポップガード

ポップガードはマイクアームとセットでついていたものが一瞬で壊れたので老舗マイクスタンドメーカであるK&Mのポップガード(23956)を使っています。 マイクアームにネジで挟むようにして固定できるので取り回しが良い。 ポップガードは高いものはいらないけどなにかしらは買うべき。 単純に破裂音で音が吹っ飛ぶのを防げるし、ツバでマイクが汚れる心配もいりません。 費用対効果は最高。

https://www.soundhouse.co.jp/products/detail/item/48047/

オーディオインターフェイス

オーディオインターフェイスっていうのはマイクをパソコンとかへつなげるための機材です。 私はD7というダイナミックマイクを使っているので必要ですがUSB接続できるマイクであれば不要になります。

私が使っているのはBehringer UM2

https://www.soundhouse.co.jp/products/detail/item/186277/

マイク入力できてUSB接続できるオーディオインターフェイスのうち一番コスパが良いと思う。 ツマミで音量調節もできて便利。

お金があってちゃんとしたものがほしいならSTEINBERGのUR12かUR22Cがいいかな。 UR22Cはマイク2本挿せるしUSB-TypeCが使えるからよさそう。

https://www.soundhouse.co.jp/products/detail/item/200026/

https://www.soundhouse.co.jp/products/detail/item/268678/

マイクケーブル

マイクとオーディオインターフェイスを接続するケーブルです。 たぶんAudio Technicaのキャノンケーブル3mです。 短すぎると変な風にケーブルにテンションがかかって接続部分が怖いし長いと邪魔なのでちょうどいい長さにしておくのがいいとおもう。

メーカは定番の音響機材メーカだったらどこでもいいけど信頼できるところにすべきです。 変なケーブル使うと周りの機材が壊れる可能性がありますんで。

ソフト

配信ソフト

パソコンにつないだ先はOBSスタジオで設定しています。 OBSの設定はやればわかると思います。 ポッドキャストやるならOBSじゃなくて録音ソフトにつなげればOKです。 BGMとかもOBSから流してて、音源は適当に権利がOKなものをネットから探してる。

誰かの通話しながら配信するときはちょっと面倒で、LadioCastとSoundflowerというソフトを通しています。 この2つでなにをしているのかと言うと、仮想のサウンドミキサーを作って通話音声(バックグラウンド音声)を入力しています。 macだとこういう面倒な処理が必要なんですがwinならいらないです。 詳しくは調べて。

irilyuu.com

ミラーリング

たまにiPadの画面をミラーリングして配信しています。 これはiPadmacにつないでQuickTime Playerに画面を写してウィンドウキャプチャしています。 スマホとかタブレットミラーリングするソフトもあるんですが私はこれで十分ですね。


以上、今使っている機材をメモ程度に洗い出してみました。 他に知りたいこととか質問があったら質問箱に送っていただければツイッターで回答します。

宣伝

データ分析についていろいろ配信してます。チャンネル登録よろしく!

www.youtube.com