現職のUbie（のProduct Platform組織）で働きだして2年たち、働きやすいなと思う点がいくつもある。自社の働きやすい点は慣れてくると当たり前に感じてくるので、改めて軽く言語化してみようと思う。そうすればその点を意識的に改善できるし、カジュアル面談などで自社の魅力を伝えるのにも役立つ。透明であるとにかく可能な限り情報を透明にしようとしてる点。アクセスしようと思えば一部の例外（従業員の給与だったり、ユーザの個人情報だったり）を除いてすべての情報にアクセスできる。四半期ごとにOKRを事業チームごとにOKRをたてているが、その内容は当然見れるし、OKRの背景や進捗も見れる。他にも事業計画、事業代表が集まるMTGや各チームのMTGの議事録なども当然のように見ることができる。アクセスできる人が限られていたり、議事録がなくて実質MTG参加者しか情報にアクセスできないというのを極力なくしている。そのため（だけでないが）、各チームのMTGは統一された方法で実施されてるし、ドキュメントツール（notionを使ってる）に情報を集約したり運用を頑張っている。型を作り組織に展開する組織を運営するために、色々なツールやプラクティスを導入することは各社普通に行われると思う。現職の場合はただ導入するだけではなく、運用しながら自分たちにあった形を見つけて最適化させつつ（社内ではこれを「型化」と呼ぶ）、それを組織に展開してみんなに使ってもらうようにしている（社内ではこれを「装着」と呼ぶ）。これはツールやプラクティスだけではなく、チーム内の業務においても同じようにすることもある。この場合はチームローカルなので組織全体に展開することはないが。例えば採用面接の内容は、カルチャーミスマッチを防いだり面接官が自社のバリューを意識して選考できるように、圧倒的に型化されて面接官に装着されている。どういう点を深ぼるか、どういった視点で議論するかはまとめられているし、そのための質問観点リストもある。面接後の合否判断も（詳細は書けないが）、なるべく面接官ごとにブレがないように共通基準を使って判断するようになっている（とはいえ完全にブレを無くすことはできないが）。余談だが現職の面接ではカルチャーマッチをすごく重視してるので、コミュニケーションがしやすかったり、メンバーにあった仕組みを整えやすいので働きやすいのもかなりあると思う。エンジニア運用系タスクの理解エンジニア同士なら必要性はよく分かるが他職種からだとちょっと分かりづらいというタスクが一定ある（エンジニアに限らない話だが）。例えば負債の解消、システムメトリクスやエラーの監視、ソフトウェアアップデートなどなど。こういう仕事についてもPdMやビジネスメンバーはそれがなぜ必要なのか、いつやるべきなのか、どこまでやるべきなのかをエンジニアと話して理解したり、時には議論する。というか、エンジニアも暗黙的に必要と思っていたものが、議論することでタスクが明瞭化されて今は他のものを優先したほうがよいとか、実施する範囲が明瞭化される。直近だとRailsアップグレードについて議論した。なぜやる必要があるのか、やらない場合のリスクはどういうものがあるのか、やるとしたらどれくらいコストがかかるのか。Railsアップグレードじゃなくてこの際システムをNodeアプリに書き換えるのはどうか？メリット・デメリット・コストなどは？というのをエンジニアだけじゃなくてPdMも含めて議論した。「エンジニアが必要だと言ってるからやる」じゃなくて徹底的に議論と理解を経てやる・やらないが決まったものはその後の進めやすさが違うし、何より気持ちよく仕事に取り組める。活動ごとの独立組織と組織間連携自社のミッション（テクノロジーで人々を適切な医療に案内する）を達成するためには、色々な活動が必要である。例えばプロダクト開発、マーケット開発、リスクや財務の管理など。これらの活動を高いレベルで実施するためには、それに最適な人たちが必要となる。そしてその人たちが最高のパフォーマンスを出すには、その人たちが働きやすい文化や制度（マネジメント方式・報酬制度・採用要件など）を作る必要がある。けど1つの組織の中にいろんな文化や制度を作ると、帯に短し襷に長しになったり、混ざってよくわからないものになる。そこで、Ubieではそれらの活動ごとに独立して動ける組織を4つ作り、それらの中で最適な文化や制度を作っている。普通の会社であればこれらは部署として区切られるが、Ubieでは本当に「独立した組織」として作られている。独立とは「SlackやNotionのチームスペースが別で勝手にjoinできない」「他組織のフロアには基本的には出入りできない」というような感じだ。一言でいうと「同じ会社の中にある別の会社」である。一方で、同じミッション達成のために活動しているので、組織間の連携も独立させることと同じレベルで重要である。プロダクトを開発するだけでは顧客のもとには届かないし、顧客課題を解決するためには顧客とのコミュニケーションだけでは解決しない。法律や業界ガイドラインへの準拠や様々なリスクへの対応は、目の前のプロダクトや顧客に集中していると気づけ無い（そもそも専門家じゃないとわからないことも多い）。なので各組織が独立して最高の活動をしつつも、それらを日々統合していく必要がある。とはいえ無秩序に連携してしまうと、組織間の文化や制度の違いからうまく行かないことも多い。そこで各組織の連携のために組織間連携を実施する役割を作ったり、ミーティングやアジェンダの取り扱い方を決めたりしている（社内ではこの仕組みを接合面と呼んでいる）。他にも毎月の全社会では全社OKRについて担当する各組織から状況の共有があったり、毎四半期のオフサイト（オンサイト）では全組織で合同実施をするパートもある。このように各活動ごとに独立した組織を作ってパフォーマンスを出しやすい環境を作りつつも、それらの組織をうまく連携させてミッション達成に向かうことができるのは非常に働きやすく感じる。他にも色々働きやすい点はあるが、特に自分が感じる点はこんなところである。当たり前になりすぎて見過ごしてる点やもっと根本的に働きやすい点とかもあるかもしれないが。ただし、これらの点にもやはりデメリットとのトレードオフがあったりもする。どんなものにもトレードオフがあって当然なので、それはそれとして認識しながらやっていきたい。丸山@h13i32maru

「働きやすい」を認識する

Ubie Discoveryというヘルステックスタートアップでプロダクト開発エンジニアをしている丸山@h13i32maruです。最近、チームの生産性改善をするためにトイル計測をはじめました。今日はこのトイル計測について簡単に紹介します。「生産性」ではなく「伸びしろ」の計測手作業、繰り返される作業、自動化が可能、etc改善可能な作業を計測するトイル40%超えトイルの撲滅は...これからだ！「生産性」ではなく「伸びしろ」の計測生産性を改善するにはまずは生産性の計測から始めることが重要です。計測指標として有名なものにFour Keysがあります。Four Keysは「変更のリードタイム」「デプロイ頻度」「変更失敗率」「平均修復時間」を計測してチームのパフォーマンスを評価するものです。このFour Keysは組織全体としての生産性の結果指標だと理解しています。例えば僕のチームでは事情によりデプロイする曜日が決まっていたり、ある機能が法的・業界ガイドライン的に問題ないかのレビューを別チームに依頼していたりします。これらによって「変更のリードタイム」や「デプロイ頻度」は変わってきます。このような結果指標はトップダウン的アプローチによって組織全体の生産性を改善していくのに向いていると思います。一方で今回はボトムアップのアプローチによってチーム内の生産性を改善しようと動き始めました。そのためには日々の具体的な仕事の生産性を見える化し、エンジニア以外（おもにbizメンバー）とも認識を揃えながら、改善していく必要があります。とはいえ具体の仕事の生産性を計測するのは難しそうです。そこで生産性自体ではなく、「トイル」という考えをもとに生産性の「伸びしろ」を計測することにしました。💡 Four Keysの計測やトップダウン的な組織全体の生産性改善については別途検討中です。手作業、繰り返される作業、自動化が可能、etcSRE領域において「トイル」という指標を計測することがあります。トイルとは以下のようなものです。https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles「トイルとは、手作業、繰り返される、自動化が可能、戦術的、長期的な価値がない、サービスの成長に比例して増加する、といった特徴を持つ作業です。」トイルの例としては次のようなものがあります。💡 より詳しい内容については「SRE サイトリライアビリティエンジニアリング」を参照ください。https://www.oreilly.co.jp/books/9784873117911/この定義や例はSRE領域の業務を背景に書かれているため、エンドユーザ向けのWebアプリケーション開発をしている僕のチームにそのまま当てはめるには少し難しいなと感じました。そこで、チーム内で共通認識を持ってトイルの計測が各自でぶれないように、「エンドユーザ向けWebアプリケーション開発においてのトイルってどんなもの？」というのを整理することにしました。改善可能な作業を計測するトイルの定義は前述しましたが、本質的にはトイル計測で何をしりたいかというと、以下のように書いてあります。https://cloud.google.com/blog/ja/products/gcp/identifying-and-tracking-toil-using-sre-principles作業効率を検証するために Google のサイト信頼性エンジニア（SRE）が使用している主な測定指標の一つが、日々の時間の使い方です。長期間のエンジニアリング プロジェクトのために時間を確保する必要がありますが、エンジニアには Google のサービスを稼働し続ける責任もあり、そこにも手作業が生じることがあります。つまりトイルの本質とは「ある領域の業務において、作業効率が悪いものがどれだけあるか計測する」ということです。この理解をもとに、僕のチームでは以下のようなものをトイルとして計測することにしました。定義: 「作業効率や生産性の改善余地があると感じた業務」をトイルとする。トイル40%超え計測方法はJiraのチケットに各自がトイルフラグをつけていくというシンプルなものです。昨年の10月からトイルの計測をはじめ、12月はエンジニアが行った業務のうち44%がトイルでした。SRE本では40%を超えると良くないとあったのですが、通常のWebアプリケーション開発においては40%はかなり多い印象です。感覚ですが20%ぐらいに抑えたいなという気持ちがあります。💡 10、11月はシステム運用を改善する業務が多かったため、トイルの割合が高くなっていました。直近はそれらの業務が減ってきており、比例してトイルも少し減少傾向にあります。割合を多く占めるトイルとしては以下のようなものがありました（結果だけみるとありきたりではある）。デプロイ作業不具合修正ユーザサポートや営業チームからのデータ集計依頼この中でデプロイ作業はトイルの半分ほどをしめます。なのでここを改善するとチームの生産性が向上しそうです。実際にデプロイ改善については取り組むことになっています。また、不具合修正やデータ集計依頼の根本的な改善は難しそうですが、徐々にトイル撲滅をしていこうと思っています。例えば、不具合が発生しづらいようにリファクタリングをしたり、データ集計をユーザサポートや営業チームができるように環境整備やイネイブリングを行ったりなど。トイルの撲滅は...これからだ！生産性というと抽象度が高く計測したり改善するのが難しくなりがちですが、伸びしろ（=非効率な業務、無駄がある業務）を見える化するのは割と簡単です。それらの作業を改善すれば、生産性も改善されていくと思います。とはいえまだ見える化しはじめた段階なので、改善はまだまだこれからやっていく必要があります。最後にUbie Discoveryではエンジニアを積極採用中です。少しでも興味を持ってくださった方はTwitterでお気軽にメンション・DMください。https://twitter.com/h13i32maruhttps://recruit.ubie.life/

生産性改善のためのトイル計測

この記事はTrickleアドベントカレンダー2022の1日目です。見るより気兼ねなく書く、Trickleというサービス・Trickleの機能紹介（アクティビティログサービス）Trickleを開発している丸山@h13i32maruです。今回Trickleのアドベントカレンダーを実施することになりました！といっても25日全てというわけではなく、数名のユーザが書いてくれると言う感じです。それでもめちゃくちゃ嬉しいです。どうしてアドベントカレンダーをやることになったかというと、先日ToLiさんという方がTrickleの振り返り兼紹介記事を書いてくれました。その後、その記事を見たTwitterユーザの方がTrickleに興味を持ち、アプリを使い始めてくれたようです。昨日たまたまこの記事を見かけて、あまりにも面白そうすぎたのでTrickle入れたどう使うか何も決めてないけど…Trickle（トリクル）を使って4年、今も自分なりに愛用してる｜ToLi #note https://t.co/5ol6RBdysS— 行木しずく (@gloom_tree) 2022年11月30日  これを見て「やっぱり実際の利用者が書いた記事は新規ユーザを惹き付けるよな〜」と思ったので、Trickle内で「アドベントカレンダー興味ある人いますか！？」と聞いてみたところ数名の方が「書きます！」「興味あります！」といってくれたので、今回アドベントカレンダーをやってみることにしたという流れです。というわけで、アドベントカレンダーの記事を通じて新規ユーザが少しでも増えるといいなと思っています。そしてなにより「ユーザがTrickleについて自身の言葉で書いた記事を読める」というのはめちゃくちゃ嬉しいです。Trickleアドベントカレンダー2022よろしくおねがいします！Trickleユーザで興味のある方は参加も自由です！ではでは〜。adventar.org

Trickleのアドベントカレンダーやることになった！

最近Twitterの運営がちょっとわちゃわちゃしてるからか、Trickle（トリクル）をおすすめしてくれるツイートを見かけて大変うれしいです 😁Trickleすっかり気に入ってしまった。ブログに近いかな、日常のつぶやきとか好きなものとかメモとかがどんどんトピックに貯まっていくのがすんごい楽しい。Twitterは主に情報収集用になる予定。— ザウコ (@Zauko) 2022年11月22日  Trickleの何が良いって、アクティビティ別につぶやきを分けられるしアクティビティごとにサブスクができたりするところ。野球向けに使うなら、チーム別とか好きな選手別とかに分けておいたり。あるいは写真用に分けておいてもいい。あとはそのアクティビティごとにつぶやいてくだけ。— Kicca(吉華)⚾️ (@Kicca_ctb) 2022年11月18日  Trickleはマジでおすすめ>RT例えば、このアカウントのする歴史史料の話は興味あるけど、ゲームとかついて行けないし頭痛くなるんですけど……みたいな時は、歴史トピックの読者になるだけで良いので。トピックありきで投稿されるから。長文も修正も可能で、blogのイメージに近いよ。— 黒い塊 (@bottomofalake) 2022年11月9日  みんな！！Twitterの代わりにTrickleもおすすめだぞ！！好きな話題を自由に割り振れるし文字制限もないぞ！！ちょっとTwitterはさわがしいなって感じの人には特におすすめhttps://t.co/NTN9qKYbq1 #trickleday— 眠藻🟢創作垢 (@sskask07320377) 2022年11月9日  他にもたくさんツイートされててすごく嬉しいこのビッグウェーブ（？）に乗るしかない！ということでTrickleの紹介記事を書きました。今回は機能面での紹介をしていきます。コンセプトやなぜ作ったのかなどは以前に書いたので興味のある人は読んでみてください〜。blog.h13i32maru.jpトピックアクティビティリンク振り返り機能見た目の変更ユーザブロック各プラットフォーム対応サブスクライブ検索ログイン鍵機能はないトピック自分の好きな話題（読書とか映画とかポケモンとか）を「トピック」として作成し、そのトピックごとにメモを書いていきます。ようはブログのカテゴリなのですが、Trickleでは必ずこのトピックごとにメモを書いていく必要がります。そう聞くと面倒と思うかもしれませんが、自分の中でトピックがはっきりしている人にとってはすぐに慣れますし非常に便利です。逆にふわっと日常のことや思ったことを書いてくのは合わないかもしれないです。ちなみに僕は日記トピックを作ってそういうふわっとしたことも書いているのでやろうと思えば全然できます。あとはアカウント分けをしなくても、トピックを使えば書き込みを分けられるので便利という感想もよく見かけます。 自分のトピック一覧  ホーム画面（自分のメモのみが表示）      アクティビティ先ほどメモと記載したものをTrickleでは「アクティビティ」と呼びます。Twitterの「ツイート」、ブログの「記事」に相当するものです。アクティビティの由来は日本語訳そのままで「何かしらの”活動”」という意味です。スポーツ、ゲーム、料理、などなど自分の好きな活動について書いていく感じです。とはいえ、使い方はユーザにとって色々です。欲しい物をひたすら書いていく人もいれば、家族や友人と話して面白かったことなどを書いているユーザもいます。アクティビティの文字数制限は5000文字です。なので基本的には文字数制限に困ることはないと思います。長文を書いたときは折りたたんで表示されるので見づらくなることもありません。編集も自由にできます。時間制限もありません。ちなみに5000文字に特に意味はなくて、将来はもっと大きくするのもありかなと思っています。というのもブログ記事のように超長文を書き留めるという使い方も視野に入れており、Markdownへの対応も検討しているからです。動画の添付には未対応です。画像は添付できるのですが動画には対応していません。これは意図的ではなく単純に開発が間に合ってないだけです。そのうち対応したいと思っています。個人開発してるツールについて書いたアクティビティリンクアクティビティにはリンク機能というものもあります。これは引用リツートみたいなもので、他のアクティビティを紐付けることができます。複数リンクすることも可能です。また、自分がリンクしたアクティビティ一覧や、リンクされたアクティビティ一覧も見ることができます。これは自分だけではなく他のユーザのものも見ることができます。友人のアクティビティにリンクしてる様子振り返り機能日々どれくらいアクティビティを書いているかはタイル機能*1で振り返ることができます。たくさん書いてる日は濃い緑になります。このタイルをタップするとその週のアクティビティを見ることもできます。他にも年間の書き込みを振り返る事ができる年間データ機能というのもあります。ある年に書き込んだアクティビティの件数、日数が見れます。トピックごとに見ることも可能です。 年間の利用状況  その年のアクティビティ  その年のトピックごとの利用状況       見た目の変更Trickleではアプリの色を変更できるカラーテーマを提供しています。14色のカラーでライトバージョンとダークバージョンがあるので28パターンあります。ちなみに僕が愛用しているのはカラフルテーマのダークバージョンです。このカラフルテーマは背景がユーザアイコンの画像や、トピックの画像になるので、かなりカラフルになって楽しいです。他にも細かいですが、ユーザ名の後ろにバッジをつけることもできます。バッジの種類は600種類以上あります。 テーマ一覧  ピンクライトテーマ  カラフルダークテーマ      ユーザブロック特定のユーザをブロックすることができます。ブロックするとお互いに「アクティビティ閲覧不可」「アクティビティのリンク不可」「トピックのサブスクライブ不可」などの状態になります。各プラットフォーム対応Trickleはスマホ版・デストック版・ウェブ版で利用できるのですが、それぞれ明確に利用目的が設定されています。スマホ版（iOS・Android）書く・読む含めたすべての機能を利用できますTrickleはスマホアプリ版を使うのが前提となっていますアカウント管理やウェブへの公開などもスマホ版で操作しますデスクトップ版（Windows・Mac）書くことに特化したアプリです例えば「パソコンでなにか作業をしているときにそのことをTrickleにも書き留めていく」みたいな使い方です。基本的には自分のアクティビティを書くことしかできず、他人のアクティビティ見たりということはできませんウェブ版自分のアクティビティをTrickle外に共有したい場合に使います例えば「映画の感想をTrickleに書いたけど、Twitterにも流したい」ときに、そのアクティビティをウェブに公開できます。なので実際はウェブ版というよりウェブ公開機能になります。そのためウェブ版はログインや書き込みなどの機能はありません。トピックをまるごとウェブに公開したり、アクティビティごとに公開を設定することができますサブスクライブTwitterのフォロー機能に相当するものとして、Trickleにはサブスクライブ機能があります。しかしフォローと違い、Trickleでは「興味あるユーザの興味あるトピック」をサブスクライブします。これは「Aさんの読書トピックをサブスクするけど、ゲームトピックはサブスクしない」という使い方ができます。Twitterにも同名のトピック機能やInstagramのハッシュタグフォロー機能がありますが、これらはサービス全体で共通のトピックやハッシュタグとなっています。一方Trickleのトピックはユーザ個別のものになっています。なので単純に特定の話題を見たいというよりも、自分が興味を持っているユーザの話題を見ることができます。「読書の話題なら何でもよい」ではなく「このユーザの読書トピックに興味があるのでサブスクする」という感じです。つまりサブスクしたトピックはその人にとって非常に興味があるものになるので、サブスクしたトピックにアクティビティが書き込まれるとプッシュ通知が飛んできます。このプッシュ通知をOFFにする機能は提供しておりません。トピックごとにプッシュ通知をOFFにできるようにして欲しいという要望は当初からあります。しかしこの仕様はサービスのコンセプトに基づいた意図的なものです。やや特殊な仕様であるのは認識していますが、自分自身にはこの仕様がプラスに働いている面が大きいため現在の仕様を続けていくつもりです。もしどうしてもプッシュ通知をOFFにしたい場合はスマホ自体の機能でTrickleのプッシュ通知をOFFにしてもらう必要があります。サブスクしているトピックの内容はホームタブとは別タブになっています検索アクティビティやトピックを検索することができます。アクティビティの検索については「サービス全体から」「自分のアクティビティから」「サブスクしているトピックから」というような検索も簡単にできます。ただし、検索機能自体はあまり作り込んでおらず内部的にはただの文字列マッチです（Like検索）。本当はもっといい感じに作りたいのですが時間が取れていません。自分の過去のアクティビティを検索できるのは便利ですログインTrickleはGoogleログインのみ*2をサポートしています。以前はパスワードログインでの利用だったのですが、現在は提供しておりません*3。パスワードログインはパスワードというセキュアな情報をサービスに保存することにもなりますし、パスワードリセットの提供も必要になるため廃止しました。鍵機能はないサブスクを承認制にする機能（いわゆる鍵アカウント）は提供しておりません。この機能に対する要望も当初から結構あるのですが、今のところは提供する予定はありません。というのも承認制について僕は以下のように理解しているためです。承認制は「サービス内でユーザ同士のコミュニケーションを円滑・安全にするための機能」と理解していますしかしTrickleはコミュニケーション自体をそんなに重視はしていませんなので承認制はサービスのコンセプトに合わないと考えていますどうしてもサブスクしてほしくないユーザがいる場合はブロック機能があります承認制の機能を作るのは難しい技術的には認可と呼ばれる仕組みを作ることになるのですが、これを問題なく作り運用していくのは難しいです実装に問題があると最悪の場合、認証されていないユーザが内容を見れる可能性もでてきます承認制を提供した場合、使い方を工夫すると「DMのような個人間のメッセージのやり取り」を可能にしてしまいますDMのような機能を提供するには電気通信事業の届け出や登録が必要になります承認制の機能がここに該当するかは専門的知識がないので正確にはわからないのですが、安易に提供するわけにはいきませんまた、個人的な感想では承認制を必要に思ったことが一度もありません。Trickleは自分の余暇の時間を捻出して運営しているため、自分が必要と思わない機能はなるべく作らないようにしています。これは運営を長く続けていくためになるべく負担を減らしたり、モチベーションを保つためです。ご理解いただけると助かります。一方で「完全に自分しか見れないトピック」は欲しいと思うことがあります。僕はTrickleにいろいろなことを書き込んでいるので、よりプライベートなこと（例えば子供の写真だったり、他人には知られたくない内心だったり）もTrickleに書きたくなります。わざわざ別アプリに書くのは面倒です。というわけでこの「完全に自分しか見れないトピック」は今後検討したいなと思っています。以上Trickleの機能を紹介しました。興味のある方はアプリをダウンロードしてみたり、僕のウェブ版をみてもらうと雰囲気がわかると思います。Twitterから乗り換えるというよりは、Twitterを情報収集・発信・コミュニケーション目的などで使い、Trickleを自分のための記録や考えの整理なんかに使うのがいいんじゃないかと思っています。*1:GitHubのあれ*2:iOSではAppleログインも可*3:パスワードログインを使っていたユーザは今も使える

Trickleの機能紹介（アクティビティログサービス）

こんにちは丸山@h13i32maruです。今日、Jasper v1.1をリリースしました🚀 割と大きめの変更が入っているので、内容をブログにしました。OAuthアプリ化OAuth認証に対応し、GitHub OAuthアプリとなりました（#245）。これまではPersonal Access Token(PAT)のみ対応だったのですが、OAuth認証を使うことで、Jasper利用開始時のアクセストークン設定がすごく簡単になりました。それと、アクセストークンを個別に管理するのではなくGitHub OAuthアプリとして管理できるようになります。なお、GitHub Enterpriseの場合は引き続きPATのみの対応です。PATからOAuthへの移行Personal access tokens管理画面から、Jasperで利用しているPATを削除してください。その後にJasperを再起動すると、アクセストークンの再設定画面が表示されます。ちなみにJasper v1.1.1でアクセストークンにread:projectスコープを要求するようになったので、バージョンアップ後はいずれにしろアクセストークンの再設定画面が表示されると思います。OAuth Device Flowhttps://github.blog/changelog/2020-07-27-oauth-2-0-device-authorization-flow/Device FlowによるOAuth認証は以下の手順通りに実装するだけで、非常に簡単でした。https://docs.github.com/ja/developers/apps/building-oauth-apps/authorizing-oauth-apps#device-flowGitHub Project対応新しいGitHub Project(a.k.a beta, v2)に対応しました（#234）。これまでも旧GitHub Project(a.k.a classic)には対応していたのですが、そちらは今後利用されなくなっていくと思います。GitHub Project自体は先月GAされ、classicからの移行も可能なようです。https://github.blog/2022-07-27-planning-next-to-your-code-github-projects-is-now-generally-available/https://docs.github.com/ja/issues/planning-and-tracking-with-projects/creating-projects/migrating-from-projects-classicOAuthアプリでのGitHub Projectアクセス問題JasperでもOAuth認証でアクセストークンを設定して使っている場合、条件に合致するとGitHub Projectの情報が取れません。僕が把握してる条件は以下のような感じです。JasperをOAuth認証でアクセストークンを設定しているOrganizationのissueやPRが対象パブリックなリポジトリパブリックなGitHub Project対象OrganizationがJasper（OAuthアプリ）を承認していない通常、OrganizationがOAuthアプリを承認していない場合でも、パブリックリソースにはアクセスできるはずです手元の検証でもJasperが承認されていなくとも、issueのタイトルなどは取得できました現在、これらの内容をまとめてサポートに問い合わせ中です。その他の更新Filter Streamの改善Filter Streamに複数のクエリを指定できるようになりました（OR接続）label:release_@current_dateのようにラベルに@current_dateを使って相対日付を指定できるようになりました #242詳しくはこちらGitHub Enterpriseでのavatarアイコン表示不具合の修正 #231自分自身によるissue更新時の通知を抑制 #250issue上のコメントハイライト修正 #251日本語化 #246組み込みブラウザ内のダークモードを非サポート #249代わりにGitHub公式のダークモードをご利用ください以上v1.1の更新情報でした。GitHubスポンサーを公開しているので、応援してくれる方はスポンサードしてくれると嬉しいです😍github.com

Jasper v1.1をリリースしました

2017年から個人で開発しているTrickleというサービスがある。最近、これのバックエンド構成を変えたり、新機能追加などをした。技術的に目新しいものや凄いものはないけど、頑張ったのでその時の話を残しておく。バックエンドExpress → Next.jsMulter → BusBoyWeb版GAE → Cloud RunクライアントアプリReact Nativeのアップグレードreact-native-image-crop-picker → react-native-image-pickerソーシャルログインアイコン変更バックエンドExpress → Next.jsこれまではExpressでモバイルアプリ向けのWeb APIを作っていたが、今回Web版も作るにあたり、Next.jsに移行した。まずはこれまでのモバイルアプリ向けAPIをNext.jsのAPI Routeで作成。Expressと非常に似た感じだったので、ハンドラー部分だけ新規実装して、残りはほぼそのまま動いた。APIを移行するにあたって、少しだけ実験実装を入れてみた。通常、Next.jsのAPI Routeは一つのパスでHTTPメソッドをすべて受け取って、ハンドラーの中で分岐するようになってる。今回はその方式ではなく、パス1つにつき1つのHTTPメソッドに限定するようにしてみた。例えばこんな感じで、GET, POST...ごとに個別のパスを作った。こうすることで各ファイルの中は非常にスッキリした。/page/api/items/             - index.ts             - [itemId].ts             - update.ts             - delete.tsもうRESTではないし、いっそのことすべてPOSTで受け取るようにするか？みたいにも考えた。けど、そこまでやるのはGraphQLへ移行するときがよさそう。来年とかにGraphQL移行したい。あとExpressではMulterを使って画像（マルチパート）をうけとっていたが、Next.jsではBusBoyを使ってストリームとして処理してみた。これは後述する。Web版実装はSSRを使うことにした。これはOGPを使えるようにしたかったため。特にハマることなくサクサク実装できた。過去にNext.jsの小さなアプリを1, 2個作ったことはあるが、がっつり使うのは今回がはじめて。その時も思ったが、やはりNext.jsはすごく開発しやすい。最高。Multer → BusBoyExpressのmiddlewareとしてMulterを使って画像などのマルチパートを処理していたが、Next.jsでそのまま使える感じではなかった（？）ので、BusBoyを使うことにした。クライアントから画像などの大きなファイルを受け取ってGCSなどのクラウドストレージに保存する場合、ストリームで受け取ったものをそのままストリームとして書き出すのがメモリ使用量を抑えられる。しかしMulterはすべての画像を一度すべて受け取ってから処理することになっているので、メモリ効率があまりよくない（と思う）。今回BusBoyを使うことにしたので、ストリームとして処理できるようにしてみた。なんだけど、運営してるサービスでは画像の受け取り時にリサイズ処理をサーバ上で行っているため、すべてをストリームパイプラインで実施することはできない。そこで以下のようにストリームからの画像読み出しのタイミングを調整して、すべての処理を直列で実施することにした。ストリームから画像1つ読み出し → 画像リサイズ処理 → GCSに保存 → ストリームから画像1つ読み出し → 画像リサイズ処理 → ・・・これによって、1リクエストの中では画像リサイズ処理が同時に複数実行されないので、メモリのピーク使用量は抑えられていると思う。一方で、トータルの処理時間は長引くので、結局良いのか悪いのかは微妙なところ。ちなみにMulterも内部的にはBusBoyを使ってるらしい。マルチパートなデータを処理するライブラリの比較については以下のサイトがよかった。https://bytearcher.com/articles/formidable-vs-busboy-vs-multer-vs-multiparty/Web版Web版を作るにあたり、URL設計を当初は愚直に/items/[itemId]にしようかと思っていた。しかし、itemIdが外に露出するのは少し嫌な感じがする。露出すると、以下のような弊害がある。コンテンツ数が予測されるクローリングされやすいこの2つ、実害としてはそんなにないし、僕の個人サービスは全然有名ではないので心配し過ぎではある。とはいえ露出させるメリットもなさそう。でも、こういうところを検討することは勉強にもなるので何かやってみることに。単純に思いつくのはitemId + saltをMD5にしたり、UUIDを使う方法だけど、それだとURLとして長い。では先頭N文字を使えば良いかといえば、それは想定されていない使い方だし、文字種が少ないので衝突性が高くなったりと微妙である。そこでZennのURL設計を見てみたところ、/articles/a873bbbe25b15bというようになってる。記事ごとに独自IDを発行して、それをURLとしてるようだ。そういう実装が簡単にできるライブラリをさがしてみたら、Nano IDというのをみつけた。これは文字種や長さを自由に調整しつつランダムな文字を作れるというもの。衝突確率のシミュレータなども公開されている。今回はこれを使って[0-9a-f]{14}でIDを生成した。最終的には以下のようなURLとなった。https://trickle.day/topics/7d9cfed9e3e143GAE → Cloud RunこれまでGoogle App Engineのflexible環境を使っていた。これは前述したサーバサイドで画像リサイズをしているので、ピークメモリ使用量が結構必要になるからである（メモリ1GBにしてる）。しかし、これが結構お高い。月間で8500円ほどかかっている。これは高すぎて辛いので、サーバレスにして安くしたいと思いCloud Runに移行してみた。ミニマムインスタンス1、リクエストの処理中にのみCPUを割り当てる、という条件で月間1500円ぐらいにおさまりそう。安い。Next.jsをCloud Runで動かすのは簡単だった。Next.jsの公式どおりにDockerfileを書いて（yarnをnpmにかえた）、Cloud Runのチュートリアル通りにデプロイすればよい。https://nextjs.org/docs/deployment#docker-imageクライアントアプリReact NativeのアップグレードReact Nativeは個人開発のように開発リソースが限られてる状況でiOS, Androidのアプリを作るのにすごく役立ってる。しかし、React Native自体のアップグレードはまじで辛い。公式からアップグレードツールは提供されているが、それでうまくいったことが一度もない。今回のv0.63からv0.68へのアップグレードもやはりうまくいかなかった。なので、僕は毎回新規にアプリを作成して、そこに既存のソースコードやライブラリ、設定を移植するという方法をとっている。今回もその方法で実施した。昔はReact Nativeのネイティブモジュールを入れるのもハマることが多かったけど、最近それはすごく簡単になってるのでそこにはストレスはない。細々としたプロジェクトの設定や、プッシュ通知の設定、アイコンの設定などは面倒ではある。なので設定した場所をドキュメントとして残していってる。順調にいけば半日ほどで完了するので、アップグレードツールでハマってしまうことを考えたらこっちのほうが現時点では良いと思ってる。けど、辛いのは辛い。react-native-image-crop-picker → react-native-image-pickerReact Nativeでギャラリーから画像を選択するにはネイティブモジュールを使う必要がある。これまではreact-native-image-crop-pickerを使っていたが、これが結構不安定で辛い。Androidでqualityを1未満でpngをリサイズすると、jpegに変換されてしまい、透過が消えるAndroidのレスポンスにfilenameがないAndroidでPhotos経由で写真を選択するとレスポンスがとれないiOSでpngをリサイズすると、mimeがjpegになるそこで今回react-native-image-pickerも評価してみた。iOS14以降ではないと画像選択の最大枚数の制御ができない今はiOS15がメインなので、そんなに問題ではない取得した画像パスが選択した画像順にならない内部でリサイズされた順番になってそうAndroidでは返ってくるデータのwidth,heightがexif rotationを考慮した値になっていないなので、画像を取得したらあらためて、React NativeのImage.getSize()でサイズを取得して回避しているというわけでreact-native-image-pickerのほうがよさそうなので移行した。ワークアラウンドは多少必要だけど、全体的にはcrop-pickerに比べて全然良い。どうしてreact-native-image-pickerを最初から使ってなかったのかは忘れた（当時も評価したような気がするんだけどな）。ソーシャルログインFirebase Authを使ったソーシャルログイン（Googleログイン、Appleログイン）をサポートした。実装自体はReact Native Firebaseのドキュメント通りにすれば、簡単にできた。細かい注意点としては以下のようなものがある。iOSシミュレータではAppleログインができないできるようにする方法もあるみたいだが、実機インストールして試せばよいので深追いせずGoogleログインのみにしたかったが、Appleの規約上ソーシャルログインを実装する場合、Appleログインを入れる必要があるAndroid版にAppleログインは実装しなかったAndroidの場合、Firebaseプロジェクトにアプリ署名鍵のSHA 証明書フィンガープリントを追加する必要があるアプリ署名をGoogle Playでしている場合手元のアップロード鍵のフィンガープリントではなく、アプリ署名の方を入れる必要があるサービス内のアカウントと紐付けるためにサーバ上ではFirebase Adminを使ってクライアントからもらったidTokenを検証するクライアントから直接Firebase UIDを送ってそれを使うと、UIDによるなりすましができてしまうためそして、ソーシャルログインを実装したので、ID/Passwordによる新規のアカウント発行は停止した。サービスリリース当初はReact Nativeによるソーシャルログインモジュールがまだ整ってなくて、仕方なくID/Password認証にした記憶がある。今からサービス作るなら、ソーシャルログインのみにするのがよさそう。それと、これまでID/Passwordでログインしていた人をソーシャルログインへマイグレーションする機能（アカウントマージ）は今回は未対応。結構大変なので先送りで。アイコン変更今回サービスのアイコンを変更した。ただ自分でアイコンデザインはできないので、99designでデザインコンペを実施してみた。料金グレード（参加できるデザイナーのレベルと連動）はいくつかあるが、最高グレードでやってみた。99designsの最高レベルのデザイナーはどんな感じなのか体験したかったのと、下位グレードにして後悔するのは避けたいなと考えたため。結果としては満足行くものができた。しかし、レベル感としては全員が全員たかいわけではないようだ。応募してくれたのは5人ほどでそのなかでいいなと思ったのは2名。みんな複数案件掛け持ちでやってるのだろうから仕方はなさそう。でもデザイナーと細かくやり取りしながらすすめていけるのはよかった。またアイコン作成するときは使ってみようと思う。ちなみにアイコンを変更した理由は、以前のアイコンは「記録していく」「ためていく」という意味合いが強かったが、「書くこと自体」にもっとフォーカスしたアイコンにしたかったため。これ以外にも細かい実装をめちゃくちゃたくさんした。だけどまだまだやりたいことがある。デスクトップ版のソーシャルログイン対応SequelizeからPrismaに移行MySQLからPostgresqlに移行RESTからGraphQLに移行React hookに移行ぼちぼちやっていこうと思う。ちなみに今回話題にした個人開発してるサービス自体については以下の記事を書いた。興味を持ってくれた方は読んでみてほしい。見るより気兼ねなく書く、Trickleというサービスhttps://blog.h13i32maru.jp/entry/2022/08/12/154716丸山@h13i32maru

個人開発してるサービスをExpressからNext.jsにしたり、BusBoyを使った話しなど

先日、Trickle（トリクル）というサービスのバージョンアップをしました！Webからも見れるようになったり、細部が使いやすくなったため、あらためてサービス紹介をしてみます。https://trickle.dayTrickleは「Twitter、少し疲れてきたなぁ。でもやめたいわけではないし、うーん」と自分が困っていたことを解決するために作ったサービスです(2018年リリース)。同じように感じてる人や、何かを書き留（と）めることが好きな人にもっと使ってもらいたいと思っています。気になった方は是非続きを読んでみてください。使い方(1) 自分のトピックごとにアクティビティを書き留める(2) 他人のトピックをサブスクライブする(3) アクティビティをリンクするQ&ATwitterと何が違うの？何故作ったの？○○機能は使えるの？どんな人が作ってるの？使い方以降ではTrickleの用語がいくつかでてくるのですが、これらはTwitterのもの想像してもらうとイメージしやすいと思います。 Twitter     Trickle  ツイート  ↔  アクティビティ  フォロー  ↔  サブスクライブ  引用RT  ↔  リンク  複数アカウント  ↔  トピック それではサービスがどんなものか知ってもらうために、3つの主な使い方を紹介します。(1) 自分のトピックごとにアクティビティを書き留める(2) 他人のトピックをサブスクライブする(3) アクティビティをリンクする(1) 自分のトピックごとにアクティビティを書き留める「ホーム」は自分の書き留めたアクティビティ（テキストや画像のメモ）です。「トピック」というのは、自分が興味のあるアクティビティのまとまりです。各ユーザはこれらのトピックを自分の好きなように作成します。僕の場合だと、「本の感想」「丸山家」「サラダ生活」などのトピックを作成しています。そして、このトピックごとにアクティビティを書き留めていきます。トピックごとに書き留めるので、あとから見返すときも便利です。年間で見返す機能も提供しています。他のユーザの使い方も紹介します。yohei-kikutaさん食事、子育て、テック系、機械学習、読書などのトピックtolitoreyさん語学で遊ぶ、面白かった記事、本を読む、おうちなどのトピックmadobeさん読書、たわいもないこと、映画、ほしいものなどのトピック各ユーザ、おもいおもいのトピックを作成していて楽しそうです。(2) 他人のトピックをサブスクライブするTrickleでは「人をフォローする」という機能はありません。そのかわり「トピックをサブスクライブする」という機能があります。💡 インスタはハッシュタグのフォロー、Twitterはトピックのフォローという機能がありますが、ハッシュタグもTwitterのトピックもユーザ単位ではなくサービス全体で共通です。一方でTrickleのトピックはユーザ単位で独立したものです。トピック単位でサブスクライブすることで興味のある人の興味のあるものだけをみることができます。例えば僕はyujifさんの「ごま＆しお」、yohei-kikutaさんの「プログラミング」や「子育て」などのトピックをサブスクライブしています。僕がサブスクライブして見ているアクティビティまた、サブスクライブしているトピックが更新されると、通知が飛んでくるようになっています。これは「通知が来てもいいぐらい、本当に見たいものだけをサブスクライブしよう」というサービス設計意図です。サブスクライブするトピックを絞ったり、興味が薄れたトピックはサブスクライブを外すことを推奨しています。やや強い思想だとは思いますが、SNS疲れの原因の一つである「多くの情報を見すぎること」をサービス内で予防するためでもあります。(3) アクティビティをリンクする最後はTrickle内でのコミュニケーションについてです。といってもTrickleには「いいね」も「メンション」も「リプライ」もありません。このようなSNSによくあるコミュニケーション機能を提供していないのは、Trickleはあくまでも自分のアクティビティを書き留めていくサービスだからです。そのためコミュニケーションを強く誘発するような機能を公式には提供しないことにしています。その代わり「リンク」という機能を提供しています。リンクは自分のアクティビティに別のアクティビティを関連させるだけのシンプルな機能です（Twitterの引用RTみたいなもの）。このリンクとトピックを組み合わせることで、ユーザ自身が自分にあったコミュニケーションをできるようになっています。例えばいいねトピックや返信用トピックを作ったり、ブックマークのように使ったりというのを見かけます。このようにユーザが自分の求めるレベル感でコミュニケーションを取れること、公式にはハイレベルなコミュニケーション機能を提供しないことで、サービス全体としては割と静かでおとなしい雰囲気です。その結果、SNS疲れやバズることが起きづらくなっています。Q&AここまででTrickleがどういうサービスなのかはざっくり伝わったかと思います。以降では、疑問に思われるだろうなというものをQ&A形式で紹介していきます。Twitterと何が違うの？何が違うのかを整理するために、まずTwitterのアプリ紹介文を見てみます。一緒に会話してみませんか ツイッターは無料のSNSアプリです。日本や世界の最新ニュースや話題のトレンドをどこよりも早くお届けします。国内のニュース、国際情勢、音楽 、スポーツ、政治 、経済 など注目のトピックをフォローしてみたり、海外セレブのアカウントをフォローしてみてください。世界の最新情報はいつもツイッターが真っ先にお知らせします。世界中で人気のSNSでは、友達やあらゆる人とつながったり、世界に向けて自分の声を発信することができます。次にTrickleのアプリ紹介文を見てみます。書き留めておくアプリです。アクティビティはトピックというまとまりごとに書き留めることで、あとから振り返るときにも便利です。そして、他の人の興味のあるトピックがあれば、それをサブスクライブしてみましょう。Twitterは一緒に会話やつながり、発信というワードで表されるように、ユーザ同士のネットワークが主体のサービスです。「自分」はサブ的な要素です。それに対して、Trickleは書き留めるやサブスクライブというワードで表されるように自分が主体のサービスです。「ネットワーク」はサブ的な要素です。表面的にはTrickleでできることはTwitterと似ていますが、目指す構造（コンセプト）が違います。この目指す構造が違うので、サービス上での体験も細かいところで変わってきます。例えばTwitterではアプリを起動すると、フォローしている人も含めたツイートのタイムラインが表示されます。最近ではフォローしてない人のツイートも表示されたりもします。一方で、Trickleはアプリを起動すると、自分が書き留めたアクティビティだけが表示されます。※ ここでまとめたのはあくまでも「Twitterがどのような構造を目指して作られているか」であり、もちろんTwitterを「自分を主体」として使っているユーザもたくさんいると思います。何故作ったの？僕はTwitterが好きで2007年から利用していますが、2つ困ったことがありました。(1) その人のツイートについて、興味があるものとないのもが混在する例：日常の平和なツイートや技術的な話はみたいけど、仕事の愚痴やゲーム実況などは興味がない(2) xxについてツイートしたいけど、興味ない人がいたり、マウンティングみたいに思われないだろうか・・・僕はソフトウェア開発に加えて、料理や家族の話題が多いのですが、そういうのをツイートしづらいと感じてしまう他人を気にし過ぎでは？という気もしますが、そういう性格なので仕方ありません。それとTwitterはどんどん情報を詰め込んでくるのでこの流れが加速してしまいます。そうしてこれらがひどくなると、「徐々に自分が削られていく」ことになります。でもそんなに辛いなら、Twitterやめれば？という話なんですが、僕は「何かを書く」というのが好きな性格なので、自分の行動や思考を書き残したいとも思っています。それに興味のあるツイートもたくさんあるので、やはり見てると面白いです。そういうわけで僕は「自分が主体であり、自分への影響をコントロールしたい🧘でも完全に一人なのは少し寂しい😥」という気持ちに気づき、これを実現できるようなサービスとしてTrickleを作りました。※ これは僕個人の動機なので、利用してる他のユーザの動機とは必ずしも一致しないと思います。なのでTrickleに興味があればこの背景は気にせず一度使ってみてほしいです。○○機能は使えるの？Trickleは個人開発なのでスピードはゆっくりですが機能拡充をしています。今回のバージョンアップでいくつかの要望に答える機能をサポートしました。ソーシャルログイン機能（Googleログイン） ※デスクトップ版のソーシャルログイン機能は現在開発中ユーザブロック機能Web版のサポート。厳密にはユーザが自分のトピックやアクティビティをWebに公開できるというものです。ユーザ名の変更機能次はエクスポート機能やMarkdown対応をしたいと思っていますが、マイペースにやっていきます。また、よく要望として上がるプライベート機能（鍵アカウント、鍵トピック）は現時点ではサポート予定はありません。あると便利なのはわかっているのですが、サービスのサポートが複雑になるため見送っています。どんな人が作ってるの？個人サービスとして僕、丸山@h13i32maruが作っています。サービスやプロダクトを作るのが好きな人です。JasperというGitHub向けのissueリーダーなどを作っています。仕事はUbie Discoveryというところで働いています。もうちょっと詳しい話はh13i32maru.jpにまとめてあります。また、GitHubスポンサーも公開しているので、TrickleやJasperの開発を応援してくれる方はスポンサードしてくれると嬉しいです😍github.com最後までお読みいただきありがとうございました。Trickleに興味を持たれた方はぜひ使ってみてください。感想もお待ちしております。https://trickle.day/

見るより気兼ねなく書く、Trickleというサービス

今年からスクラムマスター(SM)を始めた。1ヶ月ほどたったので、「やってみて気づいたこと」や「具体的に取り組んだこと」を残しておく。ただし、僕はスクラムマスター研修は受けてない野良SM（？）である。なので、間違いとか超基本すぎることなどがあるかもしれない。やってみて気づいたことスクラムマスターの仕事は「スクラムチームを改善する」ことに尽きると思った。その観点で次の事が特に大事だと気づいた。「スクラムチームの改善」は「プロダクトの改善」と同じスクラムチームを一種のプロダクトだと考えて、課題見つける→PBIにする→解決するSMはスクラムチームの改善において、いわゆるプロダクトオーナー的な役割である司会・議事録係・ミーティング調整役ではないまずはとにかく透明性をあげるプロダクトオーナー(PO)、BizDev、エンジニア、デザイナー、ドメインエキスパート、SM、etcのやってることや頭の中を見える化するコミュニケーション量や回数を増やすことは見える化に重要コミュニケーションが生まれやすい仕組みをどんどん試してみるわからないことは率先して質問しまくってチーム内のコミュニケーション潤滑油にする改善結果はスクラムイベントに組み込む改善したものは仕組み化して継続していきたいそのために可能な限りスクラムイベントに組み込んで、自然と継続できる形にするとよい取り組んだこと色々やったけど、特に良かったなと感じたものをざっと書き出しておく。スクラムガイドを読み直したSMになったときに何をすれば良いのかわからなかったのでスクラムガイドを読み直した読み直したけど、やっぱり抽象的でよくわからなかったけど、↓を読んでスクラムチーム自体の改善をするとよさそうかな〜とぼんやり思ったチームにKeep/Changeアンケートを投げた具体的にどんな改善をすればいいのかわからなかったので、アンケートを投げてインプットをもらったスクラム改善を見える化したカンバンを作成して、アンケート内容をPBIとして積んでいった毎週一人リファインとプランニングをしているスクラム改善の進め方を考えた全部一気には無理なので、1スプリント(1week)で1改善を目安にすすめることにした当初は初速を重視して、改善の実務はSM単独でやることにしてみたやりたいPBIをみんなで話した積んだPBIを元にメンバー数名と各自がやりたいPBIを話した結構バラけたので、参考にしつつまずは何に取り組むかをSMとして意思決定したプロダクトオーナーとチームOKRについてめっちゃ話したOKRの背景、達成のための登り方、現在の状況、エピック、スプリントゴール、将来の展望などなど1on1で話した後、チームメンバー全員呼んで1onNでも話したこのチームOKRについて話す会は毎週行うようにしたマーケットの調査や検証のタスクもPBIにするようにしたこういうタスクはPOやBizDevがやってるけど、チームへの共有にばらつきがあったPBIにすることで見える化され、チームへの共有はもちろん、リファインメントやプランニングでも扱えるようになって透明性がめっちゃあがったスクラム改善で消化したPBIをチームの定期MTGで共有どんな改善をしたか、次どんな改善をしたいかを共有して、インストールとフィードバックを得るリファインメントのチートシート作成リファインメント時に重要な点をチートシートにして、認識揃えたり議論するのを忘れないようにするためまだブラッシュアップは必要そうリファインメントではWhy・Whatに集中して、Howはあまり話さないようにするこれは僕がやったというか以前からPOが意識してたけど、それをより意識するようにしていった次にやりたいことSMとしての動きについてチームメンバーからのフィードバックは好評だった。一方で次に改善すべき点も色々見えてきたので、それを試していきたい。具体的なHowの検討をより良い感じにしたい効果検証・学習・スプリントレビューなどの検査周りを良い感じにしたい可能な限りチームメンバー全員でSM業務をやれるようにしたい理由: 一人で改善するより全員で改善するほうが、視点や解決策などが多様になって強くなるはずだし、自己組織化にも有益そうだからスクラムイベントの司会や議事録業務をチーム内で回すスクラムチーム改善をチームメンバーも消化できるようにするそのためにはスクラムチーム改善の型を作る必要がありそうスクラムチーム改善もスクラムで回せるようにして、SMがそのPOをするようなイメージSMの仕事というような内容を書いて下書きを社内に公開したら、他のスクラム経験者からめっちゃ良いフィードバックをもらったこのフィードバックを受ける前は「SMの仕事はチーム改善」と思っていたけど、真の仕事は「チームの自己組織化（自己管理型）の推進」というのに気付かされた。自己組織化が重要そうというのはふんわり思っていたけど明確に意識はできてなかった。この真の仕事をするために、具体的な手法として次のようなステップを経ていきそうだと思った。ステップ1: スクラムイベントを運営する人ステップ2: チーム改善する人ステップ3: チームにチーム改善を浸透させる人今回僕がやったのはステップ2で、この記事もそこの即した内容になってる。そして「次にやりたいこと」で書いたのはステップ3をなんとなく意識していた感じだったんだなと。こういうフィードバックもらえるのめちゃ助かる。感謝。色々新しい発見があったので、SMに挑戦してみてよかった。スクラムやSMについて雑談するMeetyも作ってみたので興味有る方はぜひ！meety.net丸山@h13i32maru at  Ubie Discovery

スクラムマスターは「スクラムチーム改善」のプロダクトオーナー

TL;DR本記事は「2つの仮説をもとにした雑談の考察」仮説: 物理雑談とリモート雑談は対立関係ではなく相互補完関係仮説: 物理ワークとは違う、リモートワークならではの雑談が生まれやすい仕組みが必要まとめ: リモート雑談はデジタルであることのメリットを活かすようになっていきそう「Gather」良いCOVID-19の影響で仕事はリモートワークになり、そしてほぼ同時期に子供が産まれ子育てを始めた。COVID-19はしんどいけど、一方でリモートワークはめちゃくちゃありがたい。リモートじゃなかったら仕事と育児家事を両立するのは無理だったと思う。もう物理100%の以前の勤務スタイルには戻れない。もし戻ったら確実に生産性がめちゃくちゃ落ちる。なので、今後もリモートワークで働きたい。技術の進歩であったり、会社での取り組みであったりでリモートワークでもかなり普通に働けている（みんなが一斉にリモートワークになったというのもすごく大きい）。ただし、「（仕事に関係する）雑談」に関しては物理のほうがいいという話をよく聞く。自分も半分は同意するんだけど、半分は違和感がある。違和感はだいたいこんな感じ。物理雑談 vs リモート雑談なんだっけ？これまで物理の雑談だけだったので、リモート雑談の最適化ができてないだけでは？リモートでの雑談にもいいところあるし、楽しいものもあるよ？物理雑談とリモート雑談は補完関係そこで、一つの仮説をたててみた。仮説: 物理雑談とリモート雑談は対立関係ではなく、補完関係にある。例えば「外食をする」と「食事のデリバリーを頼む」は利用者側にとっては対立関係ではなく補完関係にあると思う。前者はお店の雰囲気なども含めたトータルの美味しさ、後者は好きなものを手軽に食べれる美味しさ。他にも「音楽のライブ」と「音楽のサブスク」も補完関係にありそう。こんな感じで物理雑談とリモート雑談も補完関係にあるのではないかと。ただし、現状のリモート雑談は物理雑談を補完できてないので、対立関係のように捉えられてしまっていると。もしくはリモート雑談で物理雑談を再現しようとしてしまっている（でも再現できなくて、物理がいいねとなる）。雑談のスコープ仮説を掘り下げる前に、今回扱う雑談のスコープは次のようなものとしておく。リモートワークが中心の会社での雑談とする今回扱う雑談は「仕事に関係する話を複数人の同僚でカジュアルに行うもので、ミーティングとは違いインフォーマルなもの」仕事に関係ない趣味やプライベートに関する雑談はスコープ外この雑談によって得たいものは「参加者の情報同期とコラボレーション」物理雑談は実際に対面でする雑談、リモート雑談はインターネットを使ってする雑談リモート雑談も同期的に行うものに限定する。例えばSlackなどのチャットツールによる雑談は非同期なので今回は除外するZoomやGoogle Meetでの雑談を想定している雑談の特性とマルバツ表仮説の通り補完関係にあるとするなら、次のことを思考してみるのがよさそうだ。物理雑談の強いところ弱いところを把握するリモート雑談でその弱いところを補完して、強いところは物理に任せる仕組みを考えるこの前提の上で、雑談の特性とマルバツ表を考えてみた。 特性  物理雑談  リモート雑談(現状)  参加可能な人数  ◯  △  途中参加のしやすさ  ◯  △  雑談しているのをすぐに発見できるか  △  △  雑談の内容を後から知れるか  ✕  ✕  五感を含めた情報量や熱量の多さ  ◎  △  開催の手軽さ  ✕  ◎ ※これは5分ぐらいで考えた粗いものである。他にも特性はありそうだけど、そこはあまり精緻化せずこれでいってみる。あくまで仮説の方向性がありなのかを思考実験するためのものであるため。リモート雑談で物理雑談の何を補完するかこのマルバツ表によるとリモート雑談で物理雑談を補完するには、「雑談をすぐに発見できるか」と「雑談の内容を後から知れるか」について最適化が必要である。これはリモート雑談がデジタルであることのメリットを活かせそうである。とりあえず思いついたのは次のような方法だ。どこかでリモート雑談が開始されると、Slackのチャンネルに通知され、発見しやすくするZoomやMeetのURLも一緒にあればすぐに参加できそう常になのか、任意なのかは論点ありそうリモート雑談の録画・文字起こし・要約・カテゴリが配信され、検索可能となっている雑談内容が検索可能になることで、なんとなく不安感を持つ人もいるかも知れないそれと、技術的難易度が高そうか？一方で、すでに物理雑談で◯や◎となっているものは、リモート雑談で最適化は必須ではなさそう（してもよい）。また、「開催の手軽さ」は物理雑談✕、リモート雑談◎なのでこれは維持したほうがよさそう。これまでは物理雑談とリモート雑談が相互補完にあるという仮説を元に色々考えてきたが、次は視点を少し変えてみる。リモートワークで雑談が生まれやすい仕組みが必要実際のオフィスの場合、「会話が生まれやすいような導線や部屋などを意識したレイアウト設計をする」というのを聞いたことがある。同じように物理ワークとは違う、リモートワークならではの雑談が生まれやすい仕組みを設計する必要があると考えてみる。ではどんな仕組みを設計すればよいのか？物理（オフィス）ワークからリモートワークへ変化したことによる影響を元に考えてみることにする。今思いつくのは次の2点だ。相手の仕事の雰囲気が見えないスキマ時間を効率的に使ってしまう相手の仕事の雰囲気が見えないリモートワークになったことで、雑談のハードルがあがったという声をよく聞く。これは「相手の仕事の雰囲気が見えないので話しかけて良いのかどうか分からない」というものだろう。相手が集中して作業をしてるのか、それとも話しかけてもよさそうな感じなのか。もしくは他の誰かと話しているのか、離席しているのかとか。これは物理ワークだったときは相手が今どういう雰囲気で仕事をしているかは見ればなんとなくわかったので、それに応じて話しかけるかどうかを判断できた。リモートワークでもとりあえずSlackなどで話しかけてみて、レスがあれば雑談する。レスがなかったら集中してるんだなと思って諦める。というのをすることもできる。できるが、僕はレスがないとちょっとさみしいなと感じてしまうので苦手である。スキマ時間を効率的に使ってしまうミーティングとミーティングの合間、タスクが切りよく終わった瞬間など、物理ワークならこういう瞬間は絶好の雑談タイミングである。しかしリモートワークだとそのタイミングに細かい雑務を片付けたり、Slackを巡回したり、外の空気を吸いに行くなどをしがちである。雑談を誰かに振るというのをしない。これは前述の「相手の仕事の雰囲気が見えない」というのもあるだろうし、リモートワークだと何故か（？）スキマ時間を効率に使わねばと思ってしまう。理由はうまく言語化できないが。見える化 and/or 定期開催これら2つの問題を解決する仕組みとしては、例えば次のような方法がありそうだ。仕事の雰囲気を見える化するSlackのステータスを都度変更するというので可能そうだけど、もうちょっといい方法がほしいように思う雑談を定期開催にする毎週や毎日の決まった時間に雑談を開催するこれは割と行っているところも多そうで、前職では帰りの会というのを実施していたリモートワークで雑談が生まれやすい仕組みは他にも色々必要かもしれない。が、そういう仕組が必要そうというのは方向性としては正しそうな気がする。「Gather」良いという感じで、雑談について頭にあったものを吐き出してみた。ちょうど会社(Ubie Discovery)で物理とリモートでの雑談*1について話題になっていたのもあるため。で、これを書いてる間に社内ではGatherというサービスがまたたく間（まじで1, 2日で)に浸透して、Gatherでするリモート雑談めっちゃ良いじゃんとなった。Gatherはサービスの作り込みが結構されているのもあるが、前述した物理雑談を補う点や、リモートワークで雑談が生まれやすくなる仕組みが作られている。雑談をすぐに発見できるか？人が会話している、集まっている様子が可視化されているのですぐに発見できるただし、Gatherの画面を見ていないと雑談には気づけ無いこれはまあ物理雑談もそういうものだと思うので、現状でも十分だと思う相手の仕事の雰囲気が見えない静かにするモード(Quiet Mode)であったり、PCデスクの前に座るなどで集中状態を可視化できる逆に談話スペースにいることで雑談可能を示せるちなみに通常のミーティングもGatherで行われつつあるので、他チームのミーティングにふらっと参加してコラボするというのも発生している。他にも自分のデスクトップ画面を共有して、作業風景を垂れ流しながら仕事をしてる人もいたりする。要はデジタルであることのメリットを最大限活用して、物理では難しかったコミュニケーションの体験を作れるのである。だからといって、Gatherによるリモート雑談だけでよくて物理雑談は不要とはならなさそうだ。あくまでも相互補完という感じがしている。一方で、Gather単体では解決が無理そうなものもある。雑談の内容を後から知れるか？録画機能は他のアプリを使って頑張ってねという感じぽいスキマ時間を効率的に使ってしまう個人的にはこれは意識的に雑談時間を設けたり、定期開催するので良いかなと思っているリモートワーク中心になり、（仕事に関係する）雑談に悩みを持っているなら、Gatherは試してみるのはおすすめである。ゆくえというわけで、穴だらけの論理展開だったが、これまでの考えをまとめるとリモートワーク下における物理雑談とリモート雑談のゆくえは次のようになると思った。物理雑談熱量や雰囲気といった言語化しづらいものも含めた体験を必要とするときに行う例えば期初やプロジェクト発足時のキックオフだったりオフサイトみたいなものリモートワーク中心の会社では手軽な開催はやや難しいので、頻度や内容の工夫もあるとよさそうリモート雑談デジタルで行うことのメリットを活かし、物理では実現が難しい体験を模索して、物理と相互補完する例えばちょっとしたアイデアについて話したい、隣のチームの雑談やミーティングにふらっと参加するなど手軽に開催できるので、思い立ったらすぐに開始するぐらい俊敏にやるこのあたりの話は論文があったり、リモートワークを何年もやってる会社が知見をまとめていたりしそう。誰かがいい感じの記事を書いてくれるのに期待。2022年は雑談をもっと雑にやっていきたい。丸山@h13i32maru*1:社内では「ただ話す」と呼ばれていて、少しニュアンスは違うが

物理雑談とリモート雑談のゆくえ

社のみんなが一年の振り返りブログを書いてて、僕も何か書くか〜という気持ちになった。が、あと2,3ヶ月でUbie Discovery(以下Ubie)に入社して一年たつので振り返りはその時にしようと思う。というわけで（？）、今回はこの一年で遭遇した社の化け物メンバー(=めちゃくちゃすごい人)を勝手に紹介する自己満足記事を書くことにした（ブログはいつも自己満足だよな？）。ちなみにここに記載したのは直接一緒のチームで働いた人を中心に書いた。社には他にも化け物がたくさんいる。@sys1yagi @maguhiro @shikajiro @NishimuuuuR @smurakos @takayamag 直接一緒に働いたことはないけど他にも@sonopy_uさん(組織開発の化け物)、@itkqさん(SREと事業ブリッジ*1の化け物)、@yohei_kikutaさん(クソリプ・雑コラの化け物)とかもいる。いやー、本当に化け物ばかりでやばい。こうやってすごい人のことを紹介すると自分もすごい人になれる気もするが、そんなことはないので僕は人間としてぼちぼちやっていきます。*1:SREのポジションから事業にめちゃ貢献したり事業にSRE観点を注入してるというの言語化したかった

社の化け物メンバーを勝手に紹介する

こんにちは丸山@h13i32maruです。すごい今更ながらNext.jsに入門したので感想をメモしておこうと思います。入門資料@hokacchaさんがクックパッド社のインターンシップ用に公開している動画を見て入門しました。要点がコンパクトにまとまってるので、これを見れば基本は理解できるようになってよかったです。SSGCodeLunch.fmのサイトをNext.jsのSSGで作り直しました。もともとreact-dom/serverのrenderToString()を使ってなんちゃってSSGを自前で実装していたので、移行は簡単でした。getStaticPropsやgetStaticPathsの仕組みはうまいこと考えられてていいな〜と思いました。それと、データを特に持っていない本当の静的サイトでもNext.js使ってSSGで作るのは良さそうと思いました。サイト内のパーツをReactコンポーネント化できるので。TypeScript連携特に何も考えず.tsxでファイルを作ってNext.jsを起動すれば、TypeScriptの使用を検知してtsconfig.jsonを吐き出してくれて何も設定いらずに使用できました。すごい快適。ただtsconfig.jsonのstrictプロパティはtrueに変更したほうがよさそう。あと、公式ドキュメントにもTypeScriptセクションがあって、TypeScriptでの書き方（主に型の付け方）がまとまっていて便利でした。SSR自分の家庭内で使う「子供の献立作成アプリ」を作るのにSSRを使ってみました。CSRでも良かったんですが、近々別のサービスでSSRを使う予定だったので。SSGと同じ要領でgetServerSidePropsを実装すればSSRできるのはすごい簡単でした。Next.jsのSSGやSSRの抽象化の仕組みは仕様がシンプルなのに、やれることに制限がなくていい設計だなぁと思いました。SSR/SSGをする他のフレームワークを使った事ないので他と比較してどうかはわかりませんが。サーバ/クライアントSSRで実装していると、サーバ側で動くコードとクライアント側で動くコードが頭の中で混乱しました。pages/配下から呼び出されるコードはSSRするときにサーバ側でも動くし、クライアント側でも動く（ハイドレーションされる）というのは理解はできてても難しいですね。このあたりは書いていくうちに慣れては来ましたが、たまに「あれ？なんでここエラーになるんだっけ？？」みたいなのがあって「あ、これはサーバサイドでしか動かないコードだったわ」みたいなのがあります。ディレクトリ構成Next.jsではpages/とpages/apiしかディレクトリの規則がないので、自由に構成することができます。そこでどんな構成がいいのかがちゃがちゃして今のところは以下の構成になってます。./src├── client│   ├── Repo│   └── Component│       ├── Fragment│       ├── Page│       └── View├── pages│   └── api├── server│   ├── ServerRepo│   └── Route└── typepages/にはコンポーネントの実態はおかずに、getServerSidePropsの実装に集中するようにしています。// ----------------------------// src/pages/FooPage.tsx// ----------------------------export default function page(props: FooPageProps) {  return <FooPage {...props} />;}export const getServerSideProps: GetServerSideProps<FooPageProps> = async (context) => {  return ...;}// ----------------------------// src/client/Component/FooPage.tsx// ----------------------------export type FooPageProps = {...};export const FooPage: React.FC<FooPageProps> = (props) => {  return ...;}src/clientとsrc/serverに分けたのはなかなか分かりやすくて良いんですが、SSRをしている都合上src/client/Component配下のコードはSSR時にも実行されます。もうちょっとしっくりくるディレクトリ構成がほしいな〜と思いました。API Routeものすごい素朴な感じですね。HTTPリクエストメソッドに応じたルーティング的なものもありません。ここはもうちょっと仕組みがデフォルトでほしいところです。でもexpress.js風なシンプルさは安心感がありました。next/linkパラメータ定義をファイル名に埋め込んだルーティングは最初ちょっとびっくりしましたが、すぐに慣れました。そういう規約のおかげで、画面遷移もnext/linkを使って簡単に書けるのがよかったです。ただ、遷移元で遷移先のパスを愚直に文字列で組み立てる方法だと、パスが変わったときやパラメータ定義を変えたときなどに困りますね。なので遷移先でURLを組み立てる関数を公開するとかの工夫をしたほうがよさそうだなと思いました。あと、SSRだと画面遷移時にURLは変わりますが、ブラウザのローディングバーなどが動きません。これはHistory APIを使ってるからだと思います。その結果、画面遷移が体感的に遅く感じてしまいます。なので、pages/_app.tsxのなかでrouter.eventsを使い、画面遷移時に独自のローディングバーを表示するようにしました。// src/pages/_app.tsxexport default function MyApp({ Component, pageProps }: AppProps) {  const [loading, setLoading] = useState(false);  const router = useRouter();  useEffect(() => {    router.events.on('routeChangeStart', () => {      setLoading(true);    });    router.events.on('routeChangeComplete', () => {      setLoading(false);    });  }, []);  return (    <>      <Component {...pageProps} />      <Loading enable={loading}/>    </>  );VercelVercelめっちゃ便利。デプロイが超簡単でした。Next.js使った簡単なアプリならこれで十分です。ただし、問題はデータストレージです。今回作ったアプリは家庭内で使うだけのアプリなので、ファイルにJSONをただ書き出せれば良かったんですが、Vercelではファイルアクセスはできません（そもそもサーバレス）。かといって、RDBMSをどこかにたてて、そこにVercelからつなぐようにするのも面倒そうだなと思ったので、今回はGitHubのgistにデータを保存するようにしました。gistはGitHubのアクセストークンと@octokit/coreがあれば簡単に読み書きできます。まあレイテンシーとか処理時間とかは遅いですが。あとは毎回JSONをフルで読み書きする必要があるので、同時アクセスでぶっ壊れます。なので雑な排他制御を実装してお茶を濁しました。Vercelにデータストレージもついていればまじで完璧なんだけどな〜。低スペックなRDBつけてくれないかな。sqliteベースでもいいので。その他.envが何もせず使えて便利でした。しかもVercelには環境変数を設定する機能もちゃんとついてて快適。styled-componentsを使ったんですが、ちょっとだけ追加設定が必要でした。https://github.com/vercel/next.js/tree/master/examples/with-styled-componentsreact-beautiful-dndを使うのにも少しだけ設定が必要でした。https://github.com/atlassian/react-beautiful-dnd/blob/master/docs/api/reset-server-context.mdまとめNext.jsはすごく快適に開発できてめちゃくちゃ良かったです。ReactなどのWebフロントエンドエコシステムとサーバサイドをいい感じに連携させるのは大変という課題をよく聞きます。Next.jsはその課題を、Webフロントエンド特にReactを開発の中心に持ってくることで解決しているんだなと思いました。ただ、React/TSが初めての人が独習していくのは大変そうだな〜と感じました。まあこれはNext.jsやWebフロントエンドに限った話ではないと思いますが。というわけで、久々に新しいツールにちゃんと入門して楽しかったです。現職のUbie Discoveryで、Nuxt.jsからNext.jsへ移行した話とかもあるので興味ある方は是非。

今更ながらNext.jsに入門した

@h13i32maruUbie Discoveryに入社して半年がたった。半年働いてみて、これまで働いてきた会社と比べて違うなと感じたことが結構ある。それらを忘れないように残しておこうと思う。ちなみに個人的に感じたことや解釈なので、ズレていることがあるかもしれないのであくまでも主観ということで。人ではなく仕組みやコトを管理組織運営に組み込まれた権限委譲徹底した目標設定と運用人事評価をしない意思決定人ではなく仕組みやコトを管理Ubie Discoveryではマネージャーと呼ばれる人はいないし部長などの役職もない。じゃあどうやって組織を運営しているかというと、そもそも「人や人の行動を管理（マネージ）する」という管理スタイルではない。Ubie Discoveryで管理しているものは「目標・目標達成の方法・様々な型（プロセスやフレームワークのこと）」などの仕組みやコトである。そして管理する対象が人ではないため、上司部下という関係は不要になる。更に面白いのが、仕組みやコトの管理は全社員がそれらを管理するというのを（理論上は）行える。これによって全社員に当事者意識や全社目線というものが生まれやすくなっていると思う。これは人が人を管理するというスタイルでは役職の階層構造が生まれるのでどうしても難しいことであり、仕組みやコトを管理するスタイルのメリットだと思う。一方で、人が人を管理することをしないので、「モチベーション維持」「成長やキャリアのサポート」などの個人的な事情については手薄になりがちである。そのためUbie Discoveryではそのあたりについて自分でなんとかできるタフさが求められるように思う。もちろん、相談にいけばみんな快くサポートしてくれる。組織運営に組み込まれた権限委譲これまで働いてきた会社でも権限移譲というのはあった。しかし、「どのような権限を・どれくらい移譲するか」というのは移譲する側によって濃淡があり、組織全体で統一されていなかったり、不透明だったりする。Ubie Discoveryでは、どのような権限をどのようなプロセスを経て移譲していくかが組織運営に明確に言語化されて組み込まれている。これは共同代表の二人から各チームへの権限移譲でも、各チームからさらに小さなチームへの権限移譲でも同じである。つまり権限移譲する側によって濃淡がなく、社内のどこでも統一された方法で運営される。このように権限委譲が浸透しているため、トップやマネージャーが全て意思決定するよりも、現場で課題に向き合ってる人々がスピード、質、多様な視点を持って意思決定できる。さらに権限移譲は人に移譲するのではなく、全社目標を階層構造に分解したときの、その目標（正確にはその目標を達成する役割）ごとに移譲される。この役割（≠役職）というのも統一的に決まっている。例えばチームに人をアサインする役割、親チームとの連携を行う役割、議論をファシリテートする役割などである。これにより権限と人の結びつきが緩和されて、流動性が生まれやすくなっている。例えば一般的に「部長」という役職を一旦人に与えてしまうと、さまざまな理由によりその人から部長という役職を剥がすことは難しい。しかしUbie Discoveryでは先月まではリードの役割にアサインされていた人が、次は全然別の役割をやるといのは日常的に起きている。とはいえ、これは仕組みだけの話だけではなく、各自のマインドによるところも大きいと感じている。余談だが、社内では「willがある仕事をやるのが一番パフォーマンスが出る」という原則のもと異動がすごく推奨されている。そして、実は権限移譲だけでなく組織運営自体が明確に言語化されている。というのもUbie Discoveryではホラクラシーという組織運営のフレームワークを採用しているからだ。ホラクラシーとはティール組織の具体的な実装である。ここで書いた権限移譲や役割、それを決めるプロセスなどはすべてホラクラシーにより規定されている。ここまで組織運営が明文化されて、実際にそのとおり運営されている組織というのはこれまで全く経験したことがなかったので非常に新鮮で良いなと思っている。一方でその組織運営になれるには時間と学習コストを要する。まだその仕組に慣れていないので「こういうときはどうするんだっけ？」というのがちょいちょい発生する。徹底した目標設定と運用「仕組みやコトの管理」「権限委譲」が組織の根幹にあるため、そのままでは各自が良いと思う方向にバラバラに進んでいき、組織力を発揮しづらくなってしまう。そこでUbie Discoveryでは目標設定と運用にめちゃくちゃ労力を割いている。まず目標設定についてだが、共同代表の二人がトップダウンの目標を準備する。それと同時に各チームもボトムアップの目標を準備する。そしてこれらの目標を共同代表と各チームの代表でアラインして全社目標とチーム目標を作っていく。この目標設定で面白いのが目標だけではなく、それを達成するための大枠の方法についてもセットで決めていくことである。社内ではそれを「目標の登り方」と表現しているが、いわゆる戦略のようなものだと思っている。このようにして全社目標とチーム目標を一旦決める。ちなみに個人目標は決めていない。一旦と表現したのはこの目標が発表された翌週にUbie Discoveryの全メンバーでそれらの目標について議論したり、不明点を質問したりというのを一日かけて行い、最後の調整をするからである。この目標の発表と最後の議論がすごい熱量で行われる。正直僕はこれまで働いてきた中で、目標の発表や議論についてここまで熱量高く行われるというのを体験したことなかった。そしてなんと、この目標設定は四半期ごとに行われる。ものすごい労力が必要だけど、事業環境はすごいスピードで変わっていくので少なくとも四半期ごとにする必要があるのだと思う。目標は設定するだけではなく、実際に運用してこそである。そこで、Ubie Discoveryでは毎週のWin Sessionというミーティングで各チームから目標について進捗や良かった点、問題点を共有している。これが毎回大いに盛り上がる。また月に一回、共同代表とチームが目標についてリファインしている。同じく月に一回、共同代表からUbie Discoveryの全メンバーに対して売上やプロダクトの導入数、今月のハイライトなどの共有がある。もちろん日々の開発中にもこれらの目標は頻繁に参照される。そしてこのような運用を通して、目標は期中にも変わっていくことがある。というのもこれは事業環境の変化、不確実性が減ったり、新たに学習したことなどにより、より良い目標が見えてくるからだ。ここまで目標設定と運用に力を入れており、社員全員がその目標に対してすごい熱量を持っていて、それを起点にすべての物事が動いているというのはこれまで経験したことがなかった。なので、最初はめちゃくちゃビックリした。一方で、この目標とその登り方がだいぶコンテキストが高い内容になっている。これは四半期もしくはそれ以上のスピードで目標や登り方が変わっていくので、その字面だけを見てもだめでちゃんと各事業の状況を理解できている必要がある。なので入社当初は日本語は読めるけど内容が全然わからんという感じだったので、同僚に解説を何度もお願いしたりした。というか今でも自分が所属するチーム以外の目標や登り方は完全に理解できているかというと怪しい。ちなみにUbie Discoveryでは目標のフレームワークとしてOKRを採用している。人事評価をしない意思決定Ubie Discoveryでは人事評価をしないということになっている。人事評価が無いのではなく、しないという意思決定をしているのだ。なぜそのような意思決定をしているかというと、「 事業の不確実性が高い状況では各々の事業貢献を正確に把握できないため」「自分をよく見せようという政治的な動きを排除するため」「人事評価にはコストがかかるので、そこにコストをかけるより事業を進めるほうがRoIがよいため」などの理由がある。詳しくはUbie Discoveryのメンバーが書いた以下の記事を参照してほしい。報酬設計などについても書かれている。この人事評価が無いというのは個人的には非常に快適である。これまで人事評価をする・されるの両方を経験しているが、時間も体力も精神力もかなりコストがかかる。そしてその上で正解が無い。この難しい問題から開放されて、事業やプロダクトに集中できるというのはかなりのメリットである。人事評価はなくても事業をすすめる上での各自へのフィードバックというものは存在している。フィードバックを欲しいと思った人がフィードバックをもらいたいと思う人を指名して、フィードバックを書いてもらうというものだ。これはいつでも誰でも実行することができる。僕も何度か指名してフィードバックをもらったことがある。フィードバックをもらうのは気軽な一方で、フィードバックを書くときは僕は苦労している。僕は前職でマネージャーをしていたときがあるので人事評価の際はメンバーにフィードバックを書くこともやっていたのだけど、Ubieでフィードバックを書くときはどうしてもその時と比べると質が落ちているように感じる。マネージャーだったときはしっかりメンバーの業務を見たり、1on1で話を聞いたりなどしていたため、それに基づいてフィードバックを書けていたと思う。また人事評価もあったのでいわゆるグレードと呼ばれるようなものがあり、そこに「このグレードならこういう成果や能力を持っている」と記載があるため、それと比較してフィードバックをすることができる。Ubieではそういうマネージャー業やグレードというものは一切ないのでフィードバックの質が落ちるのかなと思っている。ただ、じゃあコストをかけようというのは「人事評価をしない」という意思決定に対して本末転倒である。この点についてはなにかいい方法がないかなとたまに考えたりしているが、今の所あまりよい仮説をたてられていない。という感じで割と独特な組織なので、人によっては好き嫌いや合う合わないがある。そのため「採用」についてもこれまでとの違いを感じることが多い。他にも「日々の開発」「エンジニアリング」などについても違いを感じたものがあるのだけど、それらは今度書くことにする。もしこれを読んでUbie Discoveryに興味を持った人は以下を参照してほしい。Ubie Discoveryの紹介資料Ubie DiscoveryのカルチャーガイドUbie DiscoveryメンバーのMeetyそれと、Ubie Discoveryに転職〜入社1ヶ月までの話も書いてるので興味があれば参照してほしい。転職の意思決定（クックパッド → Ubie）入社して一週間、素早く生き残るためにやったこと（Ubie）入社一ヶ月の分報戦記（Ubie）

Ubie Discoveryに入社して感じた「これまでとの違い」

こんにちは丸山@h13i32maruです。つい先日、devchat.fmというポッドキャストに出演して、「ドキュメント」というお題について話しました。なぜこんなニッチなお題について話したかというと、Ubie Discoveryに入社して5ヶ月の間にいくつか*1まとまったソフトウェアドキュメントを書いたので、自分の中でホットな話題だったからです。#devchatfm 33回目は、Ubie DiscoveryのSWE @h13i32maru にドキュメントを書くことで得られるメリットや、ポイント・工夫などを聞きました！#33 チームの生産性を上げるドキュメントのすすめ with@h13i32maruhttps://t.co/TrmZd13D91— 久保 恒太 / Ubie CEO (@quvo_ubie) 2021年8月12日  これらのドキュメントは個人的にわりと良く書けたと思ってますし、他のソフトウェアエンジニア（以下SWE）からも「わかりやすい」「すごくいい」などの感想をもらいました。それに気を良くしてdevchat.fmでもべらべらと喋ったのですが、せっかくなのでちゃんとまとめておこうと思ってブログに書くことにしました。今回はソフトウェアやシステムの内部構造を説明するドキュメントについての話です（システムドキュメント、ARCHITECTURE.mdなどと呼ばれるようなもの）。ユーザマニュアル、Design Doc、ADRなどのドキュメントについてはスコープ外です。それと僕はテクニカルライターとかではなく、ドキュメントを書くのが好きな普通のSWEです。なので的はずれなこと書いてたらごめんなさい。# なぜドキュメントを書くのか# どんなときに書くと良いのか# 意識してること## メンタルモデル## 俯瞰## レイヤー## 推測## その他# ドキュメントの問題## メンテナンス## 保存場所# なぜドキュメントを書くのかドキュメントを書く理由は人によって様々かもしれませんが、僕の場合は「ドキュメントにより、そのシステムをスムーズに理解できて、コードの読み書きを効率的にできるようになるため」です。例えばドキュメントを読んでから、システムのコードリーディングをすると、所要時間が半分になるならすごい時間の節約になりますよね。そのシステムに関わる人が多ければ、ドキュメントを書くのに使った時間を回収することができると思います。つまり、ドキュメントをアセット（資産）にすることで、生産性を上げたいということです。極論、一人で開発してるならドキュメントは不要なことが多いです。しかしチームで開発している場合は、ドキュメントがあるおかげで新しくチームに入った人がスムーズにシステムを理解できれば、生産性が上がるはずです。そしてシステムに触れる人が多ければ多いほど、そのドキュメントのRoIは良くなります。# どんなときに書くと良いのかなんでもかんでもドキュメントを書けばよいというわけではありません。前述したとおり、RoIが良いと予想される場合に書くべきです。具体的には以下のようなシステムや機能についてはRoIが良くなりそうだと思っています。社内のSWEにあまり実装経験が無いようなシステム事業ドメインのコアでいろいろなSWEが触るようなシステム世間一般に情報が無い社内独自のシステム逆に以下のようなものはRoIが悪いかなと思っています。Webや書籍などの情報が十分にあるシステム社内のSWEに実装経験が豊富なシステムプロトタイプなど頻繁に実装や設計が変わるシステムとはいえ、このあたりはまだ自分の中でもふわっとしてるところです。# 意識してることコードの読み書きを効率的に行えるようなドキュメントを書くためにいくつかのことを意識しています。特に「メンタルモデルの構築」は重要だと思っているので、そのあたりを中心に紹介していきます。Ubieで書いたドキュメントを公開できると良かったんですが、流石に内部向けドキュメントすぎるので断念。## メンタルモデルコードの読み書きをスムーズに行うには、脳内にそのシステムのメンタルモデルが構築されているかどうかにかかっています。メンタルモデルとは「そのシステムの設計や実装について推測可能になる」ということです。例えば「ここがooってことは、多分あれはxxだろう」とか「この機能を追加するにはあのあたりのコードに手を入れればよさそう」などです。このメンタルモデルというのは「コードを読む → 脳内で抽象化する → モデルとして組み立てる」という感じで構築されていきます。しかしこれをコードを読みながら行うのはすごく大変です。というのもコードは最も細かい粒度で書かれておりそれを読み解くのは脳内メモリとCPUをかなり使いますし、そもそもコードはメンタルモデルの構築を目的に書かれていません。そこで、ドキュメントの出番です。メンタルモデルを構築することを目的に書かれたドキュメントを読むことで、コードを読みながら行うよりも遥かに効率的にメンタルモデルを構築できるようになります。メンタルモデルの話は以前に書いた記事も参照してみてください。以降の話はすべてこのメンタルモデルをスムーズに作れるようにというのを意識したテクニックです。## 俯瞰ドキュメントにはまず対象システムの俯瞰から書き始めます。その俯瞰も詳細には書きません。読む人がほぼほぼ知ってそうなレベル、わかりきってるレベルから書き始めます。そうすることで読者の現在の理解とのギャップを最小限にして、スムーズに読み始められるようにします。そしてまずは最も抽象度の高いレベルのメンタルモデルを構築できます。システムドキュメントでよくありがちなのが、いきなり詳細な設計図、ER図、フローチャート、UMLなどから始まるものです。これは読者の現在の理解とギャップが大きすぎるので、理解が難しくなります。それに、そのレベルで詳細な場合はコードを読むのと変わらずメンタルモデルの構築も難しくなります。書き手の頭にはすでにメンタルモデルが構築されているので、いきなり詳細から書き始めたい欲求はありますがぐっと我慢します。## レイヤー俯瞰した内容から徐々にブレイクダウンした内容を書いてきます。アーキテクチャ、コンポーネント群、処理フローなどなど。このときに1つのセクション内で書く話題はレイヤー（抽象度）を揃えることを意識します。例えばあるウェブサービスの設計についてのドキュメントがあるとします。その中のコンポーネントについて書いたセクションで、APIサーバ(Rails)セッションサーバ(Redis)マスターデータ(Postgresql)FooService(Rubyのクラス)と並べてしまうと、FooServiceだけ別レイヤーのコンポーネントで浮いてしまいます。他にもテキストエディタの設計についてのドキュメントがあるとします。その中の処理フローについて書いたセクションでユーザ入力キャレット制御入力テキスト取得パースHTML更新と並べるとキャレット制御だけ他のものに比べて詳細すぎます。このように1つのセクション内に別レイヤーの話題が入ってくると、そのセクションの理解が難しくなり、結果としてメンタルモデルの構築が阻害されてしまいます。この考えはプログラムを書いてるときと同じ考えです。レイヤードアーキテクチャだったり、SLAP(Single Level of Abstraction Principle)と呼ばれるものですね。そしてここからわかることは、レイヤーをちゃんと分けてドキュメントを書くためには、そのシステムの設計自体もまた正しくレイヤーを分けて作られている必要があるということです。なので、もしドキュメントを書いていて、うまくレイヤーに分けて書けないなと感じた場合は、システムの設計になにか問題があるかもと思ってチェックしてみると良いかもしれません。## 推測メンタルモデルを「そのシステムの設計や実装について推測可能になる」と説明しました。人が何かを推測するときは「因果関係から推測（演繹的）」と「パターンから推測（帰納的）」があります。なのでドキュメントにもそれらの要素を入れることで、メンタルモデルを構築しやすくなります。具体的に僕が意識して書いてることは以下のような点です。因果関係から推測（演繹的）エディタ上にReactコンポーネントをマウントする必要があるので、パフォーマンスが必要インクリメンタルビルドはフルビルドと比べたときにパフォーマンスが良い一方で、実装は複雑になりがちで潜在的な不具合があるかもしれないこの補足により「エディタのパフォーマンス改善をするにはインクリメンタルビルド周りに手を入れる必要があるかも」「テキストを編集中に特定条件下だと不具合が起きるのはもしかしたらインクリメンタルビルド周りが怪しいかも」などの推測ができるようになります。パターンから推測（帰納的）未回答の質問チェック主訴の質問チェック症状の深堀り質問チェックこれによって「病院固有の質問はこれらと並列に実装されてそうなので、多分あの辺りから読めば良さそう」「ooという質問を追加したいけど、これらの質問と並列ではなさそうだから、症状の深堀り質問の中にいれるのがよさそうかも」というような推測ができるようになります。これら因果関係やパターンからの推測はそのシステムに詳しいSWE（= メンタルモデル構築済み）なら、コードを読まなくても大体のあたりをつけるという感じで自然と行っているものだと思います。## その他図miroを使って書くことが多いです。キャンバスが広いのとちょうどよいコンポーネントが揃っているのでおすすめです。レビュー# ドキュメントの問題最後にドキュメントにつきまとう「メンテナンスの問題」と「保存場所の問題」についてです。ただし、僕はどちらについてもベストプラクティスは持って無くて、どうしたらいいんだろうな〜と思いながらやっている状況です。## メンテナンスドキュメントは書かれたその瞬間から、コードや設計に対して古くなっていきます。これ自体は仕方のないことですが、問題はそれをメンテナンスしていくのが大変ということです。この問題に対して僕は現時点では2つ対策をとっています（が、どちらも完璧ではない）。ドキュメントにコードレベルの詳細を書かないつまりドキュメントには安定している構造（かつメンタルモデルの構築に役立つもの）を中心に書き、よく変更されるもの（コードレベルの詳細）は極力書かないようにします。サンプルコードや枝葉の実装解説などもできるだけ少なくします。これでメンテナンスの頻度自体を少なくできます。スナップショットだと割り切るそれでももしドキュメントとシステムに乖離がおきたら、そのドキュメントを読んだ人にその乖離を積極的に直してもらうようにします。というのも、ドキュメントを読んだということは実際のコードを直近読む可能性が高いはずです。なのでドキュメントの乖離に気づきやすいというわけです。それと最初からある時点でのスナップショットだと明記しておけば、古くなったドキュメントは信頼性が低いという前提で読者に読まれるはずです。そして古すぎてもう実際のシステムと違う点が多いものは、デメリットの方が大きいのでさっさと捨てましょう。## 保存場所ドキュメントを保存する場所はどこがよいのか？正直今のところどこが良いのかわかっていません。選択肢としては3つぐらいありそうです。システムと同じリポジトリ社内情報ストックサービス(notion、google docsとか)色々なドキュメントを保存するドキュメント専用のリポジトリ個人的には「ドキュメント専用のリポジトリ」に保存するのが良さそうなので、試してみようと思っています。理由はこんな感じです。SWEが慣れているレビューシステム(GitHubのPull Request)を使えるドキュメントの実例がすぐ近くにあるリポジトリをまたいだシステムのドキュメントを保存できるというわけで、ソフトウェアのドキュメントについて思っていることをつらつらと書きました。ドキュメント書くのは楽しいので興味ある人は是非書いてみるといいと思います！ではでは。*1:カルテエディタ、問診フロー、主訴検索についてのドキュメント

ソフトウェアドキュメント作法

こんにちは丸山@h13i32maruです。僕は今、Ubie Discoveryで医療従事者向けのカルテエディタを作っています。人生で初めてContent Editableを使ってエディタを作ってるんですが、それがすごく楽しいです！というのも、エディタを作るには色々技術的な課題があります。例えば、テキストをパースするには？ASTからHTMLをビルドするには？パフォーマンスのよい更新方法は？などなど。それらの技術的な課題を解決していくのが単純に楽しいという感じです。また、車輪の再発明は極力抑えつつ、自分たちのプロダクトでやりたいことを実現できるような工夫もしています。というわけで、今回はそんなエディタ作りで取り組んだ課題と解決策を紹介していきたいと思います。エディタの概要メンテしやすいテキストパーサ - PEG.jsメンテしやすいHTMLビルダー - ReactDOMServerライフサイクルをまたがる処理 - プラグイン機構パフォーマンスの良い更新処理 - インクリメンタルビルドキャレットのリセット回避 - キャレットプラグイン責務と依存の明確化 - レイヤードアーキテクチャリグレッションや不具合の検知 - ユニットテスト有益な設計議論やレビュー - ドキュメントエディタの概要まずはじめに作ってるカルテエディタを簡単に紹介します。いわゆるWYSIWYGエディタとして作っています。ただ、Google DocsのようなWYSIWYGというよりはNotionのように「いくつかの記法を持っていいて、それを入力するとスタイルが適用される」みたいな感じのものです。例えば今回作っているカルテエディタでは【】を入力すると見出しになり、：を入力するとラベルになります。このあたりの記法はカルテでよく使われる記号を元にしています。他にも特定の記法でReactコンポーネントを埋め込めたり、空セクションのグレーアウトなどの装飾が適用されるようになっています。余談ですがこういうタイプのエディタってなんて言うんだろ？個人的にはWYSIWYG2.0ぽいなと思ってます（調べても出てこなかった）。処理の流れはざっくり以下のような感じです。というわけで、以降では具体的な話をしていきます。メンテしやすいテキストパーサ - PEG.js今回テキスト（カルテ）のパースをどうするか悩んでいました。というのも過去にすごく単純なテキストパーサは作ったことはあり、その時の経験からある程度の規模のパーサをパーサ素人が書く/メンテするのはかなり難しいとわかっていたので。そこで以前に名前を聞いたことがあったPEG.jsというパーサジェネレータを調べてみたところ、どうやら宣言的な構文でルールを書くとテキストパーサを自動生成してくれるものだとわかりました。というわけで、実際にPEG.jsを使ってパーサを生成してしてみたのですが、宣言的にパーサを書けるのは思った以上に体験がよかったです。命令的なコード（if, forなどの通常のプログラミング）と違い、状態管理が発生しないのが特に良いですね。それにPEG.js自体の仕様は凄くコンパクトで学習コストもそんなにかかりませんでした。今後テキストパーサを実装するならPEG.jsを積極的に使っていこうと思います。ただし、PEG.jsでは以下の点に気をつける必要があります。宣言的な構文でルールを書くのは、いつもと違った脳みそを使う感覚があり、慣れは必要PEG.jsの正規表現（ぽい構文）はバックトラックや控えめマッチがなくて、貪欲マッチのみしか使えないPEG.jsの開発は結構前に止まってるようなので、開発が活発な他のパーサジェネレータに乗り換えたほうがいいかもしれないメンテしやすいHTMLビルダー - ReactDOMServerテキストをパースした結果のAST（Abstract Syntax Tree）からHTMLを組み立てるのに当初は文字列としてがちゃがちゃ組み立てていました。ただそれだと見通しが悪かったり操作しづらかったりで、実装やメンテのコストが高くなるのが目に見えていました（幸いにも補完はIDEの力でなんとかなりましたが）。そこで、JSXを文字列に変換できればHTMLを組み立てるのがすごく楽そうだなと思って調べたら、ReactDOMServerというどんぴしゃのものが公式にあったので使うことにしました（ReactDOMServerとありますが、サーバサイドやSSRとは関係なく使用することができます）。これによって、HTMLの組み立てを文字列操作や命令的コードで実装するのではなく、宣言的コードとして実装できるようになり、実装コストも体験（IDEの支援や通常のUI構築との親和性）もすごく良かったです。ライフサイクルをまたがる処理 - プラグイン機構エディタを作り始めたころはいろんなコンテキストのコードが一箇所にごちゃまぜになっていて、だいぶ見づらくなっていました。例えば「HTMLを更新した直後」では「キャレット位置の復元をする」「エディタ内にReactコンポーネントをマウントする」などのコンテキストが異なるコードを同じ場所に書かざるを得なかったのです。これはかなり辛いなと思って試行錯誤をしてるうちにライフサイクルをフックできるプラグイン機構作ればよさそう！とひらめきました。というわけで、エディタのいろんな処理タイミング（ライフサイクル）に外部からコードを差し込めるようにするためのプラグイン機構を作りました。例えば「エディタからテキストを読み出す直前」「HTMLを更新した直後」などなどのタイミングで外部からコードを差し込めるようになっています。プラグイン機構はTypeScriptのインターフェースとして提供して、実装側はそのインターフェースを実装してエディタに渡すようになっています。実際にこのプラグイン機構を使って、外部からReactコンポーネントをエディタ中に埋め込んだり、キャレットや改行の処理をするプラグインを作りました。ただ、欠点としてプラグインが提供しているフックタイミングをちゃんと把握してないと理解が難しくなります。現在はコードにコメント書いたりドキュメントでカバーしているという感じです。以前にESDocでプラグイン機構を作ったときもこのあたりはちょっと難しかったなぁというのを思い出しました。パフォーマンスの良い更新処理 - インクリメンタルビルド最初の実装ではユーザが文字を入力するたびに、エディタ内のHTMLを全て作り直していました。ただ、それだと文字入力があるたびにエディタ内に埋め込んだReactコンポーネントのunmount/mountが走ってしまいます。さらに画像があると文字入力のたびにその画像がちらついていました（再読み込みが行われるため）。この問題を解決するには全HTMLを作り直すのではなく、必要な部分だけ作り直すインクリメンタルビルドの仕組みが必要です。とはいえ、これは世に云う早すぎる最適化な気もします。悩んだのですが結局、インクリメンタルビルドを採用することにしました。というのも、これはエディタ設計の根幹に関わることなので、後から実装するとしても多分エディタの設計からやりなおしになるだろうなと。とはいえ最初から作り込みすぎるのは良くないので、まずはインクリメンタルビルドのキモである「そのユーザ入力による更新範囲の判定ロジック」「部分更新の仕組み」をざっくり作ってリリースすることにしました。細かいチューニングは後々必要になったときにやればよさそうなので。しかし、やっぱり実装は複雑で難しい感じに。。。このような仕組みはこれまで一度も作ったことのない部分なので、何度かリライトしないと洗練されないなと思っています。あとはOSSなエディタから学習するというのもありかもしれません（それも難しそうだけど）。キャレットのリセット回避 - キャレットプラグインContent Editableではキャレットの制御がめちゃくちゃ面倒です。なぜかというと、キャレットが存在する場所のHTMLを書き換えるとキャレット位置がリセットされ、親要素の最初の文字位置に移動してしまいます。これでは「ユーザが文字を入力→ 新しくHTML作成して書き換える」のたびにキャレット位置がリセットされて使い物になりません。そこで、HTMLを書き換える前にキャレット位置を覚えておいて、HTML書き換え後に適切な位置に戻すようにしました。このときにHTML書き換え前後でキャレット位置を保存・復元するのが難しかったのですが、最終的には以下のようにしました。HTMLを更新をする直前にキャレット位置にマーカー文字を挿入する: 例 foo{{caret}}barそれを含んだテキストをパースしてHTMLを組み立てるときに、キャレット位置をHTML要素として書き出す: 例 <div><span>foo</span><span class="caret"></span><span>bar</span></div>このHTMLをエディタに書き込んだ後に、class="caret"を持つDOM要素を見つけて、そこにキャレットを移動する実際はもう少し泥臭い実装が入っているんですが、それでもだいぶシンプルにできたと思います。それと、キャレット制御は編集処理のいろんなタイミングに実装を入れる必要があるんですが、前述したプラグイン機構を使うことで実装を一箇所に集約することができたのは良かったです。けど、そもそもキャレット制御せずにいい感じにできないのだろうか？？それともやっぱりContent Editable使う以上は必須になってくるのかな🤔責務と依存の明確化 - レイヤードアーキテクチャエディタを作るにはいろいろな処理を実装する必要があります。テキストのパース、ASTからHTMLの組み立て、編集処理、ユーザ入力のハンドリングなどなど。これらの処理をきっちり責務ごとに分割し、さらに依存関係を明確にすることは重要です。そこで、今回は「責務ごとにレイヤーを切って、依存関係をレイヤーからレイヤーへ単方向にする」というレイヤードアーキテクチャの設計をかなり意識しました。責務ごとにレイヤーに分けるときに注意したのは「エディタのレイヤー」と聞いたときに、なるべく自然と想像できるような切り方になるようにしたことです。ただ現在のレイヤー整理が正解なのかは正直わからないです。というのも僕は今回初めてエディタを作ったので、エディタについてのドメイン知識がまだ浅いためです。このあたりは今後も開発をしていくことでより良いものが見えてきそうです。ちなみに現時点で成功したなと思う責務分割は「ユーザ入力のハンドリング」と「テキストの編集処理」をきっちり分けたことです。このあたりは意識しないと境界が曖昧になり、処理がスパゲティになるので特に注意する必要がありました。リグレッションや不具合の検知 - ユニットテスト前述したようにエディタはいろいろなコンポーネントで成り立っています。それらのコンポーネントはなるべく疎結合を意識して作られていますが、とはいえある変更が思いもよらぬ影響や不具合を生み出すことがあります。それがメイン実装者ではなく他のメンバーも手を入れていくならなおさらのことです。そこで、ユニットテストはわりと充実させました。具体的にはパーサ、HTMLビルダー、編集処理あたりを中心にテストを書きました。特にASTやHTMLのテストはそのまま書くと大変なので、Jestのスナップショットテストをガッツリ使ってみました。カバレッジはあまり重視してなかったですが、さくさく書ける部分で大体80%ぐらい。これ以上はコスパが悪そうだったので、一旦このぐらいまでにしました。Jestをしっかり触るのは今回が初めてだったのですが、スナップショットテストは超便利だと思いました。ただし、テストコードとスナップショットが離れてるのでPRレビューはしづらいですね。。WebStormだとテストコードからスナップショットへ一発で飛べるようになってるので多少はましですが（ただし、一つのテストの中で複数のスナップショットテストしてる場合には対応してなさそう）。インラインスナップショットという手もありますが、それはそれでテストコードがみづらくなりそうなので見送りました。あとはやはり入力がユーザインタラクションになる部分(= UI側)に近くなればなるほどテストはしづらいのを改めて感じました。WebStormのスナップショット連携機能有益な設計議論やレビュー - ドキュメント      今回のWYSIWYGエディタは僕がメインで開発していたのですが、やっぱりチームメンバーと設計について議論してフィードバックをもらったり、実装をレビューしてもらいたいというのは当然あります。しかし、ここまで紹介してきたとおり、WYSIWYGエディタはどしても設計や実装が複雑になってしまいます。そうなると有意義な議論やフィードバックをもらったりするのも難しくなりますし、レビュー負荷も高くなってしまいます。そこで、今回はドキュメントをしっかり書くようにしました。具体的にはARCHITECTURE.mdを書いたり、文字だけでは分かりづらい仕様やアルゴリズムを図示しました。例えばカルテテキストから生成したASTの仕様や、そのASTからHTMLを生成する流れ。他にもインクリメンタルビルドの大まかな戦略や実装方法についてもドキュメントを書きました。ドキュメントを書くときに気をつけていたのは、エディタ全体について俯瞰的なメンタルモデルを構築してもらえるようにしたことです。他にもコード上には書かなかったり汲み取れなかったりすることは、ドキュメント化しました。具体的には「なぜこのような仕様・実装になっているのか？」「棄却した選択肢はなにか？」などです。このドキュメントを使って実際に設計議論をしたのですが、そのときに「エディタに機能追加するのが現状だと大変そうなので、改善したほうが良さそう」とか「Reactコンポーネントを追加していくときはプラグインの形で実装していくとよさそう」などの有益なフィードバックをもらうことができました。結果としてより良いものが作れたと思います。それと、チームメンバーからはドキュメント自体に対して、このようなフィードバックをもらうこともできたので、書いてよかったな〜と思っています。ちなみにドキュメントを書く工数は多少かかってしまいました。多分トータルで、2~3日ぐらいはかけたと思います。ドキュメントって書きすぎるのも良くないというのは理解していますが、今回はこのドキュメントを書くことで得られるメリット（チームメンバーの理解度アップ、有益な議論やフィードバック、今後のメンテナンス時のサポートコスト低減など）が僕一人の工数よりも大きいと判断したため書くことにしました。それと僕はもともとこういったドキュメントを書くのは好きな性格なので、書く事自体が楽しみだったというのもあります。ただし、今後のドキュメントのメンテナンスについてはどうするか検討中という感じです。以上、エディタ作りの楽しかったところ（課題・解決策）を紹介しました。エディタ特有のものもあれば、ソフトウェア開発一般的なこともあったと思います。「ここ参考になった」「自分ならこうする」などの意見があれば、教えてもらえると喜びます。最後に宣伝。最近meetyでカジュアル面談（実際は面談というか会社紹介）をオープンしたので、興味ある人は連絡ください！テキストエディタについて語りたい人も是非！

Content EditableでWYSIWYGエディタ作るの楽しい！

入社一ヶ月の分報戦記（Ubie）

@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。技術的負債が生まれる背景まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないのでさらっと見てもらえれば十分だ。 負債  内容  ポーリングキュー  Issue取得のポーリングキューはもともと単純なFIFOだったが、優先度付きFIFOが必要になった  Streamのデータ構造  複数種類のStreamが異なるデータ構造を持っていたが、統一的なデータ構造が必要になった  Main/Rendererの通信  ElectronはMain/Rendererの通信に便利なモジュールを提供しているが、それを使うとパフォーマンスの問題が発生するため、別の仕組みを使うことになった  Reactコンポーネント  Reactコンポーネントを小さくわける・なるべく状態を持たないなどの書き換えをすることになった  モジュールの依存関係  モジュールの依存関係を整理して、UI層からデータ層に向かうシンプルな単方向依存にすることになった これらの技術的負債はJasper v1.0で返済したのだが、結構たいへんだった。最初から技術的負債を生まなければどれほど良いか。そもそもこれらの技術的負債はどうして生まれたのだろうか？僕が開発スピードを優先してコードの質を落としていたのだろうか？いや、そうではない。少なくとも僕はその時その時に自分が書ける最善のコードを書いていたつもりだ。では本当の原因は？それは僕がJasperの開発過程で様々なことを学習して新たな理解を得たが、その理解をコードに反映していなかったから技術的負債が生まれてしまったのである。例えば先程の「ポーリングキュー」はIssueリーダーというドメインについて学習して新たな理解を得たから生まれた負債だ。また「Main/Rendererの通信」はElectronアプリについて学習して新たな理解を得たから生まれた負債だ。本来ならこれらの理解をすぐにコードに反映すべきだったが、それをしなかった。しなかったというか、自分の理解とコードにギャップがあることをはっきりと認識できていなかったのだろう。それが徐々に大きくなっていき、コードに手を入れるのが大変になっていったのだ。では今後、技術的負債を生み出さないようにするにはどうしたら良いのだろうか？実は本質的には技術的負債を生み出さないようにすることはできない。なぜなら技術的負債は先ほど書いたように、学習の結果うまれるものだからだ。例えば今このとき自身が考える必要十分で最善のコードを書いたとする。しかし開発を進めていくとビジネスドメインやプログラミング全般について学習し、新たな理解を得る。この新たな理解と目の前のコードにはギャップが生じている。結果としてそのギャップが技術的負債になるわけだ。人は最初から完璧な理解をもって完璧なコードを書けるわけではない。むしろ技術的負債は学習して新たな理解を得られた結果生まれるものなので、生まれること自体はポジティブである。例えば「インデントが無いコードを書いていたが、コードフォーマットについて学習して新たな理解を得た結果、以前のコードが技術的負債となった」というような場合だって、前進しているんだから素晴らしい。どんな場合も「今この時、自分が考える必要十分で最善なコードを全力で書いた人」が責められる理由は一つもない。※ただしここでは話を単純にするために「学習しない・意図的に雑なコードを書く」というのは考慮していない。それは別次元の話である。生態①: 「対象についての理解」と「目の前のコード」のギャップが技術的負債生態②: 技術的負債が生まれないようにするのは本質的に不可能生態③: むしろ技術的負債が生まれることそれ自体はポジティブである2つの技術的負債とはいえ技術的負債があることで開発スピードや保守に影響を及ぼすのは事実である。ではどうすればよいのか？返済できる日がくるまでじっと耐えるしかないのだろうか？まず技術的負債を発生原因が異なる「ビジネスドメインの技術的負債」と「プログラミングの技術的負債」に分けて考えてみる*1。ビジネスドメインの技術的負債例えば医療機関を対象にしたソフトウェアを開発しているとする。開発するなかで「病院とクリニックではビジネスモデルが違う」「医療クラークや医療事務がいる場合、業務フローが異なる」などを学習して新たな理解を得る。そうすると、それまでのコードと今の理解にギャップが生じて技術的負債となる。Jasperの負債でいうと「ポーリングキュー」や「Streamのデータ構造」についての負債がこれにあたる。この負債は「学習して得た新たな理解をコードに反映できないので負債を作ってしまう」ことが多いだろう。なぜならビジネスドメインの学習というのはエンジニアに限らずチーム全体で積極的にすごいスピードで行われる。そうすると学習で得た新たな理解をコードに反映するタイミングを逃したり、学習が早すぎて追いつかないなどがあるからだ。なのでビジネスドメインの新たな理解を定期的にコードに反映する機会を作れば負債を最小限に抑えることができる。プログラミングの技術的負債例えばユーザデータを集計する様々なバッチを開発しているとする。開発する中で冪等性という概念とそれを実現する方法を学習し、新たな理解を得る。そうすると、それまでのコードと今の理解にギャップが生じて技術的負債となる。Jasperの負債でいうと「Main/Rendrerの通信」「Reactコンポーネント」「モジュールの依存関係」についてがこれにあたる。この負債は「知らないことで負債を作ってしまう」ことが多いだろう。なぜならコードを書くときは身につけたプログラミングスキルの中から適切なものを選んで使っていく（もちろんそれ自体にも難しさはあるが）ので身につけてないものは使えないからだ。なので、必要なときに必要なプログラミングスキルを学習する機会を作れば負債を最小限に抑えることができる。※ここでも話を単純化するために{ビジネスドメイン, プログラミング}の技術的負債を独立して考えているが、実際は両者は相互に影響しあう。また、新たな理解を正しくコードに反映できるかという問もある。生態④: 技術的負債には「ビジネスドメインの技術的負債」と「プログラミングの技術的負債」がある生態⑤: ビジネスドメインの技術的負債は「新たな理解をコードに反映できない」から発生する生態⑥: プログラミングの技術的負債は「知らない」から発生する技術的負債を小さく抑えるここまででわかった技術的負債へのアプローチは次の2点だ。「ビジネスドメインの新たな理解を定期的にコードに反映する機会」を作る「必要なときに必要なプログラミングスキルを学習する機会」を作るしかし本当にそんな機会を作ることができるのだろうか？ビジネスの場では常に最優先のタスクが存在し、不確実性が高いものもたくさんあり、時間と人はいつだって足らない。そんなときに一見ビジネス価値を生まないような機会に時間をさけるだろうか？その方法は...実を言うと僕にはここまでしか考えられなかった。本当なら生態を完全に解き明かし、技術的負債を最小限に抑える仕組みをズバッと言いたかったのだけど。でも、スクラム開発は技術的負債を小さく抑える参考になるかもしれない。スクラムは開発を通して様々なことを学習し、その学習で得られた理解をプロセスやプロダクトに反映し、現時点で最適な状態を常に保とうとする。そのために様々な機会（プランニング・リファインメント・レビュー・デイリースタンドアップ・レトロスペクティブなど）を仕組みとして備えている。これは先程の技術的負債へのアプローチとかなり共通する考え方である。なので、スクラムに技術的負債へのアプローチをうまく組み込んだ形が作れるかもしれない。生態⑦: ビジネスドメインの新たな理解を定期的にコードに反映する機会を作って対処生態⑧: 必要なときに必要なプログラミングスキルを学習する機会を作って対処生態⑨: これらの対処方法はスクラムと相性が良いかもしれないというわけで、技術的負債について考えたことを書いてみた。明快な結論は出せなかったが、こうやって考えを残しておけばいつか続きをかける日がくるかもしれない。最後に一つ注意してほしいのは、今回の話は技術的負債について精緻にも網羅的にも検討されたものではいということだ。例えばベンチャーでドメインの学習がすごいスピード進む場合どうしたら良いのか。すでに大規模なシステムがあり人も入れ替わっていく場合はどうしたら良いのか。などなど、検討していないことはたくさんある。そこはご了承いただきたい。記: 丸山@h13i32maru*1:「ビジネスドメインの技術的負債」が本来の意味での技術的負債であり、「プログラミングの技術的負債」そもそも発生させるなという扱いになっている

技術的負債の生態

こんにちは丸山@h13i32maruです。コロナの影響により、昨年からリモートで働き始めました。最近転職して新しい職場になりましたが、こちらもリモートで働いています。同僚もリモートで働く人がほとんどです。そんなリモートワーク、基本的には最高なのですが、現状「雑談」はオフィスワークより明らかに劣っていると思います。そこで、前職では「帰りの会」という雑談タイムを自分のチームで運用していました。これが結構楽しく満足度も高くて大変良かったです（僕が退職したあとも続いてるらしい）。残った3名で今もやってます！（笑）いい相談＆雑談時間です— 堀犬 (@horiinu) March 7, 2021 今回はこの「帰りの会」という雑談タイムが何故良かったのか振り返ってみます。結論としては「仕事の話をメインのネタにした」「画面共有や開始時間などの小さな工夫を積み重ねた」という感じです。ちなみに、今回の話はオフィスワークでの雑談を再現するものではありません。リモートワークでの新たな雑談の形を模索するものです。目次帰りの会オフィス雑談・リモート雑談ネタのマッチング度合いリモート雑談のネタ小さな工夫帰りの会帰りの会は以下のように運営していました。毎日17:30から最大30分、エンジニア4人位で集まる今日やった仕事をGitHubのIssueやPRの画面を映しながら各自が話す質問とか相談とかも自由に割り込んでいく終わったら（なるべく）退勤するぱっとみはよくある朝会やDaily Standupのように見えます。しかし帰りの会は「昨日やった仕事・今日やる仕事・問題点」ではなく、「今日やった仕事」にフォーカスして話し始めます。今日やった仕事を話すなかで、「明日やる仕事・問題点」などに話題が移ることもあります。また「共有」ではなく「会話」が目的です。なので些細なことを質問したり、話が脱線するのも問題ありません。この「帰りの会」が結構うまく回っていて面白かったです。ではなぜこの帰りの会は良かったのか？一番の要因は「今日やった仕事」をメインのネタにしていたからだと思います。オフィス雑談・リモート雑談オフィスに出社しているときの雑談って自然と発生するのが基本ですよね。例えば隣の席の同僚に「ちょっと今いい？この前の〜」とか、コーヒーを入れに行ったときに居合わせた同僚に「最近何してるの？」とかとか。これをオフィス雑談と呼ぶことにします。オフィス雑談はその相手が興味ありそうなネタで話しかけたり、もしくはそのネタに興味ありそうな相手に話しかけます。そして、その雑談に興味を持った人が新たに参加して（もしくは呼ばれて）いきます。一方でリモートワークにおける雑談は予め日程と人が組まれて雑談をすることが多いと思います。例えばチームメンバーで毎週○曜日○時に雑談をするみたいな。これをリモート雑談と呼ぶことにします。リモート雑談は日程とメンバーがまず決まっていて、ネタは雑談が開始されてから手探りしていくことが多いと思います。ネタのマッチング度合い雑談が楽しくなるかどうかの重要な要素に「メンバーとネタのマッチング度合い」があります。オフィス雑談は会話してる人たちと話のネタのマッチング度合いは常に高い状態にあります。なぜなら、オフィス雑談は開始時にネタと人のマッチングが完了しており、新しく人が増えるときもうまくマッチングされた人だけが参加します。しかしリモート雑談の場合は日程とメンバーが決まっており、雑談が始まってからネタを探っていきます。なので、参加メンバー全員とネタのマッチング度合いは全員が全員高いわけではありません。マッチング度合いが高くない結果、活気が生まれづらかったり、特定メンバーだけ話している状況になりがちです。例えば「5人で集まったけど、サッカーの話になり、その中の3人だけが話してる。残りの2人は無の表情で聞いてるだけ」みたいな状況思い当たりませんか？リモート雑談のネタではリモート雑談を楽しくするにはどうしたら良いのか？一つの解決策は帰りの会でもそうしていたように「仕事の話や仕事に関係しそうなこと」をメインのネタにすることだと思います。なぜなら仕事の話は基本的には全員にマッチングするネタだからです。帰りの会では参加メンバーがエンジニアだけだったので仕事の話でも特にエンジニアリングに関わることがメインでした。ちなみに仕事の話じゃなくても参加メンバー全員がマッチングするネタなら楽しく話せると思います。ただ、個人的には仕事の話のほうが毎日変化もあるし、仕事自体へのメリットもあるので、雑談として好みです。とはいえガッチガチの仕事話にしちゃうとせっかくの雑談なのに気楽さがなくなってしまうので、楽しく雑談できるように意識する必要があります。そのためにいくつか小さな工夫をしていました。小さな工夫帰りの会を楽しく過ごすために以下のような工夫をしていました。「帰りの会」という名前どんな話題でもよい雑談ではなく、仕事に関連する話題とわかるようにするためといいつつも、気楽でくだけた感じを出したかったGitHubのIssueやPRを画面共有口頭で話すだけより内容の解像度がぐんと高くなるので、盛り上がりやすい画面が表示されてるので、ついつい内職してしまうのを防げる画面共有は誰か一人が担当するほうがスムーズやったことから話し始めるやったことは特になにも考えなくても話し始められるやること・相談事などは話し始めるのが少し難しい質問や感想を入れて楽しくする特に会がまだこなれないうちは意図的にするただし、進捗や間違いなどを詰めたり上長ムーブをすると楽しくないので気をつける毎日最大30分頻度が大事(要出典)なので毎日開催あまり話題がないときは早めに切り上げる逆に長過ぎてもダラダラしてしまうので最大でも30分で切り上げる開始時間は遅め（17:30とかにしてた）この後にミーティングや本番リリースなどがないのでリラックスして会話できる帰りの会が終われば、仕事を終えるというリズムを作れる帰りの会でアイデアやアドバイスを得られると、仕事のやりかけ状態となり、翌日仕事に取り掛かりやすいメンバーは多くしすぎない（4人位にしていた）多いとどうしてもネタのマッチング度が下がるそれと各自の発言量も減ってしまうというわけで、「帰りの会」というリモートワークでの雑談についてでした。帰りの会以外にもリモートワーク時代の面白い雑談はあります。例えば、Slackの分報に雑に色々書き込んでいるとそれにレスをもらい、そのまま少し雑談（テキスト）になったりすることがあります。これはオフィス雑談とリモート雑談の中間のような感じですね。このように今後はリモートワークで良い雑談をするための、再現性のある方法やソフトウェアがどんどん出てくるといいですね〜。

「帰りの会」というリモート雑談の形

こんにちは丸山@h13i32maruです。1.5ヶ月の仮想無職をおえて、ついに3月1日から新しい会社（Ubie ユビーというヘルステックスタートアップ）で働き始めました。一週間働いてみて思ったのは、医療ドメインとUbieの事業構造（課題、ソリューション、プロダクト、マーケット）がおもしろい。これにつきます。医療ドメインは誰にとっても身近でありながら、その奥にはすごい森が広がってるみたいな感覚になりました。知的好奇心をうずうずさせるようなプロダクト開発が好きな人には凄く合うと思います。そんな面白いことに関わるんだから早くパフォーマンスを出したい！というわけで、入社して一週間でやったことを残しておきます。事業構造の図を書いてみたり、組織の波に乗ったり、Slackの分報を活用したりなど。先日の転職の意思決定という記事では事業ドメイン、組織、自分の成長、報酬という軸で考えたので、今回もそれに合わせて書いておきます。ただし、報酬は雇用契約以上でも以下でもないので特にやったことはありませんでした。目次🏥 事業ドメイン事業構造の図を書くドメインエキスパートと話す施策について質問する👥 組織波に乗るブログを書く🧑‍💻 自分の成長環境構築分報で互助🌱 その他分報にどんどん書く物理出社🏥 事業ドメイン事業構造の図を書く社内のカルチャーガイドにUbieが考える医療の課題やそれのソリューションが書かれています（カルチャーガイドは社外版がある）。これを読み込んだのと社内で見聞きしたことをがっちゃんこして、課題、ソリューション、プロダクト、マーケットの関係を自分なりに図に書いて咀嚼しました。図にしてみると各所がすごく良くシナジーしていて、事業構造のお手本のようでなるほどな〜となりました。その図を見せられないのが非常に残念ですが。ドメインエキスパートと話すサンプルカルテを社内のドメインエキスパート（Ubieでは本物の医師も在籍している）に解説してもらう会があったので参加しました。問診がどう行われるのかとか、書いてある問診結果の読み取り方などを聞く会です。たとえば「肩で息をする」と書いてあった場合それは単純にその動作を表すだけでなく「自助による呼吸が必要なレベル」と解釈する病院まで一人で来た（独歩）、杖や付き添われてきた（護送）、担架で運ばれてきた（担送）など、どうやって病院に来たかは重要深ぼっていく問診、広げていく問診、時系列に沿う滑らか問診などなど。この話をもとに、帰宅後に奥さん（看護師）ともカルテの話もしました。カルテや問診というのは医療における独自の言語なんだなと面白かったです。施策について質問するUbieでは隔週でランダムに数人集まりお互いやっていることについて会話します（コラボミーティングと呼ばれる）。そこでヘルステックならではの○○についてとか、今最も力をいれてる○○施策とかについて話を聞きました。新参者な僕には、それらについて分からないことが色々あります。なので素直に質問したり、分報に聞きに行ったりしました（Ubieでは全員がSlackに分報を持っている）。このへんはここで詳しく書くわけにはいかないのですが、すごく面白かったです。今後👥 組織波に乗る組織（カルチャー）については自分から動くというよりは、オンボーディングや日々の型がかなりしっかり設定されていてそれに参加しました。特にオンボーディングは手厚くすごく体験がよかったです。まだ参加したことのないものもありますがざっくりこういう感じです。3daysオンボーディング毎週のカルチャーメンター1on1課題図書・推薦図書の読み込み*1ホラクラシー関連タクティカルミーティングガバナンスミーティングOKR関連毎週の全社会でOKRについて各事業から話す会毎月OKRをチームと代表ですり合わせる会隔週でランダムで集まった数人でチームの仕事について話す会月末の全社会では事業全体について話す会四半期ごとのオフサイトで次四半期のOKRを話す採用関連リファラル採用のオンボーディングと伴走声をかけたい人達のリストアップ会スクラム関連どんな組織（カルチャー）にしたいか・どうすればそうなれるかをしっかり考えて言語化し、型を作って運用する。これが実践されているので、どのフレームワークも形骸化させずしっかり根付いているように見えました。純粋にめちゃ凄い。人が集まるだけではカルチャーは自然と作られない。意図を持ってカルチャーを作る必要がある。そんな感じです。ブログを書くUbieでは「全員で採用活動していく」というのがマジで行われています。全社OKRに採用の話がはいっていますし、オンボーディングに採用のセクションがあります。オンボーディング後も継続的な採用活動サポート（伴走）が行われます。その採用活動ですが、Ubieではリファラルがメインです。僕はあまりリファラルが得意ではないので、代わりに積極的にブログを書くようにしています。内容はUbieの話に限らずエンジニアリングや雑多な話も含めて、先月半ばから合計4本書きました。もともと文章を書くのは好きなので、頑張って続けていきます。今後🧑‍💻 自分の成長※ソフトウェアエンジニアとしての成長について環境構築ソフトウェアエンジニアの入社儀式として、開発用の環境構築で色々ハマるというのも経験しました。けどそれは常に変化する事業にソフトウェアが追従しているのでそういうものだと思います。ハマったところは本人がドキュメントを更新するの精神でPRを出したりしていました。今はgood first issueをやっています。分報で互助同日入社のソフトウェアエンジニアの方がいらっしゃったので、お互いの分報で環境構築の助け合いをしたりしていました。同日入社の方がいるとなんか安心感が得られますね。今後🌱 その他分報にどんどん書く入社が決まるとSlackに自分の分報が作られます。僕はそこに何でもどんどん書いていきました（もともと分報好きなタイプ）。些細な疑問や感想にもレスがもらえたりするのですごくありがたいですね。もちろん雑談チャンネル、質問チャンネル、チームチャンネルもあるので、慣れればそういうところで聞いていくのがよさそうです。ただ少し驚いたのは、前職と比べてSlackはわりと静かな感じがしました。本人が入る前から元同僚に荒らされており治安がやばい物理出社Ubieでの最初の一週間は物理出社しました。業務メンターも物理出社してもらえたので、隣で仕事をすることができて大変助かりました。コロナの影響により前職ではリモートワークをしていたので、物理出社で働くのは一年ぶりです。やはり何もわからん新参者にとってはすぐ隣に相談できる人がいるのはありがたいですね。しかし通勤はめちゃ大変というのを思い出しました（ドアツードア40分）。通勤は身体に良くない！多くの社員がリモートワークなのもあり、来週からは僕もリモートワークにします。今後というわけで入社一週間でやってることでした。早くパフォーマンスを出せるようにやっていくぞ！次は入社一ヶ月後ぐらいにまたブログ書こうかな。ではでは。【PR】最後にお決まりのDMください。もしくは採用サイトからカジュアル面談や会社説明会に申し込むこともできますー。どうぞよろしくおねがいします 🙏*1:How Google  Works、一兆ドルコーチ、Measure What Matters、スクラムガイド、Running Lean、医療現場の行動経済学

入社して一週間、素早く生き残るためにやったこと（Ubie）

こんにちは丸山@h13i32maruです。最近転職したのと、子供がいるなか快適にリモートワークできるように、西新井の2LDK賃貸に引っ越しました。書斎最高！西新井も最高！引越し後、自宅環境を住みやすく整えるのが楽しかったので、以前から使っているものも含めて買ったものや自宅付近の環境について記録しておきます。ガチ勢てはないので、普通の範囲ではあるとおもうけど。場所次の職場は三越前駅が最寄りなので、そこになるべく行きやすい場所を検討しました。同僚から東武伊勢崎線だと一本で行けると教えてもらってその沿線で色々見た結果、足立区の西新井が良さそうだったのでそこで物件検索。足立区、治安がよくないイメージだったんですが西新井はファミリー層が多く、北千住とは全然違う雰囲気で落ち着いています。ファミリー向けのでかいマンションもいくつもあり、数年前に再開発が行われたようです。保育園は少し前に爆増しており、待機児童はほぼゼロ。西新井周辺にもわりとたくさん保育園があります。https://www.city.adachi.tokyo.jp/kodomo-seibi/taikijidousuu.html駅近くにアリオ（イトーヨーカドー）とイオンがあり、アリオ側の方には大きな公園もあります。小さな子供がいると公園は重要度が高いので嬉しいです。買い物はだいたいネットスーパーなのですが、お店に買いに行くのも好きです（今はやや難しいけど）。西新井にはスワヤという有名な激安八百屋があります。肉と魚の良いお店はちょっと見つけられていないですが、イオンは割と力を入れてそうでした。物件子供と奥さんが日中家にいるなかでの、リモートワークがしばらく続きそうなので2LDK以上。あとは徒歩駅10分以内、築浅、予算15万円以下とかの条件で探しました。西新井では2LDKなら10〜13万円くらいで全然見つかるようです。最終的には不動産屋でキャンセルされた物件が条件最高でネット無料（これは遅くてだめだったけど）もついていたので、そこに決めました。他には戸建て物件をみたんですが、立地良くない・小さい子供には階段が危ない・日当たりと窓数が微妙ってことで見送りました。ネット環境回線物件についてるネットは測ってみたら60Mbpsほどしか出ませんでした。無線LANも完備していましたがそちらは更に遅くて30Mbpsぐらいしかでない。こりゃだめそうと思いつつも一応提供会社に確認してみると、一部屋10Mpbsぐらい出ればいい程度の設備しか入れてないとのこと。マンション自体にはフレッツ光+光配線方式が入ってるのにどうしてこんなことに。。あいだのルータの性能なのだろうか？まあどうしょうもないので備え付けネット環境は諦めて、個別に契約（フレッツ光 + BIGLOBE）することにしました。結果、めちゃはやい！調子が良いと有線LANで500〜600Mbpsほどでます！前居はVDSLだったので、むちゃくちゃ改善されました！最高！NURO光は管理会社から無理と言われていたので検討してません。無線ルータこれまで使っていた無線LANルーターはちょいちょい接続が切れたりしていたので、新調しました。これはIPv6対応しており、BIGLOBEのサイトで対応機種一覧にも載っています。Google Nest WiFiはIPoEに対応してないとのことで諦めました。BIGLOBEでIPv6オプションしていたので、終端装置にルータを接続するだけで自動判別してつながって便利でした。部屋数と距離がふえたので、中継機も必要かもと思ったんですが、今の所大丈夫そうです。書斎デスクこれまでは小さなテーブルをリビングにおいて仕事や個人開発してたけど、念願の書斎手に入れたので、デスクを新調。僕は腰が痛くなりがちなので、時々たってパソコンしてみようと昇降式デスクにすることに。1cm単位で高さを変えられるので自分の体に合わせやすいのも利点ですね。当初はflexispotにしようと思ったんですが、納期が4月とかだったので諦めて、アマゾンで山善のものを購入しました。スペックと値段はほぼ同じなので満足。組立サービスもお願いできて便利でした。サイドテーブルデスクは横幅120cmで十分と思っていたけど、もうちょいあってもよかったです。なので前居で外部ディスプレイおいていたサイドテーブルを横に添えたらちょうどいいさいずになりました。大きい机を買っても小さくできないので、100〜120cmのデスクを買って、サイドテーブルで拡張するのは結構おすすめです。椅子椅子は職場で座っていたハーマンミラーのセイルチェアがよかったので、特にほかを検討することなく決定。ただし定価だと10万ぐらいするので、オフィスバスターズってところで6万円の中古を購入しました。これまでは木のダイニングチェアでパソコンしてきたので、だいぶ進化し。快適〜。ジョイントマット椅子のローラーで床を傷つけないようにニトリで購入しました。ジョイントマットなのでサイズを調整しやすくて便利です。これは表面の布感が好みでした。ただその分、ローラーは少し回りにくいかも。ケーブルトレイテーブルに固定して配線をスッキリできて便利です。昇降式の場合、上げ下げするので各種配線をまとめておけるので安心です。ディスプレイ特に不満点もオススメもポイントなし。4k 60hzに対応してて、ベゼルはWebカメラつけるのにちょうどよいです。今ならもっと良いのあるかも。WebカメラMacについてるカメラでもいいのだけど、撮影角度を良くするために外部ディスプレイ上部から撮影したかったので購入。Amazonには色んなメーカーのが安くたくさん売ってるが、どれがまともなのか分からないので知ってるメーカーのものにした。フルHD・30FPS特に不満なく使えてる。レンズフードがついてるのは物理的にカメラを遮断できるので安心感あってよいです。キーボードフィルム以前のMacはバタフライキーボードで凄く打ちづらかったので、フィルムをつけて打ってました。今はシザーキーボードに戻ったけど、その時の名残でつけています。長くタイプしてても指が痛くなりにくくておすすめです。ディスプレイ台https://www.amazon.co.jp/gp/product/B07BVHWC9D/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1僕はディスプレイとMacを前後で置くスタイルなので、ディスプレイを少し高くするのに買いました。台の下に開発用のスマホおいたり、配線を通せて見た目もスッキリできてよいです。以前は机のスペースの都合上、コンパクトな高さ可変式の台を使っていました。こちらも便利でおしゃれでよいです。いまはサイドテーブルの上においてあります。ワイヤレス充電器AirPods充電用にかいました。オンラインミーティングするのにAirPodsの充電が切れてるとだいぶ面倒なので、簡単に充電できるのは助かります。ハイパワータイプにしたのは特に理由なかったと思います。二酸化炭素計僕は家で作業してるとたまに頭痛がしたり、だるくなる事があります。そういう時は窓開けたり、散歩で良くなることが多いです。これは多分二酸化炭素濃度が問題なのかなと思い、二酸化炭素濃度計を購入。NDIR方式でAC電源かUSB給電できるものを探して、こちらを購入。グラフも見えるし、モノクロで謎の派手さがなく良い感じです。最初は屋外でも800ppmでてたので、キャリブレーションしたら正常になりました。ノートPCスタンド自宅用と仕事用のMacがあるので、1台をかたづけるのに購入しました。平置きするより断然スペースとらないのでおすすめです。スマホもおけるタイプもありましたが、コンパクトさをえらんでこれにしました。PCマットなくてもよいのですが、スマホとかペンとかおくのにガチャガチャうるさくなくて快適。オープンラック僕の場合は物理本はほとんど処分してるので、立派な本棚は不要です。けど多少は物理本があるので、小さくてスッキリ見える山善のオープンラックを購入しました。合わせてブックエンドも購入。ネジ穴が皿穴になってて細かいところもちゃんとしてました。山善良いメーカーだな。ティシュケースせっかくなのでティシュも紙箱のままではなく、ケースにいれることにしました。取替も簡単なので良い感じです。ポット作業中は水分はしっかり飲む必要あるので、部屋ですぐに飲めるようにポットを購入しました。クッキークリーム色かわいい。家のケトルが800mlなので2回分入る1.5Lにしました。お茶はコーン茶おすすめです。香ばしてく美味しいです。ナッツ類リモートワークでの昼食は眠くならないように少なめにしてるので、夕方小腹が空きます。あと朝早く仕事始めるとお昼前にお腹が空いてきます。その時に食べる用として、ナッツ・ドライフルーツ・ジャイアントコーンなどを買ってボトルに入れてあります。エアコン友人の助言により一番安いのにしました。特に良い点も悪い点も無いです。強いて言うなら、もう少し静かだとよかったかな。ビデオミーティングでの音が気になるかもなので。リビングシーリングライト特に吟味したわけではなく近くのノジマで購入しました。明るさ、色味を調整できてメモリーできるならなんでもよさそうです。お掃除ロボット奥さんが友人から凄くおすすめされたとのことで特に検討せずこれに決めました。間取り図を覚えるタイプではなく、適当に走り回るタイプなので、安くてかわいい奴です。注意点は無線LANは2.4GHzのみのようです。そりゃそうか。カーテン特にこだわりはなく1級遮光と防炎と色で決めました。ピッタリの横幅がなければ小さいより大きいを選択するのがよさそうです。品は満足しましたが、Amazon梱包の都合上折り目がついてしまいます。それが嫌な場合はニトリなどで買うのがよいかもしれません。僕は次の日には気にならなくなっていました。キッチンマグネットフック前居は換気扇のカバーに溝があったのでそこにS字フックをつけてお玉などをぶら下げていました。新居はそれがないのでマグネットタイプを購入したのですが、すごく便利です。少しフックが浅めなので、大きなものをかけるならこれにS字フックつけると解決します。ゴミ箱子供が中身をいじらないように背が高くて蓋付きを選びました。それ以外は特にこだわりはありません。布巾掛け使った布巾をかけるのに便利です。アイデア商品って感じで好き。キッチンマット毛足があるタイプだとそこにゴミが溜まったり、掃除ロボットが掃除できないのでつるつるタイプを購入しました。低反発なので長時間たっていても疲れないらしいです。ベビーゲートキッチンに子供が入ってこないように設置しました。突っ張り式・拡張フレームあり・通行ドアあり。掃除ロボットが下を通れるように空中に少し浮かせて設置してあります。安定感あるので多分大丈夫だとは思うのですが、真似する場合は自己責任でお願いします。ウッドブロックを台座にしようと思います。発泡スチロールの台座も検討しましたが、子供がかじりそうなので却下。ベッドルーム化粧台前居でパソコンデスクとして使っていましたが、今回新しいデスクを購入したので、これは奥さんの化粧台としてベッドルームへ行きました。コンパクトな机なので、ベッドルームのちょっとしたスペースに配置できてよかったです。モバイルバッテリーモバイルバッテリーにもなるUSB電源アダプタです。これをベッドルームでのスマホ充電に使っています。モバイルバッテリーが必要になれば外してすぐに使えるので便利です。その他防災リュック地震あって怖いと思ったのでとりあえず購入。防災リュックには常備持ち出し、1次持ち出し、2次持ち出しがあるらしい。これは多分2次相当。人感センサーライト帰宅時や外出時に自動でライトがつくように玄関のライトを交換しました。本当は洗面所のライトも交換したかったのですが、E26金口ではなくGX53というタイプで、それの人感センサーライトが無くて諦めました。変換アダプタもありませんでした。残念。傘立てドアにマグネットでつけられる傘立てを購入しました。小物も少し置けるので、買い物バッグやマスクなどを置けて便利です。メルカリ今回はじめてメルカリ使ってものを売ってみました。7品出して6品は数日で売れました。ニッチなものでも結構すぐ売れて凄い。全体的に簡単にでしたが、配送の梱包については最初よくわからなかったです。コンビニでいい感じに梱包されるのかと思っていたのですが、流石にそれはなくて自分でやる感じでした。一応梱包から全てやってくれる配送方式もあるみたいです。あと、一回付属品を梱包しわすれたことがあり返品返金のごたごたがあったのだけど無事に収束しました。そういえば、売り上げ金をメルカリポイントにすると有効期限があるので要注意です。アンペア30アンペアから50アンペアに変更しました。部屋が増えたことによりちょいちょいブレーカーが落ちるようになり、仕事中に落ちると困るなと思ったので。その時、家内のブレーカーに40アンペアとあったので、40アンペアより大きくするには機器交換が必要と思っていました。けど、どうやらそれは漏電ブレーカーのアンペアだったようです。そもそもブレーカーには漏電ブレーカー・サーキットブレーカー・サービスブレーカーの3種類があります。契約アンペアオーバーになると落ちるのはサービスブレーカーで、新居の場合は屋外についていました。https://www.best-parts-media.jp/element/7223パソコン回収昔のパソコンを捨てたかったがお金がかかるしデータも心配だったので捨てられずにいました。今回パソコン回収.comに送って無料でひきとってもらいました。データ消去証明書も依頼すれば無料でもらえます。でも次回からは購入時に下取りに出すようにしたほうが良さそう。スマホ回収パソコンと同じく、不要なスマホも捨てられずに困っていました。調べるとドコモショップではメーカーに関係なく無料で引き取ってもらえることがわかりました。目の前でスマホに穴開けて使えなくしてくれます。ただ、スマホのストレージ容量をわかってないと引き取ってもらえないようです。理由はよくわかりませんが。ロードバイク売却東京に来てからは全く乗ってなかったロードバイクをついに売却しました。メルカリで売ったりすると譲渡手続きが面倒だったり、事故にあったりでもされたら怖いと思ったので業者に売却しました。2008年に30万円で買いましたが、1.8万円での売却。まあかなり古いモデルだし、1~3万円ぐらいかなと思っていたのでOK。検討中ソファー書斎にソファー欲しいと思って検討中です。一人用サイズか二人用か。物干し竿今の洗濯竿の位置が少し下なので乾きがあまり良くないです。あと干せる量も少し足らない。突っ張り式がいいかなと思いつつ保留にしてます。洗濯機ドラム式乾燥機にしようかと思っていますが、色々ありすぎて迷っています。ヒートポンプ式が安定ぽいけど、ヒートサイクル方式もあるし、高温のヒート式もある。ふわふわ感や傷みにくいのはヒートポンプ式だけど、生乾き防止はヒート式がよいらしい。掃除や故障については単純なヒート式のほうがよいのかな。あとは電気式の分離型もありかも。ガス式はそもそも無理ですが。食器棚食器がかなりあるので収納しきれないものはまだダンボールに眠っています。前居にはいい感じの棚がありそこに収納できたのですが、新居にはありません。さすがにAmazonで組み立て式を買うのはしんどそうなので、ニトリでみようかなとおもっています。というわけで、快適な生活をおくるために色々整備したのでした。今後もリモートワークメインになるので継続的に改善していきたいです。何かおすすめ商品があれば教えて下さい。そして、明日はUbie入社。緊張する。まずは生存頑張るぞい。blog.h13i32maru.jp

自宅を快適にするために買ったものとか

こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。jasperapp/jasper/ARCHITECTURE.mdARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。https://matklad.github.io//2021/02/06/ARCHITECTURE.md.htmlhttps://github.com/rust-analyzer/rust-analyzer/blob/d7c99931d05e3723d878bea5dc26766791fa4e69/docs/dev/architecture.mdhttps://gigazine.net/news/20210210-architecture-md/今回は実際に書いてみたときの「気をつけたこと」「感想」を簡単に残しておきます。Jasperのアーキテクチャに興味がある方がいればもちろんARCHITECTURE.mdを見てください😝気をつけたことARCHITECTURE.mdも一種のマニュアルだと思うので、読者が対象（今回はアーキテクチャやコード）についてのメンタルモデルを獲得できることを意識しました。このあたりの話は以前に会社のブログに書いたので興味あれば見てください。まずは読者がすでに持っているメンタルモデルを想定しておきます。JasperのARCHITECTURE.mdを読むくらいなので、Jasperを利用している人でかつプログラマーのはずです。なので今のメンタルモデルとしては以下のようなものを想定しておきます。見たいIssueの条件をStreamで作っておくと、Issueの更新が通知される。裏側は多分GitHub APIに定期的にアクセスしてる。もしくは常時接続や更新を通知してくれる便利なGitHub APIがあるのかもしれないその読者がARCHITECTURE.mdを読み終わったら、「不具合の調査や機能追加をするために、どのあたりのコードから見ればよいのか、探し方がわかる」という状態になるのを目指します。コードをスラスラ読めるとか、当該のコードにピンポイントでアクセスできるとかはちょっとハイレベルな目標なので今回は考慮しません。なので獲得してもらうメンタルモデルとしては以下のレベルくらいがよさそうです。主要なコンポーネントはFooとBarと...で、それらはxxな感じで関連している。あの機能に関しては多分○○あたりのコードから読み始めるとよさそうということで、このメンタルモデルを獲得できるような内容になるように意識します。具体的には現在もっているメンタルモデルに直接関わるコンポーネントとそこから一段潜ったコンポーネントについて説明することにしました。あとはJasperはElectronで作っている都合上、Electron自体のプロセスモデル（Main/Renderer/IPC)については記載さざるを得ません。その他に気をつけた細かいところはこんな感じです。あまり詳細に書きすぎないメンテナンスコストを抑えて、コードの詳細が変わってもARCHITECTURE.mdを変更しなくても良くするためそれと読者のメンタルモデルを考慮すると、詳細度が高すぎると理解の妨げになるためなるべく「何故そうしたか」を書くメンタルモデルを獲得し、それが頭に定着しやすくするため（丸暗記より、演繹的に導けるほうが覚えやすい）本文中に書くと読みづらくなるものはFAQにまとめたARCHITECTURE.mdではコードへ直接リンクは貼らないほうがよいらしいが、今回は貼ってみたARCHITECTURE.mdを読みながら具体的なコードにもすぐに目を通せたほうが、更に次の段階に行きやすいと思ったから図はGoogle図形描画を使ったポンチ絵を書くだけなら十分だし、オンラインですぐに編集できるので便利感想アーキテクチャ図を書くことが一番良かったです。今までは頭の中にしかなかったものが目視できるようになると、気づくことがあります。例えば今回だと、ポーリングもユーザイベントと同じレイヤーとして扱ったほうが理解しやすそうなのでディレクトリ構造を少し修正したほうがいいなと気づきました。それとJasper v1.0で大幅にアーキテクチャを変更したので、その整理という意味でも良かったです。それと仕事でこういうドキュメントを書くことがあれば、その練習にもなりそうです。あとは単純に満足感がありました。追記UMLは実装や設計を具体的に助けるものという印象があり、かなり実装詳細によってるのかなーと思います。一方でARCHITECTURE .mdは新規参加者が全体像を掴むことを目的としてるので、正確性には多少かけたとしてもざっくり把握できることを優先してるように思いました。 https://t.co/Asxpavylrd— Ryo Maruyama (@h13i32maru) 2021年2月20日  なのでARCHITECTURE .mdの次にUMLやもっと詳細度の高いドキュメントをみるのがよさそうです。UMLやARCHITECTURE .mdに詳しいわけではないので、間違ってるかもですが。という話もブログの最後に追記しておこう。— Ryo Maruyama (@h13i32maru) 2021年2月20日  というわけでARCHITECTURE.mdについてのメモ書きでした。OSSのメンバーだったり、仕事でアーキテクチャを設計・実装する役割の人は書いてみるといいかもしれません。詳細度もあまり高くないのでそんなに時間がかからないと思います。その割にはメリットもありそうです（多分）。

ARCHITECTURE.mdというものを書いてみた

こんにちは丸山@h13i32maruです。タイトルの通り、2020年末に転職の意思決定をしました。現職のクックパッドには大変お世話になりました。次はUbie（ユビー）という医療系ベンチャーに行きます。今は有給消化中で入社は3月1日からです。この転職の意思決定をするにあたり「事業ドメイン」「組織」「自分の成長」「報酬」の視点で色々と検討しました。そこで未来の自分に検討したことを残しておこうと思います。今の正直な気持ちを書いているので、Ubieに限らず転職しようか迷ってる人にとって何か参考になれば幸いです。ちなみに今回の転職は以下のような経緯によるものです。転職活動をしていたわけではなく、中の人からお誘いいただき入社に至ったため、他に検討していた会社はありません転職するかどうかは最後の最後まで迷っており、オファー後に色々考えて転職するかどうかの意思決定をしました目次感情に流されない事業ドメイン組織自分の成長報酬意思決定感情に流されないまずはじめに意思決定するための注意点として「感情に流されない」というのを意識しました。僕はソフトウェアエンジニアですが、誰にも負けない凄いスキルを持ってるわけではありません。コンピュータサイエンスに精通しているわけでもなく、なにか大きな実績があるわけでもなく、エンジニアリング以外の高い能力があるわけでもありません。なにかあるとすれば、プロダクト開発が好きだということくらいです*1。そんなエンジニアでかつ割と保守的な性格なので、転職というのはドキドキします。合わなかったらどうしようとか、転職する（しない）を後悔したらどうしようとか色々不安になってしまいます。結果、そういう感情面で意思決定すると現状維持や楽な方に流れがちです。しかも現職（クックパッド）は大変良い会社で働きやすく、料理というドメインも好きで、とても良いメンバーがいます。さらに僕はもうすぐ35歳になりますし、子供も生まれたばかりで、20代の頃とは違います。さらにさらに世間はコロナで大変な時期です。そこで、このオファーを受けるべきかどうか論点を整理して、なるべく感情に流されないように自問自答しました*2。なので今回はエモい話や感動的な話はほとんどありません。事業ドメイン組織・チームメンバー・使っている技術・給与などが一定の水準以上なら、事業ドメイン・プロダクトが僕の転職の意思決定にとって一番重要です。なぜなら自分が仕事（サービス開発）で一番パフォーマンスを出せる状態というのは、いかにその事業ドメインが自分にマッチするかにかかっているからです。じゃあどういうものが僕自身に合うかというと「自分が使って、自分の人生や生活が良くなるもの」というのがここ数年大事にしてきたことです。儲かる・社会貢献できる・ユーザ数が多い・最先端などはあまり重視していません。結果としてそれらが達成されるのはもちろん嬉しいことではあります。なのでクックパッドというのは僕（自分で料理を試行錯誤するのが好き）にとっては現時点で最高にマッチする会社です。とはいえ6年働いてきたので、やりたいことは結構挑戦させてもらいました。特に2018年から2年間はかなり挑戦しました。2020年は燃え尽きたという感覚もあり、少しクールダウンしながら次に社内で挑戦することを探している状態でした。通常業務をしながら2020年11月には次の挑戦のPoCを作ったりしていました。今でも「自分が使って、自分の人生や生活が良くなるもの」というのはすごく大事です。しかし私生活の変化、特に今年子供が生まれたのがきっかけで「自分と家族の人生や生活がよくなるもの」への気持ちが強くなってきました。なので次にもし転職するなら医療系（か教育系）がいいなと思っていました。子供が小さいうちは病院にお世話になることも多いでしょうし、妻が看護師であり、僕自身もちょいちょい病院に行くことがあるためです。そう考えながら、Ubieメンバーとのカジュアル面談で医療のことや市場について話を聞かせてもらったら知らないことばかりでした。なにより医療自体は僕にとって未知すぎて単純にドメインとして面白そうだなと感じました。それとUbieのミッション・プロダクト・ビジネスモデルについてもすごく明瞭で良いなと思いました。シンプルでわかりやすいことは正義です。そういうわけでUbieの医療ドメインやプロダクトは自分にマッチするかもと考えるようになりました。とはいえ「自分と家族の人生や生活がよくなる」という点で仕事をしたことはありませんし、これまで大事にしてきたことを変えるのは不安があります。それに実務面ではドッグフーディングがかなり難しくなります（些細な話だけど僕の開発スタイルにとってすごく重要）。けど、これは新しい挑戦と考えることもできます。問医療ドメインとUbieの事業は僕と家族の人生や生活をよくするか？自分が仕事で大事にしてきたことを変えて、新たなことに挑戦すべきか？医療ドメインで自分のパフォーマンスを出せるか？クックパッドでの次の挑戦は未達のままでも後悔しないか？組織Ubieは評価なし・役職なしという面白い取り組みをしています。これは事業や会社の成長に全ての時間を使うためというのが主な理由だと理解しています。そのため組織運営は独特なものがあります。現時点で僕が理解しているのは例えばこういうところです。評価がないので役職はなく、役割を重視したフラット構造意思決定は各役割を持った人が行う全員が最大限能力を発揮していると信頼している各自の成長に関しては自力でなんとかできる人しか雇わない個々人の成長ではなく会社の成長が各自の報酬として跳ね返ってくる会社の成長が報酬として返ってくるので、採用は全員で行う※このあたりはまだ入社前なので、理解が間違ってるかもしれないけど具体的なフレームワークとしてはティール組織の実装系である「ホラクラシー」というものを採用しています。ティール組織は以前に読んでいて面白い*3と思っていたのでこの組織運営には興味がわきました。次に組織全体ではなく個人にもフォーカスしてみます。まずUbieに誘ってくれた菊田さんがすごく楽しそうに仕事をしているのを観測しています。菊田さんとはクックパッドで一緒に働いたことがあり、そのときも楽しそうに仕事していましたが、Ubieではそれ以上に楽しそうに見えます。彼が楽しく仕事をしているというのは彼を知っている人なら、その会社にかなり良い印象を持つとおもいます。それと共同代表二人のバランスがすごくよく見えました。一方は強いリーダーシップ、一方は安定・堅実という感じでした。ただ共同代表二人とはまだ一緒に働いたことはなくて、面談等で話をさせてもらっただけなので、実際は違うのかもしれないですが。問ピラミッド型組織ではない、全く新しい組織を楽しめるか？苦手な採用で貢献できるか？自分の成長クックパッドは長く働いていることもあり、割とコンフォートゾーンでした。なので最近は自分の成長が鈍化している感覚がありました。2020年の後半はそれまで数年やっていたPdMやマネージャー職をやめて、エンジニア（Android）に戻ったのですが、20代のときと比べると物足らなさがありました。これにはいくつか理由はあると思うのですが、一番はエンジニア業務がしっかり分業化されているところにあると考えています。分業自体は大きな組織ではよくあることだと思うし、それが悪いとは思わないです。むしろ全体最適では必要なんだろうなと思います。しかし僕のようにしばらくエンジニアブランクがある状態での復帰が分業体制というのはちょっとミスマッチなのかなと思います。それとこれまでの経験からディレクション業務や人のマネジメントというのも期待されます。そんなわけで、この状態で数年過ごしたときに自分のエンジニアとしての成長や市場価値に対する不安がありました。一方でUbieのソフトウェアエンジニアは割と広い範囲を担当しているようです。※クックパッドでも僕が所属していたレシピ事業以外では状況が違ったり、レシピ事業の中でも色々なことをやる動き方はできるとは思います。自分の成長という視点において、Ubieでの面接も非常に有益な情報を得られました。面接は計3回ありスタンス面接・技術面接の各ディスカッションが大変楽しく&めちゃくちゃ疲れました。ヘトヘトになって帰った記憶があります（最終面接は雰囲気が違ったので割愛）。僕もクックパッドで面接官をしていますが、少なくとも僕個人はここまでの面接はできてなかったです。なのでUbieの面接官は非常に能力の高い人たちだなと思いました。そして多分他のメンバーも全員がこのレベルなんだろうなと。それもそのはずで、市場の不確実性をこの短期間で乗り越えてきた（乗り越えている）人たちなので当然といえば当然です。そんなメンバーと一緒に働くことができるのかと。というか、受かると思ってなかったのでよく受かったよなという感想があります。それと僕にとってこの面接はアトラクトとしてすごく効果的でした。問コンフォートゾーンを抜けて、技術的に未知なラーニングゾーンにコロナや育児をしながら挑戦できるか？Ubieで働くことは自分が成長し、自分の市場価値を大きくあげるか？報酬ベンチャーは給与が低いけどストックオプションでカバーするというのがよく見られる報酬設計なのだと思います。しかしUbieの場合は給与水準も普通のウェブ系企業と比べても遜色ないレベルであり、さらにストックオプションもあるという設計になっています。これは会社が継続し、上場すれば手堅さと夢の両方がかなう感じです。ただ家賃補助や交通費の福利厚生はやはりまだ弱いところもあり、そこは現職のほうがよかったです。けどそこはリモート勤務をしっかり使える会社なのであまりマイナスにはならなさそうです。このリモート勤務は子供がうまれてまもないということもあり、非常に魅力的です。一方でリモートで新しい会社にうまくなじめるかは不安はありますが。組織のところでも書きましたが、評価がないので給与が定期的に上がっていくという保証は全然ありません。評価がある会社でも保証はありませんが、上がりやすい力学はあると思います。給与が上がるかどうか（とストックオプション）は会社の成長と一蓮托生です。問今後数年間、もし給与が上がらないとして、生活費・養育費・貯蓄には十分か？数年以内に上場し、十分な評価額となるか？意思決定以上で各視点の問のリストアップは終わりです。あとは自問自答するだけです。医療ドメインとUbieの事業は僕と家族の人生や生活をよくするか？Yes.  頻度は少ないかもしれないがクリティカルである。自分が仕事で大事にしてきたことを変えて、新たなことに挑戦できるか？Yes. 不安はあるけどUbieでなら挑戦する価値がある医療ドメインで自分のパフォーマンスを出せるか？正直わからない。けどUbieには医療ドメイン未経験のエンジニアもたくさんいるらしいので、僕もいけるはず。クックパッドでの次の挑戦は未達のままでも後悔しないか？Yes. 心残りではあるが、後悔はしないだろう。色々やりきった。ピラミッド型組織ではない、全く新しい組織を楽しめるか？Yes. 楽しそうだし、今後のスタンダードになる可能性もある。苦手な採用で貢献できるか？正直わからない。でも僕なりの方法で貢献すればなんとかなるだろう。コンフォートゾーンを抜けて、技術的に未知なラーニングゾーンにコロナや育児をしながら挑戦すべきか？Yes. 35歳ということもあり、挑戦するなら早いほうが良い。妻の理解も得られた。Ubieで働くことは自分が成長し、自分の市場価値を大きくあげるか？正直わからない。けど環境としては最高。あとは自分次第。今後数年間、もし給与が上がらないとして、生活費・養育費・貯蓄には十分か？Yes. 東京都最低生計費試算調査結果をもとに数年分のを試算してみたところ、いけそうと判断。数年以内に十分な評価額で上場するか？Yes. これは完全に素人感覚なので正直当てにならないだろうけど、可能性は高そうに感じた。というわけで問はほぼYesでした。事業ドメイン、組織、自分の成長、報酬どれも魅力的です。誘ってもらったときは受かると思っていなかったので、不意に手に入ったこのチャンス、活かすべきだなってことでUbieに入社することにしました。正直なところ期待と不安が入り混じった気持ちではありすが、そういう感情を棚に上げるための論点整理だったので目論見通りではあります。次は実際に働いてみてどうだったかを書こうと思います。それまで頑張って生き残ろう。ちなみに一足はやくオンボードに参加しましたが、想像の10倍よかったです。この会社を成長させてきた現メンバーの人たち、やっぱり超すごいんだなぁと思いました。もしUbieに興味を持たれた方がいらっしゃればお気軽にDMください。中の人につなぎます（僕はまだ入社前なので話せることはそんなにない😇）補足1感情面で意思決定するの全然合う人もいると思う。僕の場合は現状や性格上、こういうふうに意思決定するのが合ってたというだけで。みんな後悔しないように意思決定してください！— Ryo Maruyama (@h13i32maru) 2021年2月12日  補足2貝木泥舟はめっちゃ感情に流されている例だろ!!! / “転職の意思決定（クックパッド → Ubie） - maru source” https://t.co/fsYMy7cKPD— KOBA789 (@KOBA789) 2021年2月12日  *1:仕事でいくつかのプロダクト開発、個人ではESDoc, Jasper, Trickleなどを開発してきました*2:恋物語で貝木泥舟が自問自答したように*3:抽象度が高くて1/3ぐらいしか理解できなかったけど

転職の意思決定（クックパッド → Ubie）

こんにちは丸山@h13i32maruです。僕はTrickleというサービスを2017年から運営しています。Trickleは「Twitter、少し疲れてきたなぁ。でもやめたいわけではないし。。。もっと気兼ねなく使えるサービスがほしい」という思いから作りました。このサービスのコンセプトや作った背景を詳しく書く前にTrickleがどんなものか簡単に紹介します。Trickleには「トピック」という仕組みがあり、このトピックごとにメモを書いていきます。例えば僕は「本」「アニメ」「リングフィット」などのトピックを作って、そこにメモを書いています。また他の人のトピックを購読することもできます。このトピックという仕組みによりTrickleでは気兼ねなく自分の好きなことを書き留めることができ、書く事自体を楽しめます（1年ほど前にTwitterにもトピックという仕組みができましたがそれとは別物）。Trickleの主な画面つい先日バージョンアップ*1を行い、より使いやすくなりました。なので、今回は僕のようにSNSに少し疲れた人や書くこと自体を楽しみたいと思ってる人にもっとTrickleを届けたいと考えてこのブログを書きました。興味を持っていただけた方はこの先も是非読んでみてください！とりあえず使ってみたい方は https://trickleapp.me からインストールできます！目次特徴は「トピックとサブスクライブ」きっかけは「Twitter疲れ」コンセプトは「気兼ねなく書き留める」気兼ねなくを実現する「トピック」ユーザの感想ブログ特徴は「トピックとサブスクライブ」まずはTrickleの特徴である「トピック」と「サブスクライブ」について簡単に紹介します。トピック各自が自分の好きなトピックを作成し、そこにアクティビティ（メモや写真）を書き込んでいきます例えば「ゲームログ」「読書メモ」「猫の写真」「映画の感想」などのトピックを自由に作れますトピックはハッシュタグとは違い、ユーザごとに作成されますサブスクライブ他人のトピックをサブスクライブすることができます（いわゆるフォロー）トピックごとにできるので、「この人のゲームトピックは見たいけど、読書トピックはみなくてもいいかな」のように本当に興味のあるものだけを見ることができますきっかけは「Twitter疲れ」僕はTwitterが好きで2007年から利用していますが、2016年くらいから少し使い方に困っていました。(1) その人のツイートについて、見たいものもあるけど、見たくないものもある例：技術的な話はみたいけど、普段の雑談や愚痴はあまりみたくない(2) ○○についてツイートしたいけど、興味ない人がいたり、マウンティングみたいに思われないだろうか・・・僕はソフトウェア開発に加えて、料理や子供の話をするのですが、そういうのをツイートしづらいこれらが悪化すると、見たくないツイートが目に入ったり、他人の事を考えてツイートするようになり、結果として「徐々に自分が削られていく」ことになります。 でもそんなに辛いなら、Twitterやめれば？という話なんですが、Twitterでは有益な情報を得ることもできるし、知り合いと楽しくコミュケーションすることもできるためなかなかやめる踏ん切りは付きませんでした。それと、僕は「記録していく」というのが好きな性格なので、自分の行動や思考を何かしらに書き残したいとも思っていました。そこで、「他人のことを気にするのではなく、自分が主体であり、自分の好きなことを気兼ねなく書くことができるサービス」を使いたいと思い、Trickleを作り始めました。2017年から1年ほどクローズドテストを数名で行った後、2018年に一般公開しました。以下はその時のリリース記事です。Twitterのトレンドに入ったり、abemaTVに出演させてもらったりと思った以上に反響があり嬉しかったです。同時に、僕と同じように困ってる人は結構いるんだなぁと思いました。blog.h13i32maru.jpコンセプトは「気兼ねなく書き留める」Trickleのコンセプトは「自分の好きなことを気兼ねなく書き留めて、書くことを楽しむ」です。そのため、他者の書き込みを見たり、反応・コミュケーションしたりというのは優先度が低い作りになっています。これはTwitterやインスタ、最近だとClubhouseのような人とつながったりコミュケーションをするためのSNSとは大きく異なるものです。例えばTwitterのアプリストアでの紹介文にはこのように書いてあります。一緒に会話してみませんか ツイッターは無料のSNSアプリです。(...省略...) 海外セレブのアカウントをフォローしてみてください。(...省略...)世界中で人気のSNSでは、友達やあらゆる人とつながったり、世界に向けて自分の声を発信することができます。会話・フォロー・つながる・発信というワードからもわかるように、SNSは主体がネットワークであり、そのネットワークに参加しコミュケーションを楽しむことがメインです。一方でTrickleの主体はあくまでも自分であり、自分の好きなことを書いて残していくことそのものを楽しむのがメインです。とはいえ他者と全く関わりがないのは少し寂しいですし、一人でやるならメモアプリで良くない？となります。なのでTrickleにも気兼ねなく書き留めることを第一に考えつつも、サブの位置づけとして他者と程よい距離感で関われる設計にしてあります（このようなサービスなのでTrickleはSNSではなくアクティビティログサービスだと考えています）。SNSとTrickle、これはどちらが良い悪いではなく個人の趣向によるものですし、共存もします。現に僕はどちらも継続して使っています。人から反応が欲しかったりコミュケーションしたいもの（とか本当に他愛もないのも）はTwitterに、自分が楽しみたいと思うものはTrickleに書いています。※SNSをコミュニケーション目的で使っていない方もいると思いますが、ここではあくまでも各サービスのコンセプトという視点で書いています気兼ねなくを実現する「トピック」Trickleには気兼ねなくを実現するために「トピック」というものがあります。トピックは一見ブログのカテゴリーやSNSのハッシュタグに似ていますが、それらとは根本的に違うものです。どちらかというと「ジャンルごとにSNSのアカウントを作って使い分けている」というのが近い考え方です。例えば僕は「Trickle開発」「アニメ」「本」などのトピックを作っています。他のTrickleユーザも「漫画」「ゲーム」「ビール」「植物の話」などなど、思い思いのトピックを作っています。また、トピックのアイコンに統一感を出して、自分好みなデザインにして楽しんでいるユーザも結構いらっしゃいます。Trickleではこの作成した自分のトピックにアクティビティ（メモや写真）を書きとめていきます。そして他の人のトピックを個別にサブスクライブすることができます（フォローのようなこと）。なのでトピックをサブスクライブして見ている人は「その人のそのトピックをみたい」と思ってみています。つまり書く方は「この話みんな興味ないかも」「うざいって思われないかな」のようなことを気にせず気兼ねなくアクティビティを書くことができます。その他にも気兼ねなくを実現するために、Trickleには普通のSNSとは違ういくつかの特徴があります。🏠ホーム画面自分のアクティビティだけが表示されます。👀他人の投稿プッシュ通知が届きます。これは「プッシュ通知でみたいぐらい本当に関心があるトピックだけをサブスクライブする」という設計だからです。💚コミュニケーション機能🔔お知らせユーザの感想ブログこれらのコンセプトや機能によりTrickleは他のユーザとほどよい距離感が生まれ、結果として気兼ねなく書くことができるようになっています。そしてこのサービスを気に入ってくれたユーザの中には感想ブログや紹介ブログを書いてくださる方もいらっしゃいます。ほんとうに嬉しいかぎりです。本記事の締めとして、ここではいくつか引用させていただきます（掲載を削除したい場合はお手数ですがご連絡ください）。最後まで読んでいただき、ありがとうございました。自分の好きなことや活動を書き残したい人、つながりやコミュケーションを楽しむSNSから少し距離をとりたい人、そんな方々にTrickleはピッタリだと思うので是非お試しください。すでにお使いの方はTrickleが合いそうな知り合いに是非勧めてみてほしいです。https://trickleapp.me投げ銭（月額$1〜$5）もやっているので応援していただける方はよろしくお願いします。https://gumroad.com/l/h13i32maru*1:トピックのデザイン改善、UI改善、日本語化など

見る・話すより、書くこと自体を楽しむサービス「Trickle」

今年は子供が生まれた（めちゃくちゃ可愛い、最高）ので、あまり個人のプロダクト開発には時間を取れないかなと思ってた。けど奥さんの理解と協力があり、結構開発できたと思う。めっちゃ感謝。というわけで簡単に振り返っておこう。Jasper v1.0のリリースhttps://jasperapp.io/Jasperを開発しはじめて5年目、ついにv1.0をリリースできたぞ！！v1.0の開発は6月末からはじめて、10月に完成という感じだった。v1.0ではコンセプト自体はそのままで、内部のアーキテクチャと実装を刷新(+2万L/-1.5万L)。TypeScriptのおかげでこういう大規模な改修もあまり怖くなくできて最高だったな。この刷新によってパフォーマンスが体感できるぐらいよくなったし、拡張性もだいぶよくなったと思う。他にもデザインのモダン化、GitHub API v4(GraphQL)に対応、GitHub Projectに対応、ドキュメントの刷新などなど。だいぶ頑張った。ユーザの反応もかなり良くて嬉しかったな。手前味噌だけどJasperないと仕事にならないぐらいめっちゃ使ってるので、今後も開発頑張っていくぞ。食卓ラボリリースhttps://dininglab.app/我が家は奥さんも僕も料理が好きだし、食べるのも好き。なので食卓楽しくするためのプロダクトとして食卓ラボを作った。構想は去年からしてて、実際の開発は2月ぐらいから初めて6月末にリリース。これでReact Nativeでアプリを作るのは3つめだし、だいぶこなれた感じで作れたな。React Native自体も安定してきて、特にネイティブモジュールを追加するのが格段に楽になって最高。React Navigation（画面遷移のライブラリ）もv5からReact Componentベースになってすごく使いやすくなって最高。バックエンドはGCP(GAE + Node.js + Express)で素朴に作ってある。あまり大したことはしてない。ただのCRUDアプリ。でも結構費用かかってるのでなんとかしたい・・・。なんでかっていうと投稿された画像のリサイズ処理をアプリサーバでやってる関係でGAE Flexibleインスタンスでメモリを増やしたりしてるから。あとCloud SQLも結構いい値段する。まあ面倒なことはすべて見てくれてるからありがたいんだけどね。とはいえ高い。あとアプリのアイコンはなんかもっといい感じにしたかったが、素人には限界だった・・・。やっぱりちゃんとプロにお金払って作ってもらうのがいいよなぁ。今は数名がヘビーに使ってくれている段階なので、来年は積極的に宣伝してフィットするユーザに届けたい & 増やしたい。Trickle改善https://trickleapp.me/TrickleはReact Native/GCPで初めて作ったアプリで2018年にリリースした。なのでコードは微妙なところが結構ある。というわけで、以降に開発したアプリの良いところを取り入れたり、ライブラリのメジャーバージョンアップなどをしはじめた。React Nativeのアップグレードには専用のツールなども用意されてるけど、うまくいったためしがない。なので新規プロジェクトを作って、パッケージ入れたりアプリの設定して、ソースコードを移植するという方法をとってる。大変だけどこれが一番問題なくアップグレードできる。あとReact Navigationもv4だったのでv5にアップグレード。API体系がガラッと変わったので大変だったが、食卓ラボで使っていたので移行パスは見えてた。物量は大変だったけど。年明けからはサーバ側のコードをリファクタしていく。今のコードはだいぶひどいので、食卓ラボの設計に合わせる感じ。十分な時間があればPrismaとかGraphQLとかCloud Runとかもやってみたいが、来年使える時間は少なくなるので無理そう。とりあえず1〜2月でリファクタと機能追加頑張る。Supporter Subscriptionhttps://h13i32maru.jp/supporter/プロダクトのサーバ代やドメイン代などをサポートしてもらえると嬉しいなと思って$1〜$5/monthでサブスクを始めてみた。まだサブスクしてくれた人はごく僅か。というかパブリックな場では発言してなかったかも。今の所特典はほぼないけど、サブスクしてくれてる人だけが使えるJasperやTrickleの機能とか考えてる。来年作れたらいいな。CodeLunch.fmhttps://codelunch.fm/今年復活させた！来年は継続的に録っていくぞ！ただanchor.fmの収録アプリは音ズレがひどくてだめだった。なにか違うのを試さないと。https://zencastr.com/ がいいと聞いたので試してみる。あと、CodeLunch.fmのサイトをNext.jsに入門がてらSSGで作り直してみるかーと一瞬思ったが、やっぱりやめてTS(ts-node)で雑にHTML生成した。テンプレートリテラルを使えばHTML部分をReactぽい雰囲気でかけるし、WebStormならこれをHTMLと認識してコード補完とかも効くので雑にやるには十分。依存パッケージもTypeScriptだけなのでお手軽。動的なペライチHTMLを作るときはこれぐらいでいいや。Twitter広告作ったプロダクトをどうやって宣伝すればいいのかわからず、これまで大したことはやってこなかった。Product Huntにのせたり、宣伝用のブログを書いたり、Twitterでエゴサーチしてユーザとコミュニケーションとってみたりぐらい。けど、ちょっと試しにTwitter広告つかってみたら、これがすごい簡単でよかった。今の所効果はあるのかないのか正直わからんけど、来年はもうちょっと真面目に使ってみようと思う。ただ、お金がめっちゃとけるのでそこは気をつけないといかんな。ESDochttps://esdoc.org/今年も全く触れなかったなぁ、、、issueやPR来てるのは認識してるんだけど、今の僕はESDocを使うようなプロダクト（JSのライブラリやフレームワーク）を作ってないので、開発の優先度があがらない。まあ真に必要でやる気のある人がいればforkするなり、新しく作り直すなりするだろう（僕がJSDocをみてESDocを作ったように）。ただツールとしてはすごい面白い題材だから、やりたい気持ちは結構ある。今ならTSのためのドキュメンテーションツールとしてTSで書きたいな。プロダクト開発以外だとコロナとかリモートワークとかエンジニア復帰とか色々あったなー。来年はさらに色々ありそうなので、頑張って生存していかねば。

2020年個人プロダクト開発(とか)の振り返り

以前から開発しているJasper(GitHub用のissueリーダー)のv1.0.0をついに今日リース！やったー！前バージョンから作り直しレベルでコードを書き換えたので、かなり大変だったなぁ。でもそのおかげですごく良いものにできた！jasperapp.ioというわけで、こんにちは丸山@h13i32maruです。今日はJasper v1.0.0のリリース記事なのですが、GitHubを普段使ってる人にはJasperも是非使ってみてほしいので、少ししっかりめに書いてみました。よろしくおねがいします🙋🕵️ Jasperとは（初見の方向け）JasperはGitHubのissueを柔軟に見ることができるツールです。例えば「nodejs/nodeのbugラベルがついたissue」「自分が作成したpull request」などの条件でissueを見たり通知を受け取れます。この条件はJasperに次のようなクエリで設定します（この機能をStreamと呼ぶ）。repo:nodejs/node is:issue label:bug世の中にはGitHub用のissueリーダーは公式(github.com/notifications)含め色々ありますが、基本はGitHub Notifications  APIを使っています。しかしJasperはGitHub Search  APIを使っているので、それらのツールに比べてかなり柔軟な使い方ができます。僕は仕事でGitHubを使っているので、issueの見落としを防いだり、ユースケースに合わせて柔軟に使えるようにと考えて、このJasperを作りました。🔧 v1.0.0での改善点(すでにJasperを使ってる方向け)以前のJasperは良くない設計や実装があり、そのせいでいくつか不満点がありました。僕自身も不満だったものの、改善するのが難しかったのですが、v1.0.0ではめでたく改善することができました🎉クリックや読み込みの反応速度アップPRのマージ・クローズを正しく表示Streamのスムーズな並び替えissueを自分で更新した場合に通知をしないそれと、今回のバージョンアップで新たにnotificationsとread:orgのスコープが必要になります。Jasperに設定しているGitHubアクセストークンを編集してこれらのスコープを追加してください。🧙‍♂ v1.0.0での新機能v1.0.0では大小様々な新機能を開発したのですが、特におすすめ（と言う名の話したいもの）を紹介します！デザインmacOS Big SurからUIパーツの見た目がけっこう変わるということなので、それを参考にリデザインしてみました。テーマは明るく親しみやすい感じ。素人デザインですが、個人的には割とよくできたなと満足してます。issueの表示issueリストにはラベルやauthorなどの情報を表示しています。v1.0.0ではそれらに加えてプロジェクト名やレビュー状況なども表示するようにしました。特にレビュー状況は誰がapprove、changes requestedしてるかがぱっとわかり便利になりました。検索/Jump NavigationJump Navigationを使うとJasper内のissueを検索したりStreamやリポジトリに移動したりなどができます。検索にはクエリ（is:openなど）を使うこともできます。つまりSlackの⌘ + Kのような機能です。GitHub Projects連携GitHub Projectのカンバンと連携できるようになりました。未読既読をカンバンに反映させたり、カンバンでissueを選択したらJasperで表示するようになりました。ダークモード以前のバージョンでは任意のcssを読み込めるユーザテーマ機能でダークモードを実現していたのですが、v1.0.0からは組み込みでダークモードに対応しました（ユーザテーマ機能は廃止）。スマホとの併用これまでスマホやJasper外のブラウザでissueを見ても、Jasperでは既読になりませんでした。v1.0.0ではGithub Notificationsとシンクすることで、既読を反映できるようになりました。これでスマホとの併用もだいぶ実用的になったかと思います。📖 HandbookJasperには今回紹介した以外にも様々な機能があります。そのためJasper Handbookというドキュメントを作成しました。用途に応じて参照してもらえると嬉しいです。試しに使ってみたい →「クイックスタート」自分にあった使い方を知りたい →「ユースケース」細かいところまで使いこなしたい →「リファレンス」もしJasperを誰かに紹介してくださる場合は「クイックスタート」も一緒に紹介してほしいです🙏💻 技術的な話も書こうかと思ったんですが、長くなってきたので、またそのうち別記事にします。Electronアプリの高速化や、ダークモード対応、UIなどについて書く予定です。というわけで、Jasper v1.0.0の紹介でした。興味を持った方は是非お試しください〜。jasperapp.ioGitHubのスターもお待ちしております！

Jasper v1.0.0をリリースしました🚀（GitHub用のissueリーダー）

こんにちは丸山@h13i32maruです。GitHub用のIssue/PRリーダーとして開発しているJasperのv0.9.1をリリースしました🎉今回は軽微なバグ修正/機能改善がメインです。コンメントミニマップにスクロール位置を表示outdatedなレビューコメントのハイライト処理を修正（主にGHEへの対応）URLバーをクリクックしたら選択状態にするそれと実験的な機能として「任意のcookieを指定できる」機能を追加しました。cookieはGitHubへのAPIリクエストとウェブブラウジングに付与されます。使いどころとしては「社外から社内のGHEへのアクセスでは何かしらの認証情報をcookieにのせる」みたいな用途を想定しています。かなり限定された用途ですが、僕はこの機能があると少し楽になることがあるので、試しに作ってみました。ちなみにドメインは利用先のGitHubホスト固定、secure有効、httpOnly有効、SameSite=None固定となっています。SameSiteはLaxを使いたいけど、Jasper上でGitHubのユーザアイコンを表示してる都合上難しそうです。。実験的な機能なので、もしかしたらそのうちなくなるかもしれません。次はパフォーマンス改善をしたいのですが、その前に内部のリファクタリングをしなければならないです。なので、しばらくは機能改善を行えないかもですが、ぼちぼちやっていきます💪

Jasper v0.9.1をリリースしました

未来の自分へ、当時考えていた事を残しておく。2018年,2019年は10人程の部に所属していた。その部署はユーザ投稿に責任を持つ部署だった。部署の役割はそのユーザ投稿を伸ばすこと。僕はそこで部長という役割を任されていた。メンバーと一緒にユーザ自身もまだ気づいてないけど、ユーザが求めるものを見つける旅をする。インタビュー、プロトタイプ、テスト、議論を繰り返したし、デザインスプリントもたくさん回した。最高のメンバーと楽しくもあり大変でもある旅ができた。でも今年は部長という役割を降りることにした。同時に社内の組織変更（これはよくある）も行われて、今は30人ぐらいの部署に所属している。ただし部署の役割は大きく変わったわけではない。なんで降りたかいくつか理由はあるけど、一番は「ものづくり」がしたいから。いや当時もものづくりはしていた。でも僕のものづくりは「自分が使って幸せになるもの」というのが暗黙的に含まれてることに改めてきづかされた。思い返せばいつだって自分が使うものを作るときが一番楽しかったのだ。僕は誰かのためにものを作り、そして誰かが幸せになる。ということに残念ながらあまり情熱をもてない。あくまでも第一義的には「自分が使って幸せになる」だ。ものづくりをしている人の中には誰かのために情熱を持てる人もいて、素直にすごいなと思う。でも、僕はこの2年間でそうはなれなかった。自分の情熱は狭い。奥さんや子供が幸せになることはその情熱の中心に入るけど。そんなわけで、正解もわからないし、終わりがあるのかもわからない旅を、こんな気持で続けていくのは難しい。実際、2019年末に自分自身で疲れてるのを実感していた。会社で雇われてる身としてはこの考えは完全にあまいというのは理解しているし、プロダクト開発に関わるものとしては失格かなとも思う。でもなんとか折り合いを付ける必要がある。そこで部長という役割をおりて（降ろしてもらい）、エンジニアとして会社に貢献することにした。もちろんプロダクトのことを何も考えず、ただひたすらコードを書く人になるわけじゃない。どこに主軸を置くかの話である。一方で「ものづくりがしたい」はどうやって叶えるのか。それは主にプライベートでやっていくことにした。と言っても今までもやっていたことを続けていくだけなのであまりかわらない気もする。以前よりもう少し力をいれるようになるのかな。仕事ではエンジニアとして貢献し、給与と技術力を磨く機会を得て、プライベートでは自分が使って幸せになれるものをつくる。それが現時点での僕の落とし所だ。部長という役割をお願いされたとき、3年は続けてみようと思っていた。なので逃げてしまった罪悪感みたいなものが頭の中を漂う。でも2年間走りきったというのも確かだ。そう思って気持ちを切り替える。ちなみに降りた他の理由は「やっぱりエンジニア職は楽しい」「エンジニアリングとマーケティング（広義）の二足を履くのは超高難易度」「マーケティングの道は行き残れる人数が少ない」というのを感じたから。結婚して数年、子供もうまれて自分の価値観が変わりつつあるのを感じる。だから数年後には違うことを言ってるかもしれない。それはその時また落とし所をみつけてやっていく。育休が終わり明日からエンジニア復帰だ。仕事でプロダクションレベルのコードを書くのは数年ぶり。うまくやっていけるといいな。

自分が使って幸せになるものを作る

こんにちは丸山@h13i32maruです。GitHub用のIssue/PRリーダーとして開発しているJasperのv0.9.0をリリースしました🎉新着コメントのミニマップ今回の目玉アップデートは新着コメントのミニマップ機能です。新着コメントの位置を左のバーで視覚的にわかるようにしました(こういうのもミニマップと呼ぶかは分からないんですが、とりあえずそう呼んでます)。issueをスクロールして新着コメントが画面内に表示されればマークも消えていきます。逆にマークをクリックすれば当該の新着コメントの位置へスクロールします。Jasperの未読コメントのミニマップ機能、めっちゃいい感じになった。コメントが画面内に表示されたら連動して緑のマークも既読になる。マークをクリックすれば当該のコメントにスクロールする。 pic.twitter.com/kKAB3mJ5rG— Ryo Maruyama (@h13i32maru) June 26, 2020 実装自体は愚直に要素の位置や高さを取得して、ミニマップを作るための計算をしています。コメントが画面内に入ったかどうかはIntersectionObseverを使っています。便利。その他のアップデートJasper内でコメントを書いたときに、自分の変更による更新通知がされないようになりましたこれまでも実装はしていたけど、いまいち不安定だったのを改善StreamsとIssuesのリスト領域をリサイズできるようになりましたウィンドウの位置とサイズを保持して、前回と同じ位置/サイズで起動するようになりましたSQLiteのVacuumを実行できるようになりましたIssue/PRの説明文の更新diffが表示されなくなっていたのを修正しました全ての更新内容はこちらです。https://github.com/jasperapp/jasper/blob/master/CHANGELOG.md#090-20200627と言う訳で、なんとなくリリースブログを書こうかなと思って、今回試しに書いてみました。余力があれば今後も続けてみます。それとまだJasperを使ったことがない人はぜひお試しください🙏合わせてこちらもどうぞ〜

Jasper v0.9.0をリリースしました

こんにちは丸山@h13i32maruです。昨日、食卓ラボというサービスをリリースしました！食卓ラボは僕の「一人だと料理する気がおきない。でも家族に作るのはやる気が出るし、一緒に食べるのは楽しい。だったら一緒に囲む食卓をもっと楽しくしたい 。インスタやTwitterのように外を楽しくするサービスじゃなくて、内（家）を楽しくするサービスが欲しい」という思いから作りました。 食卓  ラボ  ノート       なので、食卓ラボは自分のために作ったサービスですが、せっかくなら色んな人にも使ってもらいたいと思っています。そこで、リリースのお知らせを兼ねた紹介記事を書いてみました。気になった方は是非続きを読んでみてください。「使い方」「作った背景」「SNSとの違い」という順で紹介していきます。使い方「食卓・ラボ・ノート」食卓ラボを一言でいうと「食卓を囲む人たちと、食卓の感想やメモを一緒に書いていくサービス」です。そしてこのサービスでは「食卓・ラボ・ノート」というものが登場します。用語が少し混乱するかもしれないので、簡単な図を書いてみました。これを念頭に置いてもらいつつ、テストに参加してくれたユーザの実例を見ていただこうと思います。食卓食卓ラボでは「食卓」というまとまりでサービスを使っていきます。例えば僕と奥さんは「丸山家」という食卓を作成してサービスを使っています。他のユーザも「菊田家」や「かわむら食堂」など自分たちの食卓を作成しています。つまり「食卓」は「一緒に食卓を囲む人たち（家族・パートナー・シェアハウス仲間・etc）で作るグループアカウント」のようなものです。 丸山家  菊田家  かわむら食堂       もちろん個人のアカウントは存在するのですが、基本的にはこの「食卓」という単位でサービスを使っていきます。ノートでは具体的に食卓ラボで何をするのかというと、「ノート」という食卓に関する備忘録のようなものを書いていきます。作った料理のこと、買ってきたお惣菜やデリバリーした料理、調理器具や食器のことなど、食卓に関することならなんでも自由です。写真のきれいさは気にせず普段の飾らない写真で大丈夫です。 トマトソースのパスタ  鯖缶詰  焼きおにぎり       そしてノートには同じ食卓の人であれば写真を追加したり、メモを書き込むことができます。つまり共同でノートを作成していけるということです。この共同のノートが食卓を楽しくしていきます。 僕と僕の奥さんがメモを書いている様子   次はノートのまとめ場所である「ラボ」についてです。ラボ僕はカレーが好きで、奥さんはパン屋が好きだったりと、同じ食卓を囲んでいても好みや関心が違うのは普通です。でもそうすると、食卓に色んな種類のノートが溢れて散らかってしまします。そこで、このサービスでは「ラボ」ごとにノートを書き溜めていきます。例えばテストユーザの方は「餃子ラボ」「缶詰ラボ」「休日のごはんラボ」などを作っています。 餃子ラボ  缶詰ラボ  休日のごはんラボ       ちょっと変わった使い方として「ネタ帳ラボ」や「気になるレシピラボ」として、今度作りたいレシピのURLなどをストックするというのも見かけます。他にも「器ラボ」というのも良いですね。 ネタ帳ラボ  気になるレシピラボ  器ラボ       食卓ラボではまず自分の食卓に好きなラボを作って、そのラボにノートをためていく。ラボごとにノートをためていくので見返すのも便利。というのが基本的な使い方になります。ブックマークやフォロー他の食卓の気になるノートを見つけたら、それをブックマークすることができます。ブックマークすると同じ食卓の人に共有されます。例えば僕がブックマークしたものは奥さんも見ることができます。同様に、好きなラボを見つけたら、そのラボをフォローして食卓内で共有することができます。 ブックマーク  フォローしているラボ  フォローしているラボのノート       食卓ではなくラボをフォローすることによって、「この食卓の○○は興味あるのでみたいけど、☓☓は見なくてもいいかな」ということができます。これはノートを書く人にとっては「見たい人だけが見ているから、気兼ねなくノートを書ける」という効果があります。サービスの使い方紹介は以上です。ここからは食卓ラボを作った背景や一般的なSNSとの違いを紹介します。作った背景「スマホに料理写真が溜まっている」冒頭でも書いたとおり、僕は食卓を楽しくしたいという気持ちを持っていたのですが、どうすれば楽しくできるか分かりませんでした。少し話は変わるのですが、僕や奥さんは料理を作ったり、美味しそうなお惣菜やお弁当を買うのが結構好きです。そして、それらの写真を撮ることも多いのですが、インスタやTwitterに載せることはあまりしません。なぜ載せないのかというと、同僚や友人に特段見せたいわけではないし、すごくきれいな写真というわけでもないからです。そうするとどこにも行き場がない料理やご飯の写真がスマホに溜まっていきます。そこで、この写真たちを使って、我が家の食卓を楽しくできるんじゃないかと思って食卓ラボの構想がうまれました。食卓に関する写真やメモを一緒にためていく→それがきっかけとなり食卓でのコミュニケーションが増える→また食卓ラボを使う。というようなサイクルを作れそうだなと。ポイントはあくまでも実際の食卓でのコミュニケーションを楽しくする補完的なものだということです。SNSとの違い「外で楽しく・内で楽しく」ここまで読んでくれた方の中には「これってインスタやTwitterで共同アカウントつくればいいのでは？」と思った方もいらっしゃるでしょう。結論から言うとそれでは難しいです。なぜなら一般的なSNSは色んな人とのコミュニケーションを楽しむことを目的に作られています。つまり外で楽しく。もちろん一般的なSNSの目的はそれだけではないと思いますが、やはりメインは外でしょう。一方で僕がやりたいことは一緒に食卓を囲む人たちとのコミュニケーションを楽しむことです。つまり内(家)で楽しく。 インスタグラム外で楽しく  食卓ラボ内で楽しく     これはどちらが良い悪いという話ではなく、目的が違うものを無理やり使っても楽しくならないということです。そこで食卓ラボでは内を楽しくすることを中心にサービスを設計しています。例えば、ホーム画面は自分の食卓のコンテンツだけが表示されるハッシュタグという全ユーザ共通のものではなく、各食卓で独立したラボを提供コメントやいいねによるコミュニケーション機能は提供しない他の人からフォローなどをされても通知は飛んでこず、同じ食卓の人のアクションのみ通知が飛んでくるなどなど。こんな感じで外ではなく内が楽しくなるようにサービスを作っています。もちろん他の食卓との関わりが全く無いのは寂しいですし、上手に扱えば自分たちの食卓を楽しくする要素にもなります。なので、そこのバランスを考えながら今後もサービスを改善していきます。以上がサービスの紹介になります。少し長いブログになってしまいましたが、最後までお読みいただきありがとうございました。 食卓ラボに興味を持たれた方はぜひ使ってみてください。何か気になることがあればこの後に載せているFAQもご覧ください。FAQ一人で使っても良いですか？はい、使っていただいて問題ありません。ですが、食卓ラボはあくまでも複数人で使うことを考えて作っているので、不便や不満があるかもしれませんがご了承ください。コメントのやり取りはできますか？同じ食卓の人とも、違う食卓の人とも、コメントのやり取りをする機能はありません。同じ食卓の人であればノートに「メモ」を追記することはできますが、これはあくまでもメモでありコメントではありません。料理レシピは書けますか？料理レシピに特化した機能はありませんが、「ノートの詳細」という機能があります。少し凝った見た目のテキストを書くことができます。詳しくはアプリの中のヘルプをお読みください。 肉味噌炒め  海南鶏飯  ハンバーグ       鍵（非公開）機能はありますか？鍵機能はありません。内を楽しくするのが一番の目的ですが、他の食卓を見たり・他の食卓から見られたりというのをうまく取り入れれば、家の食卓を楽しくするのに役立つと思っています。パソコンから使えますか？今の所iPhoneアプリ、Androidアプリのみの提供となっております。パソコン用のアプリを開発するかは検討中です。無料ですか？はい、無料です。有料機能や広告表示などは今後可能性がありますが、現在のところは無料です。。今後、どんな機能が追加されますか？まだ決定したものはありませんが「ノート詳細のリクエスト」や「ラボの製本化」などを考えています。特に製本化は面白そうなのでやってみたいのですが、さすがに個人開発では難しそうです。ご興味がある企業の方がいらっしゃればお声がけください😀感想やフィードバックはどうしたらよいですか？メールや@h13i32maruにメンション/DMをいただけると嬉しいです。もちろんTwitterでつぶやいてもらったりするだけでも嬉しいです。ブログなどを書いてもらえたら最高に幸せです。あなたは誰ですか？丸山@h13i32maruといいます。サービスやプロダクトを作るのが好きなソフトウェアエンジニアです。Trickle、Jasper、ESDocなどを作ってきました。食卓ラボはTrickleに大きく影響を受けています。ホムペはhttps://h13i32maru.jpです。

食卓を楽しくするサービス「食卓ラボ」をリリースしました！

こんにちは丸山@h13i32maruです。現在、Trickleという「気兼ねなくアクティビティを書き留められるサービス」を開発しています。去年の11月にiOS/Android用のスマホアプリをリリースしたのですが、今回Windows/Mac用のデスクトップアプリをリリースしました🎉（11ヶ月ぶり2回目のリリース）Trickle - Write down your favorite activities without hesitationというわけで、今回あらためてTrickleを紹介します！以前見かけて気になっていた人、使ってみたけど離脱しちゃった人、全然知らないけど偶然この記事にたどり着いた人、これをきっかけにちょっと試してみませんか！？トピック & サブスクライブTrickleとは自分の好きなアクティビティ(活動)について気兼ねなく書き留めるサービスです。気兼ねなくと書いたのは、このサービスはクローズドなアプリではなく、オープンなサービスだからです。サービスにログインすれば誰でも他の人が書いたアクティビティを見ることができます。でも、気兼ねなく書きたいのならクローズドのほうが良くない？という疑問をもたれるのは当然だと思います。これは僕の考えですが、オープン(=人の目)であることは良い影響をもたらす面があると考えています。例えば文章の書き方や内容を意識する、他者から影響を受けて活動を始める/続ける、活動についてコミュニケーションをとる、などなど。でもオープンであることは上手に使わないと良くない影響（書きづらくなる、居づらくなる、など）がでてきます。そこでTrickleではトピックという機能を中心に、オープンでありつつも気兼ねなく書き留められることを実現しています。トピックというのはユーザが自由に作れるアクティビティのカテゴリみたいなものです。このトピックはいわゆるハッシュタグとは違い、各ユーザ固有のものとなります（Aさんの読書トピックと、Bさんの読書トピックは独立してる）。Trickleではこの自分で作ったトピックごとにアクティビティを書き込んでいくことになります。こんな感じで、みんな自分の好きなトピックを思い思いに作っています。そして、他の人の感心があるトピックを自由にサブスクライブ(フォローのようなもの)することができます。こうすることで「Aさんのゲームトピックには興味ないけど、読書トピックには興味あるのでそれだけサブスクライブする」ということができます。これは裏を返すと自分のトピックは見られることがあるけど、それは本当にそのトピックに興味がある人しか見てないということです。よって「見てる人の気持ちを考慮しながら書くか書かないか考える」という煩わしさを無くし、気兼ねなく書けるという構造を作り出しています。それとトピックには自分が作ったトピック以外のことを書くのを抑止する効果があります。結果としてTrickleには自分の好きなものだけが集まる構造になります。ただし、「つぶやき」「雑記」みたいなトピックを作るとそれを崩すことも可能です。このあたりはユーザに委ねている部分です。リンク気兼ねなくを実現するための他のポイントとして、Trickleには一般的なSNSにある、コメントやいいね、リプライなどはありません。じゃあコミュニケーションとれないの？と思われるかもしれませんが、Trickleにはリンクという機能があり、使い方次第でコミュニケーションを可能にします。リンクという機能は「自分のアクティビティに他の誰かのアクティビティを紐付けて書くことができる」というものです。Twitterの引用RTに近い形です。このリンクとトピックを合わせることで、自分にあったコミュニケーションの方法をとることができます。例えば「Like」というトピックを作って他の人のアクティビティをリンクしていけば、イイねになります。「返信」というトピックを作ればリプライに、「ブックマーク」というトピックを作ればお気に入りに。そして、このリンクという機能はサービス内では拡散されづらい構造になっています。なぜかというと、その「Like」や「返信」などのトピックをサブスクライブしている人にしか伝搬しないからです。そして「返信」などの双方向のコミュニケーションがヘビーになりづらい機能でもあります。結果として、一般的なSNSよりも抑え気味なコミュニケーションになるので、気兼ねなくというのをサポートしています。もちろんこのリンクは自分のアクティビティを紐付ける事もできるので、コミュニケーション以外にも使えます。僕は目次のような使い方をしていますし、ユーザによってはリンク機能をハックして独自の使い方を編み出している人もいます。全体像という感じで、Trickleではトピックを中心にして、他の機能を連携させることで、オープンなのに気兼ねなく書き留められるサービスとして設計しています。Trickleは自分のアクティビティを書き留めていくことがメインで、おまけとしてコミュニケーション要素があります。一般的なSNSは真逆で色々な人とのコミュニケーションがメインです。なのでSNSを「自分の記録」として使おうとすると色々ストレスになります。もしSNSを自分の記録としても使っているようでしたら、ぜひTrickleを試してみてください！（そういえばTwitterもトピック機能を考えていたり、インスタグラムもいいね数を見えなくするなど、色々検討してるみたい）。実際のユーザ視点での感想は見つけた範囲でここにまとめています。気になる方は見てみてください。デスクトップ版そんなTrickleですが、スマホ版に加えてデスクトップ版（Windows/Mac）をリリースしました！なぜデスクトップ版を作ったかというと、長文やパソコンでの活動について簡単に書き留められるようにするためです。ユーザの使い方を見ていると、パソコンからスマホに画像を転送してからTrickleに書き込んだり、スマホにキーボードを付けて長文を書き込んだりというのをちらほらみかけました。僕自身もパソコンでの作業中にTrickleに書きたいなーと思うことがしばしばありました(余談ですがTrickleデスクトップ版を開発するのに、開発中のデスクトップ版を使いつつ、開発のアクティビティを書き留めていきました。セルフホスト感があって大変楽しかったです)。そういう経緯から、デスクトップ版は書くことに特化させています。なので、他の人のトピックを見たり検索したりというのには対応していません。将来的には作るかもしれませんが、そうなったとしても書くことがデスクトップ版での最優先事項として設計するつもりです。それとデスクトップ版では新規アカウント作成には対応していないので、まずはスマホ版でアカウントを作り、Trickleの雰囲気を理解してからデスクトップ版を使ってもらうことをおすすめしています。というわけで、デスクトップ版による11ヶ月ぶり2回目のリリースでした。好みが分かれるサービスだと思うのですが、少しでも興味を持った方はぜひ試してみてください！Twitterやインスタグラムを何かの活動記録に使っていたり、Slackなどで記録用の分報をしてる人に相性いいと思います。そしてTrickleについてブログを書いてくれたり、ツイートしてくれると嬉しいです。そのときは#trickleappmeをつけてくださいー！https://trickleapp.me

気兼ねなくアクティビティを書き留められるTrickleというサービスをリリースしました（11ヶ月ぶり2回目）

GitHub用issue readerのJasper v0.8.0をリリースしました🎉今回は、v0.8.0で改善したことや、今後考えてる機能を簡単に紹介していきます。Jasperについて詳しくはこちらとかこちらの記事をみていただけると。https://jasperapp.io/ https://github.com/jasperapp/jasperTypeScript化v0.8.0でTypeScript化しました。Jasperの機能的には特に変化がないのですが、開発するにはすごくいい感じになりました。もともとずっと生JavaScriptを書いていたのと、保守的な性格なので「WebStormが頑張ってくれるから、生JavaScriptで十分」と思ってたんですが、仕事でTypeScriptを書く機会があり、「これはいい！」と改心しました。TypeScript最高！React + TypeScript + WebStorm最高！(VSCodeを使ってないのは昔からWebStormで書いてるので)TypeScript導入時に参考にしたのはgfxさんの「TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に」です。そう、頑張らなくていいんですよ。漸進的にやっていけば。今回はとりあえずコンパイラを通すことを目標にTypeScript化しました。それだけでも不具合を数個みつけることができました。次はReactのstate, propsに型をつけていこうと思います。ちなみにimportを使いたいだけで入れていたbabelをやめて、開発への恩恵もあるTypeScriptにできたのもよかったです。ElectronのアップデートElectronをv6にアップデートしました。GitHubのissueはJasper内のBrowserView(いわゆるWebView)で表示しているんですが、Electronをアップデートしたおかげでその表示速度が若干向上しました。それと外部ディスプレイをつないだときやスリープから復帰したときに画面がホワイトアウトする不具合があったんですが、これも修正されました。あと、すごく細かいですが、右クリックが非同期化されてレンダリングプロセスを止めなくなったのでそこの使い心地も改善されています。という感じで、Electronのアップデートで色々改善されました。いつもElectronのアップデートPRを送ってくれるwatson1978さんありがとうございます！ちなみにApple Notarization Serviceに対応したのでMacOS Catalinaでも大丈夫！修正/変更以前から、コメント入力時にJasperのショートカットキーが誤作動する不具合があったんですが、今回修正されました。直そう直そうと思っていたんですが、PRをもらったのでそれを取り込みつつ、少し手を加えて修正完了しました。これで知らず識らずのうちにissueをアーカイブして見失わなくてすみます。やったー！他にもローカルへのissue保存件数がmaxになったときに未読件数がバグる問題をなおしたり、Chrome DevToolsをメニューから起動できるようにしました。DevToolsが使えるのでオリジナルのテーマ(CSS)を作ってくれると嬉しいなと思います。今後の話複数マシン間での同期機能を考えています。現状でもJasperのデータディレクトリをDropboxで同期したり、Jasperのデータディレクトリを変えるPRをもらったりしているのですが、今考えてるのはJasperからDropbox APIを使ってデータ同期するというものです。それとJasperのモバイルアプリも検討しています。デスクトップ版Jasperと同等の機能を作り込むのはさすがにちょっと厳しいのでどうしようかなーと悩んでいたんですが、前述のDropbox APIを使えば現実的な開発コストで実用レベルのものが作れそうな気がしています（なので複数マシン間での同期機能はDropboxのディレクトリ同期ではなく、Dropbox APIによる同期を考えてる）。実装方法としてはデスクトップ版が「最新100件程度のissueの未読情報」をJSONファイルとしてDropbox API経由でアップロードして、モバイルアプリはそれを表示するというものです。なので、モバイルアプリの位置づけはデスクトップ版の簡易ビューワアプリという感じです。もちろんモバイルで更新された未読/既読の管理はデスクトップ版にも反映させようと思いますが、Streamのポーリングや作成などはとりあえずなくてもある程度は実用できるんじゃないかと。このあたりはいつになるかわからないですが、のんびり待ってもらえると嬉しいです。というわけで、Jasperを使っていただいている方は今後もよろしくおねがいします。使ってない方も、GitHubのissue/PRを追いかけるのが大変という方はぜひ使ってみてください！https://jasperapp.io/ https://github.com/jasperapp/jasper丸山@h13i32maru