この記事は、弁護士ドットコム Advent Calendar 2023の25日目の記事です。 前日は tsuchiya さんの「ログや例外についてレビューや実装時に意識していること」でした。 はじめに: 人と成りては童子のことを棄てたり インターネットの海には、不幸な開発プロジェクトの話が溢れています。例えば「とにかく言われた通りに作ればいいんだ」「スケジュールにコミットしろ」「遅れは徹夜で取り戻せ」「障害を起こしたら減給だ」など*1。 プロダクト開発に携わる人であれば、こうしたやり方が無意味どころか逆効果であることはご存知でしょうか。では、なぜこうしたやり方が提唱されてしまうのでしょうか。 それは、旧来のビジネスの常識*2に照らせば、ある意味でまっとうなやり方だからです。問題は、プロダクト開発においてはビジネスの常識が通じないことにあります。 (加えて、にも関わらず旧来の常識が押し通され

はじめに約1年ぶりのエントリーになります。今回はマネージャーの評価基準というタイトルで書きたいと思います。 マネージャーを評価する基準というのはありそうでないなと、この1年色々な経営者・マネージャーの方と話す中で感じていました。 その時残すべき成果が出ていればマネージャーとしてOKとしている会社もあれば、「マネージャーとしての行動リスト」のようなものが5個〜多くて30個程度であり、その行動リストを評価とまではいかなくとも、チェックリストのように使っている会社もあります。 しかし、前者の場合は「成果が出ていれば色々な犠牲が出てもよし」となりますし、後者の場合は「行動リストのうち今必要が無いことも行動せよ」となるので、両方ともマネージャーを評価する基準としては何か違うなと違和感を覚えてました。 しかし、何を以て良いマネージャーなのか、それを判断する基準がなければ、マネージャーに何を求めて良いか

こんにちは！i3DESIGNデザイナーチームです。 UIデザイナーであれば主にWEBサイト作成時、「ハンバーガーメニュー」を扱う場面が多々あるかと思います。そこで悩ましいのが、ハンバーガーメニューを右に置くか左におくか？という問題です。みなさんも一度はこの問題に頭を悩ませたことがあるのではないでしょうか？そこで、この記事ではハンバーガーメニューを右上・左上のどちらに置くべきか？を考察し、まとめていきたいと思います。 ハンバーガーメニューって引用：https://material.io/components/navigation-drawerハンバーガーメニューとはアプリケーションやWEBサイトで使われるナビゲーションの呼称です。マテリアルデザインでは「ナビゲーションドロワー」と呼ばれています。 ハンバーガーメニューを開閉するボタンには、三本の横線が垂直に並んだアイコンがよく用いられます。こ

こんにちは。SmartHRプロダクトマネージャーのsonchoです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください！ 僕からは先日新たにリリースされた「キャリア台帳」の開発裏話をご紹介します。このエピソードを通じて、SmartHR内のプロダクト開発の雰囲気を感じていただければ幸いです。 はじめに・背景 新規プロダクトの立ち上げを担当することが決まったのは、2023年6月頃でした。翌月から徐々に開発がスタートし、11月には正式リリース時に対応するユースケース・開発アイテム・スコープなどがほぼ決定。僕たちは2024年5月末のリリースを見込んで開発を進めていました。 ところが、マルチプロダクト化の加速に伴い、新規プロダクトにおいても今まで以上に早期の事業貢献が求められることに。まあ簡単に言う

ごきげんよう！SmartHRプロダクトデザイナーのこぎそ（@kgsi)です。 SmartHRで2023年前半から開発に携わっていた「キャリア台帳」が、2024年2月8日についにリリースとなりました。 「キャリア台帳」は、SmartHRで収集した部署や役職、評価推移、スキルなど、タレントマネジメントに必要な従業員情報をまとめて確認できる機能です。今後タレントマネジメント領域を攻めていくSmartHRとして、欠けていたピースを埋める重要なプロダクトとなります。 さて、このプロダクトの開発にぼくは0->1フェーズから関わっていましたが、「初期開発における機能のスコープ決め」「リリース方式の選定」「開発とビジネス価値との接続」「初期フェーズでどのように関わるべきか」など...。プロダクトデザイナーとして、学びや気づきが大きいプロダクトでした。 この記事では、0->1フェーズにおけるプロダクトの開発

はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日本のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう！』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章

保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発⁠⁠、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱　自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ

このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正

はじめに フロントエンドのディレクトリ構成、世の中に色んな「推し」が有って悩みますよね。 例えば、、、 さらに最近は、App Directoryの登場や、それに合わせたNext.js公式の「推し」構成がドキュメント化されたりと、さらに色々なパターンが出てきています。 本記事の趣旨 本記事では、具体的な構成そのものではなく、 様々ある構成を横串で見通して整理できる設計思想を紹介します。 新しい推し構成の紹介ではなく、構成を考えたり決めたりするときに役立つ抽象的・汎用的な指針を提供できればと考えています。 基本となる考え 分割の方向 一般的に、アーキテクチャにおける分割には2つの方向が有ります。 (出典も良書なのでリンクを貼っておきます： https://www.amazon.co.jp/dp/4873119820) これはディレクトリにおいても同じだと思っていて、筆者は分かりやすさのために

はじめにSkillnoteVPoEの安藤です。 今回はEMであれば誰しもが悩み、苦労（工夫）している目標設定・評価について書きたいと思います。 きっかけは#1の頃から参加している「EMゆるミートアップ」で、3月1日開催の#6のテーマがそのものズバリの「目標設定・評価」だったことです。 EMゆるミートアップそもそもエンジニアリングマネージャーという職務は最近になって出てきたもので、ITという比較的新しい業界の中でもさらに新しい役割、と言えるかと思います。（オライリーの書籍も日本での初版が2022年と相当に新しいことが分かります） SaaSプロダクトが隆盛な中、エンジニアチームが継続的にハイパフォーマンスを発揮するため、また事業KPIに対して直線的に貢献できるようにしていくため、プロダクトマネージャーやエンジニアリングマネージャーといった役割の重要性が昨今非常に増してきている、ということと思い

これまで同値分割を信頼できる手法だと信じてきました。最近になってどうして同値分割が信頼できる方法なのかその理由を私が説明できないことに気づきました。この原因は2つあります： 同値分割の分割の基準が不明確であること 後述するいくつかの仮定を満たさない場合、ある同値パーティションの代表値の出力が正しければその同値パーティションの他の値の出力も正しいといえる根拠に乏しいこと この2つから、不明確な基準の同値分割はその信頼性の説明ができないこと、同値テストは後述するいくつかの仮定が満たされたときのみ有効な手段でありいずれかの仮定が満たされない場合はさして信頼できないことが導かれます。 この記事ではこの結論に至るまでの過程について詳しく説明していきます。なお誤りのご指摘は大歓迎です。ぜひ皆さんで議論しましょう。 同値分割とは 後述する複数の文献の同値分割の説明に共通しているのは以下の2点です： 入力

UNITT (大学技術移転協議会) アニュアルカンファレンス 2023 の講演資料を基にした、研究所向け & 技術起点のスタートアップ向けの資料です。『標準化』に関するセッションだったため、ルールメイキング等についても言及しています。

顧客に「要望を聞いて」機能開発してしまっていた過去 解像度を高めて“評価される開発”になるための3つの取り組み 新PdM組織での顧客解像度の上げ方 植木氏の自己紹介 植木遼太氏：私からは「新PdM組織で実践した顧客解像度の上げ方」というテーマで発表します。簡単に自己紹介をしてから本題に移らせてください。 私は植木遼太と申します。先ほどの紹介にあったように、今現在は「楽楽精算」のPdMをしています。約2年前に入社しています。キャリアとしては2010年に新卒からインフラエンジニアとしてスタートして、その後、プロジェクトマネージャー、プロダクトマネージャーと役割を変遷させていったかたちのキャリアを歩んできました。 顧客解像度向上のための取り組みBefore／After では本題に移ります。先ほどのテーマにあったように、「顧客解像度の向上って」という話があります。発表の流れとしては、「そもそもこの

TOPインタビュー実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 実は相性が悪い「開発生産性」と「アジャイル」。うまくいかない開発を好転させるためにPMがやるべきこととは【ryuzee|吉羽龍太郎】 2024年3月26日 株式会社アトラクタ Founder兼CTO／アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『プロダクトマネージャーのしごと』『エンジニアリング

Scrum Fest Niigata 2022 発表資料です。 https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16449 Dan North: �“BDD Is Not About Testing" https://www.youtube.com/watch?v=6nSwRSbc27g

スタートアップにおける悩み事の多くは、組織や人にまつわることと言っても過言ではありません。組織の課題をうまく乗り越えていくために重要なのが「ミドルマネジメント」の存在です。彼らをいかに機能させていけるかによって、事業成長の角度は大きく変わります。 そこで、ALL STAR SAAS FUNDは、スタートアップにおけるマネジメントの第一人者である株式会社EVeMと共に「ベンチャーマネジメント集中講座」を全4回で開催しました。 講師は、EVeMの創業者である長村禎庸さん。大学卒業後、リクルート、DeNA、ハウテレビジョンを経て、ベンチャーマネージャー育成トレーニングを行なうEVeMを設立されました。DeNAでは広告事業部長、株式会社AMoAd取締役、株式会社ぺロリ社長室長兼人事部長などを担当。ハウテレビジョンでは取締役COOとして同社を東証マザーズ上場に導いた経験を持ちます。 いずれの企業でも

アプリエンジニアのくまもん（YOUTRUST/X）です。 細かいUXまで気を配られているアプリは、単純に使いやすいだけでなく、操作していて心地が良く、動きに信頼感があります。しかし細かいUXの議論は、どうしても後回しになりがちで、仕様やデザインモックで厳密に表現しづらい場合もあります。 YOUTRUSTアプリには、プロダクトマネージャーの仕様書による指示というよりは、エンジニアと関係者が自主的に話し合って実装されたと思われるUXの工夫がたくさんあります。今回は、仕様書に載っていないレベルの、細かいのアプリのUX改善についてご紹介します。 デザイン領域に近いアプリの実装の話になりますが、実装パート以外は技術的な知識はあまり要らないと思うので、ぜひ肩の力を抜いて読んでいただければ幸いです！ タッチフィードバック タッチフィードバック セルやボタンをタップしたときに「タップした感」のあるタッチフ

Webプロダクト開発をしていると様々な諸事情によりUI構成を変えたり機能を増やしたり減らしたりすることが多々あると思います。そんな時に避けられない事態として「UI変更に対するお怒りがユーザーからわんさか届いてしまう」ということがあります。今回はUI上の１要素の色を変えただけで虎の尾を盛大に踏んでしまった事件の話をしようと思います。差し当たりどういうUIをどう変えたのかを明示しておきます。変える前がこちら↓↓ beforeUIほんで変わった後がこちら↓↓ afterUIご覧の通り「作業カード」と呼ばれるコンポーネントの色を「緑＆黄」から「緑塗り＆緑枠線」に変更しました。「え、それだけ？」という声が聞こえてきそうですがそうなんです。それだけなのです。しかしここはレガシードメインのtoB SaaS。toB SaaSではUIの変更がユーザー業務への影響に直結するので軽微な変更を加えるのもハードルが

予実管理はなぜ大事か予算(事業計画)とは現在の事業理解を反映したものである。予算は、売上の発生メカニズムやコストの発生メカニズムをモデル化する。モデルの中には変数(パラメータ)があり、基本的にはこの変数を達成していれば、予算が自動的に達成されるという前提で作られる。つまり予算は、その時点での事業の理解そのものを表している。 予算と実績が合わないということは、事業の理解が浅いということである。何かしら前提としていることが間違っている、見落としていることがある、わかっていないことがあるということである。事業の理解が浅いと、どれくらいのリソースを投下するとどれくらいのリターンが得られるかをコントロールできていないことになるため、投資の不確実性が高い状態とみなされる。 投資の不確実性が高い状態だと、資金調達コストが上がる。仮にまったく同じ構造の事業をもつ2社があるとする。コントローラビリティが高い

前振り タイトルは煽りの激しい釣りです。ごめんなさい。 Web業界で今流行っている自称スクラムと、RSGTで語られるような本来のスクラムとの間のギャップが大きすぎて説明が面倒臭くなったのでこの記事を書きました。 いい加減「私たちは自称スクラム開発を完璧に回しているから、スクラムの恩恵を将来得られるだろう」「私たちは本来のスクラムとはかけ離れた別物のスタイルで開発をしている。だからスクラムの恩恵は永遠に得られない」という二重思考を他人にするようお願いするのにも飽きましたしね。 さて本題といきましょう 本題 世間で、特に渋谷や五反田や六本木のWeb企業ではスクラムというものはとても流行っています。 しかしどう考えても、Web企業でよくお目にかかるスクラムと国内トップカンファレンスであるRSGTで語られるスクラムとの間には大きな隔たりがあります。 「うちはスクラムやってます」 カジュアル面談で耳