技術ブログまとめました

こんにちは、Speeeのヌリカエでエンジニアをしています。21卒の染谷です。 学生の皆さん、突然ですがエンジニアとして会社で働くってどのようなものか想像できますか？？私は開発系の長期インターンやアルバイト未経験だったので、学生の頃はなーんにもわからなかったです！！！ 今回は新卒2年目になったということで、1年間仕事をしてみてどうだったのか、Speeeで仕事をするとはどんなものかを裁量権という切り口から実態を取り上げ、少しでも働くということが想像できればと思います。 この記事を読めば、私はSpeeeは楽しく働けているぞ！ということがわかります。 私のバックボーンや何故Speeeに入社したのか、より詳しくはこちらのエンジニア新卒採用サイトへどうぞ。 newgraduate.speee.jp はじめに 現在、私は新卒採用のイベントや面談で学生とお話する機会があり、私自身も学生の頃、同じようなこと聞いてたなー気になるよなーと思いながら、私の観点からSpeeeはこうだよと実体験を交えながら紹介をさせてもらっています。 この記事で裁量権にフォーカスを当てようと思ったのも、よく聞かれるのでどうせだったらブログにして読んでもらったほうが理解にズレがなく伝わるんじゃないかなと思ったのがきっかけです。それと採用イベントって1人の学生と話せる時間が短いんですよね、なのでこの記事でより理解してもらえればと思っています。 本題の前に私が学生だった頃の話をさせてください。学生時代に私がどのような経験をして、どのようなことを思っていたのか。そのことを知ってからこの記事を見て頂くと、より一層想像できると思います。また、前提が違うのであれば、読んでいるあなたにとっては私とはまた違う感想を抱くと思います。 学生時代 私は大学時代はプログラミング系のサークルに所属していてUnityC#でゲーム制作などしていました。リーダーを務めていましたが他にやる人が居なかったからやっていた、あるあるパターンです。 リーダーなのでマネジメントのようなことも兼任していたのですが、他のメンバーでやる気のある人はあまりおらず、プログラミングをするのが好きなのも相まって私自身が頑張ってなんとか作品を完成させていました。 そんな中、他大学の学生と1年間プロジェクト活動をする機会があり、そこで初めてやる気のある人と一緒に開発し「意見出し合いながらなにかをつくるって楽しいな」という経験しました。 このような経験から、私はやる気のある人たちと働きたい。自分の手を動かしてプログラミングしたいと思ったのでベンチャー会社に就職したいと思っていました。 また、SIerが候補から外れているのは、自らの手を動かしたい。早く成長したい。裁量権を持って自由に働きたいと思ったからです。 Speeeの組織体制 Speeeで1年間体験した実態を紹介する前に「裁量権」 という言葉はいろいろな意味合いで使われることがあるので、この記事の中ではこういう意味で取り扱うという前提を明示します。 役職に関係なく自由に発言ができる ビジネスとの距離が近い 立候補すれば開発したいタスクをできる 自分のやりたいように仕事を任せてもらえる 1と2は裁量権という言葉からはちょっと違うなと思いましたか？今この文章を見ると私もそう思います。当時の私としては垣根がなく自由ということでそのようなことを思っていました。1と2をより正確に言葉に表すのであれば「無責任範囲」と言えば良いでしょうか。 また、Speeeではプロダクト単位で開発をしているので、誰がどのようなことを役割として持っているのか簡単にチームメンバーの紹介をします。 プランナー🤓 ユーザのことを一番知っているビジネス職の人。どのようなことを実現すればユーザに価値を届けられるのかを考え、要件の元となるアイデアを出す。プロダクトオーナーとも言う。 エンジニア👨‍💻 実際にプログラムを書く人。エンジニアリングの観点からどうしたらユーザに価値届けられるか考える。 1週間に1時間ある会議で、プランナーが持ってきたアイデアを議論し、ユーザへ価値を届けるためにはこの機能作ったら良いのではないかと話し合って要件を考える。 実態 実際働いてみてどうかと言うと理想通りに働けています。 後ろの席に居るプランナーと話し合いながら、つくる意義を聞きながら開発しています。 社内メールのお作法はこう！とか、完全に要件化されたものが上から降りてきてそれをコーディングするだけ！ということは一切なかったです。 開発してるときに疑問点や改善点が出てきたらプランナーに対して、slackでメンションつけてメッセージや直接席に向かって口頭で会話しています。 プランナーにはいつも忙しいところ時間とってくれて感謝です 🙏 役職やビジネスとの距離(1, 2について) Speeeの人は皆、目的思考を持っていて目的を達成するためには何が必要かを考えながら会話をしています。役職は関係ないですし職種すらも関係がないです。プランナーの専門分野とエンジニアの専門分野をそれぞれ尊重し、意見を出しつつユーザにとって良いプロダクトになるよう開発しています。 「ユーザの要望を分析するとこんな機能あったら良さそう！」とプランナーがアイデアを持ってきたとして、エンジニアはその案をそのまま鵜呑みにして開発することはありません。「この機能は本当に必要なのだろうか」「このコンテンツを作成すると重い処理になり、ページスコアが落ちて結果的にSEO下がりそう。他の方法はないのだろうか」と話し合います。 開発するという手段はエンジニアの専門領域です。責任を持って目的(プランナーの実現したいこと = ユーザの価値)を達成するためにどのような開発をすれば良いのかと意見を出します。長いと1~2時間かけて話し合うこともあります。 また、営業職が同じフロアに居るので電話していない暇そうなときを捕まえて「この機能実際にクライアントってつかってくれていますか？」「なにか不満言っていませんか？」と聞いたりもします。 業務・責任領域(3, 4について) 好きなようになんでもやらせてもらえます。 「事業として成果出したいから今週はこれらのタスクを完了したい」とプランナーから提示されるのでその中からやりたいタスクをエンジニア同士で相談して自身がやるタスクを決めます。 Speeeではスクラム開発を採用しています。スクラムではチームとしてスプリント(私のチームでは1週間)を走り切るのが大切です。そのため自分の作業だけが終われば良いという訳ではなく、チームメンバーの誰かが苦戦しているのであればペアプロするなり、詰まっている点をGithubにpushして早期レビューするなどチームで走りきる工夫をしています。 スプリントをやりきるためにはどうするかエンジニア同士で相談し「誰がどのタスクを担当しようか」「私はこのタスクチャレンジしてみたいけれど、苦戦するかもしれないのでサポートお願いします」みたいな風にやるタスクを決めています。 また、語弊がないように言っておくと好きなようになんでもということは「最新の技術使いたいからそのライブラリ使って書き換える！」ということが自由にできる訳ではないです。もちろんその最新技術を使うことで今後の開発がやりやすくなって長い目で見ると開発スピードが上がる、SQLのパフォーマンスが向上してページスコアが上がるなど事業的なメリットがあるのであれば別です。 実際に私も「リファクタリングしたいです。何故なら今後の開発しやすくなって総合的に開発スピードが上がるからです」と打診してリファクタリングしたことがあります。自身のスプリントが早めに終わり、チームメンバーも特に苦戦していないようであれば改善系のタスクに取り組むこともあります。 コンテンツ追加をがしがしやっていると中々時間が取れないので、毎週ちまちまリファクタリングやエラー修正などをやっています。リファクタリングしたい箇所や気になったエラーはGithubのissueに自由に書き出して、そこから選んで開発しています。 このように事業として成果を出すためにどのようなシステムにていけば良いのか考えつつ、大きなものは打診してというやりたいように仕事を任せてもらえます。 まとめ ということで私が学生の頃に「これある環境良いなー」と思っていた1~4をSpeeeでは満たせているので、実際に楽しく働けています。 つまりユーザ価値を考えてプロダクトつくりたいならばSpeee良いぞという話です。 読んで頂いた皆様がSpeeeで働くことを想像できていれば幸いです。 最後に宣伝です。 Speeeでは24卒エンジニア向けにインターンシップを開催します！ アルバイトのように実務を経験できる訳ではないですが、Speeeらしさを体験して頂く内容となっているので、Speeeに入社したらどのように働くのか体感できます！ この記事を見て少しでも興味を持ってくれた方が参加してくれるのを待っています。 speee-recruit.snar.jp また、Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

自身の開発チームが生み出した価値を計測し始めた話 プロダクト開発で価値あるものを生み出し続けたい、生み出し続けるプロダクトチームにしたい、塚本 (@nao_tsukamoto) です。 デジタルトランスフォーメーション（DX）事業本部でHousii（ハウシー）という事業で開発PMをしています。 はじめに 先日以下のような記事を書きました。 tech.speee.jp この記事では、短期〜中期で価値あるものを連続的に生み出していくために、OKRやNSMを活用しロードマップに落とし込んでいるという話をしました。 今回は、「実際の足元の開発で本当に価値あるものの開発ができているか？」「そのために何しているか？」ということをお伝えできたらと思います。 本記事では、 開発チームが生み出した価値の総量を計測する具体的な方法が分かって明日から実践できる 計測した指標の解釈の例が分かって次の日試してみたいと思う ということをゴールにしています。 よって、以下に該当する方にはぜひ読み進めてもらえると嬉しいです。 開発チームのスクラム運営を担う若手の開発PMの方 自分たちのプロダクトチームが価値を生み出せているのかなんとなく気になっている 図らずも惰性でスクラム開発の振り返りをしてしまっている 価値の計測ってどうやってやるの？ 私の関わっているサービスに関して 少しだけ私が携わっているHousiiというサービスの説明と紹介をさせてください。 完全会員制の家探しサービス「Housii」のプレスリリースを出しました。 こちらは、BtoBtoCのサービスです。 prtimes.jp また、先行してベータ版を出しておりましたので、今回プロダクト提供開始記念インフォグラフィックも公開しました。 prtimes.jp なぜ価値の計測を始めたのか ロードマップを定義し価値あるものを開発していくようにしたとしても、実際の開発として価値あるものを計測できたかを保証するものではありません。 それは、調査やバグ対応、運用におけるイレギュラーな対応等、スクラム開発において日常茶飯事です。 ここで少しだけHousiiのプロダクトの状態について触れておきます。 プロダクトが拡大し複雑性を増してきて以下の問題が "見え始め" ていました。 1つの機能を開発・リリースするにおいてもその影響範囲が大きくなり、仕様が複雑かつ難しくなってきた（つまり、見積もりするとポイントが大きくなって開発期間が大きくなってきた） 上記に合わせて、不確実な技術検証のための調査、仮実装タスク (スクラムでいうスパイク開発が必要になってきた バグ対応、運用におけるイレギュラーな対応等が以前に比べて増えてきた感覚があった その中でもやはり私たちは価値あるものにフォーカスし価値を生み出し続けたいと強く思っているので、それを継続していくための仕組みが必要だと感じるようになりました。 そのためにまずは、「自分たちが生み出した価値の総量を見える化」することになります。 具体的にやったこと HousiiではZenHubを使ってチケット管理をしているため、以下の方法で価値の総量の計測にトライしてみました。 issueに価値のある開発でることを意味する専用のラベルをつける 具体的には以下です。 調査、仮実装タスク、依存ライブラリアップデート等のissueにはラベルを付けない バックエンドからフロントエンド・デザインの対応が必要な一連の機能や改善タスクについては、それを1つの価値としてラベルをつける（※フロントだけで改善できるものも、もちろん1つの価値とする） 価値のラベルをつける そして、ZenHubのReport機能を使って、issueに関するデータを一覧でラベルを絞ってcsvダウンロードしスプレッドシートで集計していきます。 issueの一覧のcsvダウンロード feature数の集計 ※ここでは、価値の量を「feature数」としています。 解釈できたこと / できなかったこと そもそもの、集計した結果の見方は以下です。 スプリント単位だと少し短いし誤解釈を生むケースが多くなる月単位で見る チーム全体の「feature数」の変遷をみて、「feature数」が前月・前々月と比較しての増減の変化量を見る チーム全体の「feature数」の変遷をみて、人数が増えた / 減ったときに「feature数」の増減の変化量を見る この見方で解釈できたこととできなかったことがありました。 解釈できたこと 仕様が大きくなっていないか？ 価値の数が減っていた場合、要件定義やリファインメントが十分ではなかったことがわかります。 また、チームとして仕様検討の難易度が上がっていることに気づくことができます。 小さい作業量ばかりのものを対応していないか？ 価値の数が増えている場合、細かい改善に注力していることを示唆している可能性があります。 プロダクトフェーズやロードマップによりますが、結果的に改善系に注力しすぎていたと振り返ることができます。 解釈できなかったこと 個人が出した価値はどれくらいか？ ここで紹介した方法は個人が出した価値の計測には向いていません。 そもそも、個人が出した価値を出して計測すること自体が必要なのかは疑問なところです。 開発チーム全体として価値を生み出していこうというのが趣旨であるため私たちも集計自体しておりません。 余談 計測方法と解釈についてここまで書いておきながらお恥ずかしいのですが、本取り組みは長くは続きませんでした。 つまり、失敗でした。 どこが失敗だったかというと、 issueに、価値のある開発でることを意味する専用のラベルをつけていく バグと調査タスク、dependabot等のissueには付けない バックエンドからフロントエンド・デザインの対応が必要な一連の機能や改善タスクについては、それを1つの価値としてラベルをつける ここに運用の難しさがありました。 人力でラベルをつけていくことに限界がありました。 issueの粒度とリリース単位を明確に定義していないため、どの粒度で「価値のラベル」をつけるかの判断が曖昧になってしまいました。 それを手動で、かつチームで同じ判断基準をもって続けるには負荷が高かったです。 今はこの方法での計測はやめていて、絶賛、別の方法を模索中です。 もし別の方法で同じようなことをやられているチームがあればぜひお話をさせてもらい、アドバイスをいただきたいです。 最後に 今回、生み出した価値の数を計測し始めてみて学びもありました。それは、いつの間にかプロダクト開発の難易度が上がっていて仕様が複雑になっていることに気づけたことです。 少なからず機能を出し続けてきた私たちはいつの間にかより多くのことを検討する必要がでてきていました。 その結果、価値あるものを生み出すスピードが少し下がっていたということです。 仕様が複雑になっていることを開発チームが認識できただけでも大きな一歩だと感じています。 今では、仕様の認知負荷を下げるためにレーンを分けたり、レビュータイミングを少し細かくしたり、私のようなPMが要件定義に意識的に時間を割いたりといくつかのTryをしています。 私たちはこのことに向き合い、これからも価値あるものをより多く・よりはやく出していきたいと思います。 このテーマについて私自身も他チームでの取り組みについてお話を伺いたいなと思い、Meetyを作成しました。 ぜひざっくばらんにお話させてください〜！ meety.net エンジニアの立場としてはどうか、私では少し話しにくいという方は、Housiiのエンジニアの以下のMeetyも御覧ください。 meety.net -— Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください。 Speee DEVELOPER BLOG Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！ もちろんオープンポジション的に上記に限らず積極採用中です！！！

開発部 R&D ユニットの村田です。OSSの開発をしております。本記事では、Ruby で書かれたマンデルブロ集合を計算するメソッドを実行時に Julia に変換して実行するとめっちゃ速くなる (場合がある)、という話をします。 はじめに Ruby 3.1 では YJIT がマージされ、Rails アプリケーションが速くなりました。今後のバージョンアップがとても楽しみですね。ただし、Ruby のデータ処理対応を進めている身としては、データ処理や数値計算がより高速になって欲しいと思っています。 データ処理や数値計算を高速化する試みとして、Python では NUMBA というライブラリが開発されています。NUMBA は、メソッド単位でバイトコードを LLVM を用いてネイティブコードにコンパイルすることでメソッド実行を高速化します。ただメソッドをネイティブコードに変換するのではなく、実行時にメソッドに渡された引数の型情報を利用した最適化も行います。この仕組みはとても面白く、Ruby でも似たようなことをやりたいと常々思っていました。 ところで、データ処理や数値計算に向いていて速いプログラミング言語といえば Julia ですよね。Julia の裏側には LLVM があります。Julia では、実行時に関数単位で引数の型に対して最適化されたネイティブコードを LLVM よって生成してから実行しています。つまり、NUMBA とだいたい同じ機構が働いています。 Ruby のメソッドを Julia に書き換えて実行できれば、NUMBA のような機構を Ruby でも実現できそうです。 実験 Ruby のメソッドを Julia に書き換えて実行する仕組みを試作しました。実装は以下のリンク先のスクリプトです。 github.com 実験はマンデルブロ集合を計算する次のメソッド群を対象としました。 def abs2(z) z.real * z.real + z.imag * z.imag end def mandel(z) c = z maxiter = 80 (1 ... maxiter).each do |n| return n - 1 if abs2(z) > 4 z = z**2 + c end maxiter end def mandelbrot ary = [] (-1 .. 1.0).step(0.1) do |i| (-2 .. 0.5).step(0.1) do |r| ary << mandel(Complex(r, i)) end end ary end スクリプトを実行すると、この mandelbrot メソッドの Ruby 版と Julia に書き換えたものの実行時間を計測して表示します。 Julia への書き換えは次のようにメソッドオブジェクトを変換用メソッド jl_trans に渡すだけです。 include JLTrans jl_trans method(:mandelbrot) 実験用スクリプトの --show-jl オプションを渡すと、書き換え後の Julia コードが表示されます。上記の Ruby コードは次のような Julia コードに変換されます*1。 $ ruby -Ilib examples/jltrans.rb --show-jl function mandelbrot() ary = [] for i in RbCall.RubyRange(-1, 0.1, 1.0) for r in RbCall.RubyRange(-2, 0.1, 0.5) append!(ary, mandel(Complex(r, i))) end end ary end function mandel(z::ComplexF64) c = z maxiter = 80 for n in RbCall.RubyRange(1, 1, maxiter) if abs2(z) > 4 return n - 1 end z = z ^ 2 + c end maxiter end function abs2(z::Any) real(z) * real(z) + imag(z) * imag(z) end 実験結果 さて、スクリプトの実行結果を見てみましょう。 $ ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux] $ julia -v julia version 1.7.2 $ ruby -Ilib examples/jltrans.rb name, min, max, mean, std mandelbrot_rb, 5.803, 6.347, 6.021, 0.096 mandelbrot_jl, 0.265, 4.612, 0.276, 0.051 $ ruby --enable=mjit --mjit-min-calls=1 -Ilib examples/jltrans.rb name, min, max, mean, std mandelbrot_rb, 4.875, 6.283, 5.113, 0.197 mandelbrot_jl, 0.259, 4.256, 0.275, 0.047 $ ruby --enable=yjit --yjit-call-threshold=1 -Ilib examples/jltrans.rb name, min, max, mean, std mandelbrot_rb, 4.214, 4.836, 4.372, 0.078 mandelbrot_jl, 0.259, 4.256, 0.268, 0.047 上から順に、デフォルト状態、MJIT 有効状態、そして YJIT 有効状態です。出力されている数値はそれぞれ実行時間の最小値、最大値、平均値、標準偏差です。値の単位はミリ秒です。評価対象のコードを合計実行時間が2秒を超えるか呼び出し回数が5回に達するまで呼び出し続け、毎回の実行時間を計測し、その計測した実行時間の統計量を表示しています。 mandelbrot_rb は Ruby で実装されたメソッド、mandelbrot_jl はそれを Julia に書き換えた関数群による計測結果です。 JIT なしの場合に平均6.0ミリ秒かかっていたメソッドの実行時間が MJIT によって平均5.1ミリ秒に、YJIT によって平均4.3ミリ秒に短縮されています。JIT の効果はすごいですね。一方、Julia に書き換えた関数群の実行時間は平均0.27秒で、JIT なしの場合に対して約22倍の高速化が達成されています。Julia すごい！最初に選んだ題材を Julia が有利になりそうなコードにしておいてよかったw Ruby to Julia 実行時変換の仕組み概説 Ruby のメソッドを Julia に書き換えて実行する仕組みは、次のような手順で Ruby のメソッドを Julia に書き換えます。 対象となる Ruby メソッドの AST を作る AST に型チェッカーを適用し、ノードに対して可能な限り型づけを行う 型つき AST を捜査して Julia のコード生成を行う Ruby to Julia ブリッジの eval メソッドを使って Julia 側で生成されたコードを評価する Julia 側に定義された関数を呼び出す Ruby 側のメソッドを定義する これらの手順は、Ruby to Julia トランスパイラ (1〜3)、Ruby to Julia ブリッジ (4)、インターフェイス (5) の3パートに大きく分けられます。 Ruby to Julia トランスパイラを構成するメソッドの AST を作る解析器、AST に型づけを行う型チェッカー、そして Julia コード生成器は Yadriggy というライブラリを利用して実装しました。Yadriggy は、Ruby 文法のサブセットになるような文法を持つ DSL を実装するための仕組みを提供してくれるライブラリです。 Ruby to Julia ブリッジは、私が開発している pycall.rb の Julia 版に相当するものです。たとえば、上記の変換後の Julia コードで参照されている RbCall.RubyRange はブリッジによって提供されているものです *2。 この仕組みの将来性 現時点では、トランスパイラとブリッジの双方について、今回の実験対象である mandelbrot メソッドを処理するために必要な最小限の機能のみが実装されています。どの程度実用的なのかはまだ分かりませんが、機能を増やしていくと面白いことはできそうな気がします。 例えば、Julia の多次元配列を Ruby の配列に変換せずに Ruby から直接操作できるようなラッパーをブリッジに実装することで、numo-narray や numpy.rb の代わりのライブラリとして実用的に使える可能性があります。 また、numo-narray と Julia の多次元配列が MemoryView を介してデータ共有できるようにして、さらに、トランスパイラが numo-narray のデータを適切に扱えば、numo-narray を利用して Ruby で実装されている計算処理をデータ変換のコストを発生させずに Julia で高速実行できるようになるかもしれません。 Julia 自体が数値計算機能を持っていることと、pycall.rb では見込めなかった処理の高速化が可能になる点がとても面白いと思います。 関連研究 Ruby から Julia への書き換えによる高速化の試みは、私の今回の実験が最初ではありません。私が知る限りでは、2016年に remore さんによって作られた virtual_module が最初です。virtual_module は、同じく remore さんによって作られた Ruby to Julia トランスパイラ julializer を用いて次のように動作します。 julializer で Ruby のコードを Julia へ変換 生成した Julia コードを含む RPC サーバスクリプトを実行してサーバプロセスを起動 サーバプロセスに対して msgpack の RPC 機能で Julia 関数を呼び出して結果を取得 私が今回試作したものが virtual_module と異なる点は、Julia を Ruby と同じプロセスで動かしている部分です。そうすることで、Ruby と Julia の間でのコードとデータをやりとりが低コストになっています。Ruby と Julia の双方が処理系の C API を提供しているため、非常に薄いラッパーオブジェクトを実装するだけで Julia 側のオブジェクトを Ruby から直接操作することも、逆に Ruby のオブジェトを Julia から直接操作することもできます。 まとめ Ruby のメソッドを Julia に書き換えて実行する仕組みを試作しました。マンデルブロ集合を計算する処理を対象に実行時間の変化を計測したところ約22倍の高速化が実現されました。Ruby to Julia トランスパイラと Ruby to Julia ブリッジの双方にメリットがありそうなので、開発を続けて適用可能範囲を広げていきたいです *3。 おしらせ Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ *1:引数に不要な型アノテーションが残っていたりしますが、試作品なので見逃してください。 *2:これは、Ruby の Range#step と同じ値を生成する Julia の StepRangeLen オブジェクトを作る関数です。 *3:RubyKaigi 2022 に応募して採択してもらえたら、この実験の詳細や続報を話したいなと思っています

NSMやOKRを通じて本当に価値のあることにフォーカスするロードマップを作成した話 デジタルトランスフォーメーション（DX）事業本部でHousii（ハウシー）という事業で開発PMをしています、塚本 (@nao_tsukamoto) です。 期の始まりとなることも多いこの季節に、開発PMとしてはプロダクト開発ロードマップをアップデートしたり、新たに定義し直したりしている方も多いのではないかと思います。 私もその多分にもれず、2月後半から3月にかけてプロダクト開発ロードマップについて見直して作成し直す機会がありました。その際に思わずトラップにハマりそうになったので、トラップを避けつつロードマップ作成時に取り組み、学んだことを紹介したいと思います。 はじめに プロダクト開発ロードマップの作成においては、多くの記事や示唆が既に共有されていますので、この記事では「ロードマップって何？」や「なぜロードマップを作ったのか？」については割愛させてください。 この記事では以下のことを書いています。 プロダクト開発ロードマップの作成において、施策の積み上げと優先度付けでロードマップらしきものはできるが、本当にHousiiが目指すべき方向として正しいか、が不明瞭かつ迷いがでた NSM（ノーススターメトリック）の導入とOKRの見直しのプロセスを通して、僕らのコアは「マッチングの体験を最大限向上させること」だと改めて気づけた これらを通してプロダクト開発ロードマップを再考し、プロダクト価値を最大化するものを作成できた では、私たちのチームが上記のような状況からどんなプロセスを踏んでロードマップ改定に至ったか、を説明していきます。 特に、 プロダクト開発ロードマップを提供されていてこれでいくぞと言われているマーケや営業、企画職の方 自身でロードマップを作成してみたが、施策の積み上げになってしまっていると課題感をうっすらでも持っている方 を想定読者としていて、その方々に、少しでも自身のロードマップ自体やプロダクト開発の方向性に対している違和感を言語化でき、更に関わっているプロダクトの今後がよりよくなっていけるような示唆を与えられれば幸いです。 私の関わっているサービスに関して 少しだけサービスの説明と紹介をさせてください。 完全会員制の家探しサービス「Housii(ハウシー)」のプレスリリースを出しました。 こちらは、BtoBtoCのサービスです。 prtimes.jp また、先行してベータ版を出しておりましたので、今回プロダクト提供開始記念インフォグラフィックも公開しました。 prtimes.jp ハマりかけた施策の積み上げによるロードマップらしきもの 実は、施策の積み上げと優先度付けでロードマップらしきものはできていました。 しかし、半年後には”なんでもできる”プロダクトのロードマップができていました。 それは私たちがまだ立ち上げ期に目指すものではないのでは、という迷いがありました。 具体的には、私たちは以下のような状況にありました。 1. よりアグレッシブな事業目標（売上 / 利益）があった その中でプロダクトチームが期待されていることも感じていた よって、これはできないか？あれもできないか？と来る状態だった 2. 半年後我々はなにを成し遂げたと言えるか？の問いに対して少し躊躇していた あれもこれも成し遂げているというリリース間もないのになんでもできるプロダクトになっていた つまり、なににも尖っていない、「なんでもできるは、なんにもできない」 当時は、すでに半年前くらいに作成したロードマップはあって少し粗めではあるものの当時から目指すべき状態も定義していました。 しかし、リリースして約8ヶ月、日に日にプロダクトは大きくなり、やりたいことや改善したい部分が湧いている状態でした。 このような状況から、プロダクト価値の最大化を目指すのではなく、どこか無意識的に”なんでもそこそこできるプロダクト”を積み上げで作っていこうぜ！ という施策を積んでいました。 そしてそれは、事業戦略と照らし合わせると整合していないことが感覚的にはわかっていました。 よく言われていることではありますが、サービスが拡大期に入ると、現状のプロダクトから改善したいところやこんなものがあると良さそうとなりやすいです。 加えて、サービスを拡大していこうとすると、直接的に売上に寄与するものや、顧客が要望しているもの、拡大時の運用を楽にできるもの、に安易に流されやすいのもあります。 まさに私たちは施策の積み上げによるロードマップの作成というトラップにハマっていました。 「マッチングの体験を最大限向上させること」がコアだと改めて気づくためにやったこと 私たちは、”なんでもそこそこできるプロダクトからの脱却” が必要でした。 Objectiveの状態を計測可能かつプロダクト価値を表すものにしたのがNSMです。 Key ResultsはObjectiveを分解したものですが、あくまでObjectiveの主要部分を分解し計測可能なものにしたものなので、Objectiveによって定義した状態ができていることを素直に表せないはずです。 このような背景から、当時定義していたObjectiveの状態を計測してよりアウトカムに繋がる開発できないかと考えました。 そこで、NSM（ノーススターメトリック）を策定・導入し、改めてOKRをも策定するプロセスを通じて解決することにしました。 NSMの位置付けや定義については以下を参考にください。 jp.amplitude.com 以下の小城さんの記事でもOKRとNSMの関係性が触れられています。 note.com 以下では、その過程を具体的に見ていきます。 もしPMの方や企画の方であれば、この仮説立てと分析からしてほしいと思います。 まず、私はNSMの候補となりそうな指標の候補を3つほど出しました。 実際の指標から少々ぼかしますが、以下のような指標です。 物件の購入希望者の方が、Housiiに登録してからxx日以内にoo件の提案をもらえる 物件の購入希望者の方が、合計でn社の不動産会社様と関わりが持てている 物件の購入希望者の方が、合計でyy件の物件の提案がもらえている NSMの候補を出す上では、「広がり」「深さ」「頻度」「効率」の4軸で考えていきました。 上記で躓く方は、「自分たちのサービスやプロダクトを満足して使ってくれた方はその途中でどういう状態になっているか？」という問いを投げてみるのがよいかもしれません。 その後、上記で定めた理想状態に至った顧客とその理想状態に至らなかった顧客をセグメント分けして、上記の指標を満たしているかどうかの数値を入力していき、◯ or ×をつけていきました。 この段階では、当初候補に出した指標の数値を顧客ごとに簡単に抽出できなかったので、目視でデータを見ていきました。 正直、ここは泥臭い作業で心が折れかけました。（笑） しかし、この地道な作業のおかげで、顧客が私たちのサービスを利用して満足しているかどうか、をよりイメージできた気がします。 （※ここでいうデータは定量データのみならず、定性的なデータも含みます。） NSMの仮説指標の調査の実際の分析シート 分析した結果、3つの候補の掛け合わせで1つの指標に着地しました。 また、顧客セグメントをある程度きれいに分けることもできました。 そしてその指標は、Housiiにおいて顧客と企業がマッチングするときの精度と早さ、量を表すものとなり、改めて私たちは、「Housiiでのマッチングの体験を最大限向上させること」がコアだと改めて気づきました。 そして、結果的には、OKRもアップデートするに至りました。 それ自体に価値はあるがコアではない施策や機能が削ぎ落とされた 今回のプロセスを通して、いかに自分たちが色々なことをやりたい、と思っていたかがわかりました。 数ヶ月前の私たちは、無意識のうちに、「なんでもできるは、なんにもできない」というあるあるのトラップに向かおうとしていました。 現在はプロダクト価値のコアに気づけたことで、コアの価値に寄与しない施策を容易にやらない判断ができるようになり、私たちのプロダクト開発ロードマップは、OKRの実現・NSMの達成のために必要最低限な機能のみが記載されるものができあがりました。 そして、チームもマッチング体験の向上を実現することにフォーカスできるようになりました。 最後に プロダクト開発ロードマップの作成は施策の積み上げによって、あたかもできた気になってしまいます。 自分もそうなりかけていました。普段業務でロードマップを作成したり、眺めている方々には、これらの施策や機能はどこに向かっているのか？何の実現することに繋がっているのか？を考えてみてください。 もしこの記事を見ている方がPMや企画の方であれば、NSMは作る作らないに関わらず、「プロダクト価値を表す指標」を置くとすれば何を置くと良いか？という問いと仮説出しから始めてみて下さい。 仮説がでれば分析に進め、その仮説を正しさを見ることができます。 その過程を通じて自分たちが目指す指針が見えたとき、その道筋となるロードマップを正しく評価し改善していけるはずです。 私自身もまだまだ道半ばであり、またプロダクトもこれからなので、自分たちで決めた指針に向かって邁進していきたいと思います。 -— Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください。 Speee DEVELOPER BLOG Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！ もちろんオープンポジション的に上記に限らず積極採用中です！！！

はじめに こんにちは、情報システム部で主に社内システムを開発している三宅です。 この度、SpeeeがOSSとして公開していた speee/itamae-plugin-recipe-datadog について、リポジトリを移管することになりました。 SpeeeのOSSへの取り組みについては、 SpeeeでのOSS活動事例をご紹介します - Speee DEVELOPER BLOGの記事などを読んでいただけると幸いです。 そういった取り組みの中で、itamae-plugin-recipe-datadogは生まれました。 事の発端や経緯については、Speee在籍中にOSSとしてこのGemを公開された @takanamitoさんの書かれた記事に詳しく載っていますので、興味のある方はぜひご一読ください。 takanamito.hateblo.jp この記事では、移管するにあたってクリアコードの須藤さんにアドバイスいただいた内容を二つ紹介したいと思います。 Transfer ownershipで移管する @takanamitoさんからこの話をいただいた時、OSSのリポジトリの移管経験がなかったこともあり、二つの方法を考えていました。 GitHubのTransfer ownership機能を使う方法と、フォークしてもらって弊社側のリポジトリをアーカイブする方法です。 Transfer ownershipの場合、IssueやPull Requestの記録は引き継がれます。 一方で、フォークする場合はそれらの記録は引き継がれません。 OSSの場合、記録が残っていた方が今後の開発で役立つということを須藤さんからアドバイスしていただいたので、今回はTransfer ownershipを使うことを選択しました。 ライセンス表記は残す 移管するにあたり、ライセンスからSpeee, Inc.の表記を削除するかどうかの相談も併せて行いました。 移管後にライセンス表記が影響するのは、「将来移管先の方がライセンスを変更したくなった時」とのことでした。 ライセンス表記を残しておくと、今後ライセンスを変更する時に、弊社を含む全ての著作者に対してライセンスの変更について許諾を得る必要がでてきます。 例えば、将来的にOSSでないライセンスに変更するといったことが発生した場合に拒否をするといったことが可能になります。 一方で、今後も一切関わらないことを選択する場合は、著作権を放棄して表記を削除することもできます。 弊社としては、表記を残しておいた方がよりOSSの発展に貢献できるのではないかと考え、そのままにしておくことにしました。 （もちろん、むやみやたらにライセンス変更を拒否しようと考えているわけではないので、そこはご安心ください。） ちなみに、もし削除する場合は移管後に移管先の方が削除するのではなく移管前に弊社側で消す方が明確で良いそうです。 さいごに OSSの移管にあたり、わからないことだらけだったところを須藤さんに助けていただき、大変助かりました。 また、 @takanamitoさんは今回の移管に関する記事を書いてくださいました。 OSSの利用者や開発者として考えると、移管の経緯がわかっていたほうがより安心して利用/開発できると思うので、これまでメンテナンスを続けてくださったことと合わせて大変感謝をしています。 そして、 以下の記事にも書いていただきましたが、快くメンテナを引き受けてくださった@sue445さんにお礼を申し上げます。 sue445.hatenablog.com 今回のitamae-plugin-recipe-datadogに関しては、「Transfer ownershipを使う」「ライセンス表記を残す」という選択をしましたが、別のOSSでは異なる選択がベストなこともあると思います。 とはいえ、この記事が何かしらの参考になれば嬉しいです。 今後とも、itamae-plugin-recipe-datadogをよろしくお願いいたします。

2019年11月に、リフォームのマッチングプラットフォーム「ヌリカエ」の開発チームにjoinした竹井です。 もう2022年ですね! 去年は弊社のアドベカで tech.speee.jp を執筆しました! 最近、Amazon Connectを使ってプレディクティブコールっぽいものを実現させてみたので、その方法についてご紹介します。 そもそもプレディクティブコールとは? プレディクティブコールとは、複数のお客様に同時に電話をかけ、その中で最初に通話に出た人と通話を繋ぐシステムのことです。 この動作を図にすると、以下のようになります。 架電を開始すると、複数件の電話番号に対して同時に架電を行う 複数件架電した中で誰かが着信を取る(今回は顧客2が出たとする)と、最初に着信を取った人以外の通話は終話させる (ここで終話させた方はいわゆる「放棄呼」となる) 着信に出た人と架電を開始したコーラーが繋がり通話を開始する プレディクティブコールっぽいもの とは? 今回実現させた既存のプレディクティブコールに似た機能のことです。 プレディクティブコールはAmazon Connect上に用意されている機能ではなく、また、完全なプレディクティブコールを作る方法が見つけられなかったため、今の形になりました。 今回作成したものの動作は、図にすると以下のようになります。 架電を開始すると、複数件の電話番号に対してシステムはほぼ同時に架電を行う 複数件架電した中で誰かが着信を取る(今回は顧客2が出たとする)と、Amazon Connectに通話を転送する 転送された通話はAmazon Connectのキューに入り、それぞれ同時架電対応者が対応をする 従来のプレディクティブコールと大きく異なる点は、着信に出なかった方でも強制的に終話させることはないので、プレディクティブコールに比べて通話できる可能性のある人への接客回数を多くすることができることです。 (放棄呼を少なくできる) ずっと「プレディクティブコールっぽいもの」と呼ぶのもなんなので、以降「同時架電」と呼びます。 なぜプレディクティブコールを必要としたのか 長期間通話が繋らないお客様に対しての架電は、通電率が非常に低いです。 しかし、通話に出ていただける可能性もあり、架電をしないわけにはいきません。 そこで、複数人に同時に架電を行えるものを作りました。 ヌリカエのCS(Customer Success) メンバーは、社内自作のツールを使用して日々、お客様へ架電を行っています。 架電業務では、なかなかタイミングが合わず着信が繋がらないお客様もいらっしゃいます。 時間を変えて架け直したりなどは行っているのですが、これが長期間続くこともあります。 中には、そもそもヌリカエのサービスを使う事を辞めた可能性のあるお客様もいらっしゃいます。 (n回以上不通だった場合は通話リストにお客様を出さないようにはしています) この、いわゆる長期間お客様に架電が繋がっていない "長期リスト" への架電は、通電する確率が非常に低いです。 ですが、これは飽くまでも確率の話ではあり、電話に出てサービスを使用していただけるお客様もいますので、リストにある限りは全てに対して架電を行わなければなりません。 ……しかし、これらの案件に人が1件1件対応するのは効率の良いものではありません。 そのため、1人が同時に複数件の架電に対応できるシステムを作りました。 なぜAmazon Connect上で実現しようと思ったのか 弊社ヌリカエチームのCSメンバーが使っている社内自作のツールの架電部分が、Amazon Connectを使って実現しており、放棄呼を少なくできるメリットがあったためです。 他サービスを使う場合、架電案件管理ツールもその他サービスと繋げるための開発を行う必要が出てきます。 今回は可能な限り素早く開発を行いたかったために現在連携させているAmazon Connectを使えないかと考えました。 また、最初に説明した仕組みによって「放棄呼」を限りなく少なくすることが出来るメリットも発見できたためにAmazon Connect上で実現しました。 作成方法 まずは、Amazon Connect側の問い合わせフローの設定を行います。 大切なのは、赤枠の中身です。 同時架電を受け取るためのキューを設定したら、そこへ転送できるようにした問い合わせフローを作成します。 ruby側は、以下のようにすることでシステムからの架電を行います。 def call(destination_phone_number) connect = Aws::Connect::Client.new( region: 'ap-northeast-1', # AWSのリージョンを設定 access_key_id: xxxx, # Amazon Connectへのアクセス権限を持つIAMのアクセスキー ID secret_access_key: xxxx, # Amazon Connectへのアクセス権限を持つIAMのシークレットアクセスキー ) connect.start_outbound_voice_contact( instance_id: xxxx, # 対象のAmazon ConnectのInstance ARNの最後の `/` 以降の文字列 contact_flow_id: xxxx, # ↑で保存した問い合せフローのURLの `/contact-flow/` 以降の文字列 source_phone_number: xxxx, # 架電元電話番号 destination_phone_number: destination_phone_number, # 架電先電話番号 (今回で言う、お客様の電話番号に当たります) ) end これを対象の電話番号群に対してループしつつ呼び出せば、システムがほぼ同時に架電を行います。 ユーザが電話を取った場合は contact_flow_id で指定した問い合わせフローを実行するので、これによってキューへの転送を行い、キューに入った架電をオペレーターが対応する。 という流れで実現します。 発生しうる問題 放棄呼を少なくするための仕組みのため、1人の同時架電が2人以上に繋ることがある 同時架電を受け取ったお客様は、通話に出たのに、再度こちらのオペレーターが着信に出るまで「待ち」の状態になってしまう 留守番電話に繋ってしまう 自動で架電をしてしまう性質上のバグに気を付ける Amazon Connectの同時通話数を超過してしまう それぞれ1つ1つ解決策として用意しているものを紹介します。 放棄呼を少なくするための仕組みのため、1人の同時架電が2人以上に繋ることがある ヌリカエCSでは、同時架電対応者の他に、普段受電業務を行っているチームも一部バックアッパーとして同時架電の着信を受けられるようにルーティングプロファイルを設定しています。 同時架電を受け取ったお客様は通話に出たのに、再度こちらのオペレーターが着信に出るまで「待ち」の状態になってしまう IVRを導入することでお客様にアクションを求め「オペレーターにお繋ぎします。少々お待ち下さい」と音声を流すことで自然な体験にできそうです。 従来のプレディクティブコールでは、架電者が発信をして、お客様が通話に出ると、通話が繋ります。 お客様の体験としては、普通に電話に出た。のみです。普通の受電体験です。 しかし、今回の実現方法では、お客様は電話に出たにも関らず、同時架電を開始した架電者が通話に出るまであたかも自分が発信をして相手が電話に出るまでのような「待ち」の時間が発生してしまいます。 この問題を解決するためにはIVRを導入することができそうです。 IVRとは、いわゆる電話に出たら自動音声で「○○のサービスについては1を。○○についての質問がある方は2を」みたく言われて、こちらが番号を押すことで担当先が変わる。みたいなものです。 IVRを導入すれば、お客様に対しては弊社サービス名を伝えることと「これからオペレータにお繋ぎいたしますが、よろしければ○○のボタンを押して下さい」とアクションを求めることで架電者に通話を繋ぐまでの待機時間を自然な体験にできるかと思います。 留守番電話に繋ってしまう こちらもIVRでアクションを求めることで改善できそうです。 長期に電話に出られなかったお客様は留守番電話を設定していることが多く、同時架電からの着信に出たら留守番電話だった! ということが発生してしまいます。 こちらもIVRを導入することによって、お客様がアクションを起こさないとCSメンバーには繋らない仕組みを作れるため、↑と一緒に解決できそうです。 自動で架電をするため、架電先に誤りがないようにする 対策としては、通常の架電のエラーチェックだけでなく架電先のデータに誤りがない事をチェックするのはもちろん、テストを書くときも、メッセージやエラーだけでなく実際に架電されている案件をテストします。 また、実際のCSメンバーにステージング環境で触ってもらうのも良いかと思います。 同時架電は、システムに多くの架電処理を任せる性質上、1つの不具合が大規模なインシデントに繋る可能性があります。 特に、架電先のチェックや、ループで同時架電をさせる場合、そのループが意図しない挙動をしないかには細心の注意を払う必要があります。 テストではエラーのチェックやレスポンスなどだけではなく、実際に架電されている架電先のデータを元にテストする事を考えたり、導入前にステージング環境などで動作をCSメンバー含めチェックするなど、意図した挙動になっているかのチェックは手厚く行いましょう。 Amazon Connectの同時通話数を超過してしまう こちらは事前に、Amazonのサポートに「上限緩和リクエスト」を送る必要があります。 「上限緩和リクエスト」の上限とは、Amazon Connectの「インスタンスあたりのアクティブな同時呼び出しの数」です。 つまり、この値が「現コーラーの数」+「同時架電数」よりも多い必要があります。 もしもこちらの数が足りなくなるようでしたら、事前にAmazonのサポートに「上限緩和リクエスト」を送る必要がでてきます。 まとめ 今回はヌリカエチームが新しく架電機能として導入したAmazon Connectでのプレディクティブコールについての記事を書きました。 まだ開発、導入を行ったばかりで目立った成果は出ていませんが、今まで長期リストに対応をしていた方の効率が良くなるハズですので、今後もシステムによって効率を良くし、お客様体験もより良いものにしていきたいなと思います。 以上です! 最後に Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

こんにちは、もうすぐ本体重量40kgの大型3Dプリンターが届く予定でこれからワクワクと不安が止まらない、DX事業本部開発基盤グループの@k.bigwheelこと西田和史です。 この記事では僕の所属するグループで実行しているリモートワークをより持続的にするために行っていることを紹介します。 やっていること 画像のようにノートPCとスピーカーフォンを設置し、常時Zoomへ接続しています。 うちのチームではリモートワーク/オフィスワークどちらもいるのですが、勤務形態に関わらずこのZoomチャンネルには常に入るようにしています。 設置する前 これを設置するに至る前からチームメンバーは全員Zoomへ入るようにしていました。 これは、リモートワークのメンバーとスムーズにコミュニケーションできるようにするためです。急ぎの話でなければ非同期のコミュニケーションのSlackを使いますが、なにか困難にぶつかった時や緊急度の高い事象を素早く解決するためには同期コミュニケーションができたほうがよいだろう、そういった考えを背景としていました。 特に、チームで初めてのリモートワークメンバーが22卒エンジニアで内定者アルバイト中の角くん(初心者がインフラ構築で「わからない」を克服したこと - Speee DEVELOPER BLOG)だったため、発生するであろう無数の詰まり・乗り越えポイントを素早くサポートしたいと思っていました。 課題点 しかし、単にZoom部屋を用意するだけではうまくいきませんでした。 チームメンバーは常にZoom部屋へ入っておくことにしましたが最初期を除いてZoomによる即時のコミュニケーションはほぼなく、もっぱらSlackを使うかSlackでZoomできるか聞いたのちにZoomでやり取りすることがほとんどでした。それにより即時に返事をしたい質問にも気づいて返事するまで20分以上かかってしまうことがザラでした。 このように期待と実体がずれた原因を分析すると以下のような要因がありました。 Zoom部屋への常時ログインがオフィスメンバーには難しい。具体的にはリアルMTGやZoomの別の接続のために切断されるとMTG終了後に再接続を忘れてしまう イヤホン/ヘッドホンの常時装着の負荷が高く、どうしても外してしまう(中耳炎の原因にもなりうるし、長時間つけてストレスのないヘッドホンは高い) 解決策 これらの問題を解決する方法をいろいろ検討した結果、ノートPCとスピーカーフォンを設置することにしました。 まず常時Zoom接続のノートPCを設置することでZoomとの接続を安定させ、次にスピーカーフォンを設置することでイヤホン・ヘッドホンを常時装着する辛みを回避しました。 設置後どうなったか 劇的に改善しました。すぐに連絡したい場合でもやむなく使っていたSlack利用がすべてZoom越しのコミュニケーションに置き換えられ、非常に効率がよくなりました。 質問に対して答えるなど、情報を共有するオフィス側も口頭と顔の映像ありで安定してコミュニケーションができます。そのため、正確な情報を短時間で伝えることができ、仕事の効率があがりました。 角くんからも「ちょっと聞きたいことがあるときも気軽に質問できたのでとても使いやすかった」と好評でした。 面白かったのが常設のPCとスピーカーフォンをおいたことでリモートメンバーが実際にオフィスにいるかのような感覚を生んだことです。 常設されているPC・スピーカーフォンの近くに行って話すとまるでそこがリモートメンバーのデスクであるような感覚を生み、スピーカーフォンが常時オフィスの話し声をリモートメンバーにも流し続けることで雑談に混ざることすら可能にしていました。 最終的にこのノートPCとスピーカーフォンとダンボール台の一角は「バーチャルすみすみ」と呼ばれ、仮想の角くんが出社している一角として扱われるようになりました。 リモートワークというのはどうしてもコミュニケーション密度が下がって同じチーム内であってもシンパシーを失いがちです。しかし、このような仕組みがあればリモートであってもチームメンバーやメンティー/メンターへのシンパシーを維持できると思います。 その後 その後、角くんに続いて新たなリモートメンバーが増えたりしましたが、そのときもこの装置があることでリモートワークへの移行をスムーズに行うことができました。 最後に Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

デジタルトランスフォーメーション（DX）事業本部でPMをしています、九島です。 新卒でSpeeeに入社してから、約5年間グロースに取り組んでいて、中でもLPのABテストを継続してやってきました。この記事では、ABテスト初心者の方に向けて、自分の失敗や試行錯誤の過程をお伝えしながら、今一番上手くいっている「ABテストの型」を紹介します。 「サイトのABテストを任されたけど、どう考えたらいいの？」「ちょっとやってみたけど、もっと成果出すにはどうしたらいい？」 とお考えのEFO担当者の方にとって、一助になれば幸いです。 ABテストとは？ 1年目：200施策やってCVR上がらない 2~3年目：ユーザーニーズを掴むことが糸口に 4~5年目：行き着いたのは「ユーザー中心設計」のABテスト ①ユーザーニーズを定義し、コアの提供価値を決める ②「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる ③施策数や施策の成功数ではなく、事業の数値を結果責任として持つ まとめ ABテストとは？ web業界にいる方なら、「ABテスト」という言葉は一度は聞いたことがあるのではないでしょうか。 ABテストとは、 A、Bのパターンを用意して結果を比較するテストのやり方 どちらがよいか？　という結果が明確に出る 様々な要素でA/Bテストを行い、結果のよかったパターンを実装していくことで、最適化していく といったものです。 メリットは、 同時並行でパターンを試すことができるので、時間による変化を（ほとんど）無視してOK ツールがたくさんあり、コスト低く、フットワーク軽く実施ができる があり、一方でデメリットは、 短期では最適でも、長期に目を向けるとずれてしまいがち 検証のために、一定の流入数が必要 が挙げられます。 余談ですが、オバマ大統領が利用したのをきっかけに、ABテストは広まりました。(※参考｜オバマ大統領が簡単なテストで、６０００万ドルもの収益を上げた方法) 1年目：200施策やってCVR上がらない 僕は新卒で入社してすぐ、ABテストのプランナーになりました。 そして10ヶ月間で200施策実行し、ずっとCVRが改善しませんでした。(当時の上司、すみません。) 振り返ると、このような悪い循環にハマり、しばらく抜けられなかったのです。 「施策がなくなってきた」という方は、この循環にハマる兆候かもしれません。 はじめは順調だったが、徐々に施策がなくなっていく 「施策数」を気にして、とりあえず施策を実行してしまう ABテストで勝っているのに、事業数字が改善しなくなり、焦る 「施策の改善幅」が高い施策をやろうとリソースを確保し実行するも、工数かかるわりに大外れ やることがなくなる・施策がなくなる 当時、「自分はできる」「頭がいい」と思っていました。自分が考えた施策は当たるはずと思っていたからこそ、一度上手く進まなくなってからは目の前の数字を上げようと必死になり、空回りしていました。 今になって思うと、こちらの記事でWACULの垣内さんがおっしゃるとおり、ABテスト実施の目的が、「成果を上げること」でなく、 「成果を証明すること」になってしまっていたようです。「ABテスト」という手段にこだわり過ぎて、ユーザーを置いてきぼりにしていたんだと反省しています。 2~3年目：ユーザーニーズを掴むことが糸口に 2年目の途中から新規事業に抜擢されました。(内心、失敗してたのに僕で良いんだろうか、、とは思いました。） 事業として立ち上げたばかりということもあり、まずはユーザーインサイトを掴むため、リスティングの広告文改善から着手しました。 「3種類の広告文を追加し、結果をみて振り返り、次の広告文を追加する」という地道な活動を毎週行い、最初の3ヶ月でユーザーのコアニーズを見つけ、残り3ヶ月で見つけた軸を深堀りました。 細かな表現の違い（「安い」or「最安値」）でも結果が大きく異なり、この経験をとおして、ユーザーニーズに手触り感を持つことができました。 3年目からは、広告文の改善によって理解したユーザーニーズを元に、LPのABテストを開始しました。 大失敗をしているので不安だったのですが、ユーザーニーズに沿って改善を続けた結果、1年目で苦戦したのが嘘のように上手くいき、CVRが開始時の3倍になりました。 1年間のCVRの推移 当時の上司に勧められ、この一連を振り返って言語化しました。 それによって自信がつき、更にユーザーを意識した改善施策を実施して、成果を出せるようになりました。 社内wikiに公開しました 4~5年目：行き着いたのは「ユーザー中心設計」のABテスト 4,5年目は、同時に4領域でABテストを実行しました。 立ち上げ期・成長期・安定期と異なるフェーズのLP、異なる種類のユーザーニーズでしたが、同時に実行することで抽象化した学びとなり、自分の中で上手くいくABテストの型が分かってきました。 僕が見つけた型は、 LPやEF（エントリーフォーム）をプロダクトと見たてて、そのプロダクトを磨く手段としてABテストを実施することです。 具体的には、次の3つになります。 ① ユーザーニーズを定義し、コアの提供価値を決める ② 「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる ③ 施策数や施策の成功数ではなく、事業の数値を結果責任として持つ 1つずつ説明できればと思います。 ①ユーザーニーズを定義し、コアの提供価値を決める LPやEFをプロダクトとして見立てるのであれば、必要なのは、「誰の・何の課題を解決するためのページなのか？」を決めることです。 ABテストを実施する前に、これを決めます。それによって、施策や判断に方向性が生まれ、局所最適なABテストを防ぐことにつながります。 例えば、このような質問に答えを持っておく必要があります。 ページに流入したときの期待値 ユーザーが知りたい/やりたいことは何か？ それができない（と思っている）構造は何か？ このページで何ができると思っているか？ そのクオリティはどんなもんだと思っているか？ 流入時の期待を上回るためにできること ユーザーが得られるもののクオリティを高められないか？ ユーザーが得られるものを、想起しやすくできないか？ ユーザーが得るまでの行為を、なめらかにできないか？ LPについて、ユーザーニーズとコアの価値を定義したときの資料です ②「何をやるか」ではなく「どういう仮説を検証するか」にこだわって、施策をつくる 施策を作ろうとすると、どんな内容にしようか？ということに視点が及んでしまいがちです。改善しやすいフェーズであればよいのですが、その場合はユーザー理解が生まれづらく、施策が枯渇していきやすくなります。 僕は下記のフォーマットで毎回施策を作っています。 見ていただければわかるとおり、「仮説」のところがかなり肉厚で、しっかり設定できるようにしています。 ## 施策について ### ざっくり内容 ### 仮説 - 〇〇なので - （実数値や他の施策の結果）事実として - ↑の事実は、ユーザーの気持ちがこう動いているのだろう - 〇〇することで - 〇〇するのではないか - ユーザーの気持ちがこうなる - 結果、何の指標がどうなる ### リリース指標 - 上がってほしい - 維持してほしい ### 考察にあたっての指標 - 指標①：◯◯ - 指標②：◯◯ このフォーマットで施策を行うと、事前に仮説と指標が設計されていることで、振り返りを通してユーザー理解が深まりやすくなります。 また結果が出たときに、下記のように分岐できるので、施策のネタ切れ状態を起こしづらいです。 施策後のアクションを決めるツリー ③施策数や施策の成功数ではなく、事業の数値を結果責任として持つ 方針を決めて、ユーザーに向けて施策を実行しても、事業成果を出せないことはあります。ユーザビリティを追求することが必ずしも事業成果に紐付かない例は、いくつか思いつくのではないでしょうか。 そこで、テストのプロセスではなく、実際の事業にまつわる数字を結果責任としてみましょう。営利組織である以上、ユーザーと事業がwin-winになる関係を目指す必要があり、ここは避けては通れません。 また、実は事業全体の数字を見るとユーザー理解が深まります。 というのも、どうしてもABテストの影響ではないところで数字が変動します。そのため、数字の報告責任を果たすには、ページへの流入前・流入後の状況を把握し判断する必要がでてきます。そうすると、不思議と、今まで見ていたのとは違った景色でユーザーを見ることができます。 「責任領域が増えて大変だな、、、」と思うかもしれませんが、責任として持っていると、手段に自由度が高まり、やりたいようにユーザーと向き合うことができます。 実際の成果報告のフォーマットです まとめ 僕の5年間のABテストの経験と、上手くいくために自社で取り入れている、「ABテストの型」について紹介させていただきました。 ポイントについて改めて整理すると、 最適化の方向性をコントロールする ユーザーに向き合って施策を回す 事業数字と離れないように、モニタリングする といったところでしょうか。 僕はこの考え方をするようになってから、ABテストが好きになりました。 プロダクトとして解釈できるようになり、幅や奥行きが見えるようになってきました。また、フットワーク軽くユーザーの検証を行えるのも魅力的です。 ABテストのもう一つ好きなところは、失敗してもいいことです。仮説さえしっかりしていれば、失敗から学ぶことができ、またチャレンジすることができます。 最近は、後輩にABテストのナレッジと考え方を伝えていく役割を担っています。その過程で言語化が必要となり、正直苦戦しています。 ABテストで学んだように、最初うまくいかなくても、諦めずに取り組み続けたいと思います！ -------------------------------------------—-------------------------------------------— Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

開発部 R&D ユニットで OSS を開発している村田です。GitHub のアカウントは @mrkn です。今回は情報処理学会に寄稿した次の論文の経緯と内容について簡単に紹介します。 www.ipsj.or.jp Speee には、社員の OSS 開発を促進する取り組みとして、株式会社クリアコードの須藤さんにアドバイスをいただいたり、須藤さんと一緒に OSS の開発をしたりできる福利厚生があります。私は2018年頃から Apache Arrow の開発に入っていきましたが、当時すでに Apache Arrow PMC メンバーだった須藤さん*1に大いに助けていただきました。 Apache Arrow の開発に参加してから3年間、私は主に Arrow C++ の sparse tensor 周り、Arrow GLib、Red Arrow の開発を須藤さんと共に手掛けました。Apache Arrow の開発に参加した理由は、Ruby をデータ処理に対応させるために Apache Arrow が必要だと思っていたからですが、この3年間の活動を通してその考えは間違っていなかったと考えるに至りました。 Apache Arrow は 2020年7月にバージョン1がリリースされて徐々に利用者が増えてきていますが、Ruby への対応を進める開発者はなかなか増えません。そこで、データ処理分野における Apache Arrow の重要性と、Ruby のデータ処理対応への必要性の両方を解説する文書を書いて公開したいなと考えていました。そんなときにちょうどデジタルプラクティスのビッグデータ特集の話をいただいたため、論文を書いて寄稿させていただいたというわけです。 この論文では、Apache Arrow の特徴であるプログラミング言語中立のデータフォーマット、ライブラリ開発方針の特色、そして Ruby バインディングの開発におけるアプローチ方法について解説しています。Apache Arrow は、先進的なデータ処理の研究でも応用され始めていますので、それらの研究についても簡単に紹介しています。Apache Arrow と、Ruby のデータ処理対応のいずれかに興味があれば是非ご一読いただければと思います。 Apache Arrow の開発や、Ruby のデータ処理対応に参加してみたいと思った方は、毎月オンラインで開催している OSS Gate for Red Data Tools にご参加ください。次回は2月16日 (水) です。Red Data Tools の Gitter でお待ちしております。 speee.connpass.com *1:須藤さんは最近、Apache Arrow PMC の3代目の chair に就任しました

※この記事は、Speee Advent Calendar25日目の記事です。 昨日の記事はこちら tech.speee.jp Speeeでアウトプットをいい感じにやっていこうぜ～活動をしている菅沢です。 Speee AdventCalendar2021の出番は3回目です！！！ そして25日目！！！最終日！！！🎉🎉🎉🎉 SpeeeとしてAdventCalendarを完走するのは、2016年を最後に5年ぶりになります、、、！ いや～感慨深いですね！！！ まず最初に、この記事はポエム記事です。 アウトプット頑張ろうぜ、という活動をしていく中で、元々は採用を狙ってたんだけど、気付けばチームをもっと好きになっていたり、以前よりチームが良くなっている空気感が生まれていることに気付きました。 元々ほしいと欲しいと思っていた採用という成果にはまだ結実していません。 しかし、このチームなら難しいこともなんとかやっていけるでしょ？と思っていて、「あ、大切なものが先にきたな」と感じている、というお話です。 アウトプットを頑張ろうぜ！という活動を始めた背景 大切なことはチームに気づかせてもらった チームの対話が増えて、これまで以上にお互いに意見を交わせる空気ができた 大切なものは、ほしいものよりも先に来た お決まりの アウトプットを頑張ろうぜ！という活動を始めた背景 もともとは自社の採用の強化を狙っての取り組みとして開始しました。 背景としては、 転職活動の長期化 スカウト媒体などのいわゆるなプラットフォームのレッドオーシャン化 というマーケットの明らかな変化を感じている中で、 アウトプットを名刺代わりにしながら、Meetyのような接点からゆるくいろんな方と繋がり、ファンになっていただく、そしてタイミングなどが合えば仲間になってもらう。 という、いわゆるファン採用と言われている戦い方を組織として体得していかねば！という危機感から開始しました。 採用マーケットについての詳しい考察は、Meetyの中村さんが詳しい内容を書いてくれているので、そちらをご参照いただくのが良いと思います。 note.com 社内向けにも以下のブログの内容を発信し、積極的なアウトプット活動や外部の方とのコミュニケーションによる自己研鑽、結果的な繋がりを生んでいくことを推奨していきました。 アウトプットを楽しく続けていこう🤟 - Speee DEVELOPER BLOG 大切なことはチームに気づかせてもらった アウトプットをしていこうぜ活動を推進していく中で、これまで積極的に発信活動をしていなかったこともあり、 ブログ書けない、、、！ 登壇？！発表できるネタない、、、！ という課題に、ご多分に漏れずぶつかりました。 私自身もブログを書いたことも登壇したこともなく、こうしたらいいよ！とも言えない状態だったので、結局何が一番言いたいことなんだろうね？と内容を整理したり、構成を考えたりを一緒にやっていました。 というより、どうにか一緒にやることで書いてもらえるように必死でした。 だって、アウトプットを出していくことで採用につなげていきたいのに、アウトプットが出ないと話は前に進まないわけですから、あの手この手でどうにか書いてもらおうとするわけです。 このあたりの話は詳しくはこちらにまとめています。 Techブログとモメンタム - Speee DEVELOPER BLOG プロダクト開発のノウハウを使っていい感じにブログを書く技術 - Speee DEVELOPER BLOG 記事を執筆する人からすれば、通常業務にアドオンで記事を書いたり、登壇する人からしたら、登壇に向けた資料を作ったり、大変ですよね。 私は「ブログを書こうぜ！」とか「このイベント登壇してみようよ！！」と言いながらも、少なからず「申し訳ないなぁ」という気持ちがありました。 ところが、記事を書き終えたり、登壇をしたメンバーから出る感想は、「大変だった」よりも、 振り返りながら記事を書く中で、自分結構やれるようになったことがあるという自信が持てた、継続的にやっていきたい！ 言語化をしていく中で、ふわっと理解していた理解が深まってよかった、周りのメンバーにも薦めたい！ 登壇してこなかったけど、やってみてよかった、次はもっと〇〇な内容で登壇してみたい、周りにも薦めたい！ というポジティブな声の方が全然多かったんですよ。 なんだか、「申し訳ないなぁ」なんて気持ちで向き合ってしまった自分がすごく恥ずかしくなりました。 そんなことは一切気にする必要なんてなかったんですね。 もっと頼っていいし、信じ切ってしまってよかった。 この3ヶ月で、大切なことをチームに気づかせてもらいました！ 採用や広報をしている方々は大なり小なり「現場に負担をかけてしまうな、、、」と気にすることがあると思います。 大丈夫です！気にしなくて！！！！一緒に本気で向き合うのであれば！！！！ チームの対話が増えて、これまで以上にお互いに意見を交わせる空気ができた アウトプットをしてもう1つ大きく変わったことがあります。 それは、 アウトプットを起点にした対話が増え、雑談が増えたこと です。 これまでも対話が少なかったというわけではなかったのですが、 新たな事業が連続的に立ち上がっていたり、それに伴い組織が拡大していることもあり、事業毎のチーム間での会話がそれまでと比較すると少なくなっている状況にありました。 そうした中で、各自がアウトプットを通じて「こんなことを考えているよ！」「こういうことやったよ！」という自己開示を行ったことで、共有できる話題が増え、 これまで以上にチームをまたいだ会話が増えました。 併行して、　「まとめを作らない音読するだけの読書会」に参加してみたら良かった話 - Speee DEVELOPER BLOG で紹介しているような読書を通じた対話も増えており、相互に意見を交わしやすい空気がチームに生み出されていて、 より一層いいチームになっている！最高じゃないか！と思っています！ 😊 目まぐるしく変化する中で全速力で駆け抜けるようにプロダクトに向き合う日々を過ごすからこそ、 時には立ち止まって学びを言語化したり、雑談を通じて相互に視界を共有したり、といった時間を大事にしたいなということを気づかせてもらいました。 大切なものは、ほしいものよりも先に来た もともとはファン採用という戦い方を体得したくて始めたアウトプット頑張ろうぜ！という活動ですが、 それはまだまだ上手くできる状態ではないのです。 しかし、その道すがらで、 チームを本当に信頼するということ 相互に対話をしながらより良くしていこうとするリスペクトできるチーム という大切なものに気づくことができました。 たぶんこのチームなら大体の難しいこともなんとか乗り切れると思います！ だからこそ道中を楽しんでいこうと思います～！🚗🏔 出典：冨樫義博 『HUNTER×HUNTER【32】』 お決まりの Speeeでは一緒にプロダクトを推進してくれる仲間を大募集しています！ 事業も組織も拡大している中で、今"目の前にないもの”を社会実装していこうと挑戦しています。 不動産やリフォーム、介護領域とやや渋めの領域でプロダクトを展開していて、ぱっとイメージしずらいところもあるかと思いますので、是非MeetyやTwitterからお気軽にご連絡ください！「こんなことやってるよ～！」というのを紹介させてください🙏 twitter.com meety.net 社内メンバーのカジュアル面談も複数公開しております！💁 tech.speee.jp 様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！ もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar24日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは、DX事業本部エンジニアのさとーる（@satotoru2000）です。 先日、学生たちにアジャイル開発によるプロダクト開発の立ち上げを体験してもらうインターンを開催しました。インターンというコンパクトな形で行うことでかえってエッセンスを抽出することが出来たと感じているので、当日にアドリブで色々喋ったことを改めて言語化して整理しようと思います。 Speeeのプロダクト開発ではインセプションデッキやユーザーストーリーなど、アジャイル開発でよく使われれるツールを駆使しながら進めていくのですが、こういったツールは漫然と利用しても意味がなく、事業の成功と紐付けて考える必要があります。形式としてアジャイルの方法論を取り入れても、目的を理解し、勘所をしっかり抑えていなければプロジェクトは上手くいきません。(タイトルの「なんとなくアジャイル風」は、そういった状況を指しています) その辺りを踏まえつつ、アジャイル開発を進める上で気をつけるべき観点をまとめてみました。ここに書ききれない話もたくさんあるのですが、今回は特に開発スタート前の計画段階の話に焦点を当てています。 どんなインターンだったのか？を簡単に 気をつけるべき観点 まずは要求をありのまま正確に理解すること 一貫した判断軸を持つこと 「変化を受け入れる」ことは一貫した軸がないと成立しない 機能を減らしても価値提供のトップラインを落とさないこと 期日とスコープのよくある話と個人的見解 不確実さが大きくてもキッチリ意思決定すること アジャイル開発と意思決定 終わりに どんなインターンだったのか？を簡単に 詳しく書くとネタバレしてしまうので、簡単にインターンの内容を説明します。 今回はDX領域の仮想のサービス立ち上げを題材に、新規事業立ち上げのSprint0を体験してもらう2日間のインターンです。 事業責任者は本気の事業プランを説明するのですが、プロダクトとしてどう作っていったら良いかは分からないので、その辺りを全て担って開発スタート可能状態まで持っていく、というものでした。 つまり、実際のプロダクト開発の立ち上げフェーズをキュッと圧縮したような内容だったといえます。 気をつけるべき観点 まずは要求をありのまま正確に理解すること 事業責任者からの要求は極めて抽象度の高いものです。様々な解釈の余地があり、事業責任者が思い描くものを理解するのは簡単なことではないです。特に、開発はチームで行うものなので一人が正しく理解していてもダメで、全員が認識を合わせて望む必要があります。 まずは要求されたことをありのまま正確に理解する、というのが非常に重要です。 この辺りが不十分だったチームは、議論が紛糾したり、後半になって勘違いが見つかってやり直しが発生したりしていました。 難しい問題を正しく解釈することに向き合いきれず、「自分の意見」という分かりやすい答えに安易に飛びついてしまうが、そもそも前提が擦り合ってないので折り合わず平行線のまま紛糾する、といったケースはしばしばありました。 要求を理解するために、 要求をユーザーストーリーマップに書き出してみる 簡易なペーパープロトタイプを作って製品イメージをザックリわかせる 要するに何がしたいのか？をエレベーターピッチの形式に書き直してみる などのツールを使っていきます。 状況に合わせてとにかくアウトプットして、認識を擦り合わせていくのが良いと思います。 インターンではこんな感じのアウトプットを作ってました 一貫した判断軸を持つこと プロダクト開発の最初の段階は、最初のリリースに必要なものを見極めて、価値のある最小のプロダクト(MVP)を定義していくことが重要です。つまり、やりたいことに優先順位をつけて、MVPに必要ないものをリリーススコープから落としていく必要があります。 これらの意思決定は一貫性をもって行われる必要がありますが、検討が進むにつれて一貫性が崩れてきてしまうケースがしばしばあります。そうなると「あれも、これも」大事に思えてしまって、不必要にスコープが肥大化したり、意思決定が遅れて進捗に悪影響が出たりします。 そういった事態を回避するために、インセプションデッキなどを用いて判断軸しっかり言語化し、認識を合わせておくことが重要です。 「エレベーターピッチ」をちゃんと書くことで、何の価値提供を重要視しているかの認識が合うようになりますし、 「トレードオフスライダー」や「やらないことリスト」があると、具体的なケースで判断に迷わなくなります。 一貫した判断軸を持てているか？を確認するために、具体的な問いを投げてみるのも有効だと思います。例えばインターンでは私から学生に以下のような問いを投げていました。 フォームは「簡単に入力できる方が良い」か「詳細に入力できる方が良い」か 企業向けツールは「リッチな方が良い」か「シンプルな方が良い」か 社内向け管理画面は「自動化されている方が良い」か「柔軟に対応できる方が良い」か 一見すると判断軸が作れているように思えても、具体的なケースに照らすとそうでもなかったり認識がずれていたりします。 「変化を受け入れる」ことは一貫した軸がないと成立しない アジャイル開発は「変化を受け入れる」開発プロセスです。言い換えれば、市場という混沌の海の中にその身の一部を晒し続けるということです。その状況下では、荒波の中で舵を取り続けなければ溺れてしまうように、判断軸をもって変化に向き合わなければ翻弄されてしまいます。その結果、無数の要求や矛盾を抱え込むことになります。 こういった事態を回避するために「われわれはなぜここにいるのか」をきっちり言語化し、認識を合わせておくことが重要です。 機能を減らしても価値提供のトップラインを落とさないこと 最短でのリリースを目指すために、リリーススコープから機能を減らすことは最初に考える選択肢です。ただ、機能を減らした結果、ユーザへの価値提供も減ってしまうようなケースがあります。ある機能を作らない判断をしたり、求めている時間軸より遅らせたりする場合、その背後には必ずトレードオフが発生します。トレードオフをそのまま受け入れてしまえば事業計画はビハインドし、成長は鈍っていきます。 仕方ない部分もあるのですが、「トレードオフをそのまま受け入れず、価値提供のトップラインを落とさない方法を考える」という姿勢を持つことが重要です。無思考に機能を減らすことをせず、何とかやる方法を考えたり、代替手段がないか検討したり、頭をひねっていきましょう。 「ユーザーストーリーはアウトカムで書きましょう。Whyを書きましょう」といった話はよく言われますが、こういった場面で効いてきます。ユーザーストーリーに機能を書かずにアウトカムを書いていれば、機能を作ること以外の代替手段を開発チーム全員で考えることが可能になります。 プロダクトにとってソフトウェアが占める領域はほんの一部です。ソフトウェアの周りには営業・マーケ・CSなどさまざまな人が関わっています。そのため、視点を広げると代替手段が見えてくることがあります。 例えば、 管理ツールを作る代わりにスタッフを雇うことで解決する ユーザー訴求のためのコンテンツを作る代わりに広告を出す toB側の機能を提供する代わりに、営業やCSの体制を強化する 自分たちで作るのをやめて、第三者のサービスを利用する などです。 期日とスコープのよくある話と個人的見解 開発プロセスにおいて、期日とスコープはトレードオフとして扱われることが多いです。「見積もり上だと期日に間に合わないのでスコープ削るしかないですね」といった会話はよくある話かと思いますが、個人的にはこの考え方が好きではありません。 この考え方は、スコープを減らしてビハインドした分の価値提供をどうリカバリしていくか？に関して何も答えていないからです。これだけでは、ユーザに価値を届けることに対して半分しか考えられていないと思います。 本当に重要なのは、そのトレードオフを受け止めた上で、どうやったら目指している時間軸で価値を届けることが出来るか？を考え、あらゆる手を尽くすことだと思います。この矛盾を乗り越えようとする姿勢にこそ創造性が宿るのだと思っています。 不確実さが大きくてもキッチリ意思決定すること プロジェクトには不確実性やリスクがつきものであり、開発プロジェクトも例外ではありません。 計画する段階でどんなに検討を重ねたとしてもリスクをゼロにすることはできません。特に開発プロジェクトにおいては、不確実性コーン が示すように、プロジェクト開始時に最も不確実性が高くなります。この段階で毅然とした姿勢で意思決定をするのは非常に難しいことだと思います。 そのような状況下で、どのように意思決定すれば良いでしょうか？不確実性を抱えた状態で、どうしたらリスクを抑えることが出来るでしょうか？ アジャイル開発における計画策定と実行の方法論は、こういった課題を解決するために存在しています。例えば、イテレーションの計測を重視する姿勢や、学びを得て計画を柔軟に修正していく考え方がこれに当たります。 不確実性に絞っていうと、以下の2点を事前にやっておくのが重要だと思います。 「(どういう問題が起きるかは分からないが)少なくとも〇〇という不確実性がある」ということは明らかにしておく 問題を顕在化させ対処する方針だけは定めておく 例えば今回のインターンだと「開発速度を高めるため、認証系の機能は内製せず外部サービスを導入する」という意思決定をしたチームがありました。この場合、上手くいけば早く安全なシステムを作ることが出来る一方で、外部サービスで本当にやりたいことを実現できるのか？はこの時点では分かりませんでした。 そこで、「プロジェクトの最初の1週間で外部サービスの調査を行う。その結果やりたいことが実現できないと判断した場合は、内製に切り替える」という対応方針を定めました。 アジャイル開発と意思決定 アジャイル開発はイテレーションごとに意思決定が求められる高負荷な開発プロセスであり、アジャイルと意思決定は切り離すことが出来ません。この認識が不足したまま開発にのぞむと、非常に危険な状況が生まれていきます。 よくある例でいうと、「アジャイルは計画が変わるので、計画を決められない」という誤解です。計画は絶対に最初から決めたほうが良いです。現実を計測した学びを経て、よりベストな形に計画を変更することはあるし、変更されることを受け入れる姿勢は必要ですが、あらかじめ計画を立てたり、計画したゴールにコミットメントすることを否定する要素はどこにもありません。計画を決めなければ、当初の理想と現実との差分も分からなくなるので学習も進まないし、前述した期日とのトレードオフも認識できないので創造的な仕事も阻害されます。 設計などの技術的な意思決定も先送りすべきではありません。不確実な要素を受け止めながらその時点でベストだと思う意思決定をして、経緯をドキュメントに残すのが重要です。その時点でのスタンスをしっかり決めていれば、後から正解・不正解を検証出来るので、より良い形に直すことが出来ます。スタンスが不明瞭な設計は結果を評価できないので、何の学びも蓄積されないし、直すことも難しくなります。 このようにあらゆる場面で意思決定が求められるので、覚悟をもってのぞむ必要があります。 終わりに 今までは、こういった新規開発の混沌とした現場でのノウハウは言語化を怠っていた部分もあったのですが、改めて言葉で伝えていくことの重要さに気づきました。ここで挙げた内容はまだほんの一部だと思うので、またどこかのタイミングでアウトプットできればと思います。 ちなみに、実際に混沌の中で意思決定した話はコチラにも書いていますので、よかったらご覧くださいませ。 tech.speee.jp もっと話したい方はMeety作ったのでコチラからご連絡下さいませ。 meety.net また、Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar23日目の記事です。 昨日の記事はこちら tech.speee.jp どうも、最近は専らgraphql-rubyと戯れている石井です。 みなさん、graphql-rubyを使っていて「このTypeのこのフィールドはAdminユーザにしか見せたくないんです！」といったようにアクセス制限したくなる時が3日に1回ぐらいはやって来るのではないでしょうか。 今回はRailsとgraphql-rubyでAPIを作る際にgraphql-guardを使ってシンプルなアクセス制限を実現する方法をソースコードを織り交ぜつつ紹介してみたいと思います。 ※本記事で記載するコードは全て実装の雰囲気を伝えることが目的のサンプルコードなのでご了承ください。 想定する環境 この記事では下記のバージョンの言語、ライブラリの利用を想定しています。 Ruby: 2.7.5 Rails: 6.1.4.4 graphql-ruby: 1.12.16 graphql-guard: 2.0.0 前提 今回は以下のような架空のアプリケーション開発について考えてみたいと思います。 ユーザ向け、販売者向けにSPAを提供する ユーザはユーザ向けSPA上で商品を閲覧する 本当は商品購入などもできるべきだと思いますが、シンプルにするため割愛 販売者は販売者向けSPA上で商品を登録、編集、削除する 販売者用管理画面のようなイメージ 両方のSPAから利用する、認可必須のGraphQL API (Rails)を用意する OAuth2.0のAuthorization Code Flowに則った形式でアクセストークンを取得する アクセストークンのPayloadにpermissionsが含まれる permissionsの中身によってAPIのQueryやMutation、アクセス可能なTypeのフィールドを制限したい permissionsにはuser、sellerのような値が入っているものと仮定する 拡張性を考え、配列で渡ってくるものと仮定する アクセス制限はできればTypeやFieldごとに一つ一つ書いていく感じではなく、一元管理したい アクセス制限 = 例えば「ユーザは商品の登録、編集などはできないし、販売者はユーザのプロフィール登録、編集はできない」といったような設定 許可されていないリクエストをしたらUNAUTHORIZED的なエラーを含んだレスポンスを返却したい スキーマのイメージはこんな感じです。 Railsでgraphql-rubyを利用する際、ジェネレータでGraphqlControllerを生成してそれを拡張していくことが多いと思うのですが、SPAから渡ってきたアクセストークンをparseしてトークン所有者 (current_resource_owner)やPermission情報 (permissions)を以下のように渡すような状況をイメージしていただければと思います。 # frozen_string_literal: true module MyAuthModule def current_resource_owner # ResourceOwnerをpayloadから見つけるメソッドが定義されている想定 @current_resource_owner ||= ResourceOwner.find_by_token_payload(auth_payload) end def permissions @permissions ||= auth_payload&.permissions end private def auth_payload return @auth_payload if @auth_payload.present? http_token = request.headers['Authorization'].split(' ').last payload = JsonWebToken.verify(http_token) ... # do something @auth_payload = ... end end # frozen_string_literal: true class MyApiController < ApplicationController include MyAuthModule end # frozen_string_literal: true class GraphqlController < MyApiController def execute variables = prepare_variables(params[:variables]) query = params[:query] operation_name = params[:operationName] context = { # Query context goes here, for example: current_resource_owner: current_resource_owner, permissions: permissions, } result = MySchema.execute(query, variables: variables, context: context, operation_name: operation_name) render json: result rescue StandardError => e raise e unless Rails.env.development? handle_error_in_development e end private # Handle variables in form data, JSON body, or a blank value def prepare_variables(variables_param) case variables_param when String if variables_param.present? JSON.parse(variables_param) || {} else {} end when Hash variables_param when ActionController::Parameters variables_param.to_unsafe_hash # GraphQL-Ruby will validate name and type of incoming variables. when nil {} else raise ArgumentError, "Unexpected parameter: #{variables_param}" end end def handle_error_in_development(err) logger.error err.message logger.error err.backtrace.join("\n") render json: { errors: [{ message: err.message, backtrace: err.backtrace }], data: {} }, status: :internal_server_error end end では上記の前提のもと、graphql-guardを利用して良い感じにアクセス制限を実現する方法を考えていきましょう。 graphql-guardとは まず「graphql-guardとは何ぞや」という話なのですが、GitHubのAboutに Simple authorization gem for GraphQL. と書かれているようにシンプルにアクセス制限を実装できるGemです。graphql-rubyと一緒に使います。 実際にgraphql-guardの実装を雑に読んでみると、graphql-rubyのTracing機能を利用しているようです。execute_fieldイベントを捕捉して、type.respond_to?(:type_class)がtrueの時に権限チェックを行っているようですね。 また、利用したことがないので今回は触れないですが、CanCanCanやPunditのインテグレーションサポートもあるようです。 graphql-ruby単体でもAuthorizationに記載されているような機能は提供されているのですが、Policy Objectで書かれているようにアクセス権限の設定を一元管理できそうな雰囲気が特に良いなと思いました。 それでは実際にやっていきます。 graphql-guardを実際に使ってみる 先述したようなGraphqlControllerがあり、contextにpermissionsが渡ってくる想定で、graphql-guardの利用に必要な、以下のクラスの実装を考えていきます。 MySchema::Permission 各Permissionのアクセス権限の設定を記述するクラス どのPermissionがどのQueryやMutationを利用できるのか どのPermissionがどのTypeのどのFieldにアクセスできるのか MySchema::Policy contextで渡ってくる permissionsと上記のPermissionをもとにguardする処理を担当 guardした際のエラーハンドリングも担当 MySchema GraphQLのスキーマクラス MySchema::Permission 直近の私のプロジェクトで積極的にactive_hashを利用していたので、今回はactive_hashを利用したサンプル実装を掲載します。普通のHashで実装しても問題はないと思います。 Enumのオブジェクトはこんな感じの想定です。 # frozen_string_literal: true module Enum class Object < ActiveHash::Base include ActiveHash::Enum field :id field :slug field :name end end そしてEnumのオブジェクトを継承してPermissionのクラスを定義してみます。全フィールドを許可したい場合と一部のフィールドのみを許可したい場合などを考慮して以下のような実装を考えてみました。 各Permissionに対してアクセスできるQuery、 Mutation、Typeをホワイトリスト形式で許可していきます。QueryやMutationの実装は名前で雰囲気だけ感じ取っていただければと🙏 # frozen_string_literal: true # そういうQueryやMutation、Typeがあるんだなぁという強い想像力を働かせて読んでほしいです class MySchema class Permission < ::Enum::Object enum_accessor :slug self.data = [ { id: 1, slug: :user, name: 'user', authorized_fields: { Types::QueryType => %i[ currentResourceOwner products ], Types::MutationType => %i[ createUserProfile updateUserProfile ], Types::ResourceOwner => %i[ id email ], Types::User => %i[ id profile ], Types::User::Profile => %i[ firstName lastName ], Types::Product => %i[ id name price ], }, }, { id: 2, slug: :seller, name: 'seller', authorized_fields: { Types::QueryType => %i[ currentResourceOwner products product ], Types::MutationType => %i[ createProduct updateProduct deleteProduct ], Types::ResourceOwner => %i[ id email ], Types::Seller => %i[ id name ], Types::Product => %i[ id name price ], }, }, ] def authorized?(type, field) case authorized_fields[type] when Array # リストに含まれるフィールドのみ許可 authorized_fields[type].include?(field) when true # 全フィールド許可 true else # 全フィールド禁止 false end end end end MySchema::Policy ここで地味にMySchema::Permission#authorized?が活きてきます。contextに渡ってきたPermissionを確認して、authorized?かどうかを見てアクセス制限をやっていきます。 MySchema::Policy#not_authorized_handlerはError handlingで求められている not_authorizedメソッドで利用します (といってもエラーをraiseするだけですが）。 あとはintrospectionの場合はアクセス制限したくないので、その配慮を入れていたりします。 # frozen_string_literal: true class MySchema class UnauthorizedError < StandardError; end class Policy class << self def guard(type, field) return -> (_obj, _args, _ctx) { true } if type.introspection? lambda { |_obj, _args, ctx| raise MySchema::UnauthorizedError unless ctx.current_resource_owner permissions = MySchema::Permission.where(name: ctx.permissions) permissions.any? { |permission| permission.authorized?(type, field) } } end def not_authorized_handler(type, field) raise GraphQL::Guard::NotAuthorizedError, "Not authorized to access: #{type}.#{field}" end end end end MySchema 最後に上で定義したクラスをスキーマで利用するよう設定すれば完了です！ 許可されないリクエストをした場合はたぶん "message": "Not authorized to access: UserProfile.lastName"のようなエラーが返るようになると思います。 # frozen_string_literal: true class MySchema UNAUTHORIZED = 'UNAUTHORIZED' FORBIDDEN = 'FORBIDDEN' mutation(Types::MutationType) query(Types::QueryType) use GraphQL::Guard.new( policy_object: MySchema::Policy, not_authorized: -> (type, field) { MySchema::Policy.not_authorized_handler(type, field) }, ) rescue_from MySchema::UnauthorizedError do |_err, _obj, _args, _ctx, _field| raise GraphQL::ExecutionError.new('Unauthorized', extensions: { code: UNAUTHORIZED }) end rescue_from GraphQL::Guard::NotAuthorizedError do |err, _obj, _args, _ctx, _field| raise GraphQL::ExecutionError.new(err.message, extensions: { code: FORBIDDEN }) end end まとめ 今回はgraphql-guardを使って、アクセス制限を一元管理する実装例を紹介してみました。もちろんこれで全人類が幸せになるとは言い難いですが、シンプルなアクセス制限を実装する際の参考になれば幸いです。 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar22日目の記事です。 昨日の記事はこちら tech.speee.jp 2021年7月から業務委託のエンジニアとして主にイエウールの開発のお手伝いしている高尾です。所属は株式会社ネットワーク応用通信研究所。Rubyのまつもとゆきひろさんも在籍されており、Rubyに関するSIでそれなりの実績のある会社です。私は20年近くSIerとして仕事をしてきました。 そんな私にとってもSpeeeでの開発は魅力的です。 プロジェクトの運営、プロダクトの仕様、技術の採用、リリースなど、多くのことをエンジニアが主体的に決めます。各エンジニアがお客様の価値を理解してプロダクトを作り上げるという意識が伝わってきます。そんなエンジニアのみなさんが、 Rubyをつかって楽しくプログラミングできるように全力でサポートしていきたいと思います！ 前置きが長くなってしまいましたが、今回は Ruby on Rails を使って開発しているイエウールで導入している Rails のデザインパターンを、私の独断で Keep = 今後も積極的に使っていくもの Problem = 問題があるためメンテナンスのみで今後は使わない に分類して紹介します。 また、 Keepに対するTryとして、より良くするために今後やっていきたいこと を書きます。 なお、イエウールは2014年にサービスを開始し、2016年にRuby on Railsでリプレイスしています。そのときの最初のコミットは2016-01-25でしたので、 Railsでの開発期間は約6年間 です。 *1 それでは各デザインパターンをファイル数の多い順に紹介していきます。 Serviceオブジェクト (Keep) 最初は Service オブジェクト と呼ばれているパターンです。 このパターンについては説明は Railsで重要なパターンpart 1: Service Object（翻訳）｜TechRacho by BPS株式会社 が詳しいです。 イエウールでは app/services 以下に 140 ファイルあり、最も多く使われているデザインパターンです。 複数のモデルを操作する処理 メールやSlackへの通知 バッチの処理 その他、分類が難しいもの を実装するのに使っています。 オブジェクト指向を意識せずに、やりたいことを素直に実装できる ため、開発初期からずっと使われ続けています。 ただし、例に漏れず Service Objectがアンチパターンである理由とよりよい代替手段（翻訳）｜TechRacho by BPS株式会社 に挙げられている問題点がそのままイエウールにも当てはまってしまいました。 本質的にService Objectパターンそのものには、コードベースを読みやすくする力も、メンテしやすくする能力も、concernをうまく分割する手腕もありはしない そうなんです。 Service オブジェクトを実装した人にとっては短い時間で簡単に実装できたかもしれませんが、メンテナンスする人にとっては再利用しにくく、自動テストもやりにくいものになっています 。 Service オブジェクトパターンは今後も使っていくのですが、Tryとして (1) public なメソッドは call のみとする (2) モデルに実装すべき処理を積極的にモデルに実装する ということを気をつけていきたいと考えています。 なお、(1) を実現するために Selleo/pattern: A collection of lightweight, standardized, rails-oriented patterns.を参考にして ApplicationService クラスを用意しました。今後はこれを継承して Service オブジェクトを実装していきたいと考えています。 class ApplicationService class << self def call(*args) new(*args).call end ruby2_keywords(:call) if respond_to?(:ruby2_keywords, true) end # :nocov: def call raise NotImplementedError end # :nocov: end Decoratorオブジェクト (Keep) 次は Decorator オブジェクト と呼ばれているパターンです。 Decoratorオブジェクト | Railsのデザインパターンまとめ - applis で解説されています。 イエウールでは、特定のビューのみで使うヘルパーメソッドを定義するためにこのパターンを使っています 。Rails の Helper だとメソッド名が重複しないように気をつける必要があるんですよね。 Decorator オブジェクトは draper gem をつかって実装し、app/decorators に配置しています。 数えてみると 59 ファイルあります。結構多いです。 気軽にヘルパーメソッドを定義できて便利なので今後も Decorator パターンを使っていくのですが、Tryとして、モデルとの関連がない Decorator オブジェクトがいくつかあるため、それらをリファクタリングしていきたいです。 実際のコードではありませんが、具体的な例を挙げると、 # UserモデルとDecoratorオブジェクトの関連がなく、 # ユーザーが所属する企業名を返すヘルパーメソッドcompany_nameの # 引数にUserモデルのインスタンスを指定している class UserDecorator class << self def company_name(user) if user.company.parent_company.present? return "#{user.company.parent_company.name} #{user.company.name}" end user.company.name end end end というコードを以下のようにリファクタリングしたいということです。 # これがDraperの本来の使い方 # UserモデルとDecoratorオブジェクトを関連させて、 # company_nameメソッドでUserのインスタンスメソッドを呼び出している class UserDecorator < Draper::Decorator delegate_all def company_name if company.parent_company.present? return "#{company.parent_company.name} #{company.name}" end company.name end end Formオブジェクト (Keep) 次は Form オブジェクト と呼ばれているパターンです。 1つのフォームで複数のレコード、複数のモデルを扱うようになると accepts_nested_attributes_for を使うことになります。が、このメソッド、少し古いですが以下のような記事があり、評判がよくありません。 Railsのaccepts_nested_attributes_forについて解説してみた。 | 目指せ、スーパーエンジニア accepts_nested_attributes_forを使わず、複数の子レコードを保存する | Money Forward Engineers’ Blog イエウールでは、Form オブジェクトパターンを使って、1つのフォームで複数のレコード、複数のモデルを扱っています。 app/forms に配置していて 28 ファイルあります。 PHPから移植したフォームもあり、そういったものにはこのパターンがとても有効 です。 Form オブジェクトパターンも今後も使っていきたいのですが、Tryとして、独自実装となっているため、 pattern/form.rb at master · Selleo/pattern を参考にして、今後は以下のような実装にしていきたいと考えています。 # app/forms/application_form.rb class ApplicationForm include ActiveModel::Model include ActiveModel::Attributes include ActiveModel::Validations def initialize(attributes: nil) attributes ||= default_attributes super(attributes) end def id nil end def persisted? false end def save valid? ? persist : false rescue ActiveRecord::ActiveRecordError => e Rails.logger.error([e.message, *e.backtrace].join($/)) errors.add(:base, e.message) false end private def default_attributes {} end def persist true end end Valueオブジェクト (Keep) 次は Value オブジェクト と呼ばれているパターンです。 Railsのデザインパターン: Valueオブジェクト - applis で解説されています。 イエウールでは、例えば面積を表す Value オブジェクトで単位を平米や坪に変換する、といった使い方をしています 。 app/value_objects に配置していて 18 ファイルあります。 Value オブジェクトについては今後も使っていきたいですし、特に Try はありません。 強いてあげるならば、歴史的な経緯で実装に virtus gem を使っているため、ActiveModel で置き換えたいですね。 Repository (Problem) 最後は、 Repository パターン です。 Repositoryパターン | Railsのパターンとアンチパターン2: モデル編とマイグレーション（翻訳）｜TechRacho by BPS株式会社 で解説されています。 Problem としていますが誤解のないように先に説明しておくと、 Repository パターンが問題なのではなく、不要になったので削除するということです。 イエウールでは、住所マスターの更新にともない、それまではDBに直接格納していたものを、外部DBやAPIサーバーから取得できないか検討したことがあります。その過程で、Repository パターンを使って住所マスターのDBをラップした Addresses::Repositories::Address といったクラスを定義しました。 配置場所は特殊で app/addresses/addresses/repositories です。7 ファイルほどあります。 ただし、結局、住所マスターはDBに直接格納することになり、住所マスターのDBをラップしたクラスは不要になり、今後削除していくことになりました。 まとめ ある程度の規模になるとRailsの標準的なMVCだけでは、コントローラーやモデルが肥大化してしまい、メンテナンスがやりにくくなります。イエウールも今回紹介した5つのデザインパターンを導入して、その問題に対処してきました。特に Service オブジェクトパターンは、複数のモデルが関係する煩雑なビジネスロジックの実装に有効 だったと考えています。 また、Try を考える過程で、 デザインパターンは導入すればいいというものではなく、それらの目的や責務をしっかりと理解した上で実装しないといけない 、ということをあらためて感じました。そうしないと Service オブジェクトのようにメンテナンスや再利用が難しいものになってしまいます。 これからもイエウールは進化していきます。 機能追加と並行して、今回挙げたTryも実現して、よりメンテナンスしやすく再利用できるコードにしていきたいと考えています！ おわりに Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください。 もちろんオープンポジション的に上記に限らず積極採用中です！ *1:イエウールのサービス開始は2014年ですが、初稿では「イエウールの最初のコミットは2016-01-25でしたので、これまでの開発期間は約6年間です。」と記載しており、誤解を招く表現となっていました。お詫びして訂正いたします。

※この記事は採用広報 Advent Calendar 202114日目の記事です。 公開が遅くなってしまいすみません、、、！🙏 Speeeでアウトプットをいい感じにやっていこうぜ～活動をしている菅沢です。 元々ほぼ更新できていなかったTechブログや外部登壇などの発信活動を9月から頑張っています。 まだ開始から3ヶ月目と挑戦中ではありますが、 9月~12月で約50記事（アドベントカレンダー含む）公開 100はてブ以上のアウトプットが3つ うち1つは300はてブを超え、2017年のSpeee最高記録262はてブを更新 イベント登壇 5回 ブログ経由での面談がすでに約5件発生 と割といい走り出しができたのではないかな、と思っています。 かなり怒涛の3ヶ月だったので、自分でも振り返りをして再現性をもたせていきたいと考えているため、AdventCalendarの機会を借りてさせていただこうと思います。 採用広報なんでTechブログから始めた？ まずは小さく始める 大きい取り組みを仕込む モメンタムを産み出す わかりやすく高い成果が出ている状態 アウトプットによる成果を常に感じられる状態にする アウトプットのリズムをつくる 自分が一番の当事者になる まとめ お決まりの 採用広報なんでTechブログから始めた？ 本題に入る前に、いろいろな手段がある中でどういうモチベーションで、Techブログを頑張っているのかということに少し触れさせてください。 正直なところ採用広報をしていこう！と考えたときに、色々な手段がある中でどこから始めようかなと迷いました。 イベントでの登壇 スポンサー活動 Techブログでの発信 PR系媒体への掲載や取材依頼、、、etc 広報！というくらいなので、 わかりやすい「スポンサー活動」や「PR系媒体への掲載や取材依頼」から動きたい気持ちも正直あったのですが、 以下の理由から、Techブログや、その延長でのイベントでの登壇に現在は注力しています。 スポンサーなどで認知を得たとしても、詳しいこと知りたいなと思ったときに、手軽にSpeeeのことを知れないと情報の受け取り手の体験として悪い（し、そんな状態で採用につながると思えない） マーケットから見たときの自分たちの強みを知らないと、どういった方向性でコストを投下してPR活動をするのかが定まらない 要は、サービス全体の体験が設計されていないのに、広告費を投下してしまう、みたいな状況にしたくなかったという話です。 元々チーム全体で採用を進める文化があったため、いわゆるなペルソナ設定や訴求の設計は一定できていると考え、 まずは最小コストでアウトプットを出して、反応を元に注力していく方向性を定めたいと考え、Techブログに注力することを決めました。 ※もちろん、ペルソナや訴求設計についてもまだまだやりきれる余地はあると思っています。 まずは小さく始める まずは最小コストでアウトプットを出して、反応を元に注力していく方向性を定めたいと考え、Techブログに注力することを決めました。 にもある通り、まずはできるだけコストを抑え走り出していきたいと考えていました。 ここでのコストは、 お金 工数 心理的取り組みコスト の3つを考えています。 要は、お金も手間もかからなくて、さくっと取り組めるものから始めたいという状態です。 そこでまずは、以下を大きく2本柱として取り組むことにしました。 すでに社内向けにあるコンテンツの2次加工 カジュアル面談などでよく話している内容、など何度も話している内容のコンテンツ化 それぞれ、 お金 外部に新たに発注するわけではないので、新規で発生しない 工数 既存のコンテンツや、外部向けに数回話している内容であれば、構成ができているため1から考えなくていいという点で、工数が相対的に小さい 心理的取り組みコスト 外部向けに何度も話している内容をコンテンツ化することで、同じ説明を何度もしなくてよくなるし、候補者の方からしても事前に読めたりするので候補者体験としてもよいというお得イメージが湧くので相対的に低い というように考えたためです。 実際に走り始めてみて、 ブログを執筆しリリースするのは一定心理的/工数的ハードルがあり、こういった書きやすかったり、書きたいとシンプルに思えるものから開始するのがとても大事だな、と振り返って思っています。 実際執筆してみると、難しかったという話は、以下のブログにまとめています💁 プロダクト開発のノウハウを使っていい感じにブログを書く技術 - Speee DEVELOPER BLOG 大きい取り組みを仕込む 小さくブログを書き出すのと併行して、イベントへの登壇など実施するにカロリーが高いがインパクトも一定高いと考えられる取り組みを仕込みます。 今回は Kaigi on Rails 登壇＆スポンサーブース運営 プロ筋conf登壇 などを狙って仕込んでいました。 そもそも自分たちのことを社外の方にまだまだ知ってもらえていないため独自で発信をしても、情報を届けられる範囲が限定的になってしまうと考えていました。 そうなると発信1つ1つの反応も自ずと小さくなり、 まずは最小コストでアウトプットを出して、反応を元に注力していく方向性を定めたい という当初の目的を達成できない可能性が高くなります。 そこで、できるだけ多くの方に見ていただける場所で発信をする必要があり、イベントでの登壇を意思決定しました。 要は、事業やプロダクトの施策と同じく、大通りに施策を投下するということをしたかったという話です。 結果的に、上記の2つのイベントに加えて200～300人の参加登録のあるイベントでの登壇の機会をいただけたりと、想定していたよりも多くの登壇することができました。 そうして、ポジティブもネガティブもいろいろな反応を得ることができ、目的を達成できる状態になりました。 イベントに関わってくださったすべての方に感謝です🙏ありがとうございます！ モメンタムを産み出す ここまでの話は、一般的に考えたり論理的に考えたらそれなりに思いつきそうな作戦だと思います。 結局、それを「絵に書いた餅」にしないこと、徹底して実行する、継続して実行する、というのが難しいポイントですよね、、、、！ 私も、Techブログ運営や広報活動で一番大事なのは、現場のメンバーと一緒に実行をやりきれるか？持続できるか？という点だと考え、この数ヶ月の活動の中で一番重要視していたのが、モメンタムを生み出すことでした。 モメンタムとは、 “Startup survives on momentum” (スタートアップはモメンタムによって生き延びる) とは Y Combinator の Sam Altman による、MIT の講演での発言です（日本語版要約）。ここでのモメンタムは「勢い」と訳せるでしょうか。 引用：スタートアップはモメンタムによって生き延びる シンプルに「この取り組みイケるぞ、！という空気をつくる」と捉えていました。 Techブログはじめ発信活動はすぐに採用成果などわかりやすい成果に繋がりづらく、持続する体力がなくなることで、実行水準が下がり、結果的に成果に結実されない、 というバットシナリオにしたくないなと考えていたため、とにかくここに注力しました🔥 モメンタムを産み出すために重要なのが以下のつだと考え、それぞれに対してアクションを行っていきました。 わかりやすく高い成果が出ている状態 アウトプットに成果を常に感じられる状態にする アウトプットのリズムをつくる 自分が一番の当事者になる ここでの成果は、 ブログを出しているというアウトプットではなく、ブログごとに設定しているゴール を達成できているのか？という点を意図しています。 具体的には、Twitterやはてブのコメントによって確認したり、 1つのわかりやすい指標としてはてブ数やRT数などTwitterでの反応されている量を確認することで、質・量の両面から見ています。 あくまで「採用できたよ！」のような成果を意味していないことをご留意ください。 わかりやすく高い成果が出ている状態 Speeeにははてブで100ブクマを超えると、豪華ランチにいけるという制度があります。 アウトプットをしてそれが多くの人の役に立つと美味しいご飯が食べれる というシンプルで非常にわかりやすくいい制度なのですが、制度はあるものの、約3年半実際に制度が利用されていませんでした。 制度としての認知は一定有りながら、対象になるアウトプットが出ていなかったという背景です。 今回は、この制度をそのまま利用し3年半ぶりに制度を活用する事例をつくるぞ！という気持ちも込めて、制度自体には手を加えずそのまま採用しました！ より該当者が出やすいようにすることも考えたのですが、 「3年半ぶりに該当者がでたぞ！」という状況をつくることがモメンタムを生み出すと考え、そのまま採用するに至りました。 結果、 10月に3年半ぶりに制度を使うことができ、 12月にも+2人の越境者（100ブクマを超えるアウトプットを生み出した者）が生まれ、合計3人の制度活用事例を生み出せました！ そのうち1件は300ブクマを超え、Speeeの過去最高ブクマ数だった262ブクマを大きく更新する事ができました！🎉 どのようにそういったアウトプットを出していったのかはこれと言って特別な工夫はしておらず、 普段から業務の中で行っていることをアウトプットしたというのが事実でして、日々高水準に業務を行ってくれているチームには感謝してもしきれません🙏 いしいさんの登壇おつかれ&スライド100はてブ超え&わたしのkaigi on Rails 運営おつかれ会として大場さんにお寿司ご馳走してもらいました☺️🍣 いえーい🙌 pic.twitter.com/j0njTXiJky — ゆっけ@Speeeのものづくり組織採用の人 (@ykksg728) 2021年11月2日 アウトプットによる成果を常に感じられる状態にする プロダクト開発と同じくリリースしたものがどのように受け取り手の役に立てたのか？という点を素早くフィードバックし、 ブログを書くことでちゃんと成果につながった！という体感をできる状態をつくりました。 具体的には、 TwitterのRTや引用をSlackに垂れ流す 記事をリリース前の記事レビューの際に具体的なレビューだけでなく感想も伝える（元々広報担当の方がそのレベルで手厚くやってくれていた） 結果、レビューのタイミングや、リリース後にSlackで以下の画像の用にワイワイできる空気が生まれ、アウトプットした執筆者が「アウトプットしてみてよかった！楽しい！」と感じられる状態にできたかなと思っています。 ブログへのレビューやSNSの反応をわちゃわちゃしている様子 アウトプットのリズムをつくる スクラムチームでプロダクト開発をしていた際に、 Sprintの中で開発のリズムをつくることで、タイミングタイミングで集中するべき対象に集中できるという点がすごくいいなと思っていました。 もちろんいまも実際に執筆するメンバーは各チームでスクラム開発をしていてリズムを持っています。 そこにいきなりブログを書くという、ある意味「異物」が入ってくることで、彼らがリズムを取りづらくなるのは嫌だなと思い、 毎週1回1時間の「ブログ合宿」という時間を確保し、執筆してもらうメンバーはその時間に一緒にもくもくブログを書く、という新しいリズムをつくることにしました。 また、ブログをつくるというプロセスを分解して進めることで、毎週1回でもすこしずつ進めやすいようにできたのが良かったと感じています。 自分が一番の当事者になる 最後に、自分が一番の当事者になるということをとにかく大事にしました。 具体的には、私自身もブログの執筆や登壇活動を行いました。 また、ブログを執筆するメンバーのレビューの際には、ただレビューするのではなく、一緒にどうしたら届けたい相手に届けたい内容を届けられるかを考えたりしました。 これは、シンプルに「ブログ書いてほしい！」とか「登壇してきてほしい！」とメンバーにお願いをするときに、「実際に実行する大変さ」をわかった上でお願いしたかったからです。 頑張って執筆しているメンバーの傍らで管理表みたいなものとにらめっこしているより、一緒に泥にまみれて苦労もしたいし、なにより楽しみたいと思ってました。 そういう雰囲気のチームからモメンタムは生まれると思っています。（理屈はわかりません。経験則としてそう私が考えているという話です） まとめ つらつらと書いてしまってまとまりのない記事になってしまいました、、、、🙏 しかし、Techブログの取り組みをうまくいかせるためには銀の弾丸はなく、いろいろな取組が絡み合っていい結果を生み出すと思っているので、 それを表現できたかなというとこで良しとしたいと思います！笑 いまの取り組みをブームで終わらせず、文化にしていくためにアウトプットを楽しく続けていきたいと思います！ 🤟 お決まりの Speeeでは一緒にプロダクトを推進してくれる仲間を大募集しています！ 様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ もしSpeeeに興味を持っていただけた方はという方は是非以下のTwitterもしくはMeetyよりお気軽にご連絡ください！🙌 twitter.com meety.net 社内メンバーのカジュアル面談も複数公開しております！💁 tech.speee.jp

※この記事は、Speee Advent Calendar21日目の記事です。 昨日の記事はこちら tech.speee.jp みなさんこんにちは。イエウール事業部マーケティング推進チームの八重樫です。 2021年4月に新卒で入社し、現在は2プロダクトのプロモーション領域を担当しております。 正直、入社してからこの半年は、挫折の連続でした。 この記事では、ベンチャーに新卒で入社したサンプル1として、この半年を通して得た学びや気づきを棚卸しし、近況報告も兼ねて赤裸々に語っていきたいと思います。 特に以下のような方々にとって参考になる部分があれば嬉しいです。 今年の4月にベンチャー入社を控えている22卒内定者 全国で頑張っている21卒同期 何でもできる → 何にもできない 学生時代の自分は、何でも一人でできると思っていました。 具体的な取り組み云々は割愛しますが、それらの経験を武器に、就活でもほぼ落選することなく無事に終えることができました。 そんな自信を持って入社しましたが、入社後は何も結果が出せずにしばらく時間が経ちました。 入社時に任せていただいた半期のミッションは未達。 僕が所属していることで何かが良くなっている実感がまるでありませんでした。 そんな中、学生時代に仲の良かった友人たちが、Facebook等で 「入社初月、初受注しました！」「MVPとして表彰されました」 と投稿しているのを見ると、余計に焦りに駆られました。 あの時同じ時間を過ごしていたのに、どこでそんなに差がついたのかと感じておりました。 紆余曲折の末、手段にこだわりがなくなった 焦れば焦るほど視野狭窄になり、以前よりも独りよがりで自己満足なアウトプットを出すようになりました。 そうなればもちろん成果も出ず、困ってもヘルプを出さないので、周囲の先輩方としてもとても扱いにくい存在だったと今では思います。 また物事を長い目で捉えることができていなかったため、目の前の数値が改善していなければ、全てが駄目だと自分を追い込んでいました。 このままいくと何も上手くいかないままだ。 ただこれまで全部一人でやろうとしてできなかったならこれからもきっと一緒。 だとしたらできないことはできないと認め、周囲の先輩方に助けていただきながら進めていくのが一番得策なのではと考えました。 言い換えれば、これまで散々できないことにぶつかったため、つまらないプライドがなくなり、成果を出すための手段にこだわりがなくなりました。 開き直ってみると、これまでと比較できないほど上手く回り 少しずつ成果も出始めてきて、かなり手ごたえが出るようになっていました。 今年、この流れの中で学んだことは以下の二つです。 仕事は全て自分一人でやる必要はない、むしろ一人でやることを期待されていない 持続的に働き続けるために、スタンスと健康が重要である 以下から具体的に書いていきたいと思います。 ひとつ目：全て自分一人でやる必要はない 一個目の学びは、全て自分一人でやる必要はないと気付けたことです。 そもそも自分一人で進めることを誰も求めてないと思います。 仮に全部一人で完結させる必要があるなら、現在の自分に介在価値はありません。 なぜなら、現在担当している広告運用やCVR改善なら僕より秀でている人は五万といます。 極論、そこだけ切り取った上で得意な人に渡せば、短期的には結果が出ると思います。 ただ、事実そうなっていないのは何故なのか。 それは、仕事に必要なのは能力やスキルだけではないからです。 仮に仕事においてスキルしか必要でないなら、 ポテンシャルを測る新卒採用の仕組み自体が存在しないはずです。 ふたつ目：新卒に必要なのは、スタンスと健康だ この記事で一番伝えたいことでもありますが、二個目の学びは、持続的に活躍するために必要なのは、スタンスと健康しかないことです。 成果を出す上で「これさえできれば問題なし」といった虎の巻的なものは存在しません。 つまり、具体的に〇〇ができるといったハード面だけでなく、その人自身の人間力といったソフト面も仕事をする上では等しく重要だと思います。 誤解を恐れずに言うなら、学生時代に頑張ったこと自体に意味はありません。 学生時代に通用したことは得てして、 学生である、といったプレミアムにより求められる水準が相対的に低い 価値提供の対象が同じ学生であり、やるやらないによる経験値の差が大きい の二つにほとんどの場合区分されると考えております。 ※学生時代の自分は、どちらにも当てはまっていました そのため、スキル云々で突破しようとすると 学生から社会人に変わり、求められる水準が高まる 価値提供の対象が広がり、戦闘力の高いビジネスマンと同じ土俵で戦う必要がある ため、かなり分の悪い勝負をする必要があります。 もちろん、何かをやり切った経験は自信に繋がりますし、その後の人生をより良くするために必要なことだと思います。 ただ、おそらく自らの能力の低さに辟易し、精神的にかなり厳しいことになります。 ここで重要なのは、表題の通り これまでの戦い方に縛られず、柔軟に態度変容できるスタンス 持続的に働き続けることができる、身体的・精神的な健康 だけだと思っています。 良かったことを良かったと認め、改善すべきところは固執せずに素直に変える。 そして、ドロップアウトしないために心身ともに健康に暮らす。 これさえできていれば、遅かれ早かれ結果も付いてくると思いますし、その結果、自分自身の理想に対しても近づいていけるのではないかと感じています。 今後こうしていきたい話 偉そうなことを書いてしまいましたが、自分自身も足りていない部分が多くあります。 それでも、入社時の自分と比較すれば良くなった部分も同様に多くあります。 自分の場合は理想が高いあまり、できていない部分に目がいくため、できるようになった部分をメタ認知することで走り続けることができています。 同じように、これから入社する学生の方も全国で頑張っている同期の方も、自分の特性を理解し、自分に合った働き方を模索してみてください。 あとがき：大学時代、こんなこと書いていた これは余談ですが、今回記事を執筆する上で、学生時代の記事を振り返っていたのですが、ほぼ同じ内容を書いていました。 www.yaegac.com 変わるきっかけになったのは、そこで結果が出なかったから。 どれだけやっても結果がついてこない。それどころか周りに抜かされる。 むしろ周りに流されていただけで、そもそも向いてなかったのかもしれない。 だからぼくは安定を捨てることにした。そこで戦っても勝てないから。 書きぶりがポエム調であることはさておき。 過去に通用していた技が通用しなくなり、その度に自分自身を見つめ直し、あるべき姿に変容していくのは昔から何も変わっていないと気づいたのは大きな収穫です。 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください。 もちろんオープンポジション的に上記に限らず積極採用中です！

※この記事は、Speee Advent Calendar20日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは!22卒エンジニアで現在DX事業本部開発基盤チームで内定者アルバイトをしている角です。この記事ではインフラ未経験だった私がすまいステップのインフラ刷新業務を行う中でTerraformとKubernetesを扱う時に辛かったことと、それを克服した方法について紹介します。 すまいステップは、優良不動産会社に特化した不動産査定サービスです。 sumai-step.com 仕事始める前のスペック データサイエンス学部所属 機械学習完全に理解している(理解してないやつ) atcoder(競技プログラミングのサイト)水 信長の野望と史跡巡りが好き 今回行った業務 今回は、主にKubernetes環境の刷新とステージング環境の増設を行いました。すまいステップのKuberntes環境は2年近く前から更新されておらず、Speeeのサービスの中で最も古いKubernetesクラスタを利用していました。バージョンも2年前のままで、クラスタのバージョンを上げることはとても厳しい状態だったのでクラスタを丸ごと新しいものに置き換えました。また、すまいステップは利用者がどんどん伸びているので今後の開発者の増加を見越してステージング環境が増設しやすくなるようにTerraformの書き換えを行いました。 Terraform 最初触ったときの気持ち Terraformを初めて触った時はマネジメントコンソールでボタンをポチポチするのに比べて抵抗がありました。振り返ると、マネジメントコンソールはTerraformに比べてとっつきやすい理由が2つあると思います。 1つ目はマネジメントコンソールはページを分けることで強制的に問題を分割してくれます。例えばEC2インスタンスの立ち上げでは1ページ目にマシンイメージの設定、2ページ目にインスタンスタイプの設定、3ページ目にネットワークの設定とあり、それぞれの問題をページごとに切り替えて考えることができます。対してTerraformは一つの画面に全ての設定を一度に全て書き出さなければいけないため、どこから書き始めるとうまくいくのか全くわかりませんでした。 2つ目はマネジメントコンソールは設定の画面の中に説明が一緒に書いてあることです。初心者の私にとって操作をする場所と説明が書いてある場所が近く、使い方をいちいち調べなくてもとりあえずできるという点は魅力的でした。一方、TerraformではどのArgumentがあるのかそれぞれどの役割を持っているのかは公式ドキュメントを見にいかなければ書いていません。さらに、それぞれのリソースにはArgumentに加えてAttributeがあり、役割を知らずに混乱したこともあります。特にcloudfrontのドキュメントは複雑で最初に見たときは軽く絶望しかけました。 とっかかりをつかんだきっかけ 何度もリソースの作成に失敗する中でArgumentがRequiredなのかOptionalなのか、top-levelなのかそうでないのかなどArgumentの中でも種類があることがわかりました。また、Terraformのドキュメントでは理解できない場合は対応するAPIのドキュメントを参照すれば良いことがわかりました。ドキュメントの読み方を理解したことで景色が一変しました。ドキュメントの読み方がわかることでそれぞれの設定の役割を認識でき、一つ一つの設定を独立に考えることができるようになりました。動かすことよりもまずはドキュメントの解読に全力を注ぐのが最短距離だと感じます。 より成長するために意識したこと 手元のコードとstateファイル、現実のリソースの三者の差分を意識することでより多くの選択肢を取れるようになりました。特にTerraformでリソースの論理的な移動を行う際にはstateファイルを意識することでよりスムーズに作業できるようになり、トラブルが発生した際にも柔軟な対応が取れるようになりました。 Kubernetes 最初触ったときの気持ち ドキュメント読んでも意味わかんないしチュートリアルやっても意味わかんないしとにかく何もわかりませんでした。とにかくドキュメント見ても出てくる単語の意味がわからないので全く理解が進みませんでした。どこを自分で操作するべきところで、どこは力を入れなくていいのか全く強弱をつけられませんでした。 とっかかりをつかんだきっかけ service、deployment、pod の関係を簡単に説明してあるブログを見つけたことで道が開けました。 Kubernetes道場 8日目 - ReplicaSet / Deploymentについて - Toku's Blog そのブログは図が多用されていてとてもわかりやすく書かれていました。それぞれのリソースの全体での立ち位置を把握できたことにより、公式のドキュメントも部分的ですが理解ができるようになりました。この三つのリソースはKubernetesでサービスを公開するにはほぼ必須なだけに知らないと何も進まないなと感じました。実際、この三つのリソースを軸にして周辺の機能を調べることで理解を深められるようになリました。 より成長するために意識したこと KubernetesはTerraformに比べて必要な情報量が格段に多くドキュメントを頭から読んでいくのは非効率的だと感じました。そこで、ドキュメントではなく実際にSpeeeで運用されているサービスのマニフェストファイルを読むことにしました。Speeeのサービスのマニフェストは軸になっている部分は似ているところが多いですが周辺機能はサービスごとに違っているので、それまでの学習で理解した部分を軸に新しい知識を増やすにはうってつけで、少しずつ理解していきました。 最後に 今回担当した仕事はSpeeeでアルバイトを始めてから初めてのプロダクトに直結する仕事でした。また、TerraformやKubernetesの他にも様々な新しい経験をしました。特に本番のシステムを切り替える瞬間はこの上ない緊張感がありました。 今後もバリバリ活躍している先輩エンジニアの技術を吸収しながらつよつよを目指して頑張りたいと思います。最後まで読んでいただきありがとうございます。 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちら チェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar19日目の記事です。 昨日の記事はこちらtech.speee.jp こんにちは！ デジタルトランスフォーメーション(DX)事業本部エンジニアの岡田です。 Speeeでは、クリアコードの須藤さんにOSS活動をサポートしてもらっています。 今回、OSS活動はほぼ未経験の自分が、どのように挑戦したかを書いてみました。 最初はチャットでの相談から入り、現在もサポプロを使って勉強しています。 OSS 活動に挑戦した背景 自分は、プログラミングを社会人から始めて、特に体系だった知識をもたないまま、業務で必要なスキルを都度都度勉強してきました。 結果、WEB開発という文脈であれば、フロントエンドも、サーバーサイドも、クラウド周りもある程度は一人で実装できるようになりました。 一方で、まだまだ技術の話で分かってないことが多いなと感じており、特にライブラリ周りはただ使わせてもらうだけで、どう作られてるのかを詳しく知りたかったので、勉強したい！という気軽な気持ちで挑戦しました。 OSS Gateに参加 まず、Speeeと須藤さんで開催されている「OSS Gateミートアップ for Red Data Tools」というイベントに参加しました。 speee.connpass.com Red Data Toolsについて、詳しくはこちら！ Red Data Tools - Rubyでデータ処理！ 下のチャットで、わからないことを日本語で質問しながら作業できるので、安心でした！ red-data-tools/ja - Gitter Red Datasets にデータセット追加 須藤さんより、まずは簡単なものとして、Red Datasets にデータを追加することを提案頂いたので、まずはこちらに取り掛かりました。 こちらから自分の好きなIssueを探し、他のPRを参考にしながら、実装を行います。 github.com こちらは、須藤さんに環境構築方法や、わからないことをチャットから質問して、あっさり終わらせることができました！ Red Arrow の開発ドキュメントを追加 次に、Rubyで作られたGemを実際に修正してみたかったので、須藤さんに相談したところ、Red Arrowへの機能追加を提案いただきました！ で、早速やろうとしたのですが、Macでうまく動かずつまづきました... 須藤さんに相談しながら、上手く修正できたので、次行われる方のために、ドキュメント追加を行いました。 github.com Red Arrow の slice が、hashを受け取るようにする 環境構築ができたので、早速 Red Arrow への機能追加に取り掛かりました。 github.com 既に、table.slice(1..8) というように、rangeを渡した時は、その値でIDが絞り込まれるように実装されていました。 今回は、table.slice(count: 1..8) のように、カラムを指定して、絞り込みをする機能を追加するのがゴールとなります。 ハマったこと（学んだこと） Rangeの最後の値を確認する方法がわからない { count: 8.. } としたときに、最後の値がendlessになるかをテストしたかったです。 Range#lastを使って比較しようとしましたが、cannot get the last element of endless range というエラーが起きてしまいました。 最終的に、Range#endを使うと問題なくできました。 こちらが endの実装で、 static VALUE range_end(VALUE range) { return RANGE_END(range); } こちらがlastの実装（引数がない時はendと同じ挙動だけど、引数渡すと挙動が変わる） static VALUE range_last(int argc, VALUE *argv, VALUE range) { VALUE b, e; if (NIL_P(RANGE_END(range))) { rb_raise(rb_eRangeError, "cannot get the last element of endless range"); } if (argc == 0) return RANGE_END(range); b = RANGE_BEG(range); e = RANGE_END(range); if (RB_INTEGER_TYPE_P(b) && RB_INTEGER_TYPE_P(e) && RB_LIKELY(rb_method_basic_definition_p(rb_cRange, idEach))) { return rb_int_range_last(argc, argv, range); } return rb_ary_last(argc, argv, rb_Array(range)); } という二つの差を理解していなかったのが原因でした。 Rubyの実装を見る機会が今まで特になかったので、とても勉強になりました。 複数条件での絞り込み方法がわからない table.slice(count: ..8, name: 'okadak')というように複数で絞り込みを可能にしたかったです。 Arrow::Table は簡単にいうと、表形式のCSVのデータが入ってるイメージに近くて、今回はCSVのheaderの値を指定して、その列の値でフィルタリングしたいという感じです。 須藤さんに教えてもらったところ、こんな感じに動けばいいことが分かりました。 slicers = [] conditions = [] slicer = Arrow::Slicer.new(table) conditions << (slicer[:count] >= 8) conditions << (slicer[:name] == 'okadak') slicers << conditions.inject(:&) # 省略: slicersを用いて、filterする このメソッドの中身に関しては、まず、slicer[:count] >= 8これを実行すると、「[]」メソッドが実行されます。 def [](column_name) column = @table[column_name] return nil if column.nil? ColumnCondition.new(column) end これが実行されると、Arrow::Tableの「[]」メソッドを実行します。 def [](selector) case selector ... else find_column(selector) end end def find_column(name_or_index) case name_or_index when String, Symbol name = name_or_index.to_s index = schema.get_field_index(name) return nil if index == -1 Column.new(self, index) .... end Arrow::Columnが以下のように初期化され、 def initialize(container, index) @container = container # Arrow::Table が入る @index = index # 何列目の値を指定してるか @field = @container.schema[@index] @data = @container.get_column_data(@index) end この値を使って、Arrow::Slicer::ColumnConditionが初期化されます。 なので、slicer[:count]は、Arrow::Slicer::ColumnCondition.new(Arrow::Column.new)を返すようになります。 よって、Arrow::Slicer::ColumnCondition.new >= 8となるので、Arrow::Slicer::ColumnConditionの 「>=」メソッドが引数「8」で実行され、Arrow::Slicer::ColumnCondition::GreaterEqualConditionが返ります。 def >=(value) GreaterEqualCondition.new(@column, value) end このArrow::Slicer::ColumnCondition::GreaterEqualConditionは、Arrow::Slicer::Conditionを継承していて、conditions.inject(:&)のように実行すると、「&」メソッドが実行され、Arrow::Slicer::Condition::AndConditionが返されます。 def &(condition) AndCondition.new(self, condition) end class LogicalCondition < Condition def initialize(condition1, condition2) @condition1 = condition1 @condition2 = condition2 end def evaluate function.execute([@condition1.evaluate, @condition2.evaluate]).value end end class AndCondition < LogicalCondition private def function Function.find("and") end end このArrow::Slicer::Condition::AndConditionは、Arrow::Slicer::LogicalConditionを継承しており、LogicalConditionは複数のArrow::Slicer::Conditionを保持できるようになっているので、このArrow::Slicer::Conditionを使って、複数条件の絞り込みが可能になりました。 （Filter側の処理は今回修正していないので、説明を省略します。） 最終的には、こちらのようなコードになりました。 「slicer[:count] >= 8」みたいなコードを特に意識せずに使えるのは、誰かが裏で綺麗に設計してくれていたからなんだなと、すごく勉強になりました！ Part2へ... 今はこちらの実装をしてます！ github.com まだ終わってないので、次回も続きを書きたいと思います！ 終わりに このようにクリアコードの須藤さんに教えてもらいながら、OSS活動をしはじめています！ tech.speee.jp 現在はサポプロを使ってやっているわけですが、C++ の書き方や、コードの意図など、分からないことを丁寧に説明してくださるのでとても勉強になっています。 また、OSS活動を始めてから、Rubyのライブラリやドキュメントを読む力が上がっている感覚があり、困った時の解決速度が実際に上がりました。 何より、初めて知ることが多くてとても楽しいです！プログラミングについて、まだまだ勉強できることがたくさんあるなと感じています。 今後もエンジニアとしてのスキルをもっと上げていきながら、OSSコミュニティへ貢献できたらと思います！ Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ 読んでいただきありがとうございました！

※この記事は、Speee Advent Calendar 18日目の記事です。昨日の記事はこちら tech.speee.jp はじめに 背景 移行方針 どう移行したのか 実装 1.新しい機能をRubyで実装 2.一部機能を段階的に移行 3.メイン機能の移行 検証方法 うまくいかなかったこと 最後に、学びとか はじめに はじめまして、 Speee のDX事業部所属エンジニアの 渡邊 です。 Speee には昨年の12月に入社をして、気づけばもう1年がたっていました。今回が初めての DEVELOPER BLOG への投稿になります。 今回はJavaで実装されていたイエウールの請求周りのシステムをRubyでリニューアルした話についてご紹介します。 背景 2014年リリース当初のイエウールはPHPとJavaで実装されておりRubyに全面リニューアルされた現在でも社内向け管理ツールの特定の機能等、一部のシステムでは当時の実装が残っているものがあります。 今回ご紹介するシステムもそのうちの一つです。遡ってみると約7年ほど前の2014年3月に一番最初のコードがcommitされており、言語はJavaで実装されていました。 とはいえコードが古いことやJavaで実装されていること自体が問題になっていたのではなく、 実装当時の仕様やコンテキストを知るメンバーがいなくなってしまっている 当時のエンジニアと現在のエンジニア採用では重視するスキルが異なるため、普段の業務であまり利用しない言語で実装されたシステムの改修や機能追加を気軽に行えない などなど、ソフトウェアとしての コントローラビリティ を失ってしまっていたことが課題となっていました。 自分をはじめ、当時のことを知らないエンジニアにとって、あまり慣れていない言語で実装された仕様が分からないシステムは「蓋を開けたくないもの」として敬遠しがちな状態になっていました。 移行方針 今のエンジニアメンバーが慣れ親しんでいる言語(Ruby)で実装する 今までの継ぎ足し継ぎ足しの運用と実装で生まれた技術的な負債を解消する 事業部の各プロダクトに存在する請求周りの共通処理をgem化する 今回の大きな目的の1つがシステムのコントローラビリティを取り戻すことなので、言語はRubyを使い、ただ移行するだけでなく長年の運用と実装で生まれた技術的な負債等の改修・改善も同時に行うことにしました。 どう移行したのか 実装 上述のように今回は単純にJavaのコードをRubyに置き換えただけではなく、事業部共通の処理部分のgem化をしたり、これまでのシステムでは対応できなかったイレギュラーな請求にもシステムで対応可能にしたり、イエウールのオプションサービスの課金に対応するよう新しく実装したり、細かい改修・改善も多々行いました。 そのため、下記のように段階を分けて各フェーズごとにスケジュールをきり、可能な限りビッグバンリリースにならないように進めていきました。 1.新しい機能をRubyで実装 このフェーズではJavaのシステムには手を加えておらず、データの整合性が保たれるように新しい機能をRubyで実装しています。 ここで実装した新しい機能群はJavaのシステムで作成/更新されるデータが存在することを前提にしているため、今まで通りJavaのシステムで処理が実行されたあとに、今回実装したシステムを実行するような運用フローになりました。 2.一部機能を段階的に移行 このフェーズから段階的にJavaで実装されていた機能をRubyに移していきました。 システムの要となる金額の計算や複雑な請求のステータス更新処理の役割はこれまで通りJavaのシステムで担当してもらいつつ、社内の売上管理ツールへの連携や請求書発行処理等の分離できそうな部分からRubyに移行しました。 共通部分のgemもこのフェーズから本格的に運用がスタートしています。 3.メイン機能の移行 最後にメインとなる機能を移行して実装自体は完了です。可能な限りJavaのテストコードをRSpecに移していくようなこともこのフェーズで実施しました。 検証方法 今回の移行に関して一番大変だったのは新しいシステムにバグがないかを検証することでした。 データ構造的に毎月の請求締め処理を実行する時点でのデータでないと算出される金額に差分がでて正しく検証ができないため、特定時点のdumpデータを2つの検証環境にインポートして新旧システムでそれぞれ処理を実行し、2つのシステムで算出された金額や更新されたデータに差分がないかをチェックするという方法で検証していきました。 このdumpデータが非常に重く、検証用のDBにインポートするだけでも割と待ち時間が発生し、さらに請求システムの実行にもそれなりに時間がかかるため、毎回検証するための環境を用意するだけで一苦労でした。 金額やデータの差分チェックもある程度自動化はしていましたが、データ量が多いため非常に大変でした。 うまくいかなかったこと ここまでざっと実施したことを短くまとめて書きましたが、実際の移行には長い期間がかかっており、特に請求周りのシステムには高い堅牢性が求められるため神経を使うことが多かったです。 途中でプロジェクトの一時停止やメンバーの入れ替わり等もありましたが、Javaの機能を移行し始めてからでも5,6ヶ月ほどはかかっていたと思います。 また、当然不具合なしで進んだということもなく、考慮漏れや細かいバグの修正と検証を何度も何度も繰り返してきました。 特に本番に向けた作業においては、何か不具合が起きたときにどう対処/リカバリーするのかを漏れなく想定して動くのが非常に大切だと身にしみてわかりました。 また、今までの継ぎ足し継ぎ足しの運用で生まれた技術的な負債の全てを解消するには時間がかかりすぎるため、計画していたスケジュールに収まるように、泣く泣くスコープを縮小する判断も何度かしています。 最後に、学びとか 最後に、年末らしくこのプロジェクトを漢字1文字で表すと...「難」でした。 というのも、最初は仕様が分からないといっても動いているコードは存在しているわけなので、旧システムのコードを注意深くリーディングしていけば移行できるだろうと軽く考えていました。 蓋を開けてみると想像以上に属人化している部分や、なぜそうなっているのか、今も使われている機能なのか、判断するのが難しい部分が少なくありませんでした。 実際に運用していくフェーズはまだまだこれからですが、いつかこの大変だった移行プロジェクトの恩恵を受けられると信じています！ また、当たり前のことかもしれませんが、このプロジェクトを通して、エンジニアの技術的なスキルアップが「新しいモダンな技術をガンガン使い倒してドヤれるようになる」ことだけではないと改めて再認識できたので非常によい学びの機会となりました。 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar17日目の記事です。 こんにちは、Speeeの八木です。 8月に入社して新規事業でエンジニアをやっています。 エンジニアとしては4年目になるのですが、これまで特にブログやイベント登壇などでアウトプットをしたことがなく、社外で自発的な活動をあまりしてきませんでした。 しかし、重い腰を上げつつ登壇してみた結果、今はやってよかったなと思っています。 そんなわけで今回は、社外イベントなどで登壇してみたいと思っているけど、やっぱりやりたくないと思っているめんどくさがりやの皆さんが少しでも自分も一回くらいやってみようかなと思ってくれたらいいなと思ったので、この記事を書くことにしました！ 登壇のハードルは登壇をするという意思決定を超えるところから もちろん登壇するメリットってたくさんあるのもわかっているし、優秀な方は登壇している人も多いのでまずはやってみようと思っている人はたくさんいると思います。 ですが、僕だけではなく多くの人が勉強会で登壇することに対して心理的なハードルをかなり高く感じるのではないかと思います。 僕の場合は 通常業務で精一杯で、やるとしても個人で+αの時間を作らないといけない。それを登壇の準備するくらいなら興味あるもの勉強した方がいい。 やってみようと思って、資料作っては見るけどなぜ知らない人に頑張って時間作って登壇するんだ？資料作って理解できたし登壇まではいいか。 そんなに自分がやったことで特別なことはないから、登壇しなくていいか。 という風に思っていたので、登壇は当分はいいかなと思っていました。 ただ、今回はこの勉強会出てみない？というお声掛けをいただけき、レビューなどのサポートもしていただけると言っていただいたので、この機会を逃すと僕は一生登壇しないだろうという思いから登壇することに決めました！ 登壇も開発と同じようにレビューしてもらって登壇直前に自信を持てた！ 登壇するって言っちゃったし準備しないとな〜と思いつつ、登壇日の5日前くらいまでは、頭で登壇内容を考えつつも資料を作ったりはせず、人前に出るのやだなとか、考えた内容に対してそもそもこれを聞きたい人がいるのか？と自問自答し続けて、全く前向きに準備できなかったです。 やりますとは言ったものの、人間そう簡単に変わるわけもなく自分が決めた内容に意味も見出せずに、登壇日が近づくのを震えて待っているところで、先輩に登壇内容をレビューしてもらう機会をいただいたことで前向きに登壇することができました！ 具体的にはレビューをもらったことで、 価値提供できるイメージが湧いた レビュー時に何を伝えたいんだっけ？と聞いてもらうことで、自分が一番伝えたいことが、明らかになってどういうターゲットに刺さりそうかが明らかになりました。 登壇内容がシャープになった 自分の登壇内容のどこが価値なのかを理解したので、色々詰め込んでいた登壇内容がブラッシュアップされてシャープになりました。 登壇することに対して自信がもてた 自分の登壇内容の良い部分、良くなった部分を褒めてもらうことで自信が持てるようになりました。 という効果が得られ、そもそもこれ聞きたい人がいるのか？とか人前で喋るの自信ないなみたいなことがなくなり、登壇前も登壇も自信を持って行うことができました！ また、登壇が終わってから気がついたのですが、反響がよかったり、質問してもらえたりしても自分の登壇自体の良し悪しの評価は明確にいただけるものではないので、レビューをいただけなければ気がつけなかったと思っています。 まとめ 今回の登壇を通して、登壇自体をしたこと自体においても、自分の学びが整理されたり、登壇内容きっかけで外部の方から知見を吸収できたり、登壇したという事実自体が積み上げられたりといいことがたくさんありました。 しかし、そんなメリットがやる前からなんとなくわかっていても、人によって登壇をすること自体にいろんなハードルがあって、特に個人でやるとそのハードルを乗り越えられない方も僕を含めて少なくないのではないかと思っています。 僕は自分の登壇内容に対して、レビューしていただくことで心理的ハードルも下がり、個人で完結させていたら得られないような体験をすることができました。 また、登壇自体の反響も良かったので、レビューをもらってから登壇しきるまでを自分の中で成功体験として消化できたのが何よりも良かったです。 自分のチームや周りの人が登壇する、しようとしている時はレビューをしてもらったり、してあげたりするのが良いのではないかと思っています。 最後に 僕自身学んだことをいろんな形でアウトプットしてみようという取り組みをしており、登壇だけでなく、ブログを書いてみたりしたんですが、どちらもプロダクト開発と同じように一貫性を確認しながら作成していくことで、生産性が高く得られるものも大きい、効果が高いアウトプットになるなと感じました！ そんなプロセスをまとめてくれている記事もあるので気になった方はこちらのプロダクト開発のノウハウを使っていい感じにブログを書く技術 - Speee DEVELOPER BLOGという記事もあるのでも是非チェックしてみてください！ また、先日登壇したスライドもよかったら見てみてください。 speakerdeck.com Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで仲間を募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ 

※この記事は、Speee Advent Calendar16日目の記事です。 昨日の記事はこちら tech.speee.jp 2019年11月に，外壁塗装業者紹介サービス「ヌリカエ」の開発チームにjoinした竹井です。 もう入社してから2年になります! 吃驚しました! 突然ですが!! 皆さんは，普段どのようなデスクで働いているでしょうか!? 業務効率を求めて何かカスタマイズしているのか。癒しを求めカスタマイズしているのか。 作業スペースってとっても大切ですよね。 私は結構作業スペースに自由度の高さを求めるタイプなのですが，Speeeのエンジニアってどういうデスクで働いているのか，気になったりはしませんでしょうか!? 私は気になります! と，言うことで突然ではありますが今回は，実際にSpeeeで活躍しているエンジニアのデスクまわりを一部お見せしたいと思います! No.1 竹井 No.2 西田 No.3 秋吉 全景 入力機器 業務必需品 No.4 酒井 まとめ No.1 竹井 まずは私から。 はい。ざっくりとこんな感じです。 典型的なオタクの匂いをぷんぷんと感じますね。 それぞれのフィギュアの紹介は控えます。 この記事はアニメキャラクターの紹介記事ではないので。 ただ，非常に多くのフィギュアを置かせて頂いております! (7体) 少し変わったところで言うと，ちょっとしたボードゲームがデスクに置いてあります。 こちらは一声かければ基本的には誰にでも貸し出しているもので，新規入社さんが来たときなどにオンボーディングでよく使って頂いているボードゲームです。 今回はそれぞれの詳細な紹介は控えますが，どれも誰とでも，手軽に簡単に遊べるものをチョイスして置いています。 社内の知り合いとわいわい盛り上がるというよりは，新入社員など，まだお互いの性格や人柄がハッキリしていない人がいても楽しめるゲームになっています。 どれもオススメですので，オンボーディングでお困りの方は是非一度遊んでみて下さい! デスク右側に置いてある小物は， こちらの記事の執筆にもご協力頂いている西田さんに作って頂いた，GitHubの活動草を3Dプリンタで出力したもの。や， こちらも記事の執筆にご協力頂いている秋吉さんに作って頂いた，R6SのFrostが使うフロストマットを3Dプリンターで出力したもの。や， (秋吉さんとはよく一緒にR6Sを遊ばせて頂いています) メカニカルキーボード好きがいれば社内に1つはあるであろうキーテスターや Github公式が販売しているコースターなどがあります。 コースターはGithubで買ったら「このナイスなコースターを皆で是非使ってくれぃ」的なメッセージと共に予想外に沢山頂いたので，複数枚持って来ていて欲しい方にはお渡ししています。 (近くのよく行く飲み屋さんにもいくつか置かせて頂いていたり) で，お次はキーボードについてです。 今メインで使っているキーボードはRazer BLACKWIDOW V3 MINI HYPERSPEED - Phantom Pudding Edition Yellow Switch USです。 Razerというのは会社名で，Razerはゲーミングキーボード，マウス，最近だとヘッドフォンやマイクなどのPC周辺機器から，PC本体やノートパソコン，チェアまで幅広く商品を取り扱っています。どれもゲーミング用品として販売していて，キラキラ光っているイメージがあると思います。まぁあながち間違いではないです。 何故ゲーミング用品を仕事で使っているのかと言うと，一部のゲームでは早く，正確な操作が求めれ，できるだけ疲労などのパフォーマンスが落ちる要因を取り除きながら長時間プレイすることあり，そんなハードな環境向けに作られた物であれば，別にゲーム以外で使ってもメリットがあると思っているからです! 業務でも疲れにくく，早く，正確に操作を行って生産率を向上させ，早く帰ることができればもっとゲームができるじゃないか!! ということで，会社でもゲーミング用品を使わせて頂いています。 ただ，キラキラと光らせたりする部分は業務上無くっても良いように思いますよね。わかります。 でも，そのライティングもテンションを上げてくれるのであれば取り入れる余地はあります。 うおーっ!って集中してガーッとコードを書いている時なんて音楽にノリノリになりながらガンガン仕事進めていたりしますもんね。そのテンションアップのためのライティングなら良いと思います。近くの方の迷惑にならないライティングであれば。 使っているマウスもRazer製のもの。 Razer DEATHADDERV2を使っています。 家ではRazer DEATHADDERV2 PROになります。 こちらの選定理由もキーボードと同じで，もちろん，業務の効率化を目指しているからです!! ……と，普通に家でゲームをするときに長時間使用するデバイスでもあるので，やっぱり手に馴染んでいるし，逆に言えば平日も同じものを使ってそのまま手に馴染ませたままにしておきたいのです。 その他の環境で言うと，4Kのモニターを2枚使用しています。幅を1人で取り過ぎなのでは?と思われる方もいるかもしれません。 エンジニアで4Kの，しかもこれだけのサイズのモニターを2枚も使っているエンジニアは社内でもなかなかに珍しいです。 入社の際にアンケートでディスプレイの仕様を選択するのですがその時に「え! 4K選べるの! すごい! じゃあ4K!!」って選んじゃいました。赤ちゃんかよ。 で，入社したらデザイナー以外で4K選択してる人はいないよって聞いて吃驚しました。 まぁ，そうですよね。必要かと言われると微妙なラインではあります。 No.2 西田 ここからDX事業本部開発基盤グループの西田が書きます。 僕のデスク全景です。基本的に物が多くて汚いです。特にUSBケーブルで大量のデバイスを繋いでいるためUSBケーブルが絶望的にごちゃついています。 ここは3Dプリンタで印刷したものを飾っています。 うちの立体造形のベンチマークであるGitHubの草です。これは最新バージョンでスプレー着色したもの。境界線が綺麗でないのが改善点です。 自作キーボードカレンダーです。2022年分もそろそろ遊舎工房で発売される頃ですね。 Speeeカルチャーが書かれたスタンドと1ヶ月前に頂いたカルチャー賞のトロフィー。 これはうちのMacBookを建てるためのスタンドです。ご覧の通りデスクに物が多くMacBookを平置きするスペースがないので非常に便利です。 実は文房具集めるのも趣味で、会社には一部ですが持ってきています。 最近のお気に入りはuni ball one Fとエナージェル限定ブラックカラーズコレクション(一番左の2本)。 会社で常用しているErgodox Ezです。 以前使っていたbat43は今キーマップ調整中です。 マウスは定番のLogicool M570。もう8年ぐらい使っており、壊しては買い壊しては買いで累計8台ぐらい使っています(これは会社では2台目)。 僕はデスクではmacbookを閉じているので、USBでこのwebカメラを付けています。 別でwebカメラを置く利点としては、カメラを置きたい場所が自由になる、輝度・高さが違うmacbookのディスプレイと他のディスプレイを同時使用しなくて良い、などがあります。 プロジェクトペーパー。僕はかなり図を書くことを重要視しているので結構使います。 これは会社では3冊目です。 22卒内定者で今リモートアルバイトをしてくれているSくんが映った専用PC。勤務中は常時映っており、逆にチームメンバーも全員常にzoomへ入っていることでお互いの顔が常に見えるようにしています。 この場所は通称バーチャルSくんと呼ばれて擬似的にSくんが存在しているように見せています。将来はペッパーくんを使ってよりリアルさを出していきたいです(時期未定)。 先程のPCに接続されたスピーカーフォン。これが常時こちらの音声を常に向こうへ伝え、逆にSくんの声もここから常時聞こえます。 エンジニアは入社時に5種類以上の椅子から好きなものを選べるのですが、僕はContessaを使っています。 デスクをまとめるために使っている追加の引き出しです。 No.3 秋吉 DX事業部 開発基盤グループの秋吉です。Symphony X と名取さなさんを応援しています。 全景 こんな感じです。 ディスプレイはフルHDのものを2枚とMacBook Proのディスプレイの計3枚で作業をしています。MacBook ProはPCスタンド(AliExpressで1500円くらい)を使用して、隣のディスプレイとの高さを合わせています。 軟弱エンジニアである私が開発するためには常に何かを調べながら作業する必要があります。そのため、基本的にはターミナルとChromeでそれぞれ1枚ずつ使用しています。 また、社内でのコミュニケーションツールとしてSlackを使用しているため、MacBook Proのディスプレイに常に表示するようにしています。 入力機器 キーボード 本体: CorneCherry V3 自作キーボード キースイッチ: Zilent V2 (62g) タクタイル感のある静音スイッチ キーキャップ: Aliexpress で購入した安価なやつ GMK Dots 2 を注文中 トラックパッド Magic Trackpad 入力機器のこだわりポイントとしては、やはり左右分離型の40％キーボードである CorneCherry V3 です。かっこいいですね。 このキーボードは手をホームポジションからほとんど動かすこと無く全てのキーを押すことができます。さらに、左右分離型であるため、長時間同じ姿勢で作業をするときの負担を最小限に抑えることができます。また、トラックパッドを中央に配置することで、左右のキーボードの距離を稼いでいます。 業務必需品 名取さな【立体ヌォンタート！】 名取さな【立体ヌォンタート！】 ラーメンカレンダー (この写真には写っていませんが、)前年に行ったラーメン(主に二郎系)の画像でカレンダーをOKURUのサービスを利用して毎年作っています オタク丸出しですね。しかし、モチベーションを維持するための業務必需品だと思っています。気持ちが沈んでいては効率的な開発を行うことはできません。ありがとう、名取。 それではおつかれさな〜 No.4 酒井 イエウール事業部の酒井（@ryo_touch）です。非エンジニアですが書かせてもらいます。 ガジェット構成 モニタ2枚 クラムシェルにして2ヶ月くらいが経ちました キーボード：logicool MX Keys 要らんやろと思ってたテンキー、意外と使う F1キーは外しています マウス：logicool MX Master3 ペンタブ：Wacom Intuos マウス代わりに利用します 絵は描かないですが、ちょくちょく文字を書きます ウェブカメラ：logocool C505 zoomでのMTGが増えてきたので購入しました 文房具 プロジェクトペーパー Vコーン（青/赤） ジェットストリーム（黒） 構成自体はよくある構成ですが、クラムシェルやペンタブ利用は社内の非エンジニアではマイノリティなほうです。 マウスとキーボードを自分で買ってるひとも見るには見るけど半分もいってないのでは？と思います。 マウスの使い分けについては、基本キーボードでなんとかしたい、そうでなければペンタブつかう、ほんの少しずらすときはマウス、という具合です。 紙とペン派で、プロジェクトペーパー+Vコーン+ジェットストリームは5年くらい構成が変わりません こだわりポイントは、3つあります。 モニタの高さを合わせるためにジャンプを2冊積んでいます（まだ足りてないw） ケーブル類は机の隠すところに押し込んでいるので、必要最小限のケーブル露出にしています 先輩から誕プレをいただき、11月からバランスボールを導入しました。いまのところ快適ですが、姿勢改善への寄与度は怪しいです。 GitHubの草は、西田さん（@k_bigweel ）さんに3Dプリンタ+塗装で作っていただきました。 わたしが設定を間違えてpublic repository分のみの出力にしたため、アカウントつくってから何もしてないひとになってしまいましたw 今後の展望 ブックエンドみたいなものを買って、ラップトップを立ててスペースを作りたい ジャンプを買い足して、モニタの高さを揃えたい（わたしは単行本派） プロジェクトペーパーの買い置き まとめ いかがでしたでしょうか!? 今回は実際にSpeeeで働くエンジニアのデスク，使っているデバイスなんかをご紹介しました! 個人的には，デスクに好きな物を置けたりするかどうか，入社する際に確認をしたりするタイプの人間なので (Speeeでも面接の時の質疑応答でフィギュアを置けるか確認した) ，こうやって実際に働いている人のデスクを見れるの，嬉しいなと思い記事にしてみました! もしも，こういうデスクに拘っちゃうの，わかる〜!って方や，もっと詳細訊きたいよ〜!と言う方が入れば，↓のリンクより実際にお話を聞くこともできるので是非ご確認下さい! Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar15日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは、イエウールのPdM（プロダクトマネージャー）の嶋です。 あと嶋稟太郎という名前で短歌をやっています。 突然ですが、 開発チームへの問い合わせが多すぎて困っていませんか？ プロダクト開発を続ける上で、改善要望や不具合調査のような「問い合わせ対応」は避けられないものです。しかし問い合わせ対応ばかりでは本来開発したいものが遅れてしまい事業の成長スピードも遅くなってしまいます。このトレードオフとどう向きあったか、最近１年の学びを書いていきます。 どんな人向け？ オペレーションが複雑なサービスや、複数の開発プロジェクトが並行するフェイズのプロダクトマネジメントに関わっている方に読んでいただきたいです。 一般的な話と弊社の体制① 「問い合わせ」に含まれるもの 問い合わせには障害対応の依頼のほか、営業がクライアントの要望を吸い上げてあげてくれたもの、マーケティング施策のためにちょっと開発して欲しい、といった社内外からの要望も「開発チームへの問い合わせ」としています。 このうち、障害対応のような緊急度が高いものは”やる”判断が簡単です。判断が難しいのは機能の改善要望のような「やった方が良さそうなもの」です。重要度と緊急度のマトリクスでいう左の象限にあたります。問い合わせを一つずつ「やるorやらない」の精査をするのは大変なので、ざっとPdM（私）が内容を見て重要度が高そうな順に対応するようにしていました。 ”問い合わせ”のマトリクス 一般的な話と弊社の体制② エンジニア個人に調査や改修を直接依頼してしまうと、誰がどの問い合わせに対応しているか分からなくなったり、最適なメンバーのアサインができずに対応に時間がかかってしまう問題が起こります。 この問題に対して、DX事業部では４年ほど前から個人に問い合わせが行かないように仕組みで解決を図っていました。 具体的には、開発チームへの問い合わせ用のgoogleフォームを用意し、入力された内容や選択肢に合わせてslackの問い合わせ対応チャネルで適切な関係者に通知すると言うシンプルなものです。 この仕組みは社内にも浸透しており運用できていたのですが…… 問題が起こった 問い合わせが多すぎる！！ 改善の要望が上がることは健全な状態です。ただ、当時のイエウールは新規の開発プロジェクトが増えてきたタイミングで、各所から機能の改善要望が来るようになっていました。 問い合わせ対応はPdMと複数名のエンジニアでさばいていましたが、問い合わせの頻度が多すぎて他のプロジェクトの作業が中断されてしまい、重要度の高い開発に集中しにくい状態となりました。 考えたこと エンジニアの負担を減らすぞ！！ どうした まずは「重要度がよくわからない問い合わせ対応」を工数の大きさで分類して特徴を見ました。 ざっくりいうとこんな感じ。 大　問い合わせ対応の範疇を超えておりプロジェクト化すべきもの 中　依頼者の問い合わせに書かれた内容だけでは仕様が決められないもの 小　軽微な修正 このうち特に「中」の量が多く、大きな負担になっていたので、早く開発できるように詳細な要求を書く と決めました。要求を一度見ただけで理解できるようにドキュメントを整理して開発チームに依頼する、これでやりやすくなるはず！！ 結果は… エンジニアからめっちゃ不満が出る。 理由を聞くと 「細かく書かれた要求を淡々と開発するのは辛い。」 もう少し聞いてみると、 どんな背景があってなんのための開発なのか知りたい もっといいやり方があるかもしれないが手段が限られている つまり、ここでの問題は要求が細かいことではなくて、なぜこの問い合わせ対応を行うのか？ というwhyの対話ができていないことでした。 改めてwhyから考え直す 本当に知りたいのは、相手がなぜ問い合わせしているのか。 対応の優先度を決める前に、PdMから依頼者に問い合わせの目的（どんな課題を解決したいか）を聞くようにフローを変更しました。またエンジニアからも依頼者にwhyをヒアリングしやすいように要求のテンプレートを変更しました。 要求のテンプレートの例 ### どんな成果に紐つくか - [ ] 事業成果 - メリット: ○○ユーザー向けの○○○ページでの流入を○○増加できる - [ ] 開発チームで必要な工数 - どの程度余計な時間がかかっているか: 1度の対応で10分程度 - 頻度はどの程度か: 月1回以上 - [ ] 開発チーム以外の工数 - どの程度余計な時間がかかっているか: 1度の対応で10分程度 - 頻度はどの程度か: 月1回以上 - [ ] セキュリティリスク - 発生しそうなリスクがあればかく ### 要求 ### 完了の定義 ### 改修の対象（プロダクト、機能、ページなど） ### 注意事項 ### 要求の補足 もうひとつ「問い合わせ対応の捉え方を変える」 そもそも問い合わせ対応する意味ってなんだろう？を考えました。 もちろん、インシデントにすぐに対応したりサービスの品質を保つためには欠かせません。ただそれだけでは不足を感じていて、組織や開発プロジェクトが大きくなるフェイズに合わせて考え方を変える時が良い来たと思って、問い合わせ対応へのスタンスを整理しました。 その時の開発チームに共有したことの抜粋がこちらです。 問い合わせ対応とは 事業成長の機会 さまざまなコンテキストを持った依頼・相談が発生するからこそ、相互の背景を理解し合い、信頼関係を育む重要なチャンス。 エンジニア以外のメンバーが「こんなこと実現できるのかなぁ」と悩まずに適切に相談できる組織の文化を作る。 依頼者が手段を狭く捉えて、目的から考える思考の妨げにならないようにしたい。 問い合わせ対応のスタンス 問い合わせを一次受けする人は、問い合わせ内容から各部署がどんな動きをしようとしているのか、それは事業戦略とどう接続するのか洞察しながら対応しよう！ 依頼者をリスペクトしよう 成果のために考える範囲を広げようとする姿勢は善。 依頼者が細かい仕様を知らないのは当たり前。 即リアクションしよう！ 案件の緊急度に応じて対応。 PdMも問い合わせ内容を見てエンジニア対応が不要と判断したら自らボールを持つ。 緊急の依頼が来ることもあるので、見ている人がいるとすぐわかるようにスタンプを押そう。 次に対応する人がやりやすいようにしよう！ 注意が必要な対応など、ドキュメントを残す。 結果は… ただ優先度の順番を並べるだけではなく「やらない」判断がしやすくなった。 さらに、成果を増やせる改善案や仕様を開発チームから提案できるようになった。 ”問い合わせ”のマトリクス その２ これまではPdMの感覚的な優先度で対応順を並べていましたが、事業への影響を理解することで重要度がはっきりして やらなくて良いものを判断できるようになりました。 1件あたりの考える時間は増えましたが、やらないものを早く決めることで対応の総量をスリムにできました。開発チーム内でも成果を共通認識として対話することで、最適な手段を提案しやすくなりました。 あらためて過去の問い合わせ対応を振り返ってみると、開発に対するアウトカム（事業的な成果）が曖昧で、本当はすぐにやらなくて良いものがありました。問い合わせ対応のような一見細かいものでも、whyを中心に対話することで、より大きな課題に気付いたり、より良いアイディアを出せる機会になるのだと思います。 Whyから考えて意思決定しよう！ 上に書いた体制や取り組みが完成形とは思っていません。最適な形は絶えず変化します。ただwhyから考える思考は、どんな状況でも欠かせないと思います。 私たちは考え続けます。🤔🤔🤔 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

この記事は、Speee Advent Calendar 14日目の記事です。昨日の記事はこちら tech.speee.jp デジタルトランスフォーメーション事業本部 イエウール事業部 プロダクトマネージャーの塚本（@nao_tsukamoto）です。 今回発表したイベントについて PeerQuest Inc. 様主催の、#開発PM勉強会 の第7回目のイベント、「要件定義どうしている？共有LT」で発表させていただきました。 peer-quest.connpass.com 発表した内容について 結局行き着いたのは、（あるある話だとは思いますが）whyとwhatの定義をしっかりすること でした。 その過程で多くの失敗をしたので、当時私がやってしまった要件定義時の失敗について発表しました。 発表資料はこちら speakerdeck.com サマリ howへの決めつけによるプロダクトの失敗確率は相当高い howの決めつけ - その1：エンジニア側への決めつけ howの決めつけ - その2：ビジネス側への決めつけ howの決めつけ - その3：既存のシステム・仕様への決めつけ プロダクトマネージャーがhowを決めつけてしまっては、プロダクト開発は失敗すると言える よって、whyとwhatの定義をしっかりすべきであり、 howはチームに属すると肝に命じよう Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar13日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは。Speeeの岡部です。 5月からSpeeeに入社してプロジェクトマネージャーをしています。 前職はネット広告の代理店で2年間は広告の運用を、その後2年間は業務改善系のプロジェクトをいくつか担当していました。 そんな僕が最近、ひしひしと感じていることがあります。 「業務改善って本当に難しい！」 「オペレーション・エクセレンス」という言葉をよく耳にするようになりましたが、それを実現するのはすごく難しいです。それどころか業務を改善しようとして、かえって悪化するケースもあるんです。「え、そんなことあるの？」と思うかも知れませんが、結構起こりがちです。 僕も何回かやってしまったなーという経験があります。 その改善施策を実施して、削減される時間とコストはいくらですか？ その改善施策を実施するには、どのくらいの時間とコストがかかりますか？ その改善施策を実施して、解決される課題は何ですか？ その改善施策をやらなかったとして、どのような悪影響がでますか？ やらかしたなーと思ったときはだいたい上記の質問に答えられないような状態でした。 どのような業務改善施策であれ、これらの質問にスラスラ答えられないとプロジェクトとしては黄色信号です。知らず知らずのうちに、 本当の課題が解決しないままフローが複雑になってしまった 人件費含む投下コストが回収出来なかった ほんとは取り組まなくてもいいようなことに時間を使ってしまった といった「目的を達成しない余分な仕組みや取り組みをやっただけ」に陥っていることがあります。この記事ではこういった状態を「業務改悪」と呼んでいきます。 そんな「業務改悪」をやってしまわないようにするために、注意するべき点は3つあるんじゃないかなと、僕は考えています。 課題をきちんと特定する その課題は解決するべきものかを判断する 制約条件を見定める 今回は業務改善に関わっている人、あるいはこれから関わっていく人に向けて、 「業務改悪」にはどんなパターンがあるのか、どういった点に注意すればよいのかを仮想の事例を踏まえて解説していきます。 担当案件を増やすプロジェクトの仮想事例 ================================================= あなたはWEB制作会社に勤めている開発チームの一員です。 この会社はさまざまな企業の自社HPを作成する会社で、営業チームと開発チームの2つのチームに分かれています。 営業チームが契約を受注しクライアントの要望を集め、開発チームは営業チームがまとめた要望を元に適切な構造やデザインを考えて実装し納品します。 営業チームは毎月たくさんの契約を取ってきますが、開発チームは一人当たり3社担当するのが限界で会社の売上は伸び悩んでいます。 そんな中、「開発チームが一人当たり5社担当できるようにしてほしい」という相談があなたのもとに来ます。 「うーん、今の業務であと2社増やすのは無理だな～。」 「やっぱりサイト構造の設計に一番時間がかかるんだよな。」 そんなことを考えながらプロジェクトを進めていくことになりました。 ================================================= イメージをつかんでもらうために仮想の事例を作ってみました。 こういった事例の業務改悪になりがちなのは、 「いろいろやって開発チームで5社持てるようになったけど、大目的である売り上げ増につながらなった」というパターンです。 上記のような状態にならないように、どうやってプロジェクトを設計していくのかを その課題は解決するべきものかを判断する 課題をきちんと特定する 制約条件を見定める の3つの注意点にそってみていきます。 ①その課題は解決するべきものかを判断する 意外と見落としがちなのが、そのプロジェクトはそもそもやるべき事案なのかという検討です。 業務改善系の話のなかには、掘り下げてみると実は課題はそこじゃない、みたいなことがよくあります。 今回の例でいうと、「開発チームで一人5社担当せよ」というお題の裏には以下のような前提条件があります。 「会社の売上が伸び悩んでいる。」 「売上が伸び悩んでいる原因は契約社数が増えないからだ。」 「契約社数が増えないのは開発チームのリソースが逼迫しているからだ。」 プロジェクトに取り掛かる前にこれらの前提が本当なのか確認する作業は必須です。 この確認をしないと、「必死に頑張って一人5社担当できるようになったけど、結果として会社の売上全然伸びてない！」みたいな悲しいことが起こります。 例えばよくよく確認した結果、「契約企業数が増えない本当の理由は、営業の受注率が低いことだった」であれば、開発チームのキャパを増やしても契約社数増にはつながりません。 もっと前段まで確認すると「売上が伸びない理由は契約社数ではなく、提供サービスに対して単価が低いから」ということもあるかもしれません。その場合もお題をクリアしても大目的の「売上増」にあまり寄与しないという結果になりかねません。 いきなりプロジェクトに着手する前に「このお題はどんな前提条件のもと成立するのか」「そもそもその前提条件は正しいのか」を確認することが必要です。 ②課題をきちんと特定する。 今回の例だと「サイトの構造設計に時間がかかっていること」を課題感として捉えています。プロジェクトに取り掛かる前の当たり所を探る段階であればよいですが、本格始動するタイミングでこの状態では具体的な改善アクションが定められないので不十分です。 僕が課題の特定のためによく使うフレームワークは「What,Why,How」です。 「What,Why,How」の思考法はいろんな場面で使われますが、課題解決の場合は 「What」：「我々を困らせている事象は何なのか」 「Why」：「なぜその事象が起きているのか」 「How」：「どうやってそれを解決するのか」 と問いを立てると整理しやすいです。 特に重要なのは「What」と「Why」です。この2つが見えればおのずと「How」も見えてくることが多いです。 今回でいうと 「What」は「サイトの構造設計に時間がかかっていること」と設定し、 「Why」で「なぜ時間がかかっているのか」と要因を洗い出します。 （個人的には「Why(なぜ)」よりも「What made（何がそうさせているのか）」と置き換えたほうが適切な課題設定ができる場面が多いです。） 「サイトの構造設計に時間がかかっていること」の「Why」を掘り下げると、例えば 「営業の集めた要望を読み解くのに時間がかかっている」 「設計に必要な情報を何度も営業を介して先方に確認することで時間がかかっている」 等といった要因が出てくるとおもいます。 ここまで課題特定が進んでくると手段も見えてきます。 「要望を読み解くのに時間がかかる」のであれば、「営業のヒアリング項目をフォーマット化しよう」だったり、業務の性質上どうやっても確認がおきるのであれば、「営業にサイト構造設計までやってもらう」も一例としてはありです。 ③制約条件を見定める。 「制約条件を見定める」というと「お金とか時間とかの守らないといけない部分をはっきりさせるってことでしょ」と思いますが、ここで言いたいのは「守らないといけないと思っていた部分が実はそうでもなかった」というケースがあるということです。 そうした「誤った制約条件」を打破すると、「オペレーション・エクセレンス」な改善ができることが多いです。 例えば上記の例だと「一人5社担当」ときくとみんな5社ずつ担当するような印象になってしまいますが、実は重要顧客の担当者は3社担当のままで、シンプルな要望の顧客担当者は10社抱える、といった方法もありです。 ②で上げた「営業にサイト構造設計までやってもらう」という手法も「開発チームの業務範囲は維持する」という「誤った制約条件」を排除して生み出されるものです。 最後に ムダを減らすためにやったことがムダにならないように 業務改善をやろうとして、それが負の遺産になってしまうことはとても悲しいことです。会社として損失になることもですが、なにより本人が頑張ったことがムダになってしまうことがしんどいです。 自分の経験をもとに3つの注意点を紹介しましたが、本質的には「目的思考」を持ち続けることが重要だとおもいます。 この「目的思考」は僕らが特に大事にしている価値観1つです。「何のためにこれをやるのか」という問いを持ち続けることが、こうした悲劇を減らし、さらには本当の「オペレーション・エクセレンス」を実現することにつながると思います。 Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで仲間を募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ 

この記事は、Speee Advent Calendar 12日目の記事です。昨日の記事はこちら tech.speee.jp デジタルトランスフォーメーション事業本部 イエウール事業部PdMの酒井（@ryo_touch）です。 最近、大学の時に受けた講義内容などを復習することにハマっています。 今日は、大学での学びは、自分次第でどこに行っても繋げられるということをわたしの体験からお伝えしたいと思います。 大学（院）での学びを直接的に活かすべきか悩んでいる理系学生のみなさんの、進路の意思決定の一助となれば幸いです。 いまどんな仕事をしているか わたしは新卒でSpeeeに入社して、入社してからはプロダクトマネージャーとして不動産領域のDXプロダクトに携わっています。 プロダクトの集客施策を企画・リリースに向けて開発ディレクションをしたり、新規事業の立ち上げに際して企画を考えたりといった、企画寄りにプロダクトを良くしてエンドユーザに最良の顧客体験を届けることを考えて日々事業責任者、エンジニア、デザイナといった方々とチームになって働いています。 大学ではなにをしていたか 大学では物理・工学を勉強していました。 制御工学、物性物理、量子力学、電磁気学、電気電子回路、etc.あたりを勉強していました。特に面白かったのは制御工学です。 もともと数学が好きで、大学ではその面白さが物理で現れていました。 院に行くか迷っていて、「知ることへの好奇心はあるけど研究は向いてないな」と思って学部で卒業することにしました。 数年間教育系スタートアップでインターンをしており、そこでの体験からビジネスや事業づくりって面白いな〜と感じていたため、就活してSpeeeに入社しました（いわゆる文系就職）。 大学で学んだことが直接的に関係する仕事ではないため、「本当にいいんだっけ？」という不安や、両親への申し訳なさも少なからずありました。 ただ自分自身、高校の時から「大学行くならそこでの学びを活かすような仕事をする」と決めていたので、「なにかしらで学びをつなげる」という気持ちで仕事をすることで選択を正解にしようとしていました。 大学で学んだことと仕事をつなげて解釈し始められた 入社してもうすぐ2年が経とうとしていますが、「大学での学びを活かす」ということができ始めています。 一つひとつの事例はとても小さな話ですが、ビジネスというこれまで経験のなかった領域をこれまで学んできた物理の領域で解釈することができるときがあります。まっさらな状態からよりも深く理解・解釈できるようになっている感覚があります。 同時に、学びと仕事が結びついていくことで仕事が楽しくなっていくという嬉しさもありました。 それでは、実際によく考えている数学的思考をいくつか紹介します。 「入力と出力と関数」の考え方がよかった 入力 の全ての要素に対し，その要素を入力すると，出力 の特定の要素をただ一つ出力するものを関数という、お馴染みの関数です。 関数 の入出力システム図 プロダクト開発をするにあたって、「どんな情報を収集し、利活用するか」は重要な視点です。 出したい出力は何か？それを実現するための関数と入力は何か？入力はどのようにして準備するか？みたいなことを考えています。 例えば、ユーザが見る画面とその管理画面は情報の出力と入力と考えて、ユーザに見せたい画面（出力）に必要な情報を用意しないといけないな、といった頭の使い方ができるようになりました。 入出力システムの考え方 余談ですが、「アオアシ」作者の小林有吾先生の作品「フェルマーの料理」でも、関数の考え方を料理に当てています。この例えは料理する方にはニュアンス伝わるんじゃないかと思います。 フェルマーの料理 / alu.jp alu.jp フィードバック制御がよかった① 「フィードバック」という言葉自体は、普段の仕事で毎日のように使っている言葉だと思います。 制御工学のなかでフィードバック制御という分野を勉強しました。フィードバックというものを物理の世界で表現するとこういうことなのか！という気付きが大きかったです。 伝達関数のフィードバック回路のブロック線図 目標値に向かって差分を返し続ける。というシンプルな構造で、だからこそフィードバックを受け取る・渡すときは目標値を意識するようになりました。 「これじゃ〇〇に対して足りていないです」という表現でフィードバックするように意識するようになり、闇雲に打ち返されているような感覚をなくすことが出来ました フィードバック制御がよかった② グラフのような、目標値を青破線（1.0）としているシステムに対して 目標値を超えたり下回ったりしながら（振動しながら）目標値に近づいていくグラフと、目標値を超えずに滑らかに目標値に近づくグラフがあります。 例えるならば、車の運転で50kmで走ろうとしているときに、 50kmを超えたらブレーキを踏んで、下回ったらアクセルを踏んで..を繰り返すようなグラフと、 50kmを超えないように慎重にアクセルを踏んでいくようなグラフです。 目標値への道筋がグラフの形のように異なる わたしは完璧主義的なところがあり、頭ではわかっていても完璧なものを1回で出そうとしてしまいがちです。けれどこのグラフを見ながら、「いい施策を作るためには早く小さく、6割くらいでもアウトプットしてユーザや仲間からフィードバックをもらう」ということが大事なんだな、と腹落ちしました。 MVP（Minimum Viable Product）の価値仮説を早く検証することが大事だよね、という考えもここにつながっていると感じました。 大学行ってよかった、仕事楽しい ここまで、いくつかの数学的思考と仕事の接続を紹介させていただきました。 抽象的なモデルを扱う物理・数学の学問だからこそ、接続しやすさがあると思います。 全体的に数学などの問題を解いていて良かったなと感じる点は、「何があれば解けそうか」という解への道筋を考えるという思考体験です。 事業づくりは解き方の分からない・正解のない領域ですが、そんな曖昧な中でも自分の回答をつくるために思考をする必要があります。その思考体力や感覚は、間違いなく大学までの勉強に詰まっていたと思います。 一つひとつの接続による発見は大小によらずとてもワクワクする発見で、どんどんと仕事が楽しくなっていきました。 大学時代までの学びは忘却していくために発見の機会損失をしているだろうと考えると、もっと勉強もしていきたいと思っています。 おわりに 学んでいることは無駄にならず、これからの社会人生活にもプラスになります。 「みんな数学を学ぼうぜ！」ではなく「大学での学びは、自分次第でどこに行っても繋げられる」という記事でした。 大学での学びを直接的に活かすべきか悩んでいる理系学生のみなさんの、進路の意思決定の一助となれば幸いです。 「数学的思考はビジネスのためにある」 フェルマーの料理 / alu.jp alu.jp Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp Speeeでは様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらをチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar11日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは！Speeeデザイナーのおちーです。 デザイナーになって、1年半が過ぎました。光の速さで日々が過ぎていき、まだまだ未熟なわたしなりに、悪戦苦闘しながら学んできたことを失敗談と交えながらお話ししたいと思います！ サマリ 大学時代のわたし デザイナー1年目の生活スタート！ ぶち当たった大きな壁 わたしがやってしまっていた失敗 壁を乗り越えるために実践していること ① お互いのイメージをすり合わせる ② 言葉のまま受け取らない ③ 無思考でデザインしない 次のステージ さいごに サマリ ■デザイナー1年目がぶつかった壁 WFをそのままデザインする 意図を考えずにデザインする なぜこのデザインを作成するのか意図を理解してない ユーザーに目を向けていない　この記事でいう「デザイン」とは、 目的に沿ったデザイン、ユーザーの課題を解決出来ている、意味を持ったデザインのことです。 ■壁を乗り越えるためにやっている3つのこと 意味のあるデザインをつくる上で、大切にしなければならない3点です。 未経験でデザイナーになる方や、デザイナーを目指している方など、同じ境遇の方のお役に立てると嬉しいです。 お互いのイメージをすり合わせる 言葉のまま受け取らない 無思考でデザインしない 大学時代のわたし 大学時代は、広告や紙媒体のデザインを中心に作成していました。Webデザインも少しは学んでいたのですが、仕事にできるほどは学んでいませんでした。 そして、自分の好きなものを自分の好みに合わせて作る、自己満足なデザインを4年間続けていました。当時のわたしは、自分の好きなデザインを作ることがデザインだと思っていました。また、自分はデザインの道で食べていけると自信満々だったと思います。( 恥ずかしい........😓 ) デザイナー1年目の生活スタート！ Speeeには2年前にジョインしました。 入社して半年くらいは、主に、コラム記事のアイキャッチや、サイト内のバナーを作成していました。 入社前は、デザインの世界は厳しいと噂を聞いていたので、全部一人で調べて一人でやらなきゃならないと思っていました。しかし、意外にも職場環境がすごく良く、質問に対して丁寧な返信をいただいたり、わかるまでとことん教えてくれるなど、新人デザイナーからしたらとても嬉しい仕事環境でした。 ぶち当たった大きな壁 Speeeにジョインして半年が経った頃、リスティング広告のデザイン担当になりました。 今までバナーやサイトページも作ってきたし、「できる！やってやるぞー」と意気込んで取り組んだのですが、何回出してもレビューが返ってきて、永遠にFIXしないのでは無いかと思うほど苦戦していました。 バナーやコラム記事はデザインできていたのに、プロジェクトが変わっただけでここまでデザイン出来なくなるものかと怖くなりました。上司に相談し、入社してからこれまでの働き方を考え直してみました。わたしのデザインのやり方は、デザインでつまずいたら全て上司に答えをもらっていたり、プランナーさんの言う通りに作っていただけで、自分で考えてデザインするということをしてなかったことに気づきました。 もっと言うと、なぜこのバナーやモーダル、LPを作っているのかという施策の目的や方向性など全く理解していなかったのです。 わたしがやってしまっていた失敗 WFをそのままデザインにしてしまっている 意味を考えずにデザインする なぜこのデザインを作成するのか意図を理解してない ユーザーに目を向けていない　わたしは、全くデザインをしてきていない半年を過ごしていたのです。 ここでわたしのいうデザインとは「施策の目的に沿ったデザイン、ユーザーの課題を解決出来ている、意味を持ったデザイン」のことです。 施策の目的に沿ったデザインを作ることで、ユーザーの課題が解決でき、よりよいサービスにしていくことが重要だと思いました。 自分よりもこの業界を理解していて知見を持っている先輩たちからユーザー心理を学び、ユーザーが感じている課題を解決できるデザインを作成したいと思うようになりました。 壁を乗り越えるために実践していること ① お互いのイメージをすり合わせる 言葉やこのイメージワードを使って合わせていきます。 施策の説明を受ける時は、 施策のイメージやキーワード カラーなどお互いのイメージをすり合わせる ② 言葉のまま受け取らない プランナーにフィードバックをもらった時は 言葉のまま受け取らずに、言葉の背景を考える ノートに何をするのか記入する どのようなことが裏に隠されているのか見極めるように努力しています。 ③ 無思考でデザインしない ユーザー、自分自身のために、「WHY?」を自問自答しながらデザインすることを心がけるようにしています。 全てのことに言えるのですが、プランナーからいただいたフィードバックや施策の説明などは、 言われたことを考えずに進めない なぜそう言われたのか全てのことに 「WHY?」を考えてから始める。 次のステージ 1年半たった今でもできないことが多く、上司の力を借りながらデザインしている毎日です。 考えながらデザインするってこんなに難しくて、楽しいんだと思うようになりました。見栄えがいいものだけがデザインではなく、ユーザーの課題を解決するのもデザインの1つとして、とても大切だと思いました。わたしは、課題解決能力をあげていき、意味のあるデザインをつくれるように、これからも成長していきたいと思います。 そして、直近の目標は、自らがユーザーの心理を読み取りデザインに反映することのできるデザイナーになることです！ さいごに Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar10日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは、DX 事業本部 エンジニアの 宮平（みやひら） です。 Speee Advent Calendar 10日目を担当することになり、この機会に、Speeeに入って学び確立した「日々の業務で大切にしていること」について振り返っていきたいと思います。 2019年4月当時、フロントエンドエンジニア歴1年と経験が浅い中、業務委託としてjoinしました。 イエウールのエントリーフォーム改善（EFO）を担当し、施策のフロント実装をしていました。 当時は、開発環境のファイルを理解しながら実装を進めることに必死で、 要件通りに実装すること！レビューを無事に通ること！リリース期日の死守！が業務の目的になっていました。 実装する要件だけではなく、実装する目的を理解したい どういうことか ユーザーに届けたい情報も、ずらっとテキストを並べただけでは読まれない ユーザーにとって価値のある情報も届けられていないということになる 逆に、ユーザーの邪魔になる様な表示方法は避けたい 邪魔になって離脱させてしまうとそもそも価値のある内容を届けられない デバイスやブラウザ、申し込みFormに訪れた時間帯やサービスを利用する意向度によってもユーザーの受け取り方が変化し、与える印象も異なる 施策結果の振り返りをする際に、上記の様なことを学び、 目的を理解し実装することで、ユーザーに影響する価値の深度が変わるということに気づきました。 [ 気づき変化したこと ] EFOチームが追う目標により貢献していきたい → 目標の先の目的って？ → サービスやプロダクトを通して、ユーザーの課題解決ができることや、付加価値提供をし続ける このような学びの多いSpeeeで、当事者意識を持って「開発者としてどうエンドユーザに関わることができるのか」を考えて日々の業務に取り組みたいと思い、2021年6月に正社員入社しました。 具体的な変化 エントリーフォーム改善（EFO）を行う中での行動の変化 before after 開発要件を確認する ・開発目的を確認、不明点は質問するなどして理解する・開発要件を確認する 要件通りに実装後、ソースコードをできるだけ綺麗に整理する ・ユーザーの受ける印象を考えて実装する ※届けたいことを確実に伝えるために、ユーザーが「ちゃんと読めるか」という視点を持つ ・ソースコードをできるだけ綺麗に整理する 実装要件は満たせているかという観点で動作確認をする ・実装要件は満たせているか ＋ 客観的な視点で動作確認をする ブラウザ毎の表示を確認する ・ブラウザ毎の表示に加えて、デバイス毎の表示で確認する ※改行が発生する位置や※フォントサイズによる印象の違いを考える ・開発目的を達成する角度を高めるために、気づいたことをチームへ共有する ・ユーザーへの影響を考えて、要件に懸念点がある場合は変更案をプランナーへ相談する ・変更案の実装キャプチャと理由を共有する プランナーのイメージ通りに実装できているかを確認依頼する 開発目的は達成できそうか、ユーザーに届ける価値が最大化された状態かを確認依頼する ユーザーに伝わるかどうかを意識して確認、提案した際のキャプチャ ↑上記は開発途中のため一部内容に誤りがあります 結果どうなったか 実装後の手戻りが格段に減った！ 目的を理解して実装を始めることで、開発者から質問が上がり、プランナーへの確認や修正を早い段階で行える ユーザー理解が大切という共通認識がチームに定着！チームの結束力も増した！ 集計データや、市場の課題についてなど、プランナーとエンジニア間での情報共有が活発に行われる様になった 情報量の格差が小さくなり、プランナーとエンジニアが同じ目的に向かって議論できている 目的に対する議論ができることで、開発内容の質や開発スピードが向上！ 開発後のユーザーの反応を早く知りたい、付加価値を提供できる内容は早く届けたいという意識で行動を選択できるようになった ユーザーへ価値提供できているという自信が持てるようになった！ ユーザー起点の議論で要件を詰めた施策は、リリース後に良い反応を得られることが増えた まとめ ユーザーの受ける印象を考えて作業をすることは、Speeeに入って学び、今後も続けていきたいと考えています。 実装する人という小さな枠に捉われず、開発目的を理解した上で実装設計や環境整備を行えるように、技術面でも成長していきたいと思います。 今回振り返って文字に起こしたことで、無意識に実行できるようになった学びを改めて把握できました。それにより自分やチームの変化を感じ、これからの自信にも繋がりました。引き続き「開発者としてどうエンドユーザに関わることができるのか」というテーマを掲げ、具体的に業務に落とし込めるよう、チームやDX事業本部のみなさんと意見交換をしながら良いプロダクトを作って行きたいです。 おまけ Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Engineering Manager Advent Calendar 10 日目の記事です。 こんにちは、DX 事業本部のエンジニアのさとーる（@satotoru2000）です。 株式会社SpeeeのDX事業本部には専任のCTOやEngineering Managerがいません。その代わり現場のエンジニアたちと事業本部長が力を合わせて、みんなで開発組織づくりに取り組んでいます。 第二創業フェーズでもあるこの2年間は「どんどん新規事業を立ち上げていく必要があるが、その道筋は整備されておらず、走りながら考えるしかない」という状況の中で、何とかそれに耐えられる技術的、組織的な体制を整えてきました。 この記事では自身の振り返りも兼ねて、どのようにこの課題を乗り越えてきたかをご紹介できればと思います。同じような課題を抱えているエンジニアの皆さんのお役に立てたら幸いです。 DX事業本部ってどんな組織？ 組織の概要 戦略についてお話する前に、まずSpeee事業概要とDX事業本部について軽くお話しておこうと思います。 Speeeは大きく3つのセグメントに分かれています。DX事業本部は以下資料の 不動産DX事業 にあたります。 事業ポートフォリオ DX事業本部の開発組織体制 冒頭でもお話したとおり、DX事業本部はエンジニアのトップとなる人間はおりません。エンジニアの1on1や評価など開発組織のピープルマネジメントは事業本部長が担っていますが、技術的な部分は現場のエンジニアに任されていて、それぞれが走りながら意思決定する体制です。 全社横断としてはVPoEの大場がいるのですが、事業ドメインに飛び地で参入しているSpeeeの特性上、ほとんどの役割を事業本部で担う構造になっています。 当時のDX事業本部の状況 2年前のDX事業本部は第二創業フェーズといった雰囲気で、新しいサービスをドンドン立ち上げていく入り口でした。 同時に複数の新規立ち上げが走っていて、新しいエンジニアも一気に増えてくるようなフェーズです。 当時の状況はこんな感じでした。 イエウールをモデルにしたサービスを立ち上げてるけどイエウールに詳しい人はいない状態 CTOもEMもいない。自分たちで技術戦略や組織戦略を考えないといけない サービスも立ち上げフェーズだし、事業が今後どうなるか分からない そもそも入社したばかりの人も多くてコンテキストに十分追いつけてない とはいえ今の新規事業を軌道に乗せることが何よりも大事 つまり、新規事業を並列で走らせながら、同時並行でスケールに耐えられる技術戦略や組織体制も作っていく必要がある状況でした。 どうやって乗り越えてきたのか？ 最初の事業立ち上げ まず、最初に新規立ち上げをするにあたって、「既存の資産を流用してスピードを出すのか？フルスクラッチでやるのか？」という問題に直面しました。 これは双方メリデメあると思いますが、今回は「イエウールのコード資産を使わない」と決めました。当時のメンバーが決めたので実際の経緯は分からないですが、 イエウールは年数も経っておりコードが複雑化していた 技術スタックもモダンとは言えず、ベストプラクティスを取り入れられない 等があり、資産を流用してもスピードが出ない見込みがあったのと、これをパイロットプロジェクトとして成功させて、他のプロダクトに横展開することを考えていたことが理由だったと記憶しています。 そのため、Kubernetesでインフラを完全新規で作り直し、アプリケーションの設計も完全新規でベストなものを作ることを目指しました。当時のベストメンバーがこのプロジェクトに当たりました。 結果、これは大成功を収めることができ、第一関門を突破することが出来ました。 シングルテナント戦略 この時期には2,3ヶ月に1度ペースで新しいサービスを立ち上げなければいけませんでした。 まだ新しい事業がどうなるか分からないなかで、インフラの技術戦略を決めていく必要がありました。 その中で、AWSアカウントもKuberenetesクラスタもサービスごとに完全分割する「シングルテナント戦略」を意思決定しました。 この辺りは開発基盤チームの西田 が対応したので、当時を振り返ってもらいました。 当時は「Kubernetes使おう」ということだけは決めていたが、自身もKuberenetesに詳しいわけではなかった。 AWSの思想とKubernetesの思想が異なるのは分かっていて、AWSに従うならアカウントを分けるべきだし、Kubernetesに従うなら同一クラスタ上に構築すべきだった。 「分けたものをくっつけるのは簡単だが、くっつけたものを分けるのは難しいはず」と考え、先行きが不確実な今の段階では分ける側に振り切った方が良いと判断した。 結果的に、この時期に立ち上げるサービスは大小問わず全て別AWSアカウント、別クラスタで構築を行いました。 当時としてはベストな判断だったと思います。完全に切り分けたことによって、デプロイや運用の仕組みを急速に洗練させることが出来ました。あるサービスの立ち上げで起きた失敗を次の立ち上げで改善するというサイクルを回すことが出来ました。アプリケーションエンジニアとして関わっていた私から見ても「どんどん変わっていくなー」と感じていたのを覚えています。(速すぎてキャッチアップが大変だった) もしも最初からクラスタの統合をしていたら、このような急速な改善は無理だったと思います。当時の私たちには、既に動いているサービスを変えてまでリファクタリングする余裕はありませんでした。 もちろん全てを分割した揺り戻しもあって、今では集約したほうが良いサービスも分かってきているので、クラスタの統合を順次進めています。 (この辺り詳しく聞きたい方は、ぜひ西田と話してみてください) フロント技術を統一する 複数の事業を立ち上げてまもなく、「プロジェクトごとバラバラのフロント技術を採用し始める」という自体に直面しました。具体的に言うとVue派とReact派がいて、それぞれのプロジェクトで別々に技術を採用し始めました。 現場からも「ReactのチームとVueのチームあるけど大丈夫か？」という声が上がり始めていました。 そこで「既に作ってしまったものを除き、Reactに統一する」という意思決定をしました。 Reactに決めた背景としては以下です。 ぶっちゃけどちらを選んでも出来ることに大差はない ただし、どちらかに揃っていることは絶対大事 分かれていると学びの蓄積が半減してしまう 異動したときのキャッチアップのコストが掛かる 相対的に組織に有識者が多そうなReactを選択 結構思い切った意思決定でしたが、想像以上に各プロジェクトすんなり受け入れてくれました。 今振り返るとこのタイミングで決めてよかったと思っています。 コードの再利用が進んだというわけではないのですが、「とにかくReactでチャレンジしていこう」というムーブメントを起こすことは出来たかなと思っています。Reactという共通言語を通して社内でフロントエンドに関する会話が活発になりました。 ライブラリ選定などで失敗することもあったのですが、事業を立ち上げるたびに洗練されたものになっていきました。 カオスな環境を面白がってくれる仲間を集める 同時多発的に事業が立ち上がる環境下で、正直言って丁寧にオンボーディング出来る環境は提供できませんでした。 その代わり「カオスな環境を面白がってくれるような強い仲間をとにかく採用すること」に全てのエネルギーを注ぎました。 「カジュアル面談60分で知識ゼロからSpeee好き度90%にすること」を目標に、ひたすらトークを磨き込んでPDCAを回していきました。(具体的にどうやったかは菅沢 とMeetyしてみてください。) そうして入ってくれた仲間が、新規事業のカオスの中に飛び込んで成果を出してくれました。長年勤めたスタートアップを辞めて来てくれる仲間もいました。 ちなみに、オンボーディングに関しては反省点も多いです。単純に手が回ってなかったし、当時の実力ではそこまで考えきれませんでした。雑にプロジェクトに放り込んでつらい思いをさせてしまったこともあったと思います。ホントに申し訳ない。。。 全力で走りながら組織を作るために必要なこと 無我夢中で走っているときには気づかないのですが、改めて当時を振り返ることで分かる気付きがたくさんあります。私なりに全力で走りながら組織を作るために重要だと思うことを、以下にいくつかまとめてみました。 「専門家はいない。私たちしかいないんだ。」 困難な状況に立ち向かうとき、エラスティックリーダーシップのこの言葉をいつも思い出します。足りないものなんて沢山あるし、配られたカードで戦うしかないのです。 前述した意思決定に共通しているのは、学びと挑戦を繰り返したという点です。インフラやフロントエンド、組織づくりなども、最初から見通せたことなんてほとんど無かったし、学びを繰り返すうちにやっと輪郭が見えてきたという感想です。 特に、「学ばないと乗り越えられないくらい高いハードルに挑んでいた」というのが最も大きかったと思います。 Reactに詳しかった訳でもないし、採用もほとんどやったことなかったのですが「やるしかない」という気持ちで必死で走っているうちに自然と学びに変わっていきました。 重要なのは「真実に向かおうとする意思」 もっとゆっくり考える時間があれば、事前に要素を洗い出して、もっと効率的な 技術戦略を決めることが出来たのかも知れません。しかし、組織の状況、ビジネスの状況は刻々と変化をしており、ゆっくり考える時間があることの方が稀です。少なくとも私たちの組織ではそうです。 たとえ回り道をしたとしても「真実に向かおうとする意思」を持ち続けている限りいつかは正解にたどり着きます。 「正しい意思決定をする」のではなく「意思決定を自らの手で正解にする。正解にするまで諦めない」という強い心を持つことが最も大事なことだと思います。 各々が困難な課題に向かって面白いチャレンジをし続けてるなら、他に何も要らない 私たちが過ごしてきた2年間は「新しい事業に挑み、とにかく面白いチャレンジをし続けた。」ただそれだけ、と言うことが出来ます。 正直「組織づくりをしている」という感覚は全く無くて、目標に向かってひたすら努力して、ふと気づいたときには良い感じになっていた、という感覚です。 もっと制度や仕組みが必要なんじゃないかと悩んだ時期もあったのですが、それは手段でしかなく、まずは目の前の課題と向き合うの大事だということに気付かされました。 今後も既存の解決策や手段にとらわれれず、私たちらしいやり方で一つひとつ課題を潰していきたいと思っています。 最近だと、今年から新卒も入ってきており、若いエンジニアが安心してチャレンジ出来るような制度や仕組みを整備しないとなー、というのを考え始めています。 終わりに 今回は、私たちの組織の現状を赤裸々に話させてもらいました。まだまだ課題が山積みな弊社ですが、それでも「面白そう」と思ってくれる方が入れば、ぜひカジュアル面談で話しましょう！ 以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください！ tech.speee.jp

※この記事は、Speee Advent Calendar 9日目の記事です。 昨日の記事はこちら tech.speee.jp はじめまして 前職時代は、、、 Speeeにジョインして、、、 普段の業務：チームのアウトプット クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい ちがいって？ デザイナーの役割の幅イメージ フェーズによって、デザイナーの役割も変わるんだ！ 目的によって、デザイナーに求めらるもの まとめ あとがき はじめまして こんにちは！Speee デザイナーのさとこです。(デザイナー歴17年の40歳になりました😄) 今日は、プロダクトのフェーズやプロジェクトによって、デザイナーの役割って違うんだなーーー、というお話をしたいと思います。 組織を横断してデザインに携わってきた経験から、 クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい プロダクトのフェーズによるちがい という色々な「ちがい」を整理しながらお話できたらなーと思っています。 まずは、簡単に自己紹介をします。 前職時代は、、、 事業会社のSI部門でお客様のWebサイトやサービス開発のデザイン、Webディレクション、プロジェクトマネジメントをやってたよ 新規開発がメインだったよ クライアントワーク歴13年 Speeeにジョインして、、、 PDCAをまわしてプロダクトをグロースさせていきたい！という熱い思いで3年前にジョイン 現在は、組織を横断してtoC,toBのプロジェクトに関わっているよ 普段の業務：チームのアウトプット 新規プロダクト開発 インバウンド営業改善 広告運用 自社集客(SEO) https://ieul.jp/satei/東京都/ https://ieul.jp/research/ メディア運営 不動産売却お役立ちコラム まれに販促物製作 クライアントワーク(受託)とSpeeeのインハウスデザイナーのちがい 大きな違いは、2つだと思います。 ・ 1つ目は、開発形式の違い ・ 2つ目は、デザイナーの役割の幅の違い 事業会社のSI部門で受託でWEBサイトの構築やアプリ制作をやっていた私の個人の主観で書いています。2021年の今とは違う部分もあるかもしれません。ご了承くださいm(＿ ＿)m ちがいって？ 受託の場合、ウォーターフォール形式の開発がメイン デザインの専門家として参戦👨‍🌾 Speeeのインハウスの場合、アジャイル形式の開発がメイン 実装以外のオールラウンダーとして参戦🧙‍♀️🧙‍♀️🧙‍♀️ 目的や状況に合わせて何でもやる　←ここが大きな違い ウォーターフォール形式は、工程分割で開発を進め、全ての工程を完了してリリースします。 前職のデザイナーは、特に分業化が進んでいたためデザインに専念していました。ディレクターやプロジェクトマネージャーは、全工程にタッチする体制でした。 アジャイル形式は、イテレーション単位でリリースをし、チーム・施策の目的や状況に合わせてデザイナーの動きは必要に応じて変わります。カバー範囲が広くなるイメージです。 Speeeにジョインして、アジャイルで開発するようになって、目的とゴールを強く意識し、”より深くユーザに何を届けるのか？” を考えてデザインをするようになったと思います。 デザイナーの役割の幅イメージ フェーズによって、デザイナーの役割も変わるんだ！ アジャイル開発を通して、プロダクトのフェーズによって、デザイナーに求められるものが分かってきました❗️ はじめは、すべてを完璧にやろうとして悪戦苦闘していました。 時間がどれだけあっても足りず、、、ひとりで疲弊していました😭 リリースするからには、ちゃんとしたものを届けたい。。。 いつの間にか、自分がユーザファーストじゃないデザイナーになっていることに気づきました。。。 ユーザの課題、目的にフォーカスして、チームで議論しアウトプットを重ねていくことで、プロダクトのフェーズにあったデザインが少しずつ見えてきました✨ 目的によって、デザイナーに求めらるもの 実際に対応しているデザインの大小をまとめてみました。 大：ガッツリ系 LPや新規開発、改善施策など 小：さっぱり系 既存のコンテンツの拡充など ガッツリ系では、課題などをヒアリングをして噛み砕き、どんな人に、どんな情報を届けると目的を達成するアクションになるのかを考えながら、デザインに落としていきます。 ヒアリングからアウトプットまで以下のように考えています。 ヒアリングしていること 現状の課題 なぜ必要なのか(目的) 達成しようとしていること(ゴール) 事業が目指す方向のどこに繋がることなのか 今後の計画 アウトプットする際に考えていること 競合とどうやって差別化を図るか ターゲットに、最適なフォントサイズ、行間、画面幅、、、 最適なメインカラー、サブカラー、画面遷移を考慮したカラーの定義 視認性、可読性、操作性、、、 画面内に記載する文言は最適な表現か ファーストビューに必要な要素がおさまっているか メインユーザのデバイス 成果をあげるために追加する要素はないか？ 施策の目的が伝わっているか 逆に、さっぱり系と定義した既存のコンテンツの拡充の場合は、実装後の軽いレビューだけを対応し、可読性が担保できているかという観点で確認をしているくらいです。 デザインの大小によって、ここまで対応する内容を変えています。 まとめ 今回、まとめてみて改めて伝えるのは難しいけれど、整理されていくプロセスも含めて、たのしいなーと思いました！ わたしは、デザインは課題解決のためのひとつのツールだと思っています。デザインを通してユーザ、クライアント、事業の課題を解決していけるように日々精進していきます👨‍🌾課題解決のために必要なことを取捨選択して、トライ＆エラーを繰り返しながら、やっていきます！！！ あとがき 今回のブログタイトルは、ゆっけがつけてくれました！ さすがブログリーダー！ありがとう ^ ^ Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁💁💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！

※この記事は、Speee Advent Calendar8日目の記事です。 昨日の記事はこちら tech.speee.jp Speeeでアウトプットをいい感じにやっていこうぜ～活動をしている菅沢です。 AdventCalendarの出番は2回目です！！！ 昨日よりバイトリーダーならぬ、 ブログリーダーになりました シフトの空いた穴を埋めるように、ブログの穴を埋めていこうと思います https://t.co/bOdg75KEFQ — ゆっけ@Speeeのものづくり組織採用の人 (@ykksg728) 2021年12月3日 この記事では、 プロダクトを作るようにブログを書くとすごく書きやすいし、アウトプットすることに自信が持てるよ というお話をします。 9月からアウトプットをいい感じにやっていこうぜ～！という取り組みを推進していて、自分でも記事を書くのはもちろん、かれこれ30~40記事ほど作成のサポートをしています。 その中で、ブログを書くことになったメンバー（私含め）は 書き始めてみたが、執筆が思ったよりすすまない 書き始めるハードルが思ったより高い という課題に遭遇することが多く、どうにか工夫して乗り越えられてきているかも！という状態なので、 自分の学びの棚卸しとして、そして、私と同じようにTechBlogの作成を推進していて同じような課題を感じている方々に役立てたらいいな、という気持ちで記事を書くことにしました！ 目次 ブログ作成で難しいのは、執筆そのものよりゴール設定 当時の状況 ゴール設定が難しい そして体に染み付いたプロダクト開発とつながる ブログを作るというプロセスを分解してみる プロダクトを作るようにブログを作っていく ゴール設定 設計 実装 実際どうなのか？ 最後にお決まりの！！！ ブログ作成で難しいのは、執筆そのものよりゴール設定 当時の状況 TechBlogをだしていこう！という気持ちはみんなあるものの、ブログを実際に書くのは私含め初めてのメンバーも多く、以下のような課題に困っていました。 書き始めて見たが、執筆が思ったよりすすまない 書き始めるハードルが思ったより高い 実際に自分でも書いてみると、めちゃくちゃわかるんですよね。 たとえ書き始めたとしても何を書けばいいんだっけ？と途中で止まってしまうこともあり、書き進めることの難しさを感じました。 ゴール設定が難しい やってみてわかったのは、ブログを作成するという一連のプロセスの中で、実は実際に文章を作成する部分はそこまで難しくないということでした。 それよりも、 要は、誰向けの何を書いてる記事なんだっけ？（who/what） 誰がこの記事を見たら得をするんだっけ？（アウトカムの定義） というゴール設定の方が難しいと感じています。 そして、上記が決まらないと章立てや文章の構成といった設計部分が進めづらいという状況が発生します。 なぜなら、ゴールが決まってないため、章立ての良さや悪さを感覚的に判断するしかないためです。 おそらく、ブログを作成する中で、「筆が乗らないな、、、」とか「何度も書き直してる、、、」というときはだいたい、このゴール設定がふわっとしている状態で作成してしまっていることが要因だと思っています。 そして体に染み付いたプロダクト開発とつながる この現象ってプロダクト開発でも起きませんか？ どんなユーザーにどういう価値提供するかしっくり来てないのにとりあえず実装し始めて、もやもやしながら実装してて辛い 同じくな状況で、作ってみたけどなんだか違う気がして再設計したくなる みたいな状況に似てませんか？ そうなんです。似てるんです（無理やりｗ） つまり、ブログもプロダクトなんですね！！！！！！ それであれば、プロダクト開発をしている中で活用しているノウハウや考え方をうまく活用できそうです。 ブログを作るというプロセスを分解してみる ブログをとりあえず書いてみる！という立ち向かい方だと辛くなる可能性が高いことがわかったので、プロセスを分解し、1つ1つ進めていけるようにします。 ブログを作る ゴール設定 誰向けの、要はなにを書くのかを決める（Who/What） それは読み手にどういう得があるのかを決める（アウトカム） 設計 ゴールを前提にどういう章立てで伝えるのが良いかを設計する 実装 実際に文章を執筆する 以上のように分解できます。 まずはゴールを設定する ゴールに合わせて、章立てや構成を設計する 設計に合わせて実装する とはいえ、見通しが完璧ではないので、作成しながら1つ上段のプロセスに立ち戻って軌道を修正していく という、向き合い方ができそうです。 プロダクトを作るようにブログを作っていく 結論、Speeeでは現在は以下のようなプロセスでブログを作成しています。 ブログ作成の流れ 各プロセスでレビューを入れることで、曖昧な状態で次のプロセスに進んでしまわないようにしています。 また、迷ったときには手前のプロセスへ戻り一貫性を確認したり、必要に応じてすでに決めたものでもアップデートしながら進めます。 重要なのは、一貫性をキープすることだと考えています。 ※執筆慣れしているメンバーは上記のプロセスに必要に応じて乗ってもらっています。 ゴール設定 まずは、記事のゴールを設定します。ここで言うゴールは以下を指します。 ゴール設定 誰向けの、要はなにを書くのかを決める（Who/What） それは読み手にどういう得があるのかを決める（アウトカム） 例えば、ある記事だと以下のようなゴール設定になっています。 ■誰向けの、要はなにを書くのかを決める（Who/What） ・TechBlogをはじめとしたアウトプットを頑張ろうとしているけど始められていない人や ・特に社内のブログを書いてほしいメンバー向けの ・最初の一歩を踏み出すきっかけ ■それは読み手にどういう得があるのかを決める（アウトカム） ・踏み出す上での懸念点がシュッっと整理されて動き出せる 実は、上記のゴールを作る前は、「TechBlogを書くと採用に効くので頑張ろう！」というテーマで書き始めていたんですが、 書いている中で、ブログを書くことと採用を無理くり紐付けることが目的化してしまっており、筆が進まなくなったので、 一旦足を止めて上記のようにゴールを設定し直しました。 設計 ゴールが決まったら次は設計です。 前項で決めたゴールを実現するためにどういう章立てや流れの文章であるのが良さそうかを考えます。 先程のゴール設定から以下のような設計を考えました。 ・アウトプットを頑張っていこう、まずは動き出そうぜ、という話 ・アウトプットを頑張りたい理由を明確にする ・採用！でも遠い ・採用とアウトプットの関係を明確にする ・いい記事も大事、続けることが一番大事 ・個人にとってもアウトプットをすることはおすすめ ・そもそもアウトプットをすることは個人の能力開発にもなる ・大事なことはまず始めること ・まずは走り出して考えよ！ ・RTやFBシェア、いいね！とかとの付き合い方 ・アウトプットにはリスペクトを ・SNSはパーソナルスペースなので、記事を薦めるかどうかは個人の判断、押し付けたくないし、期待しすぎたくない 設計上重要視したのは、 踏み出す上での懸念点がシュッっと整理されて動き出せる というのがメイン部分のため、そこから設計をすることでした。 故に、 ・アウトプットを頑張っていこう、まずは動き出そうぜ、という話 ・アウトプットを頑張りたい理由を明確にする ・採用！でも遠い ・採用とアウトプットの関係を明確にする ・いい記事も大事、続けることが一番大事 ・個人にとってもアウトプットをすることはおすすめ ・そもそもアウトプットをすることは個人の能力開発にもなる ・大事なことはまず始めること ・まずは走り出して考えよ！ という部分から記事がスタートしていて、走り出そうぜ！という話をしています。 その上で、走り続けていく上で、「記事を出したのに社内がシェアしてくれない」などの期待値のギャップで続けられなくなるリスクに対して ・RTやFBシェア、いいね！とかとの付き合い方 ・アウトプットにはリスペクトを ・SNSはパーソナルスペースなので、記事を薦めるかどうかは個人の判断、押し付けたくないし、期待しすぎたくない という要素を入れています。 先にこの章立てのアウトラインを決めてから具体の話を作成していくことで、 各章ごとに書くべきことが明確になるため迷わず筆を進めることができるようになっています。 実装 実際に執筆します。 執筆する中で、迷いが生じたら前項までで整理できた ゴール設定 設計 をベースに整理をします。 局部的に修正すると全体の流れがおかしくなったりすることもあるので、上から下を必要に応じて行ったり来たりして一貫性を確認しながら、執筆します。 執筆者自身も最初の設計からすべてを見通せているわけではないので、作成しながら見えてくる部分もあるため作成しながら見通しを良くしていきます。 そして、完成した記事がこちら tech.speee.jp 実際どうなのか？ プロセスを多く踏んでいるので、文章でまとめると手間が増えているように感じますが、 大きな手戻りや、執筆時に迷いがある状態で文章を漫然と書き連ねていくよりも総合的には生産性高く作成できた気がします。 プロダクト開発と同じく、一貫性を確認しながら作成をすすめていくことで方法性が間違ってないと感じながら進むのは大事ですね！ また、完成状態ではなく、各プロセスでレビューをしてもらうことで、 自分が言語化しきれてない部分を整理できる 「いい話！」「このブログ楽しみ」という感想が自分の執筆のガソリンになる という点が非常にいい点でした！ 最後にお決まりの！！！ Speeeでは、不動産やリフォーム、介護領域とやや渋めの領域でプロダクトを展開していて、 どういう風にプロダクトが使われるのかを、プロダクトの創り手がイメージしづらい領域だからこそ、今回のブログ作成で活用したような、 プロダクトを使ってくれるユーザーにとってどのように価値があるのか？という点についての対話や、プロダクト全体での価値提供の一貫性を確認しながら進めていくスタイルで開発を進めています！ 小さなチームで一緒に共通言語を創りながらプロダクト開発していきたい方 技術も好きだけど、ユーザーの課題を理解したりすることがもっと好きで、自分でヒアリング行っちゃいたいです！な方 は楽しく働ける場所だと思います！💁 Speeeでは一緒にプロダクトを推進してくれる仲間を大募集しています！ 様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！ もしSpeeeに興味を持っていただけた方はという方は是非以下のTwitterもしくはMeetyよりお気軽にご連絡ください！🙌 twitter.com meety.net 社内メンバーのカジュアル面談も複数公開しております！💁 tech.speee.jp

※この記事は、Speee Advent Calendar7日目の記事です。 昨日の記事はこちら tech.speee.jp こんにちは、Speeeのヌリカエでエンジニアをしています。21新卒の染谷です。 ヌリカエのTopページのページスコアを改善しました。この記事はどのようなことを考え、何をしてページスコアを改善していったのかという奮闘記になります。 まだまだ改善すべきページはあるのでそのうち第2段があるかも!? ヌリカエの構成技術 バックエンド: Ruby 2.6.5 + Ruby on Rails 6.0.4.1 フロントエンド: slim + jQuery + Stimulus ページスコアとは この記事で言うページスコアとは、PageSpeed InsightsやLighthouseを実行した時に表示されるスコアのことです。Webサイトの読み込み速度をサーバ応答時間やコンテンツのレンダリング時間などを考慮してスコアが計算されます。0~100の数値で計測され、高い数値ほど良いWebサイトという評価を受けます。同じコンテンツのWebサイトであればページスコアが高い方が検索上位に表示されるため、SEO的に重要な指標の一つです。 また、スコア的にはPageSpeed Insightsの方がLighthouseよりも正しいとよく言われます。ただし、LighthouseはGoogle Chromeのデベロッパーツールから使用できるのでlocalhostでも実行できる点は調査向きでとても便利です。 何故ページスコアを上げるのか SEO的に重要だからです。 というのももちろんなのですが、いちエンジニアとしてページスピードが遅いサイトはいかがなものなのかと思っています。ユーザ体験的にページスピードが遅いと「なんだこのサイト。それとも電波悪いのか？」と思ってしまうため、なるべく避けたいです。そのためにページスコアを改善し、ページスピードを速くします。 改善前 改善前のTopページをPageSpeed Insightsで計測したものです。 30点、、、低い、、、 CLS(Cumulative Layout Shift) 以外アウトですね。 ここからページスコア70点を目標として改善します。 調査 まずはPageSpeed Insightsの計測結果ページにある 計算ツールはこちら。 をクリックして下記画像を見ます。これでどの項目をどれほど速くしたらページスコアが上がるかが分かります。 配点が大きく、改善できたらページスコアが大幅上昇にそうなところは LCP(Largest Contentful Paint) と TBT(Total Blocking Time) ということがわかります。 Largest Contentful Paint LCPは最大コンテンツ描画の時間です。ヌリカエのTopページでは職人さんが写った画像がLCPに当たります。これをresizeするなり、元の画像を小さくすれば解決できそうと目星がつきました。 Total Blocking Time TBTは何が影響しているかこのままだとわかりません。そんな時はLighthouseでページスコアを計測します。 Minimize main-thread work を見ると Script Evaluation がTBTを落としている原因のようです。つまりjsですね。 ここからさらに View Origin Trace ボタンを押して Performance タブの内容を見ていきます。 Long Taskと赤くなっているので先ほどのEvaluate Scriptはこれですね。 そしてさらにこれを拡大していくと むむ、何やらLayoutがどうたらこうたらと言われています。jsの中のLayoutで怒られているので多分jsによる強制的にクラスがあてがわれてガチャガチャと要素が動いているのでしょう。 ただし、どのコードがそれに当たるかまではLighthouseから読み取れないので、ローカル環境でコードをコメントアウトしてはLighthouseで計測を繰り返していきます。 コードを二分探索的にコメントアウトしては計測して行き、最後にそれっぽいjsだけをコメントアウトして見ると 🎉 TBTめっちゃ速くなった！🎉 ちなみにカルーセルで使っているslick.jsが原因だとわかりました。 slick.jsを使わずにカルーセルを実装するようにリファクタリングする必要がありそうです。 Speed Index 最後にサーバ応答時間を調査します。 サーバ応答時間はSI(Speed Index) に該当するのでLCPとTBT程、ページスコア的には影響しないのです。しかし、サーバ応答時間が長いとユーザ体験の悪さに繋がります。 この記事を書いている時には既に改善したものをリリースしてしまっているので、改善前のコードをローカル環境で実行して計測します。 4.73s、、、遅いですね。この画面ではこれ以上わからないので、TBTを調べた時と同様に二分探索でコメントアウトしつつ、計測します。また、重いSQLが主な原因であることが多いので、SQL発行の時間を見つつ目星をつけていきます。 重いSQLをコメントアウトして見ると 🎉 応答時間めっちゃ速くなった！🎉 どうやら事例という「クライアントがエンドユーザのお家をどんな施工工事をしたか」の情報を持ってくる処理に時間が掛かっていたようです。SQL実行で700ms使っているところがありました。 どうにかしてSQL実行時間を短くする必要があります。 *事例はリリースしてからそこそこ時間が経っています。重いことに気がつかなかった理由はローカル環境に事例の画像がなく、表示されないという本番環境との差異があったためです。ステージング環境でも画像なかった。本番と環境合わせるの大事。 改善 Largest Contentful Paint これは画像の問題です。ImageMagickを使いpngからjpegへ可逆圧縮し、できるだけサイズを小さくします。また、PC用とスマホ用で同じサイズの画像が使われていました。スマホ用はPC用に比べたら横幅は短くて良いので画像の左右をトリミングしてサイズを小さくします。 ステージング環境での計測結果です。 before after うーむ。LCPがちょこっとだけ速くなりました。あまり効果なかったかも？ Total Blocking Time カルーセルに使っているslick.jsが重いことがわかったので、カルーセル系のライブラリは使わずにjQueryだけで同じ挙動ができるようにリファクタリングします。 ライブラリ使わずにカルーセル作るの簡単なようでめちゃ大変だった、、、 ライブラリの偉大さを実感しました。 ステージング環境での計測結果です。 before after ローカルで検証したのと同じくらい速くなってる！スコアは25点伸びているので本番環境でも結果が期待できそうです。 Speed Index 事例のデータを生成するSQLが原因なのでSQLチューニングをします。といってもそう簡単にできないので困りものです。joinする回数を減らせば速くなるのでしょうが、テーブル設計からやり直すとなると影響範囲が大き過ぎて膨大な工数がかかります。 なので今回は低レベルキャッシュを使います。memcacheやRedisといったインメモリに保存することで事例のSQLが実行されたら1日の間、インメモリに配列としてデータを保存し、保存されている間はSQL実行せずにインメモリからデータ読み込みをするようにします。これでお手軽に700msの時間短縮になりました！ *ただし1日の間は同じデータが表示されることと、最初の1回目はSQL実行で700ms時間がかかるので使い過ぎには注意です。 ステージング環境での計測結果です。 before after beforeとafterでSIにあまり差がないですが、ステージング環境もローカル環境と同じで事例のデータが少ないため、このようになっています。 ヌリカエ開発チームでは、ステージング環境でLighthouse計測し、ページスコアに問題がなかったらリリースという運用をしています。しかし、画像がない事例は表示させない という実装をしてから本番環境と差異が出てしまっていたようで今まで気づきませんでした。本番と環境合わせるの大事(2回目)。 結果 最後に改善で行った開発を全てマージし、LighthouseとPageSpeed Insightsで計測した結果です。 🎉めっちゃページスコア上がってる！🎉 あの30点台だった頃が考えられないくらいページスコアが上がりました。 PageSpeed Insightsでは安定して60点台を出せるようになりました。 ステージング環境ではLCPが思ったより速くなりませんでしたが、本番環境ではしっかりと成果が出ています。SIもしっかり成果が出ました。 ただし、残念なことにTBTはイマイチですね。一つ不可解なのは、TBTがLighthouseでは230msと速いのに対して、PageSpeed Insightsだと990msとまだまだ遅い点です。PageSpeed InsightsはPerformanceタブのように詳細が見れないので謎です。 最後に コンテンツ量と開発速度、そしてページスコアはトレードオフの関係にあると思います。コンテンツ量は良質なWebサイトを作るために致し方がないところがあるので、開発速度とページスコアを考えながら理想のコンテンツを作成するのがエンジニアの腕の見せ所だと思っています。 良質なWebサイトを作るためにページスコアを意識して開発していきましょう！！ Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！ もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください💁 tech.speee.jp エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！