<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://blog.taross-f.dev/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.taross-f.dev/" rel="alternate" type="text/html" /><updated>2026-05-09T14:26:34+00:00</updated><id>https://blog.taross-f.dev/feed.xml</id><title type="html">T=&amp;gt;</title><subtitle>日々 =&gt; メモ</subtitle><entry><title type="html">40歳、5年目、惑惑</title><link href="https://blog.taross-f.dev/four-years-and-forty/" rel="alternate" type="text/html" title="40歳、5年目、惑惑" /><published>2025-09-13T00:00:00+00:00</published><updated>2025-09-13T00:00:00+00:00</updated><id>https://blog.taross-f.dev/four-years-and-forty</id><content type="html" xml:base="https://blog.taross-f.dev/four-years-and-forty/"><![CDATA[<p>今月でPKSHA Technologyに入って4年が経つ。そしてもうすぐ40歳になる。節目感あるし現状のポエムを書いてみようと思う</p>

<p>入社して最初の2年は旧Bedore所属でAI HelpdeskチームでSWEとEMをやってて、その後グループ会社のPKSHA Communication(当時)に異動した。今は会社のカンパニー化にともないカンパニー執行役員として複数プロダクトのエンジニア職種を統括する立場で、管理対象人数は50人くらい。</p>

<p>シンプルにここ10年で一番仕事がしんどい</p>

<h2 id="これまでとは違う難しさ">これまでとは違う難しさ</h2>

<p>なんというか、これまでのSWE→EMの延長線上でない。何を求められているのか探るところから難しくて、手探りでやってる感じがずっと続いている。自分が何をすべきなのか、どこに価値を出せるのか、もやっとしている。</p>

<p>EMをやってた時は、チームのパフォーマンスを上げるとか、メンバーの成長を支援するとか、やることがわりと明確だった。でも今の役割は、複数のチーム、複数のプロダクト、そして50人という規模。単純に2倍、3倍のスケールじゃなくて、質的に全然違う</p>

<p>でも周りからの見え方とか期待値は確実に大きくなってて、うまくいかないと「残念だ」みたいな反応をされる。このギャップがまたしんどい。期待に応えたいけど、そもそも何に応えればいいのかがぼんやりしてる。</p>

<p>頑張ってることと成果が出ることは別だし、頑張りが評価される年齢でもないし。</p>

<p>一応テーマは持って進めていた(今期は採用･そのための技術広報を回す)し、それが進んだ結果にはなっていて1年前と比べたら見え方変わっていると思うが、まだまだこれからなのもあるし、結果が出ているとは言い難い。来期もまた違うテーマが見えてきていて、それはさらに難しいものに見えている</p>

<h2 id="強みとは">強みとは</h2>

<p>実は最近、自分の強みって何だったんだろうって考えることが増えた。エンジニアとしての技術力？マネジメント能力？コミュニケーション？正直、よくわからなくなってきている。これまで「なんとなくできてた」ことが、規模が大きくなって通用しなくなってきたのかもしれない。</p>

<p>AI Helpdeskの時は、技術的な判断もできるし、プロダクトの方向性も決められるし、メンバーのケアもできる、みたいな感じで動けてた。でも今は全部を見るなんて物理的に無理で、どこにフォーカスすべきかを決めないといけない。</p>

<p>そもそも、40歳で「自分の強みがわからない」って言ってるのもどうなんだろうと思うけど、たぶん今までは環境に恵まれてて、自分の強みを深く考えなくても何となくうまくいってたんだと思う。</p>

<h2 id="極端に振り切るという選択肢">極端に振り切るという選択肢</h2>

<p>いっそ極端に振り切ってみるのも手かなと思ったりする。例えば事業にめちゃくちゃ首突っ込んでビジネスサイドとガッツリやるとか、逆に自分はなるべくボールを渡していって、メンバーが動きやすい環境を作ることに徹するとか。中途半端が一番良くない気がしてる。</p>

<p>事業に首突っ込むパターンだと、プロダクトの数値とか売上とか、そういうところまで責任を持つ。エンジニア組織の話だけじゃなくて、ビジネス全体の中でエンジニアリングをどう活かすかを考える。これはこれで面白そうだけど、今まであまりやってこなかった領域だから学習コストは高く、効果があるのか説明も難しい</p>

<p>一方で、環境づくりに徹するパターン。採用とか評価制度とか、開発プロセスの整備とか、そういうところに集中する。直接的な成果は見えにくいけど、長期的には組織の基盤を作ることになる。ただ、これだと「で、ビジネスへの貢献は？」って聞かれた時に答えにくいし、今でもだいぶ遠いのに更に遠くなってよいのか</p>

<p>正直、どっちがいいのかわからない。でも、今みたいに中途半端な状態よりはマシな気がする。</p>

<h2 id="それでもやっていくしかない">それでもやっていくしかない</h2>

<p>まだ成果が出るイメージが持てなくてつらい。朝起きて「今日も頑張るか」って思うけど、会議に出て、1on1して、テキスト書いて、｢今日もなんとかなった｣ではだめ</p>

<p>たぶん1年後くらいに読み返したら「あの時はこんなこと考えてたんだな」って思うんだろう。その時には少しでも前に進んでいたい。というか、進んでいるはず。そう信じてやっていくしかない。この「わからない」状態こそが成長の前段階なのかもしれない。今まで通用してたやり方が通用しなくなって、新しいやり方を模索してる時期。</p>

<p>40歳、5年目。まだまだ人生も折り返し。不惑ではなく惑惑、これをワクワクに(?)</p>]]></content><author><name></name></author><category term="Poem" /><category term="Life" /><category term="Management" /><summary type="html"><![CDATA[今月でPKSHA Technologyに入って4年が経つ。そしてもうすぐ40歳になる。節目感あるし現状のポエムを書いてみようと思う]]></summary></entry><entry><title type="html">引用画像を作成するためのツールquottoをつくった</title><link href="https://blog.taross-f.dev/quotto/" rel="alternate" type="text/html" title="引用画像を作成するためのツールquottoをつくった" /><published>2025-07-15T00:00:00+00:00</published><updated>2025-07-15T00:00:00+00:00</updated><id>https://blog.taross-f.dev/quotto</id><content type="html" xml:base="https://blog.taross-f.dev/quotto/"><![CDATA[<p><a href="https://github.com/taross-f/quotto">quotto</a>というコマンドラインツールを作りました。</p>

<p>Kindle quoteみたいなノリでKindle以外の文章の引用画像を作成するためのツールです。おもにオライリーの電子書籍を引用するために自分は作ったのですが、汎用的に使えるようになっています。</p>

<h2 id="できること">できること</h2>

<p>e-reader風のシンプルなデザインで、美しい引用画像を生成できます。文章だけでなく、本のタイトルや著者名も含めて画像化できるのが特徴です。</p>

<p><img src="/images/quotto-sample.png" alt="quotto sample" /></p>

<h2 id="使い方">使い方</h2>

<h3 id="インストール">インストール</h3>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># グローバルインストール</span>
npm <span class="nb">install</span> <span class="nt">-g</span> quotto

<span class="c"># プロジェクト内にインストール</span>
npm <span class="nb">install </span>quotto
</code></pre></div></div>

<h3 id="基本的な使い方">基本的な使い方</h3>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># シンプルな引用</span>
quotto <span class="nt">--quote</span> <span class="s2">"偉大な仕事をする唯一の方法は、あなたがやっていることを愛することです。"</span>

<span class="c"># タイトルと著者付きの引用</span>
quotto <span class="se">\</span>
  <span class="nt">--quote</span> <span class="s2">"Stay hungry,</span><span class="se">\n</span><span class="s2">stay foolish."</span> <span class="se">\</span>
  <span class="nt">--title</span> <span class="s2">"Stanford Commencement Address"</span> <span class="se">\</span>
  <span class="nt">--author</span> <span class="s2">"Steve Jobs"</span>
</code></pre></div></div>

<h3 id="オプション">オプション</h3>

<ul>
  <li><code class="language-plaintext highlighter-rouge">--quote</code>: 引用文（必須）改行もサポート</li>
  <li><code class="language-plaintext highlighter-rouge">--title</code>: 本や記事のタイトル（任意）</li>
  <li><code class="language-plaintext highlighter-rouge">--author</code>: 著者名（任意）</li>
  <li><code class="language-plaintext highlighter-rouge">--output</code>: 出力ファイル名（任意、デフォルトはタイムスタンプベース）</li>
</ul>

<h2 id="技術的な話">技術的な話</h2>

<p>Claude Codeで100%Vibes Codingで作りました。Vibes CodingだとT3StackなどのTypeScriptベースで作っていくとうまくいきがちで、さらにCLIだと精度があがる印象ですね</p>

<p>オライリーの技術書から気に入った文章を引用する際に、きれいに画像化してシェアしたいというのが作成のきっかけでした。Kindleだと簡単に引用できるのですが、それ以外の電子書籍では同じようなことができないので、自分で作ってみました。</p>]]></content><author><name></name></author><category term="Tools" /><category term="CLI" /><category term="Node.js" /><summary type="html"><![CDATA[quottoというコマンドラインツールを作りました。]]></summary></entry><entry><title type="html">全体最適という幻想と、個別最適の衝突から生まれる本物</title><link href="https://blog.taross-f.dev/individual-optimization-creates-total-optimization/" rel="alternate" type="text/html" title="全体最適という幻想と、個別最適の衝突から生まれる本物" /><published>2025-07-06T00:00:00+00:00</published><updated>2025-07-06T00:00:00+00:00</updated><id>https://blog.taross-f.dev/individual-optimization-creates-total-optimization</id><content type="html" xml:base="https://blog.taross-f.dev/individual-optimization-creates-total-optimization/"><![CDATA[<p>「全体最適を考えて動いてください」</p>

<p>マネジメント層からよく聞くこの言葉。でも、正直なところ「それって具体的に何？」って思いませんか。</p>

<p>最近、自分でもよくわからなくなってミスったので、その反省を書きます。</p>

<h1 id="サッカーで考える全体最適の罠">サッカーで考える全体最適の罠</h1>

<p>まず例え話として、サッカーのボランチ（守備的ミッドフィルダー）の話をしましょう。</p>

<p>ボランチの選手が「チームの方針のことを考えて」守備重視でプレーしたとします。攻撃参加を控えて、ディフェンスラインの前でがっちり守る。一見、全体最適っぽいですよね。</p>

<p>でも結果はどうでしょう。</p>

<ul>
  <li>中盤の攻撃力が落ちる</li>
  <li>前線が孤立する</li>
  <li>得点チャンスが激減する</li>
  <li>結局、守備的なのに失点も防げない</li>
</ul>

<p>なぜこうなるのか。それは、ボランチが「想像上の全体最適」を追いかけたからです。</p>

<h1 id="個別最適の衝突が生む本当の最適解">個別最適の衝突が生む本当の最適解</h1>

<p>本来なら、こうあるべきでした：</p>

<ol>
  <li>ボランチ「俺は攻守のバランスを取りたい」</li>
  <li>センターバック「もっと前線をカバーしてくれ」</li>
  <li>オフェンシブMF「もっと前に出てきて欲しい」</li>
</ol>

<p>この「個別最適のぶつかり合い」から、議論が生まれます。そして監督（上位レイヤー）と擦り合わせた結果、「今日は相手が強いから守備7：攻撃3でいこう」といった<strong>具体的な</strong>全体最適が見えてくる。</p>

<p>エンジニアリングでも同じですよね。</p>

<ul>
  <li>フロントエンド「UXを最高にしたい」</li>
  <li>バックエンド「パフォーマンスを追求したい」</li>
  <li>インフラ「コストを抑えたい」</li>
</ul>

<p>この個別最適をぶつけ合って、初めて「今回のプロダクトではUX重視で、でもレスポンスは500ms以内」みたいな落とし所が見つかる。</p>

<h1 id="マネジメント層が陥りがちな罠">マネジメント層が陥りがちな罠</h1>

<p>「全体最適を考えて」と言いながら、実は抽象的な理想論を勝手に想像していませんか？</p>

<p>マネジメント層は確かに一つ上のレイヤーの優先度を意識する必要があります。でも、それに寄せすぎて個別最適を無視すると、チームは「で、結局何すればいいの？」状態になります。</p>

<p>大事なのは：</p>
<ol>
  <li>各メンバーの個別最適を引き出す</li>
  <li>それらを戦わせる場を作る</li>
  <li>上位の優先度と擦り合わせる</li>
  <li>具体的な行動指針に落とし込む</li>
</ol>

<p>この「議論を戦わせる」プロセスを飛ばして、いきなり全体最適を取りに行くから破綻するのかなと</p>

<h1 id="実装に落とし込むと">実装に落とし込むと</h1>

<p>コードレビューでもよくある話です。</p>

<p>「もっと全体のアーキテクチャを考えて」という抽象的なフィードバックより、「このモジュールの責務はXXだから、この処理は別モジュールに」という具体的な議論の方が建設的。</p>

<p>個別最適（各モジュールの責務）を明確にして、それらの関係性を議論することで、結果的に良いアーキテクチャ（全体最適）が生まれる。(ちょっと違うか…?)</p>

<h1 id="結論">結論</h1>

<p>つまり”全体最適”とは、個別最適の議論を戦わせる姿勢 + 結論を軌道修正してそれにコミットする動き ということ。全体最適は”目指すもの”じゃなくて”個別最適をぶつけあった結果として生まれるもの”。</p>

<p>個別最適を主張して、他の個別最適とぶつけて、上位レイヤーと擦り合わせる。このプロセスを大切にすることが、本当の全体最適への道なんじゃないでしょうか。</p>]]></content><author><name></name></author><category term="Management" /><category term="Poem" /><summary type="html"><![CDATA[「全体最適を考えて動いてください」]]></summary></entry><entry><title type="html">エンジニアパパ、育休2ヶ月のリアル</title><link href="https://blog.taross-f.dev/days-of-parental-leave/" rel="alternate" type="text/html" title="エンジニアパパ、育休2ヶ月のリアル" /><published>2025-06-12T00:00:00+00:00</published><updated>2025-06-12T00:00:00+00:00</updated><id>https://blog.taross-f.dev/days-of-parental-leave</id><content type="html" xml:base="https://blog.taross-f.dev/days-of-parental-leave/"><![CDATA[<p>「育休って実際どんな感じ？」</p>

<p>育休取得を予定されている人から何度も聞かれそうなこの質問。5月半ばに3人目が産まれて、エンジニアとして初めての育休(2ヶ月)を取得しました。正直、想像していたものとは全然違う日々を過ごしています。</p>

<p>この記事も、深夜2時赤ちゃんの寝息を確認しながら、一人カタカタとキーボードを叩いて書いています。</p>

<p>我が家の構成：妻、0歳女の子、保育園年中の次男、小学1年生の長男</p>

<h1 id="タイムスケジュールという名の戦場">タイムスケジュールという名の戦場</h1>

<p>「育休中ってなにやってるの？」という疑問を解くために、ある日のスケジュールを晒してみます。</p>

<p><strong>6:30</strong> 起床 → 上の子2人の朝ご飯準備。「今日のメニューは？」「またパンかよ」のやり取りから1日が始まる<br />
<strong>7:30</strong> 長男を登校班へ送る。
<strong>8:20</strong> 次男を保育園へ。「パパ、今日お迎え来る？」と毎日確認される<br />
<strong>9:00-12:00</strong> 束の間の自由時間…と思いきや、洗濯、掃除、役所への書類提出etc<br />
<strong>12:00-14:30</strong> 昼食後の昼寝タイム（これがないと夜まで持たない）<br />
<strong>14:30-16:00</strong> 長男の宿題バトル。音読を聞く作業がなぜか30分を超える
<strong>16:30</strong> 次男お迎え → 即お風呂 → 夕飯準備
<strong>18:00</strong> 家族でワイワイ夕食。この時間が一番にぎやか<br />
<strong>21:00</strong> 妻が上の子たちを寝かしつけ（そのまま一緒に寝落ち）<br />
<strong>21:00-3:00</strong> 赤ちゃんとの1対1。寝ていればPC作業もできるし、眠かったら無理せずに一緒にねる。寝ない日はもうあきらめてミルクあげたりオムツ変えたり。Audible聞いたりも<br />
<strong>3:00</strong> 妻とバトンタッチ。</p>

<p>もちろん、このスケジュールの間にも3時間おきのミルク、おむつ替え、泣き対応が割り込んできます。まさにマルチタスクの極み。</p>

<h1 id="俺役に立ってる問題">「俺、役に立ってる？」問題</h1>

<p>育休1週間目、ふと不安になって妻に聞いてしまいました。<br />
「育休とった意味、ありそう？」</p>

<p>妻の答えは意外とシンプルでした。<br />
「一人だったら、今頃倒れてる。特に上の子対応しなくてよいのは楽」</p>

<p>そうか、これを妻が一人でやっていたら…と想像すると、確かにゾッとします。</p>

<h1 id="折り返し地点で見えてきたもの">折り返し地点で見えてきたもの</h1>

<p>1ヶ月が経過。生活リズムは安定してきましたが、睡眠不足との戦いは続いています。連続3時間以上寝られた日は、まだ片手で数えられる程度。</p>

<p>そんな中でも、技術への興味は失っていません。Claude Codeが話題になっているのを見て、赤ちゃんが寝ている隙に触ってみたり。エンジニアの性ですね。</p>

<p>昼寝の質を上げるために<a href="https://amzn.to/442tsLW">CIOのUSB充電式アイマスク</a>を導入したのは、我ながらナイスな判断でした。15分の昼寝でも、しっかり暗くなると回復度が違います。</p>

<h2 id="チームの理解に救われる">チームの理解に救われる</h2>

<p>仕事面では、チームメンバーの理解と協力に本当に感謝しています。育休取得を伝えた時の「お互い様だから」という言葉。男女問わず育休が当たり前に取れる環境って、改めてすごいことだなと。</p>

<p>週に数回飛んでくるメンションにも、余裕を持って対応できています。完全に仕事から離れるのではなく、この程度の距離感がちょうどいい。</p>

<h2 id="燃え尽きからの回復">燃え尽きからの回復</h2>

<p>実は育休に入る前、仕事に対して少し燃え尽き気味でした。プロジェクトの山を越えて、次の目標が見えなくなっていたというか。</p>

<p>でも、この1ヶ月で少しずつエネルギーが戻ってきているのを感じます。子どもたちと過ごす時間が、意外なリフレッシュになっているのかもしれません。</p>

<h1 id="これからの1ヶ月">これからの1ヶ月</h1>

<p>長男が「パパ、最近家にいるね」と嬉しそうに言ってくれたり、次男が保育園で「うちのパパは赤ちゃんのお世話してる」と自慢してくれたり。赤ちゃんの様子も正確に説明できるくらい理解できているのは初めてです。</p>

<p>残り1ヶ月。きっとあっという間に過ぎていくでしょう。でも、この経験は確実に自分を変えてくれている気がします。</p>

<p>エンジニアとして、父親として、一人の人間として。<br />
育休は「休み」ではなく、改めて自分と家族を見つめ直す「修行」なのかもしれません。</p>]]></content><author><name></name></author><category term="Life" /><category term="Poem" /><summary type="html"><![CDATA[「育休って実際どんな感じ？」]]></summary></entry><entry><title type="html">HHKB Studioはじめました</title><link href="https://blog.taross-f.dev/hhkb-studio/" rel="alternate" type="text/html" title="HHKB Studioはじめました" /><published>2024-01-31T00:00:00+00:00</published><updated>2024-01-31T00:00:00+00:00</updated><id>https://blog.taross-f.dev/hhkb-studio</id><content type="html" xml:base="https://blog.taross-f.dev/hhkb-studio/"><![CDATA[<p>先週の入荷以降だいぶ安定して買えるようになったHHKB Studio、自分も買ってみたのでさんざんこすられてますが、3日ほど使った感想を書いてみます。JIS配列</p>

<h1 id="セットアップ">セットアップ</h1>

<p><img src="https://github.com/taross-f/taross-f.github.io/blob/master/images/hhkb.png?raw=true" alt="セットアップ" /></p>

<p>MacBookのキー配置と近づけるために英数とかなを2キーに割り当てしてます。前からやってるけどこれやらないとミスタッチしすぎてイライラしちゃうので</p>

<p>Gesture Padは以下のように設定</p>

<ul>
  <li>左
    <ul>
      <li>上: Ctrl+↑ (Mac側ショートカットをMissionControlにしておく)</li>
      <li>下: F11 (Mac側ショートカットをアプリケーションウィンドウにしておく)</li>
    </ul>
  </li>
  <li>左下: 左右スクロール</li>
  <li>右下: Ctrl+←→ (Mac側ショートカットをスペース切り替えにしておく)</li>
  <li>右: スクロール</li>
</ul>

<p>これは自分の使い方的にアプリケーションウィンドウをよく使うのと、全画面で開くZoomなりなんなりをスペース切り替えしたくなりそうでそのあたり入れてみました</p>

<p>が、感度最大にしても反応が悪いときが多くてつらくて使えてない…</p>

<p>ポインティングスティックは調整中だけどspeed2と3の間くらいにしてます。細かいところ動かしづらくなるもののぎりぎり許容できるくらいかなと</p>

<p>KarabinerでEmacs key bind入れてるんですが、一部うまく動かなくなっていてSetting &gt; DevicesのModify EventをONにしました。ただこれの弊害なのかわからないけどペーストするときの挙動がちょっとおかしくて2重にペーストされるときあるようで、なんらか環境の改善が必要そう</p>

<h1 id="感想">感想</h1>

<p>キータッチについては評判が良かったので現物触らずエイヤで買ってみて、打ち心地はかなり良かったです。キーストロークが浅いのがはじめだけ気になったけどすぐ慣れたし、音も静かでいい感じの音ですね(個人の見解)</p>

<p>ポインティングスティックはまだ慣れなくて、修行と思って使ってます。あとスティックとクリックを右手で同時に触ってると、これまで使ったことない筋肉使うのか手が疲れてくるので、クリック系左手にしようかと考えているものの、クリックしたつもりが⌘キー打ってたりするのでまだ慣れが必要ですね</p>

<p>見た目はこんな感じになっています。トラックパッドはまだしまえていないけどつい使ってしまうので少し離して置いてあるのがミソ(?)です</p>

<p><img src="https://github.com/taross-f/taross-f.github.io/blob/master/images/IMG_3745.jpg?raw=true" alt="見た目" /></p>

<p><a href="https://amzn.to/49jamCj">PFU キーボード HHKB Studio 日本語配列 (ポインティングスティック メカニカルキーボード)</a></p>

<p><a href="https://amzn.to/3SoG4qT">Crean リストレスト パームレスト 木製 クルミ材 キーボード用 腕置き 滑り止め付き おしゃれ (S 60鍵まで対応)</a></p>]]></content><author><name></name></author><category term="Life" /><category term="Environment" /><category term="HHKB" /><summary type="html"><![CDATA[先週の入荷以降だいぶ安定して買えるようになったHHKB Studio、自分も買ってみたのでさんざんこすられてますが、3日ほど使った感想を書いてみます。JIS配列]]></summary></entry><entry><title type="html">2023年振り返り</title><link href="https://blog.taross-f.dev/review2023/" rel="alternate" type="text/html" title="2023年振り返り" /><published>2023-12-31T00:00:00+00:00</published><updated>2023-12-31T00:00:00+00:00</updated><id>https://blog.taross-f.dev/review2023</id><content type="html" xml:base="https://blog.taross-f.dev/review2023/"><![CDATA[<p>2023年の振り返りをしようと思います</p>

<h1 id="仕事">仕事</h1>

<p>2023年は、特に技術分野において大きな変化があった年でしたね。OpenAIやLLM周辺の動向を追いつつ、ユースケースを適切に選択してプロダクトへの実装も進めてきました(おもにチームメンバーが)。3月時点でAzureOpenAIをプロダクトに実装していたので、相当早かったはず</p>

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">プロダクトへは弊チームのハイパー優秀なTechLeadが爆速実装してくれてました! 顧客にも早速使われ始めてて流れに乗れてる感ある😎 <a href="https://t.co/I1UoEYqMgb">https://t.co/I1UoEYqMgb</a></p>&mdash; 古屋 太郎 (@taross__f) <a href="https://twitter.com/taross__f/status/1636233333708566529?ref_src=twsrc%5Etfw">March 16, 2023</a></blockquote>
<script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<p>このタイミングでAIを事業の柱にしている弊社にいられたのは幸運だなあと思いました。またLLM絡みで登壇機会も複数いただけました。他のコミュニティで話した人でもあのときの講演見てましたよ、みたいなことを言われることもあったり</p>

<p><a href="https://blog.taross-f.dev/microsoft_build_japan/">Microsoft Build Japan2023に登壇した</a></p>

<p><a href="https://blog.taross-f.dev/saasonaws2023/">SaaS on AWS 2023に登壇した</a></p>

<p>後半はこれまで所属していたチームを異動し、別の子会社のPKSHA Communicationに出向して歴史の長いプロダクトとリリース直後のプロダクトそれぞれでEM的な業務をやっています</p>

<p>なかな大きなチャレンジで、全員初対面でバリューストリームも全然違う組織において課題を解決していかなければならず、まずじっくり観察するところから入って少し自分がいる意味が出てきたような状態ですね。ただこれは本当に難しくてこのロールで成果を出すってなんだっけ…という状態を週に何回か思い返して悩む状態を続けています。これまでのプロダクト開発SWEの延長上にあるマネジメントと異なる現状なので、アンラーンが必要で2024年もここできちんと成果なり自分の中で手応えが感じられるようにすることが個人の目標になるでしょう</p>

<p>これまでと視点を変えないといけない打席をもらえてると感じているので、ここは結果につなげていきたいですね</p>

<p>副業は去年一つ手伝いはじめたところ、うまくワークできずストップしてしまったりしました。すこしアドバイス的なこともしましたが、やはりスクラムチーム入らずにやっていくのは厳しいですね。ご迷惑をおかけしました…</p>

<p>また前職もほとんど何もやってない状態で契約だけずっとあったのでちゃんと契約終了として、今抱えている副業はゼロになり、手は空いています! ただ個人でいろいろやりたいこともあるので、あまり積極的に副業はやらないようにしていくつもりです</p>

<h1 id="生活">生活</h1>

<p>一番大きなできごとは妻の仕事復帰でした。上の子は幼稚園通っていましたが保育園に転園し、妻のシフトに合わせて日に応じて送り迎えをするスタイルになりました</p>

<p>幸運なことに子供二人とも徒歩5分の保育園に入園できてよかったです。そこがだめだったらチャリで15分みたいな園になってたので生活もだいぶ違ったはず</p>

<p>妻も5年ぶりの仕事復帰でいろいろ大変だと思いますがなんとかやれているようです。会社としても基本リモート+裁量労働+休み多めなので調整しやすくて助かっています。子供たちも保育園の洗礼(?)なのか半年くらいはやたら体調崩してましたが、だいぶ安定してきました</p>

<p>子供連れてフェスにも行けたし、旅行も気軽に行けるようになったしいろいろ楽しめるようになってきた感あります</p>

<p>趣味としては年初にコロナになったきっかけでUndertaleにハマったりしたおかげか、Undertale関連の音楽をよく聞いていたし、ピアノをちゃんと練習したくなって来ました。あとはティアキンやったり</p>

<h1 id="来年に向けて">来年に向けて</h1>

<p>仕事も個人の業務としては今年の大きな変化を受けてきちんと成果につなげていきたいですね。あとはいろいろな場所にも顔を出して、とくにコミュニティ活動みたいなの苦手なので、技術広報だったりコミュニケーションだったりするためにもアウトプットを重要と捉える1年にしていきたいと思いました</p>]]></content><author><name></name></author><category term="Life" /><category term="Poem" /><summary type="html"><![CDATA[2023年の振り返りをしようと思います]]></summary></entry><entry><title type="html">SaaS on AWS 2023に登壇した</title><link href="https://blog.taross-f.dev/saasonaws2023/" rel="alternate" type="text/html" title="SaaS on AWS 2023に登壇した" /><published>2023-11-04T00:00:00+00:00</published><updated>2023-11-04T00:00:00+00:00</updated><id>https://blog.taross-f.dev/saasonaws2023</id><content type="html" xml:base="https://blog.taross-f.dev/saasonaws2023/"><![CDATA[<p>先日AWSの方から会社にお声がけを頂き、<a href="https://aws.amazon.com/jp/blogs/news/saas-on-aws-2023-10-10-11/">SaaS on AWS 2023</a> というイベントに2023/10/11に登壇させていただきました</p>

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/95e364afca0c461baedf2cefa79a6266" title="SaaSにおける生成AI の実装とその未来" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

<p>社内のEmbeddingやRAG実装の事例を紹介しつつ、実は事例ごとに結構気にするところ違うんですよね、という話をしました。冒頭に生成AIの実プロダクトへの実装やられている方挙手してもらったら数人しかいなくて、弊社にいると当たり前のように実装事例あるんですがまだまだこれからやっていくところが多いんだなと改めて感じました。また今回は社内の事例を集めたので当事者でない情報も多かったですが、お客様含め協力的でとても助かりました。ありがとうございました</p>

<p>Ask the speakerではほとんど質問者は現れなかったのが少し悲しかったですが、AWSの方とガッツリ話せたので良しとします。あとは懇親会で出たビールがCOEDOビールメインで、ロジやられた方にとても親近感を覚えました</p>

<p>弊社は引き続きRAGだったりLLM関連技術を踏まえて社会実装しているのでご興味ある方はぜひ<a href="https://twitter.com/taross__f">DM</a>でご連絡ください。採用ページリンクは<a href="https://www.pkshatech.com/recruitment/">こちら</a></p>]]></content><author><name></name></author><category term="Meetup" /><summary type="html"><![CDATA[先日AWSの方から会社にお声がけを頂き、SaaS on AWS 2023 というイベントに2023/10/11に登壇させていただきました]]></summary></entry><entry><title type="html">Microsoft Build Japan2023に登壇した</title><link href="https://blog.taross-f.dev/microsoft_build_japan/" rel="alternate" type="text/html" title="Microsoft Build Japan2023に登壇した" /><published>2023-07-24T00:00:00+00:00</published><updated>2023-07-24T00:00:00+00:00</updated><id>https://blog.taross-f.dev/microsoft_build_japan</id><content type="html" xml:base="https://blog.taross-f.dev/microsoft_build_japan/"><![CDATA[<p><img src="https://raw.githubusercontent.com/taross-f/taross-f.github.io/master/images/_DRC5231.jpg" width="400" /></p>

<p>少し前ですが所属するチームでMicrosoft Teams上でのアプリケーションを開発していることもあってMicrosoftの方からお声がけを頂き、2023年6月27日Microsoft Build Japanで登壇しました。上記はめちゃくちゃそれっぽく撮影いただいた写真です。タイトルは、”Azure OpenAI Serviceを活用した AI SaaSプロダクト開発の実践”でした。プレゼンテーションの内容については、以下のリンクからご覧いただけます。</p>

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/c054d6e9d5dc4b619b538607c091e7c3" title="Azure OpenAI Serviceを活用した AI SaaSプロダクト開発の実践" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

<p>私の所属するチームでは、Azure OpenAI ServiceをAI SaaSプロダクトに組み込んでいます。登壇では、そのLLMのプロダクトへの実装に当たって考慮すべきポイントや注意すべき点について話しました。アンケートの内容も悪くなかったようですし、反響もすこしはいただけたのでよかったかなと思います</p>

<p>なお、久しぶりのリアル登壇であり、ピンマイクをつけての発表は初めての経験でした。その新鮮さと直前の機材トラブルからか逆に緊張がほぐれてたすかりました</p>

<p>現在私たちはLLM含めざまざまなアルゴリズムを組み込むプロダクト開発を進めています。この分野に興味がある方は、下記リンクから詳細をご覧いただけます。カジュアル面談もできますのでぜひご連絡ください</p>

<p><a href="https://aisaas.pkshatech.com/aihelpdesk/">AI Helpdesk LP</a>
<a href="https://www.pkshatech.com/recruitment/">リクルーティング情報</a></p>]]></content><author><name></name></author><category term="Meetup" /><summary type="html"><![CDATA[]]></summary></entry><entry><title type="html">ハッカソン実施時のChatGPT活用について</title><link href="https://blog.taross-f.dev/hackathon-chatgpt/" rel="alternate" type="text/html" title="ハッカソン実施時のChatGPT活用について" /><published>2023-04-28T00:00:00+00:00</published><updated>2023-04-28T00:00:00+00:00</updated><id>https://blog.taross-f.dev/hackathon-chatgpt</id><content type="html" xml:base="https://blog.taross-f.dev/hackathon-chatgpt/"><![CDATA[<p>最近とあるハッカソンに参加して、それをすすめるのにChatGPTに聞きながらやったらかなり楽だったのでメモ</p>

<h1 id="アイディア出しシート作成">アイディア出しシート作成</h1>

<p>プロンプト</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>2週間のハッカソンがあります

### テーマ
XXX
YYY
ZZZ

まずアイディア出しをしたいと思います。複数のメンバーがスプレッドシートにアイディアを書き込んでいきたいです。そのときのデータとしてカラムはどのようなものを用意するのがよいですか? テーブル表示してください
</code></pre></div></div>

<p>レスポンス</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>
以下に、アイディアをまとめるためのスプレッドシートのカラム例を示します。

| アイディアID | アイディア名 | 概要 | テーマ | 想定ユーザー | 使用技術 | 提案者 | 優先度 |
|-----------|-----------|-----|-----|---------|-------|-------|-------|
| 1         | 例: 質問箱Bot | 匿名で質問や悩みを共有できるSlackBot | XXX | 社員 | Slack API | 山田太郎 | 3     |
| 2         | 例: ペット写真共有アプリ | ペットの写真を共有できるWebアプリ | YYY | 社員 | Web開発技術 | 鈴木花子 | 2     |
| 3         | 例: スキル向上サポートシステム | スキル向上を支援するWebアプリ | ZZZ | 社員 | Web開発技術 | 佐藤一郎 | 1     |

このテーブルには、以下のカラムが含まれています。

1. アイディアID: アイディアを一意に識別するためのID
2. アイディア名: アイディアの名前
3. 概要: アイディアの概要説明
4. テーマ: アイディアが対象とするハッカソンのテーマ
5. 想定ユーザー: アイディアの対象ユーザー
6. 使用技術: アイディア実現に必要な技術やツール
7. 提案者: アイディアを提案したチームメンバーの名前
8. 優先度: アイディアの実現優先度（1が最高、3が最低）

チームメンバーは、このテーブルにアイディアを追加・編集し、ハッカソンのアイディア出しを効率的に行うことができます。
</code></pre></div></div>

<p>そのままスプレッドシートに貼れるの出てくるので便利ですね</p>

<h1 id="スケジュール">スケジュール</h1>

<p>プロンプト</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>次に2週間の期間をどのように使うと良いでしょうか? スケジュール例をあげてください。また情報が足りない部分は質問してください
</code></pre></div></div>

<p>レスポンス</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>2週間のハッカソンスケジュール例を以下に示します。ただし、実際のスケジュールはチームのスキル、アイディアの複雑さ、リソースの可用性に応じて変更する必要があります。

### 週1
- **Day 1: オリエンテーション・アイデア出し**
  - チームビルディング・役割分担
  - アイディア出し・スプレッドシート作成
  - アイディアの優先順位付け・選定

- **Day 2-3: 設計・プランニング**
  - アイディアに基づくプロジェクト計画の作成
  - タスク分解・担当者割り当て
  - プロトタイプ設計・技術選定

- **Day 4-6: 開発・実装**
  - 各メンバーが担当タスクに取り組み
  - 定期的な進捗報告・課題共有
  - 必要に応じてリソースの調整・問題解決

### 週2
- **Day 7-10: 開発・実装（続き）**
  - 各メンバーが担当タスクに取り組み
  - 定期的な進捗報告・課題共有
  - 必要に応じてリソースの調整・問題解決

- **Day 11-12: テスト・デバッグ**
  - 実装された機能のテスト・デバッグ
  - ユーザビリティテスト・改善提案
  - 不具合修正・機能改善

- **Day 13: ドキュメント作成・プレゼン準備**
  - プロジェクトのドキュメント作成
  - 成果物のデモンストレーション準備
  - プレゼンテーションのリハーサル

- **Day 14: 成果発表・デモ**
  - 各チームの成果発表・デモンストレーション
  - フィードバック受け取り・質疑応答
  - ハッカソンの結果発表・表彰

上記のスケジュールは一例ですが、ハッカソンの目的やチームの状況に応じて、柔軟にスケジュールを調整してください。また、進捗状況や問題に応じて適宜コミュニケーションを行い、チーム全体で情報共有や問題解決を進めることが重要です。以下に、ハッカソンを成功させるためのいくつかのポイントを挙げます。

1. **コミュニケーション**: チーム内でのコミュニケーションを円滑にするため、定期的なミーティングやチャットツールを活用して情報共有を行いましょう。また、随時相談や質問ができる環境を作ることも大切です。

2. **タスク管理**: タスク管理ツールを使用して、各メンバーの進捗状況や担当タスクを可視化しましょう。これにより、チーム全体の進捗が把握しやすくなり、問題が発生した場合に迅速に対応できます。

3. **フィードバック**: プロジェクトが進行する中で、他のメンバーからフィードバックや意見を求めることで、アイディアや実装の改善につながります。柔軟な姿勢でフィードバックを受け入れ、改善に取り組みましょう。

4. **タイムマネジメント**: 2週間という短い期間内でプロジェクトを完了させるため、タイムマネジメントが重要です。進捗状況を確認し、必要に応じてタスクの優先順位を調整することで、効率的な作業が可能になります。

5. **デモ・プレゼンテーション**: ハッカソンの最終日には、成果物のデモンストレーションやプレゼンテーションが行われます。事前にリハーサルを行い、プレゼンテーションの内容やデモの手順を確認しておくことで、スムーズな発表ができます。

上記のポイントを押さえつつ、チーム一丸となってハッカソンに取り組むことで、有意義な成果物が生まれることでしょう。プロジェクトの進行に合わせてスケジュールを調整し、効率的に作業を進めてください。

</code></pre></div></div>

<p>スケジュールだけじゃなくポイントまで教えてくれる</p>

<h1 id="mtgアジェンダ">MTGアジェンダ</h1>

<p>プロンプト</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ハッカソンのキックオフミーティングを1時間で行います

上記のDay2-3の部分までをできるところまで進めたいです

会議のアジェンダ:
</code></pre></div></div>

<p>レスポンス</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>1時間のキックオフミーティングでDay 2-3の内容まで進めるためのアジェンダを以下に示します。

1. **開会の挨拶 (5分)**
   - ミーティングの目的説明
   - 参加者自己紹介

2. **アイディアの共有・選定 (15分)**
   - スプレッドシートにまとめられたアイディアの概要説明
   - チームメンバーからの質問・意見交換
   - 投票や議論を経て、最終的なアイディアの選定

3. **プロジェクト計画・設計 (20分)**
   - 選定されたアイディアに基づいたプロジェクトの目標・スコープ設定
   - プロトタイプの設計、使用技術の選定
   - タスク分解・担当者割り当ての検討

4. **役割分担・リソース確認 (10分)**
   - チームメンバーの役割分担（プロジェクトマネージャー、デザイナー、開発者など）
   - 必要なリソース（ツール、データ、API等）の確認と手配

5. **タスク管理ツール・コミュニケーションツールの設定 (5分)**
   - タスク管理ツール（例: Trello, Asana）の設定・導入
   - コミュニケーションツール（例: Slack, Microsoft Teams）の設定・導入

6. **ハッカソン期間中のミーティングスケジュール決定 (3分)**
   - 定期的な進捗報告・課題共有のためのミーティングスケジュール設定
   - その他必要なミーティング（例: デザインレビュー、技術検討会）のスケジュール設定

7. **質疑応答・その他連絡事項 (2分)**
   - チームメンバーからの質問・疑問解消
   - その他連絡事項や注意点の共有

</code></pre></div></div>

<h1 id="まとめ">まとめ</h1>

<p>自分が考えるまえにこの手のとりあえずなにか日本語作る系の作業は、ひとまずChatGPTに聞く一択ですね</p>]]></content><author><name></name></author><category term="ChatGPT" /><summary type="html"><![CDATA[最近とあるハッカソンに参加して、それをすすめるのにChatGPTに聞きながらやったらかなり楽だったのでメモ]]></summary></entry><entry><title type="html">Next.jsアプリケーションをCDNで効率的に配信する方法</title><link href="https://blog.taross-f.dev/nextjs-vercel/" rel="alternate" type="text/html" title="Next.jsアプリケーションをCDNで効率的に配信する方法" /><published>2023-04-23T00:00:00+00:00</published><updated>2023-04-23T00:00:00+00:00</updated><id>https://blog.taross-f.dev/nextjs-vercel</id><content type="html" xml:base="https://blog.taross-f.dev/nextjs-vercel/"><![CDATA[<p>Next.jsはReactアプリケーションを構築するための非常に強力なフレームワークです。Next.jsアプリケーションをCDN（Content Delivery Network）を使って配信することで、パフォーマンスと可用性を向上させることができます。この記事では、Next.jsアプリケーションをCDNで効率的に動かす方法を紹介します。</p>

<h1 id="なぜcdnを使うのか">なぜCDNを使うのか？</h1>
<p>CDNは、ウェブサイトやアプリケーションのコンテンツを効率的に配信するためのネットワークです。CDNを利用することで、以下のような利点が得られます。</p>

<ul>
  <li>レイテンシの低減: ユーザーに近いデータセンターからコンテンツが配信されるため、レイテンシが低くなります。</li>
  <li>パフォーマンスの向上: キャッシュを活用してサーバーへの負荷を減らし、コンテンツの配信速度を向上させます。</li>
  <li>可用性の向上: 複数のデータセンターにコンテンツを分散させることで、障害時でもサービスが利用可能な状態を維持できます。</li>
</ul>

<h1 id="vercelを使ったnextjsアプリケーションのcdn配信">Vercelを使ったNext.jsアプリケーションのCDN配信</h1>
<p>Vercelは、Next.jsアプリケーションを簡単にCDNで配信できるプラットフォームです。以下の手順でNext.jsアプリケーションをVercelでデプロイし、CDNを利用して配信することができます。</p>

<ol>
  <li>
    <p>Vercelアカウントの作成
まず、Vercelの公式サイトにアクセスしてアカウントを作成します。</p>
  </li>
  <li>Vercel CLIのインストール
Vercel CLIをインストールすることで、ローカル環境からVercelにデプロイできます。次のコマンドでVercel CLIをインストールします。
    <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>npm i -g vercel
</code></pre></div>    </div>
  </li>
  <li>Vercel CLIでログイン
インストールが完了したら、次のコマンドでVercel CLIにログインします。
    <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>vercel login
</code></pre></div>    </div>
  </li>
  <li>Next.jsアプリケーションのデプロイ
Next.jsアプリケーションのルートディレクトリに移動し、次のコマンドを実行してアプリケーションをデプロイします。
    <div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>vercel
</code></pre></div>    </div>
    <p>初めてデプロイする場合、Vercel CLIはいくつかの設定を尋ねます。適切なオプションを選択して進めてください。デプロイが完了すると、アプリケーションのURLが表示されます。</p>
  </li>
  <li>カスタムドメインの設定（オプション）
Vercelでは、カスタムドメインを設定してアプリケーションを配信することもできます。Vercelのダッシュボードでプロジェクトに移動し、「Settings」タブの「Domains」セクションでカスタムドメインを追加してください。ドメインのDNS設定を更新し、VercelのCDNに対応させます。</li>
</ol>

<h1 id="まとめ">まとめ</h1>
<p>Next.jsアプリケーションをCDNで配信することで、レイテンシの低減、パフォーマンスの向上、および可用性の向上を実現できます。Vercelを使用してNext.jsアプリケーションを簡単にデプロイし、CDNで効率的に配信できます。これで、Next.jsアプリケーションをCDNを利用して最適化された方法で配信することができます。</p>

<p>この記事はChatGPTで生成しました</p>]]></content><author><name></name></author><category term="Next.js" /><category term="Vercel" /><category term="ChatGPT" /><summary type="html"><![CDATA[Next.jsはReactアプリケーションを構築するための非常に強力なフレームワークです。Next.jsアプリケーションをCDN（Content Delivery Network）を使って配信することで、パフォーマンスと可用性を向上させることができます。この記事では、Next.jsアプリケーションをCDNで効率的に動かす方法を紹介します。]]></summary></entry></feed>