Helpfeel Tech Conf 2024 午後の部
13:20-14:00 Helpfeel開発部のいまと未来2024
去年ハッカー集団を目指すといったらしい
その話もする
ハッカー (Helpfeel Inc.)=テクノロジー&アート&デザイン&クラフト
テクノロジー
知識を実用する
社会実装し、世の中に作用する
アート
美しさ
UIの美しさ、インターフェースの美しさ
美しさも気にしてるんだ
情熱、ひらめき、共感
デザイン
自分たちの課題から抽象化して物事を捉える
突破するデザイン: あふれるビジョンから最高のヒットをつくるという本を思い出した。
定石のしゅはり
俯瞰
クラフト
バウハウス宣言より
「私AだからXには関わらない」と壁をつくるのではなく、一緒に作っていく
高い職業倫理
おおむね維持できている
個人開発やっている人が多い
未踏関係者が多い
プロダクトエンジニアの発見
いままでフルスタックエンジニアの求人を出していたが、違和感があった
複数領域の専門性を高めてプロダクト開発
生成AIを軸に新しいプロダクトや機能を生み出す
外部環境による変化への対応がキー
外部環境：社内外のステークホルダーの増加
ユーザーの増加
インフラ規模が巨大
株主の増加
従業員の変化
Nota Tech Conf 2022の時は21人しかいなかった
今は185人
指数関数的に増加している
増加するステークホルダーという課題にふまえて、責任を果たすハッカー集団を目指す
これがプロダクト開発3本の矢
もともとは株主への説明のために作った図
開発者自身が3つの視点を持つ
1. ソリューション新規開発
開発者が経営者の帽子をかぶる
組織として何に貢献したいか
「仮想通貨のスキャルピングに人生を賭けていないのはなぜですか？」の答え
顧客要望の実現化
開発者が顧客の帽子をかぶる
素人発想玄人実行
ビルドトラップを避ける
自分が使っていないものを想像できない
例：アクティブディレクトリを使っていないから、対応できません
プロダクトの磨き上げ
開発者が開発者の帽子をかぶる
専門性から生まれる気づきでプロダクトを改善する
UI/UX向上
ほとんどのユーザーは指摘せずサイレント離脱する
これよくいわれてそうなことだ
仮に指摘したとしても、それはほとんど間違っている
セキュリティ対策
ユーザーは問題が起きるまで気づかない
バグ修正もしっかり
これら3つの視点を全部もつ
どうするか
各領域にリーダーを置く？
領域ごとの型化？
これらがどうなったか、来年紹介する
補足：現実と恋に落ちる
制約と限界のなかでベストを尽くすことから始める
from プロダクトマネージャーのしごと
フレームワークやモデルは有用なフィクション
現実から有用なフィクションを取り出して試す
現在の開発部
Augmented Humanもさんが考えた
ただこれはAIを否定している企業と捉えられてしまうことがあったので、新しいコンセプトを作った
リソースに偏りがある
scrapboxがほとんどいない
Gyazo
500TB～600TB/月を越える大規模インフラ
マルチプラットフォーム対応
VisionProにも対応している
Scrapbox
1500万ページ突破
プロダクトサイクル
Gyazo: 成熟期
次のグロースを模索
海外ユーザーがほとんどなので、円安の影響をモロに受ける
Cosense: 導入期
PMF前夜
まだ導入期だったんだ
Helpfee: 成長期
事業成長の途中
コーポレートIT
上場するために体制を強化している
上場目指してるの知らなかった
昔
Nota Inc.は米国法人だった
Helpfeel Inc.で日本法人にした
Nota Tech Conf 2022だけオンライン
スクボ使わなくなったのは残念に思う
大規模化、電源が足りないなど問題がある
検討はしてるみたい
プロダクト開発三本の矢
13:59:25 おわり
14:00-14:20 休憩
歩き回るもののあまりはなせず
挙動不審と化している
14:20-14:40 Cosenseへのリブランディングについて語ります 
ben akikoy yado
>Cosenseのリブランディングの紆余曲折や外部パートナーとの協力、社名・ロゴの意味、ブランディングの進め方について深く掘り下げ、Cosenseの哲学に触れる
今日はけっこうCosenseの話してる
名前「Cosense」は
さんが発案した
3000件くらい考えて、そこから絞り込んだ？
最初はcosenseは候補になかったらしい
もう一度考え直したときの候補にcosenseが入っていた？
有力だった他の候補
「CoAhead」？
「いきなり1案に決めました」よりも「3案くらい出して絞り込み」
いきなり1案はうまくいかない。
3回くらいコンサルティング会社に出してもらったがしっくりこない
絶望感
そのあとbenさんから提案がきた
それも数回繰り返し、ようやくcosenseが出てきた
嫌いだったから変えたわけではない
かなり強調してる
Nota社名変更よりScrapboxがCosenseに名称変更のほうがはるかに大変だった
社名変更は「やるぞ！」って感じ
scrapbox変更は「やるのか……？」という感じ
名前が決まってからロゴ作成を開始
"table:cosenseはロゴ決定後か
ロゴが全く決まらなかった
ギリギリのギリギリ
アイコン記法で投票するが、みんな空気を読んでこっちに投票とかしない
それ自体はいい雰囲気だと思う
最終的に合意できたのは奇跡っぽいな
Cosense裏話おもしろい
リブランディングに込めた思い
組織でも使ってほしいという願いを込めてcosenseとした
14:40-15:00 A デザインとデータで貢献する - 売上向上のためのデザイン施策 takeru
>デザインとデータの組み合わせが売上向上にどう貢献するかを具体的な事例と共に紹介し、デザイナーがデータを活用する重要性を強調。デザイナーがデータを活用する際の具体的な手法やツール、成功事例を紹介
デザインの本質はコミュニケーションなので、成果の確認は大切である。
現在Gyazoチームは20件の短期的な売上向上施策を実施中（開発中のものも含む）
そのうち3分の1は成果が出ている。
GyazoのWebAppのメニューが時々変わっているのはこれのためだったのか。種明かし感！
課題の見つけ方
2種類のデータを両方見る。それを習慣化する。
定量データ
大きなKPI（AU、UP数）、小さなKPI（各施策や機能からのCV）を毎週確認している。
定性データ
定量データの裏には定性データがあるので、定性データを見ることで課題を見つけられるし、説得力にも繋がる。
Gyazoでの実例
課題
無料トライアルを経験したユーザーは、しなかったユーザーよりもProに転換しやすい。
なので、Gyazoチームとしては無料トライアルをオンにして欲しいが、オンにしてくれる人が少ない。
原因
ヘルプのトラヒックを分析したら、無料トライアルは課金されると勘違いされていることがわかった。
解決策
無料トライアル誘導の文言を改善
Gyazo proに無料トライアルあるの知らなかった
良い施策の3要素：どれか一つでも欠けると失敗してしまう。
1. どれくらいの効果を見込めるか
2. 実装コスト
3. ユーザー目線：例えばバナーを出しまくったりするのは、ユーザーのことを考えていないということ。
Chrome拡張機能のUIにProへの誘導を付けたが、ほとんどProになってくれるユーザーはいなかった。
こちら側からの一方的な情報提供だから失敗。
Gyazoアプリの設定画面にProへの誘導を付けたら、Pro購入数が15% UP
設定画面でGyazo GIFの録画時間を伸ばそうとして諦める人がいることがわかったから実施。
ユーザーが求めている物に対するアプローチなので成功。
効果測定
効果測定をしない施策はやらない方がマシ
ポイント
提案時点で成功とリスクの指標をはっきりさせる。
施策単位の指標を計測する。
施策単位で成功失敗がわかる。
14:40-15:00 B Gyazo 開発 Platform Engineering hiroshi
>Gyazo 開発/運用の歴史をざっと振り返り、実践的な細かい TIPS みたいなのを紹介します。現場の雰囲気が伝われば幸いです。
14:43:31 聞いてる
Gyazoの歴史
2007年に
さんが個人サーバーで開始
perl→PHP→Rails&Go→GKE&Docker
今はほとんどGKEで済んでいる
gyazo.comがRails
i.gyazo.comがGo
gyazoのplatform engineering
CI/CDの話がほとんどだ
なじみない世界なので、用語があんまりわからない
version更新を自動でやる設定など
one-off bachの処理
background jobにすると便利
自分が使わないもののユーザーがほしいものを想像するのが苦手
Cosense/Gyazoは自分で使っているから、こういう開発支援はモチベあがる
>アクセシビリティを1年間取り組んだ成果と未来への展望を共有。最近の活動や成果を総覧的に語る。
1年経ってたのか。1年って早い……。
15:05:43 見てる
やっていないとコンペで負ける
やったほうがいいから、やらないと死ぬ時代になった
エンタープライズ対象のプロダクトだとアクセシビリティが必然視されるから始まったのだろうか……
じゃないらしい。↑は社内でアクセシビリティの取り組みを広げるためのモチベーションであり、
さんとしてはやりたい気持ちを持ち続けていた。
目指すところ
当たり前を当たり前に実装したい
次のメガネを作る
キーワード
ボトムアップ
関心のあるメンバー間の取り組みから初めて、広げていく
越境
エンジニアだけに閉じていては限界がある
デザイナー、マーケターetc.にアクセシブルに
サービスにたどり着くためのアクセシビリティが必要だから。
ブログ、プレスリリース、展示会に出すアセット、タクシーのCM、営業資料、……のアクセシビリティ
実際にやったこと
勉強会
freeeやsmartHRが資料を公開している
ここにも勉強会資料として社内Cosenseのキャプチャが登場
視覚特性のエミュレーション機能がchromeにある
サービスLP観察会
勉強会をきっかけに開催
デザイナーと一緒に開催
Lighthouseってアクセシビリティのためのやつなんだ
なんの機能か今まで知らなかった
パフォーマンスやSEOも測れますね。
「Helpfeelオレンジを使うとコントラスト比確保が難しい」
ブランティング側にとっては言葉にできないもどかしさだろうな……
a11y作業DAY
pastakさんが作業通話
アクセシビリティ作業を1日中たれ流す
改善PRの提案
<a>と<button>の使い分け
ランドまークロールの改善
モーダル関連のフォーカス改善
アクセシビリティオフィスアワー
a11yDayは長丁場で大変だったので、2週間に1回、1時間程度にした
アクセシビリティ改善ニュース
今は停滞中
毎月出そうとすると、毎月機能更新を実装しなければならない
課題
アクセシビリティオフィスアワー以外の施策がなかなか継続しない
関心がある人とそれ以外の人の格差を埋めていきたい
アクセシビリティに限らず難しい。
ボトムアップの限界？
アクセシビリティに関する知の高速道路を作りたい
継続性と組織とのすりあわせが課題
cosenseは独自UIだからなあ
SaaSが社会のアクセシビリティを上げることに貢献するという考え方とてもいい。
>リバースプロキシを自力で運用するのは難しい。既存のアーキテクチャを把握しながら、リバースプロキシを剥がしていく過程を解説。トラブル対応やSEOなどへの影響を事前に検討した。
15:20-15:40 休憩
2人でshokaiさんのところにいく
二人なら怖くない
Cosense独自のページ内検索UIのことを聞く
まさかの布石だった
もともとページ内検索だけで済ますつもりはなく、いろいろ揃ってきたので実装し始めた
15:40-16:00 A Helpfeelの要望管理を支える技術 niboshi
>AsanaとCosenseの同期周りを掘り下げ、リリース周知待ちの運用などを紹介
Helpfeelには顧客から要望が来る。
「ExcelでHelpfeelのデータを管理したい」「動画のサムネを0秒時点にしたい（ほぼ原文ママ）」などが来る。
なぜ要望管理をするのか
優先度をつけたい、……
要望管理で何を把握したいのか？
プロジェクトマネジメント観点では、
担当者、状況、予実管理、優先度
各要望に属性を付与したり、フィルタ、ソート、グルーピングして管理している。
プロダクトマネジメント観点では、
ニーズの高い要望、要望の背景、……
要望の周辺知識が欲しい。
事例-要望-解決策は多対多で紐づいている（知識のネットワーク）。
アイデアというのは複数の問題を一気に解決するものであるの背景にありそうな考え方。
「バックログツールでは知識ネットワークを作れないので、これをやるためにCosenseを使う」
Cosense出てくると思ったら出てきた。
PjMとPdMで視点が違うっていうことが明文化されている！
CosenseとAsanaの連携をどうやっているのか？
niboshiさんがCosenseSyncerというツールを作っていて、CosenseのJSONをAsanaに流している。
この同期を取る仕掛けは面白そう
Asanaにはメモを一切書かず、Cosenseに書くとAsanaにCosenseのURLが出るなど
15:40-16:00 B 自律的な開発と部署間連携 balar
>部署間の壁を越えて社内の業務改善ツールを作った話。課題や問題点を把握するために取り組んだ事や優先度付けの考え方などを話します。
例：Helpfeel記法展開ツール
今まではserverにdeployしてから確認していた
別部署の社内定例に顔を出す
課題の発見よりも、業務内容を知ることが目的
議事録にコメントを書く
要望や困りことはページに切り出して、開発部にすぐ投げれるようにする
入社して数ヶ月たった人と話す機会を作る
どういうところで苦労したか、時間がかかったか聞く
ツールを限定せずにざっくり聞く
どうなると解決になるか一緒に考える
要望をそのまま解決しない
要望の背景を探す
リリースした機能を実際に触ってもらう場を作る
改善をゴールにしない
業務で利用する前に一度経験してもらう
課題の優先付け
どこからやるか
簡単なものから、ではない
判断の基準
performanceをのばすもの
あると便利なもの
github copilotが使える状況など
performanceを下げているもの
ないと困るもの
例：メモ帳で開発しなければならない状況
performanceを下げているものを優先して解決する
本来の業務とは違うところで時間をかけることを、困ることを減らしたい
本質的なことに集中させたいということか
16:00-16:20 A Helpfeel開発チームのオンボーディング yado
>フルリモート＆ドキュメント文化のHelpfeel社において、Helpfeel開発チームが実践しているオンボーディングの取り組みを紹介
新しいタスクを実施するまでのオンボーディング
フルリモートでオンボーディング
はじめは、Google Meetを使って口頭で
雑談も交えて、互いのパーソナリティを知るチャンスと捉えている
1. 情報の調べ方・書き方を学ぶ
必要な情報はCosenseにある
どうやってしらべたらよいのかを学んでもらう
全員で情報共有をするという意識を持ってもらう
MTG 中に話したことをドキュメントに残す練習
2. 開発環境の構築
ドキュメント化されている
「これは導入してください」「あとは好きにしてください」がはっきりしている
3. 各主要機能について概要を理解する
知らない用語が多すぎる問題
主要機能についてざっくり説明していく
各機能のCosenseのリンクがあるのでいつでも思い出せる
4. 各主要環境の設定をローカル環境で行う
特に重要な機能についてはローカル環境で動かす
手を動かすことで
5. 本番環境に自分用のデモプロジェクトを作る
顧客提供前の機能を本番環境で確認
閲覧には必ず認証をかける
オンボーディングもドッグフーディング
情報のアップデートを新メンバーと一緒に随時行う
「あぁこれ古くなっているわ」という部分を、画面見ながら一緒に改善できるのっていいよなぁ
PowerPointとかExcelだと後で直すになってしまう
オンボーディングツールと日常業務で使っているツールが同じ
16:00-16:20 B Cosenseチームでの開発の進め方 ohnishi
>Translation modeの開発やCosense開発チームの具体例を紹介。開発人数や担当範囲、意思決定の背景などを明らかに
2024-01からは3人体制
shokai,balar, ohnishi
7月にインターンが1人
開発の特徴
相互レビューなし
他の人のは
さんがレビューする
理由:
どういうことなの..
内部実装の知識が少ないというのもある
ピアレビューをしない・ピアレビューをしなくてもうまく回る
writeとpreviewを行き来するのが苦手
scrapboxが使えなくなった時のためにPR本体にも説明は書くが、3倍くらい時間がかかる
単体で意味が分かるように書き直すため
開発の具体例
改善
全文検索翻訳結果は、そのまま下に表示していた
しかし、概要が長いとぱっと見わかりづらい
色々試す
本文と翻訳文を交互に表示
本文の最後に翻訳文
✅本文を全部改行し、その下にそれぞれ翻訳文を入れる
意外とどのパターンでもうまくいった。
うまくいかなかったこと
QuickSearchの翻訳
そこもやるんかい！徹底してるなぁ
むずかしそうだなあ
じっさい、本文の翻訳だけでもかなりガクガクしてる
「Helpfeel社内のプロジェクト（9万件）で試したらDeepL API ProのQuotaを突破」
草
ガクガクってようはスクロール速度が不連続ってことだよね
スムーズにスクロールできればいいのかな
DeepLのAPIからのレスポンスが返ってきた順に訳文を入れると、項目の高さが変わるから（空けておくという手もありそうだが）
実際cosenseは文字での説明がほとんど
そういえばPopupMenuもそうだ
ちなみに自分がアイコンを使っているのは、スペース削減が目的
16:14:21 あれさんかな
タイプのタイミングで気づいた
昼くらいからずっとこのページに張り付いてます
いいはなし
テンプレ構成に従わなくてもいい
この考え方好き。
一旦型にはめてみて、「これ要らんのでは」と思ったらはずしてみてもいいのではないか
nextで勝手にdirectoryが作られたり、index.tsが作られたりするやつ
下手にテンプレ使うと、根幹がどうなってるかわからず混乱する
注：cosenseが小規模というのもある
ユーザーに悪影響がない部分はどんどん失敗したほうがいい。
手戻りを恐れるなに通づる
めっちゃよかった
16:20-16:40 A Helpfeelでの新しいプロダクトの生み方と育て方
>新しいプロダクトが生まれる瞬間や育て方、エンジニアドリブンでPMF成功したプロダクト開発の秘話、研究と顧客ニーズに焦点を当てた話
Helpfeelの説明
Helpfeel社で新しいプロダクトが生まれる瞬間
Helpfeelは展開ヘルプにCosenseを組み合わせたもの。
ドッグフーディング
開発現場でのニーズの発見
新機能を提案できるエンジニアになるために、
PMFできる領域を探す。専門領域に向き合う。
試作検証を繰り返す
並行して新技術にもキャッチアップする
……
需要だけを狙って作る感じじゃなくて、自分の技術を需要に合わせるという作り方が面白い機能に繋がるんだろうなぁ……。
任天堂っぽさを感じる。
お問い合わせフォームと分析機能
問い合わせの分析までをセットで作り込んでいるのがよさそう
件数の推移を可視化して減少を確認
検索ボリュームの確認
「TFIDFベースで重み付け」
これはクライアントサイドとサーバーサイドのどちらでやっているのだろう？
インクリメンタル検索
文章の後ろに重きをおいて、話題の遷移に対応する
ユーザーマニュアル検索
「工業製品のPDFマニュアルを検索したい」という要望から
ナレッジの有効活用：PDFは綺麗に作り込まれているのでそのまま使う。
思い切っている。ついついテキスト化したくなってしまう。
補足的なFAQをPDFではなくCosenseに書ける。
あまりイメージできなかったのだが、Cosenseの検索結果にPDFの内容も含まれるという感じなのだろうか
研究中の開発ソリューション
質問文生成
FAQドラフト生成
頻出トピック抽出
全文意図予測検索：「ドキュメントさえあればすぐに検索可能になる」を目指したい。
NotebookLMのようなものを連想するが、展開ヘルプ+Cosenseというモデルならではのできる部分もあるのだろうか？
16:20-16:40 B 地球規模で考えるプロジェクト管理 nishiyama
>地球規模のプロジェクトにおけるマネージャーの重要性と役割、歴史的なプロジェクト事例、Gyazoでの活動内容を紹介
壮大な話がはじまりそう
プロジェクト管理はソフトウェアに限定されない
大規模建設工事
地球温暖化対策
SDGs
プロジェクト管理の対象のスケールに制限はない
有給をとって台湾一周プロジェクトした
アジェンダ
事例研究：ギザの大ピラミッド
プロジェクト管理のさきがけ(おそらく)
こうかいぶんしょのメレルの日誌に着目
現代で言う現場監督の業務日誌
地球規模のプロジェクトは、成果物が数千年にわたって残る
時間や人数の管理が必要
そのツールが業務日誌だった
業務日誌とtodoリスト
日誌をつける目的：進捗管理
後追いのTODOということ
一番シンプルなのがGTD
gyazoのタスク管理
何を使っているかよりも、継続して繰り返し確認することが大事
「継続して繰り返し確認できるか」さえ担保できれば、ツールなんてなんでもいい
ここ大事だと感じた
yes
僕は「自分が書いたテキスト」の確認でも継続できるのでそれでいい
大半の人はその程度では耐えられないようだ
ここまで
プロジェクト管理の第一段階は頭の中を文書に固定すること
頭の中にあるものを外に出すを別の解釈でとらえたもの
こうかんがえて収集してみるのもよさそうだ
現在地を把握するために外に出す
事例研究
イギリス東インド会社
ワンピース
ナミはなんの役割をしていた？
航海士の役割を果たした
現在地の特定
今どこにいるかを決める
航海計画策定
これからどうするかを決める
トラブル対処
ここまでのまとめ
航海士の仕事は、間違った方向に進むのを避けること
北極星以外の方向に進むのを避ける
事例
プレスリリースを目標とした
現状確認
第一段階はすでにクリアしているとわかった
第二段階を得意なエンジニアにお願いした
計画策定
PMは詳しくない
担当エンジニア(現場)のほうが詳しい
だから会議などでメンバーの話を聞く
ドメイン関係者の話を聞くことが大事
現代的な意義
ウィーン会議の再評価
実は舞踏を通じた国際協調だっのでは？
まとめ
個人的な営みに基礎を置きつつも
この話題さんの興味に引っかかりそう
まあプロダクトマネージャーって感じ
プロデューサーもそうだけど、ビジョン持ってて皆を牽引する何でも屋さん
16:40-17:00 休憩