bunty's blog

ググったこととか勉強したことのメモ

2023 年の振り返り

飛行機の中でメモを書いたはずなんだけど、どこかに行ってしまって書き直している。そこまで書く気がなくなってしまったが、メモ程度に残しておく。総じて 2023 年は大変な一年だった。

よかったこと

とりあえず移住できたのはよかった。そのための準備をしたり、環境に適応することにたくさん時間を使った。 色々な繋がりができたりと思ったよりも楽しい生活が送れたのが一番。

悪かったこと

迷っている時間が長かった。自分の環境の変化、世の中の変化の速さなどもあり、思い切った行動が取れなかった。 また、新しいコミュニティに入る時もどうしようかと何度も先送りにすることが多く、無駄な時間を過ごしたなと思った。 体調も結構崩したし、メンタル的にも少しやられてる期間があった。

もっと詳細書きたいんだけども、一旦こんなところで。

起業の科学を読み直して思ったことのメモ

年末年始でたくさん本を読み漁っていた。起業の科学と解像度を上げるらへんを読んでいていくつか共通点があったり、思ったことがあったのでメモとして残しておく。

  1. ソリューションより課題 特に自分のエンジニアということもあり、どう解決するか、解決策の方から入ってしまいがち。こういうアプリを作れるんじゃないかとか、このサイトのここを変えた方が良いんじゃないかと。 そうするとあたかもそこに課題がありそうな感じがするのだが、実際には課題があるのかどうかは検証していないということが多い。

良い解決策ではなく、良い課題を見つけるということが自分にとっては市場に意識すること。 Facebook などの事例などもあり、自分が欲しいと思うものを作るというのはやりやすそう。

  1. 作る前に売る これも意識したい。やっぱりすぐに作りたくなっちゃう。作る前に検証してなるべく作らないということができたら良い。

  2. スタートアップとスモールビジネスの違い 本では軽く説明されていただけだが、自分としてここも意識しないといけないと思った。 というのも、スタートアップを作りたいということではなくて、スモールビジネスをいくつかやりたいと思っているので、課題の大きさやソリューションのクレイジーさなどを意識しすぎると動けなくなりそう。

  3. MVP の質 これも色々と作りたくなってしまうので、とにかく早く出す。恥ずかしいと思う段階で出す。

  4. Content is King, but UX is Queen これもとにかく早く出そうとか思うと UX がひどいものにしてしまいそう。

Nreal を使ってみたが合わなくて購入をやめた

前に Notion で書いていたブログからの移行分 (2023/2/11)


Twitter でちらほらと Nreal をディスプレイ代わりに使っている人を見かけたため、移動する時や外でも大きなディスプレイとして使えたら良いなと思い試してみた。

Nreal Japan

いきなり購入しなくても、kikito と言うサービスでレンタルができて、気にいればそのまま購入もできるとの事だったので試してみた。

紹介コードを貼っとくfriend14efdcce6b16

kikito[キキト] - ドコモのデバイスお試しサービス あなたにぴったりのデバイスを、ぴったりの使い方とともに提案します

結論としては、自分には合わないと感じて購入をやめた。

合わなかったところ

もう少し改善されたらまた試してみたいので、どこが良くなかったかをメモとして残しておく。

1. 重い

慣れの問題かもしれないが、もちろん普通のメガネに比べると重い。普段メガネもしていないのでこれをかけていることにかなり違和感があった。

2. 目が疲れる

VRをやっているような少しの疲れを感じる。長時間の作業には向かないなと感じた。1 つ目の重いと言う事と合わせて、集中しきれないような気がした。

3. 大きなディスプレイで操作している感はない

これが 1 番大きいのだが、初めて Oculus を使ったときのような感動は全くない。まぁディスプレイっぽいものが写ってはいるのだが、自分の部屋で大画面のディスプレイを使っていることもあり、正直大した事はないなと思ってしまった。

また、デュアルディスプレイのような設定もあるのだが、片方のディスプレイを見ながらもう片方を作業すると言うことができず、結局デュアルディスプレイの良さは何もなかった。

逆に良かったところとしては持ち運ぶことを考えるとかなり軽い。また隣の人からディスプレイを見られることもまずないと思うので、外で作業する時にはセキュリティー面でも良さそうに感じた。 もう少し改善が進めば全然購入の可能性はありそうなので今後に期待したい。

whisper で話者分離を試してみる

前に Notion で書いていたブログからの移行分 (2023/2/11)

whisper で話者分離を試してみる

いくつか文字起こしのサービスを比較検討してみて、whisper が 1 番精度がよかったが、話者分離ができないことがネックだったのでそれを試してみた。試した日は 2023/02/11。

下記の記事がよくまとまっていたので、Google Colab で試してみた。

pyannote.audioで簡単話者分離〜whisperを添えて〜 - Qiita

動画を wav に変換

.wav にしないといけないようだったので ffmpeg で変換をする。

$ ffmpeg -i movie.webm -ar 16000 movie.wav

1番良い結果が得られるように試す

ベースは Qiita の記事のソースコードで、いくつか設定を変更して試してみる。

num_speakers の設定

今回は人数が 2人と決まっていたので num_speakers を設定。これは指定しておいて損はなさそう。

diarization = pipeline(audio_file, num_speakers=2)

language の設定

また、日本語が対象なので language も指定した。

text = model.transcribe(waveform.squeeze().numpy(), language="japanese")["text"]

明らかにおかしいなという結果が出るようになった。もちろん「ご視聴ありがとうございました」なんて一言も言ってないし、似てる言葉すら発していない。ちなみに large モデルで試していて、whisper 単体で文字起こしをするときに比べると体感で 2,3 割質が下がったように感じる。

[105.6s - 105.6s] SPEAKER_00: ご視聴ありがとうございました
[110.7s - 112.0s] SPEAKER_00: うん。分かりました。

[315.2s - 316.9s] SPEAKER_01: おやすみなさい
[318.7s - 319.4s] SPEAKER_01: おやすみなさい

[899.2s - 900.0s] SPEAKER_00: Focal on the play priority見てねお気に召したい被写体数少なくみんなおめでとうFocal on the play priority銘很に味わえるFocal on the play priorityお水食い

language の指定なし

逆に指定しない方が良いのかな?と思い試してみる。(気になるところを抽出してみた)

全体的に英語が増えたなという印象だが、よくみるとかなり色々な言語が混ざった結果になった。

[280.4s - 281.2s] SPEAKER_01: Mm-hmm.

[2132.3s - 2133.0s] SPEAKER_00: الله أكبر

[2200.8s - 2201.2s] SPEAKER_01: No, no.
[2222.1s - 2223.3s] SPEAKER_00: Yeah, you do.

[2377.4s - 2378.1s] SPEAKER_01: 過得好

[2507.6s - 2508.8s] SPEAKER_00: 정도되어 있었네.

出力に含まれる言語が日本語と英語だけなら、英語だけの出力は非表示にしてしまおうかと考えたが、なかなか色々なパターンが含まれており機械的にやるのは無理そう。

sample_rate の設定

これは sample 通り 16000 のままにした。もともと ffmpeg-ar 44100 を指定していたので、これに合わせて sample_rate も 44100 にしてみた。44100 に設定をするとほとんど一致する箇所がないくらいに質が下がった。

結論

  • 今回のやり方だと、話者分離はできるが精度が下がる
    • 事前に検証をした Amazon Transcribe と同じくらいの精度に感じた

次やりたいこと

  • 少し前にこれを見かけたので、このモデルを使ってみる

超高精度で商用利用可能な純国産の日本語音声認識モデル「ReazonSpeech」を無償公開

  • 話者分離の結果とwhisperの文字起こしを統合する処理を入れる

whisper 単体だとかなり精度が高く、今回試した方法だと話者分離ができる反面精度が下がるという結果だった。その意味でここにまとめられているケースは試してみたい。

「16時間でプロダクトに自信が持てるドリル」を始めた

最近この note に沿って本を読みつつドリルを始めた。 note.com

なんで始めたか

最近のタスクが、手を動かしてとにかく作るよりも、データを見てどこに問題がありそうか?具体的にどんな機能をどんな優先度で作るか?などを考えることが多くなってきた。 業務委託のエンジニアと働くことが多かったので、今までも正社員の立場的に自分が何かと巻き取ることが多かった。 なので似たようなことはやってきているものの、かなり雰囲気でやっているというか、ちゃんと学んだことはなかった。

自分のキャリアを考えても、可能性の一つとしてプロダクトマネージャーもあるかなと思っているので、ちょうどタスク比率が変わってきたタイミングでちゃんと学んでみようと思ったことがきっかけ。

やってみてどうか

1週目はすごい楽なんだけども、2週目から一気に大変になる。本を並行して読みながら、参考になる記事も読みながらやるのでインプットも多い。 まだ3週目の途中で、気分転換がてらこの記事を書いているので、またもう少し進んだら詳細を書いておきたい。

デザイナーがいない中でも Figma の html.to.design プラグインを活用して乗り切る

今まで開発がメインでデザインはあまり経験値が高くない。ノンデザイナーズデザインブックを読んだり、一度友達のウェブサイトのデザインをやったことがあるくらい。 なので、なかなかデザイナーがいないと困ることがあるのだが、今の開発はデザインナーが入っていないこともあり、デザイン面も担当している。 まだβ版として提供していることもあり、見た目の綺麗ななどよりは必要な機能が揃っていることやユーザーが迷わないことなど、優先度をつけてできる範囲で行なっている。

そんな中、最近よく使うようになったのが、Figma の html.to.design プラグイン、この記事を読んでから使い始めたが、めちゃくちゃ便利。 coliss.com

もともと Figma を使ってデザインを作ってきた訳ではないので、Figma 自体そこまで使いこなせていなかった。 デザイナーに Figma で作ってもらって、その Figma をもとに実装をするくらい。 Figmaを使いこなせるようになったところで、一からデザインをうまく作れるスキルを持っている訳ではないため、既存の Web サイトをもとに作れるのが楽。

Figma の管理ができてなくてもなんとかなる

常に Figma のデータを最新のデザインであると定義してしまうと、Figma 側を適切に管理する必要が出てきてしまう。 Figma のスキルが低いことと、ちょっとした変更であれば Figma を触らずに直接 Web サイト側を修正したい。

このプラグインを使うと、Web サイト側を一気に Figma に持って来れるため、Figma 側の管理をそこまで気にしなくて良くなった。 必要な時に必要なページを import してしまい、開発が完了したらそのページは使い捨ててしまっても問題がない。 自分のようにプログラマーがデザイン面も触らないといけない時や、もともと Figma が入っていない状態から Figma を導入する時にはとても有効に使える。

他のサイトを参考にするときに楽

デザイナーじゃない人がデザインを考える時、おそらくは他のサイトをたくさん参考にすると思う。(デザイナーはどうだか知らないが) 自分の場合、イメージが近いサイトをメインの参考にするサイトとして、それプラス2,3参考にするサイトをピックアップして組み合わせるようにしている。 1つのサイトから全てを参考にしてしまうと、ほぼ丸パクリのようなサイトができてしまうからだ。

このようなケースで他サイトを参考にする場合には、もちろん Figma のデータは存在しないため、今回のプラグインがあることで一気に効率が上がった。

Notion でブログを書き始めたけどすぐに続かなくなった

はてなブログ自体あまり書きやすくないなと思い、以前 Notion でブログを書くようにしたことがあった。 使い慣れていることもあり、書きやすさは断然 Notion なのだが続かない。 そもそも色々とセットアップするのがめんどくさいし、自由度が高い分やりたいことが色々と出てきて結局手につかない。 仕事で Notion を使うことが多い分、仕事との境目がなくなるというか、少し別のものを使いたい気持ちもある。

仕事で使っていなくてかつそこそこ使いやすいものと考えると、今なら note なんだろうなと思う。 ただ、note ってもう少しちゃんとしたものを書くようなイメージがあって、こんな自分用のメモをダラダラと書きにくい。 ここで好き勝手に書いてみて、考えがまとまったり綺麗にまとめたりするときに note を使うようにするのがちょうど良さそう。