この記事は、筆者が技術選定について思うところをまとめた記事です。Twitterに同じ話を何回か書いているので、文章にまとまっていたほうがよいと思い用意しました。 やや過激な思想で愚痴も含んでいるので、共感いただけると嬉しいものの、みなさんを説得しようというつもりはありません。こいつはこういう考え方なんだなという心持ちでお読みください。 積極的な技術選定と消極的な技術選定ITエンジニアの方々の中には、技術選定をする立場の方も多いでしょう。技術選定にあたってはさまざまな事情を勘案しなければならない難しいもので、それだけに多くの人が技術選定に関する各々の考えを述べています。 筆者は、技術選定における意思決定のプロセスは、積極的な技術選定と消極的な技術選定の2種類があるのではないかと思っています。 積極的な技術選定は、選定される（あるいはされない）技術そのものが原因となる意思決定です。 一方、消極

翻訳者の一人である @yuya_hirooka さんからいただいたアジャイルリーダーシップを読みました。献本ありがとうございます！ この本では、「アジャイル」については知識がある前提で、チームや組織をアジャイルにしていくためのリーダーシップについて学べます。 書籍にも書いていますが、アジャイルリーダーシップはプラクティスではなく「心のあり方」です。 そのため、書いていることが考え方にフォーカスしていて抽象的だと感じるものが多く、実践が難しいかもと思いながら読んでいたんですが、ふと「あれ？でも、今の会社・組織ってアジャイルリーダーシップ出来てるな。」と感じました。 その辺りも含めて、本の感想をまとめます。 アジャイルリーダーシップ　変化に適応するアジャイルな組織をつくる 作者:Zuzana Sochova共立出版Amazon 📖 目次 第1部　アジャイルリーダー　――隠れたリーダーシップを

はじめに 概要 一般的な1on1 目的 実施方法 Product Teamの1on1 目的 実施方法 まとめ Product Teamの1on1の課題とメリット 課題 コーチとクライアントの組み合わせ決めはどうやるのか コーチがクライアントの業務をしらない可能性が高いが問題ないのか 全く話したことのないメンバー同士になる可能性があるが良い1on1になるのか コーチ、つまり全てのメンバーが1on1の意義を理解できている必要があるが問題ないのか メリット コーチ（メンバー）のコミュニケーション能力の向上が期待できる 普段業務でかかわらないメンバーと話す機会になる コーチ（メンバー）が違う視点を持つきっかけになる おわりに はじめに こんにちは！Product Teamのデータサイエンティストの堀内です。 私が所属しているProduct Teamは、リーダーがいないフラットな組織として、ほかのエ

こんにちは、ベースチーム所属の天川です。この記事では、6月から私たちのチームがPdM2人体制になり生まれた問題とそれに対してデリゲーションポーカーというワークを試したお話をします。 ワークを通して役割分担が明確になるだけでなく、できたてのチームで現在のスキル感やこれから挑戦したい業務のイメージが共有できるメリットを感じました。 PdMだけでなく、チーム内で責任範囲が分かりにくく動きづらいと感じる人にぜひ試していただきたいです。 PdMが2人体制になった！ 私が所属するベースチームは、6月に2つのチームが合併して生まれた新しいチームです。元のチームにPdMが一人ずついたため、合併後はPdMが2人のチームになりました。 しかし、コドモン内でも初めての構成だったこともあり、業務の割り振りやメンバーとのコミュニケーションで困りごとが生まれました。2人のPdMとしてのキャリアが半年・1年と浅かったこ

『アジャイルリーダーシップ: 変化に適応するアジャイルな組織をつくる』（原題: The Agile Leader : Leveraging the Power of Influence）という本を、会社の同僚3名と一緒に翻訳しました。 今日、発売です。 www.amazon.co.jp 僕が愛してやまないジュンク堂池袋店にも入荷してました。うれしい。 11/18新刊：ISBN978-4-320-12493-6　共立出版『アジャイルリーダーシップ』Zuzana ochova著　ユーザベース訳　20冊入荷 pic.twitter.com/AAwl2bCFwI— ジュンク堂書店池袋本店 PC書担当 (@junkudo_ike_pc) 2022年11月18日 アジャイルプラクティスを導入し、実践していく方法は20年以上前からさまざまな書籍で語られ続けていますが、チームや、さらには組織をアジャイルへ

アジャイルリーダーシップ を翻訳者の一人であるヒロオカさんにいただいて読みました。ありがとうございます！今の自分にグサッとくる内容でとてもとても良かった。今後の自分の行動も変わりそうです。今日から数日後の11月22日に発売されます www.kyoritsu-pub.co.jp 読みやすかった 著者は SCRUMMASTER THE BOOK を書かれたズージーさん ズージーさんの本自体が読みやすいのと、あと、ユーザベースさんの翻訳が読みやすいのとで、とても読みやすかった。英語の言い回しって日本語にすると分かりにくかったりするけど、そういうのがなくて、自然に読むことができた アジャイルリーダーシップ？ 「アジャイルリーダーシップ」ってタイトルを見たときは、アジャイルなチームのリーダーの話なのかな？スクラムマスターはこうあるべきだよとかって話？と思ったのだけど、読み始めてみるとそうじゃなくて、

はじめまして！GMOペパボの和島（@wajimaf）です。私が勤務するGMOペパボは「ロリポップ！レンタルサーバー byGMOペパボ」をはじめ、ハンドメイドマーケット「minne byGMOペパボ」、ネットショップ作成サービス「カラーミーショップ byGMOペパボ」、オリジナルグッズ作成・販売サービス「SUZURI byGMOペパボ」など、「インターネットで可能性をつなげる、広げる」をミッションにさまざまなサービスを展開しています。 各チーム、それぞれが最適な開発体制を追求しており、もちろんスクラムに取り組むチームも多いです。そして、弊社ではスクラムやスクラムに含まれるプラクティスに取り組んでいるのは“開発”チームだけではありません。バックオフィスや広報など、“開発以外”の業務でも関わるメンバーたちが朝会や振り返り会といったプラクティスを導入し、効率化を進めているのです。 私自身は2010

みなさん、こんにちは。「制御不能なアジャイルモンスター」こと及部敬雄（@TAKAKING22）です。私は現在、 Silver Bullet Club というソフトウェア開発チームに所属していますが、チームでは2017年5月にモブプログラミングを採り入れ、現在も継続しています。こうした経験のなかで得られたモブプログラミングに関する知見を、書籍、記事、コミュニティ活動などを通して発信してきました。また、アジャイルコーチとしてチームや組織へのモブプログラミングの導入支援もしています。 本稿では、モブプログラミングを実際の現場で活用する際に直面しがちな悩みポイントを抑えつつ、個人やチーム、そして組織がモブプログラミングとどう向き合っていけばよいのかについて、ご紹介します。 モブプログラミングとは モブプログラミングの流れ なぜモブプログラミングが必要なのか 分担作業とモブプログラミングの比較 2つ

こんにちはこんにちは!!あやぴーです。 最近の仕事ではF#を使ったり、Clojureを使ったりすることが多いのですが、今日は久しぶりにClojureの話を書きます。 Clojureでテスト書くときに一緒に使うライブラリ何使ってますか？ テスト対象が依存する関数をモックしたい - mockfn 複雑なデータ構造のdiffを簡単に知りたい(あるいはデータ構造の比較を簡単にやりたい) - matcher-combinators モックした関数が取る引数をスマートに制限したい - mockfn & matcher-combinators まとめ Clojureでテスト書くときに一緒に使うライブラリ何使ってますか？ アプリケーションでユニットテストレベルのテストを書くとき、どういうライブラリを一緒に使っていますか？Kaocha？Midje？test.check？shrubbery？Flare？ 今回

アジャイルソフトウェア開発を企業が導入する際に、スクラムと並んで名前が挙がる開発手法にエクストリームプログラミング（XP）があります。ガイドブックや研修が存在するスクラムに対して、ペアプログラミング（ペアプロ）やテスト駆動開発といったプラクティスをエクストリーム（極限的）に実践しようというXPの導入には、どこから始めればよいのかと戸惑う開発組織もあるようです。 2022年6月に開催されたユーザベース主催の勉強会「エクストリームプログラミングで見える開発風景」では、XPの提唱者であるケント・ベックの著作などの翻訳者として知られる角征典さんと、XPを導入しているユーザベースのソフトウェアエンジニアである野口光太郎さんが講演したのち、XPの始め方やエンジニア以外との体制づくりなどについて、視聴者の質問をもとにパネルトークが行われました。 本記事では、組織にXPをどのように導入するか、またスクラム

はじめまして。そーだい（@soudai1025）です。私は普段は技術コンサルティングや受託開発を請け負う合同会社HaveFunTechの代表として、また、予防治療の自社サービスを展開する株式会社リンケージのCTOという二足の草鞋を履き、日々、さまざまなWebサービスの開発に携わっています。 これまでの開発経験のなかで、データベース設計に関わるさまざまな問題に遭遇してきましたが、本稿ではとくに、アジャイル開発時に発生しやすい問題とその対処についてお伝えしたいと思います。開発の現場で目にしやすい実装におけるアンチパターンを示しつつ、アジャイルという指針を維持しながら、対処となるデータベース設計についてご紹介します。 会員登録のアンチパターンと処方箋 イージーな実装とシンプルな実装 Userと言う名の罠 拡張と破綻 データベースは変化に弱い 仕様変更とテーブル変更 Addで変化に追従する 正規化

現代の職場におけるもうひとつの安全性 ハーバードビジネススクールのエイミー・C・エドモンドソン教授が体系化した「心理的安全性」は、人材が活躍しイノベーションが起こる職場の条件として広く知られている。今回の研究で、現代日本の若手においては、心理的安全性が高いだけの職場では活躍できていないことが明らかになった（前回）。そこで、現代の若手が活躍する職場における、ファクターＸとも言える「職場のキャリア安全性」が存在するのではないかと提起した。この「キャリア安全性」と（暫定的に）呼んでいる要素とは何なのか、その性質を深掘りする。 まず、キャリア安全性は統計的には以下のような性質を持つ。 時間視座、市場視座、比較視座の3つの俯瞰的な視点で、“自身の現在・今後のキャリアが今の職場でどの程度持続的で安全な状態でいられると認識しているか”を示す。 「このまま所属する会社の仕事をしていても成長できないと感じる

ゆるい職場時代。若手が成長し活躍する職場とは 前回、「職場環境が厳しくて離職したい」若手と「職場環境が“ゆるくて”離職したい」若手が存在していることが明らかになった。それでは、近年の労働法令改正によってもたらされた新しい環境のなかで、若手と職場の良い関係とはどういったものだろうか。 今回は、若手が成長し活躍できる新しい時代の職場に必要な要素を検討する。その結果として明らかになったのは、「心理的安全性が高いだけの職場では若手は活躍できていない」という実態と、心理的安全性とマイナスの相関を持つが若手の活躍とつながる、あるファクターの存在であった。 「キャリア安全性」 今回実施した調査（※1）からは、大手企業（1000人以上）の新入社員（入職1～3年目の大卒以上正規社員）のワーク・エンゲージメントと関係する要素として、2つの要素が存在していることが明らかになった（図表1）。 図表1　ワーク・エン

仕様書の通りのITシステムをカッチリと時間をかけて作っても、顧客に「依頼したものと違う」と言われてしまう。ソフトウェアエンジニアの「いいものを作りたい」という気持ちがビジネスに生かされていない。そう感じていた平鍋健児さんは、ピラミッドのように大きな建築物を数十年かけて作るやり方ではなく、生鮮食品のように鮮度を大切にしたアジャイルの開発手法に出会い、この20年を実践と普及に取り組んできました。 近年はビジネスの立場からも語られる「アジャイル」ですが、このインタビューではアジャイルを導入する企業がステージや事業規模に応じてどのような課題に直面するのか？ とくに、小さなスタートアップ企業がアジャイルネイティブから大きくなったメガベンチャーだけでなく、旧来の開発手法を続けてきた既存の企業が、自分たちにフィットしたアジャイルを見つけるときに参照できるいくつかの事例とあわせて紹介します。 アジャイルが

こんにちは。株式会社アカツキでエンジニアリングマネージャーをしている、石毛琴恵です。私がマネージメントするチームでは、約1年半前から、スクラムのスケール手法であるLeSS（Large-Scale Scrum）を導入しています。本記事では、「これから自分の環境でLeSSを取り入れたい」「スクラムをスケールさせたい」と考えている方に向け、私のLeSS導入体験やそこから得た学び、失敗したこと、導入した結果や今後の挑戦についてお伝えしたいと思います。 なお、本記事のテーマは、「LeSSの実践」です。そのため、スクラムやLeSSの基本的な概要については、詳しく触れません。これらの基本概念に関しては、スクラムガイドやless.worksをご参照ください。 LeSSを導入した環境について LeSSとはなにか？なにをどのように解決するものなのか？ なぜLeSSを採用したのか LeSS導入のプロセス。チーム

みなさん、こんにちは。 ユーザベースという会社でSaaS事業のCTOを務める林 尚之です。 本日、新しいWebメディア『Agile Journey』がローンチされました。私はこのメディアに編集長として関わりますが、本稿では『Agile Journey』がどんなメディアで、なぜアジャイルをテーマとしたメディアを立ち上げたのかをお伝えしたいと思います。 『Agile Journey』はできるかぎり「実践」にフォーカスしていきたいと考えています。すでに世の中には、アジャイルに関する事柄を解説する本や資料がたくさんあり、「ペアプロってなに？」「TDDってなに？」という問いに対する基本的な解は容易に見つかるでしょう。しかし、「やり方を知る・理解する」と、「それをいかに実践するか」には別の難しさがあります。実際、私も「アジャイルをいかにして、実践するか」に関して日々、頭を悩ませていますし、試行錯誤を繰

はじめに こんにちは。Product Team の竹原です。SPEEDA の「セグメント比較」機能に関する開発を担当しています。 私が所属している開発チームでは、2022年1月〜3月の期間で新しい機能「セグメント比較編集」をリリースしました。 この機能の開発のため、フロントエンド・バックエンドともに新規実装をすることになりました。 しかし開発に着手した直後から2ヶ月間ほどは開発遅延が目立ち、チーム内に暗雲が立ち込めていましたが、 それを私たちがどのような解決策とともに乗り越えてきたのかをご紹介します。 はじめに 遅延の原因は何だったのか 1. 複雑なドメインに対する理解が浅かった 解決策: ペアプログラミングをする際、ドライバー・ナビゲーターの時間配分を工夫する 2. ユーザーストーリー1つ1つの粒度が大きすぎた 解決策: ユーザーストーリーを分割する基準についてチーム内で合意する 3.

こんにちは。 Product Team の相川です。 現在はProduct TeamでINITIALというプロダクトの開発をしております。 前回からアジャイルについてブログを発信していこうと思い、ブログを書き始めました。 前回はユーザーストーリーについて書かせてもらいましたが、今回はそのユーザーストーリーを小さくすることと大きくすることについて説明します。 tech.uzabase.com ユーザーストーリーは小さい方が良い 小さくリリースするので早くフィードバックをもらえる 見積もりがしやすい スコープの調整がしやすい ストーリーを出す時点での考慮漏れが減る ユーザーストーリーを大きくする データとしての関連性があり、ストーリーを分けてしまうと単独では価値がなくなってしまうもの 明らかにまとめて開発した方が効率が良いものたち まとめないという選択肢 ユーザーストーリーを小さくするためにで

はじめに こんにちは。Product Teamの中嶋です。 今回は、日々のペアプロでProduct Teamの皆さんが、普段どういったことを気をつけてペアプロをしているのかをご紹介したいと思います。 はじめに 慣れてない側としてのコツ わからない時は、「わからない」を口に出す ペアにスピード調整してもらう 慣れている側としてのコツ ペアプロ慣れてない人とのペアプロの心得を読む いま、どこを見てますよとちゃんと伝える 視覚的補助を入れる 質問のハードルを下げるためには ピンポンペアリングを試す その他 ペアプロって Apex と同じ？ おわりに モブブロで書いたふりかえり 慣れてない側としてのコツ わからない時は、「わからない」を口に出す 実況中継をするように、自分の頭の中を言葉にするように心がけます。 難しくても、頑張って声に出してみます。逆に話せないと「あ、自分これ分かってないな」って気

はじめに こんにちは。Product Teamの中嶋です。 前回の記事では、Product Teamが普段どんなペアプロをしているのかを書かせていただきました。 今回はペアプロとXPの価値の一つである「フィードバック」について、自分なりに言語化していこうと思います。 はじめに ペアプロは最小のフィードバックループを形成する ペアプロは秒のフィードバック 先生と生徒の関係性では、先生以上の意見が出ない ペアでフィードバックループを回していくには？ わからないことは素直に伝える ドライバーは自分のやっていることを実況する 実況をしながら進める例 積極的に質問をする 肯定のフィードバックも大事 おわりに ペアプロは最小のフィードバックループを形成する XPの価値の一つに「フィードバック」があります。*1 XPチームはできるだけ早く、できるだけ多くのフィードバックを生み出そうとする。フィードバック