目次 目次 はじめに 分散システム視点での自動テストシステム 分散システム構成 入力 出力 テスト対象システム コンポーネント ノード Testcase Allocator Cucumber Selenium Browser 事例：食べログで起きた分散システム視点でのFlakyテスト 問題 Flakyテストの事象: "たまに" "不特定" "多数のテストケースが" "Cucumberのstepの60秒タイムアウトエラーで失敗する" Flakyテストの原因調査の複雑さ 原因と対策 「事象A: たまに（4回に1回程度の頻度で）」の原因と対策 「事象B: 不特定 (毎回異なるテストケース)」の原因と対策 「事象C: 多数のテストケースが(テストケース全体の20~70%程度)」の原因と対策 「事象D: Cucumberのstepの60秒タイムアウトエラーで失敗する」の原因と対策 結果 巻き込まれて
BASE BANKでPdMをしている岡です。 先日、あるプロダクトの機能開発にあたってデザインスプリントを実施しました。 すると、「デザインスプリントはチームビルドとしても良い効果がある」という意外な発見がありました。 今回の記事では、このデザインスプリントの意外な効果について書きます。 この記事で述べることのまとめ デザインスプリントはチームビルドとしても良い効果がある 良い効果1：長期的なミッション・ビジョンに立ち返る 良い効果2：不確実性やイレギュラーケースを洗い出せる 良い効果3：機能要件をアクティブラーニングできる 良い効果4：メンバーのプロダクトへのエンゲージメントを高める デザインスプリントとは デザインスプリントとは、新しいプロダクトや機能のアイデアを迅速に検証するための 5日間の集中ワークショップ形式のプロセスです。 具体的には次のようなプロセスで行われます。 各プロセス
組織を変える5つの対話
対話を変えれば組織文化も変わる―。組織内の対話を変えることで、アジャイルな組織文化を築くための実践的な方法を解説します。 オープンな自己表現と相手への理解を促進する「対話診断」を使い、信頼と心理的安全性を築きながら共通の目標に向かって進むための会話の進め方を紹介します。5つの対話ステップ（信頼の構築、心理的安全性の確立、目的の共有、コミットメントの構築、説明責任の遂行）を実例とともに解説し、日々のコミュニケーションを通じて組織内のエネルギーを高めて革新を促す方法を提案します。 迅速な意思決定と主体性を育むアジャイルな組織文化への変革を目指すリーダーやチームメンバー必携の一冊です。 推薦の言葉 はじめに 第I部 1章 ソフトウェア工場からの脱却 1.1 ソフトウェア工場での労働 1.2 アジャイル：人間駆動の開発 1.3 リーンソフトウェア：チームを強化する 1.4 DevOps：運用担当も
Agile Practitioner / CSP-SM, CSP-PO(Certified Scrum Professional) / Modern Offshore Development / Vietnam / Paris Hilton / RareJob / BOOKOFF / TIER IV, Inc.
開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。 そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。 吉羽氏のセッションの内容をダイジェストで紹介しましょう。 本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は後編です。 それでもまだ定量的な報告を求められたら？ それでもまだ、定量的な指標が必要なんだと言われたら、これはなかなか手ごわい状況です。 そういうときにどうするか、という話をします。 これはケント・ベックの
上記は、idとnameそしてroomをプロパティとして持つ、Hotelの型です。 nameが文字列型の必須のプロパティであり、roomというオブジェクトを複数持つことが簡潔に定義できます。 ちなみに、Roomの型は以下のように表現できます。 SDLは非常にシンプルで簡潔であるため、どのような言語を扱う技術者や非技術者でも理解しやすく、チームの枠を超えて、組織のデータモデルを定義するためのドキュメントとして機能します。 一方、欠点として、SDLにはfieldの値を計算して返すResolverの実装が含まれていません。 GraphQLを機能させるためには、何らかの言語でResolverの実装を追加で行わなくてはならず、GraphQLのみをSingle Source of Truthとすることはできません。 Code First Code Fistは、開発者はResolverだけを書くのみでよく
テスト駆動開発の発想×ポモドーロテクニック=『TODO駆動ポモドーロ』で作業効率化する手法を実践してみた - Qiita
この記事の手法は個人的に考えたものであり、効果は個人的な主観です。実際に作業効率がいかほど上昇したのかを数値かしたわけではありませんし、その効果を保証するものではありませんので予めご了承ください。 この記事が刺さると思われる人 副業などで一日の1,2時間で成果を上げる必要がある方 一日の隙間時間を見つけて学習をしている方 ポモドーロテクニックをやってみたけど「イマイチ効果がないな」と思われている方 ポモドーロテクニックとは？ ご存じの方も多いかと思いますが、一応すごーく簡単に説明しておきます。 タイマーをセットし、25分間作業に集中 5分の休憩を取る これを4回繰り返したら、少し長めに休む（30分くらいが目安） ただし、ポモドーロテクニック自体の生産性向上への直接的な寄与は実験によって確認されたものではないそうです。 その辺りはパレオさんのこちらのブログに書かれておりますので気になる方はご
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 世界を代表するAI企業編 世界を代表するAI企業のアカウントを紹介しますが、各社についての詳細説明はこちらの記事を見ていただければと思います。 〜対話型AI編～ OpenAI もはや解説不要。とりあえず脳死でフォロー。 11月に作成されたChatGPTアカウントも。どのように運用されていくのか要注目。 Anthropic ChatGPTの競合として、Claudeという生成AIを開発、運用する企業です。 InflectionAI 創業１年目に、13億ドルの資金調達をしたことやGAFAMやAnthropicの経営者と共にホワイトハウスへ招集されたことで話題となった企業です。 独
Regional Scrum Gathering Tokyo 2024のスライドまとめ #RSGT2024 - スクラムマスダーの日記
2024/01/09から2024/01/12に開催されたRegional Scrum Gathering Tokyo 2024（以下、RSGT2024）のスライドまとめです。 2024.scrumgatheringtokyo.org 本ブログでは、RSGT2024のセッションの発表資料をまとめています。 個人で発見した発表資料のみですので、掲載していないセッションの発表資料がありましたら、コメント欄などで教えていただけるとさいわいです。 0日目 18:40からのセッション ツナガル。ヒロガル。旅がハジマル。 ツナガル。ヒロガル。旅がハジマル。 - Speaker Deck 19:00からのセッション 知り合いを増やしてRSGTを最高に楽しむための会 1日目 10:00からのセッション Dynamic Reteaming, The Art and Wisdom of Changing Tea
企業のDXの取り組みや組織設計、マーケター育成などをテーマにトップマーケターを招くグロースXのセミナーに、『なぜ「つい買ってしまう」のか？ 「人を動かす隠れた心理」の見つけ方』の著者で、同社執行役員の松本健太郎氏が登壇。「調査を通じて顧客理解を深める具体論」をテーマに、デジタル時代のマーケターに求められるスキルや、SORフレームワークで態度変容を促すアプローチについて語りました。 前回の記事はこちら なぜ顧客理解のための定量調査の結果が腑に落ちないのか 松本健太郎氏（以下、松本）：今までお見せしたのが、「定性と定量を使い分けた顧客理解」というアプローチになります。今日視聴されている方はリサーチャーの方が比較的多いと思いますが、「いや、自分のアプローチと違うかも」とか、「ちょっとここは独特だよね」というところは、恐らくあると思います。 ただ、定性と定量を使い分けて、定性に必要なアプローチと定
「NO」と言うのはメチャ重要 及川卓也氏（以下、及川）：逆に言うと、リソースが限られているからこそ研ぎ澄ます時に、どこを削るべきかというのができる。 吉羽龍太郎氏（以下、吉羽）：そう、それが振りで、「NOと言う覚悟」の話をしようかなと思っていたんですけど。 及川：あと、あれですよ。「未完成なプロダクトを人に使ってもらう覚悟」というところにつながってくるんですよね。 吉羽：そうそう、そうそう。そのあたりの話をしていけたらいいかなと思うんですけど。 「NO」と言うのはメチャ重要だなって。僕らはすごく気軽に「NOと言ってください」と言うんですけど、いざ言うとなったら、むちゃくちゃ難しいワードだと思います。 及川：そのとおりですね。でも、「NO」と言っていますよね。 吉羽：そう。自分の経験上まあまあ言っていると思うんですけど、けっこう慣れが必要な気もしますよね。 及川：そうですよね。私は吉羽さんと
『Driving Value with Sprint Goals』は、スクラムのスプリントゴールに絞ってまるまる1冊書かれた本です。 不確実性とプランニング 第1章では非常に重要なことが述べられています。「手前の霧」と不確実性を霧というメタファーで表現していますが、ソフトウェア開発においても霧に覆われた状況に置かれることがままあります。この時に本物の霧に対してはやらないのに、何故かソフトウェア開発では、霧が存在しないかのように振る舞ったり、霧を取り除こうと考えたり分析したりできると信じたりしてしまうことがある、と指摘しています。実際に目前を霧に覆われた状況に置かれたら、計画を立てるよりも、慎重に進んでみて新しく明らかになった情報を元に次の行動を判断する。それを繰り返すはずだ、と。これは非常に秀逸な喩えだと思いました。 不確実性や複雑性に遭遇したときに、人はそこに解決策があると考えるために、
[読書] エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング～ 読んで自分の理解をまとめてみた | DevelopersIO
[読書] エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング～ 読んで自分の理解をまとめてみた ゲームソリューション部の新屋です。 長い間積み本だった「エンジニアリング組織論への招待」を読了しましたので、私なりのまとめ・感想を述べていきます。 まとめ エンジニアリングで不安と立ち向かう！ その心構えと不安の正体と分析、そして立ち向かう方法について教えてくれる本でした。 感想 上司が「視座を高く・視野を広く持て」とよく言われますが、大志を抱け、くらいのエールみたいなものだろうとずっと考えていました。本書を読むとその意図がちょっとわかった気がします。 自分はPMという立場ではありませんが、本書で紹介されているマネジメント手法は積極的に使っていけると思います（エンジニアから提案するシーンは多いですし） 本書では、開発現場で起きる数多くの問題たちが紹介されています。も
![[読書] エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング～ 読んで自分の理解をまとめてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/28da6328f8613d3f22dab21ae3790ab0f72d2e3d/height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2F1dD7b8HkT2sbiJzUIewMTD%2Fe5cdc6f33c4fdd9d798f11a4564612ff%2Feyecatch_developersio_darktone_1200x630.jpg)
再発防止策からダブルチェックを撲滅したい話
GMOアドパートナーズのtakedaです。 長年システムエンジニアやってると事故の一つや二つは起こすことあると思います。規模の大小はともかくとして。 で、事故対応に必ずついてくるのが再発防止策。ここで「確認不足のためダブルチェックします」みたいな防止策を述べたり見たりした人はまあまあ多いんじゃないでしょうか。これを撲滅したいっていう話をします。 あ、きちんと設計されたダブルチェックは有意義なものなので、そこは誤解されないよう始めに断っておきます。 なぜ撲滅したいのか ダブルチェックを再発防止策に採用することにはいくつか問題があると思います。 ・単純に工数が増大する 当然ながらチェッカーの工数がかかります。さらにいうとチェッカーたり得るのはより生産性の高いエンジニアであることが多く、チームとしての生産性に悪影響があります。 ・問題を未然に発見するための施策であり、そもそも問題を作りこまないと
新刊『時短の一流、二流、三流』が好評の越川慎司氏が開設するVoicyチャンネル「トップ5%社員の習慣ラジオ」。今回は「私のキャリアは運命の出会いで磨かれた」と題した放送回の模様をお届けします。ソフトウェア開発で注目され、さまざまなビジネスシーンで活用できる2つの手法を紹介しました。 ■音声コンテンツはこちら ソフトウェア開発で注目された2つの手法 越川慎司氏：今回は「アジャイル」と「スクラム」について、ご紹介します。共にソフトウェアの開発手法として有名です。2000年代に世の中の変化が激しくなったことで、要件定義から検証、テスト、リリースまで時間をかけてしまうと、変化に対応できなくなるというものですね。 例えば家庭用ゲーム機。「PlayStation」や「スーパーファミコン」「NintendoSwitch」「Wii」といった据え置き機は、3年から4年かけて新しいものが出ます。例えば「Pla
私の好きなRubyで世の中に価値を届ける、わからないものをわかるための距離のつめ方【Rubyistめぐりvol.3 しおいさん 後編】 - STORES Product Blog
Rubyist Hotlinksにインスパイアされて始まったイベント『Rubyistめぐり』。第3回はしおいさん（塩井美咲さん）をゲストに迎えて、お話を聞きました。こちらは後編です。 hey.connpass.com ホビーとしてのネットワーク 藤村：RubyKaigi 2021があり、そこから今回のRubyKaigiの発表に至るまでのルートを聞きたいです。 しおい：間にRubyKaigi 2022があるんですが、2021から2022までの間にちょっと落ち込んだりした時期があったという話をしていいですか？ 藤村：もちろんです。 しおい：振り返ってみると自分はプログラマではない人生を30年以上ずっと生きていて、ほぼ33歳でプログラマになったので、そうなる前と後とで自分を構成しているいろんなものが変わったんですね。住む場所も、仕事も、人間関係も、趣味も、余暇の時間にやることも変わって、そうする
プロジェクトを成功させる2つの技法『BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？』
超巨大ビルを建設したり、前例のないプロジェクトを成功させるなど、 どデカいことを成し遂げたヤツらはなにをしたのか？ サブタイトルの答えは、ITエンジニアにおなじみの 「モジュール化」 と 「イテレーション」 になる。 モジュール化とは、システムやアプリケーションを独立した部品（モジュール）に分割する設計手法のこと。分割することで複雑なシステムを管理しやすくし、保守性や品質を向上させることができる。 イテレーションとは、アジャイル開発において、計画・開発・テストを繰り返し行う短い開発サイクルのこと。反復を繰り返すことで、顧客からのフィードバックやリスクの発見を早期に行い、対策を講じやすくする。 モジュール化とイテレーション、この2つが、プロジェクトを成功に導く鍵になる。そしてこの手法を、システム開発ではなく、巨大プロジェクトに応用せよという。本書では、エンパイアステートビルの建築や、ピクサー
曖昧さが目立つFujitsu Uvanceとは？─富士通の「コンサルタント1万人計画」を検証する［後編］ | IT Leaders
IT Leaders トップ ＞ テクノロジー一覧 ＞ ベンダー戦略 ＞ 市場動向 ＞ 曖昧さが目立つFujitsu Uvanceとは？─富士通の「コンサルタント1万人計画」を検証する［後編］ ベンダー戦略 ベンダー戦略記事一覧へ [市場動向] 曖昧さが目立つFujitsu Uvanceとは？─富士通の「コンサルタント1万人計画」を検証する［後編］ 2024年4月10日(水)田口 潤（IT Leaders編集部） リスト 「Fujitsu Uvance（ユーバンス）」は2021年10月、富士通が掲げるパーパスの実現に向けて「社会課題の解決にフォーカスしたビジネスを推進する」と謳って発表したものだ。Uvanceは、「あらゆる（Universal）ものをサステナブルな方向に前進（Advance）させる」という2つの言葉を合わせた造語であり、これからの富士通の中核を担う事業を指す。発表から2年半
いろんな現場でちょいちょい話題になるので「前にツイートしたなぁ」と見てみたらすっごい長かった。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。— irof (@irof) 2020年9月17日 諸悪の根源？ とりあえず全文転記。誤変換とかもそのまま。 コメントあると「対応しなければならない」ってなるの。あれが諸悪の根源だと思ってる。 目に見えてる問題を潰したくなるのはごく当たり前の感情だと思うけど、目に見えてるもの全て潰したからと言って完璧にはならないことは理解する必要がある。言えるのは「目に見えるものはない」というだけで……そしてコメント対応とかだと、「見た目」のメタファすら使えなくなる。 「コメント対応」のような問題の潰し方をすると必ず歪になる。これは自分の目で見つけたものなら曲がりなりにも「自分の目」の精度は高くないものの一定の見方ではあるのに対し
ユーザーストーリー起点のUIデザインに潜む罠 ~モーダルな機能の実装を防ぐ~｜Takashi Ohmori
アジャイルサムライ――達人開発者への道-Ohmsha Jonathan Rasmusson 著／西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳 shop.ohmsha.co.jp Wevoxの開発も例に漏れず、リサーチやユーザーから寄せられた声といった一次情報をベースにユーザーストーリーを作成し、アジャイル的に企画→実装につなげるといったプロセスを踏む機会が増えてきました。 自分自身、ユーザーストーリー起点での企画では、 ■早い段階で、なんとなく解決方法が見える ■ユーザーニーズの解像度を上げた状態でUIデザインに入れる という実感があり、ユーザーストーリーを重宝し盲信していました。そう、あの日までは、、 改善プロジェクトのMTGで抱えた違和感 数ヶ月前、「Wevoxのユーザビリティを、問い合わせ起点から改善する」というプロジェクトのMTGにアサインされました。 Wevoxでは、お問い
Amazon BedrockのAPIをPythonアプリから呼んでみよう。LangChainにも挑戦！ - Qiita
import boto3 import json bedrock = boto3.client(service_name='bedrock-runtime') body = json.dumps({ "prompt": "\n\nHuman:KDDIアジャイル開発センターってどんな会社？\n\nAssistant:", "max_tokens_to_sample": 300, "temperature": 0.1, "top_p": 0.9, }) modelId = 'anthropic.claude-v2' accept = 'application/json' contentType = 'application/json' response = bedrock.invoke_model(body=body, modelId=modelId, accept=accept, conte
はじめに BASE でプロダクト開発をしている @rry です。 さいきん BASE では 予約販売 App にて「長期の予約商品」を設定できるようになりました！ baseu.jp 🗓️予約販売期間が1年先まで延長可能 🧵製作や入荷に時間がかかる商品も取り扱いやすく 🎄季節の限定商品を事前に販売開始も◎ 今までの予約販売 App では最長で8週間までしか予約設定することができず、オーナーさんからのフィードバックでも「8週間先も設定できるようにしてほしい」という要望が多かったため、このたび予約販売長期化 PJ として機能改修を行いました。 この PJ の裏側を開発目線からご紹介していこうと思います。 PJ 概要 PJ キックオフから10/19リリースまでの期間：約8ヶ月 PJ メンバー：開発エンジニア 2-6人、QA エンジニア 1人、PM 1人、デザイナー 1人 アジャイル・スクラム
この記事はfreee 基盤チーム Advent Calendar 2023 の2日目の記事です。 こんにちは、freee の 権限管理基盤マイクロサービスを開発するチームでエンジニアリングマネージャーを務めている sentokun と申します。今回はその権限管理基盤チームの体制について語っていこうと思います。チームビルディング的な話としてお役に立てれば幸いです。 長い記事となったので、5日目との前後編でお送りさせていただきます。後編はこちらで公開予定。 チーム体制はざっくり以下の図のように立ち上げ期、探索期、構築期を経て現在に至っており、この記事では現在について記載していきます。後編では現在に至るまでの話を記載します。 チームの歴史イメージ 権限管理基盤とは？の記事: developers.freee.co.jp また、この記事では ユーザー = 基盤を利用する freee プロダクトとし
UXデザイナーがClaude3.5で生成したReactアプリをエンジニアが修正し2時間でリリース！両者の作業と感想を語ります - Qiita
UXデザイナーがClaude3.5で生成したReactアプリをエンジニアが修正し2時間でリリース！両者の作業と感想を語りますチーム開発React感想文生成AIclaude こんにちは。KDDIアジャイル開発センターのサービスデザイナー よねみちです。 生成AIを用いたto Bプロダクトのスクラム開発や、お客様のDX・新規事業創出のきっかけとなるデザインスプリント支援などを行っています。 はじめに Claude3.5 SonnetおよびArtifact機能の公開から約半月が経ちましたが、皆さま触ってみましたでしょうか？ AIが生成したアプリやフロー図などのプレビューが見えて動かせちゃうあれです。今日時点は無料で使えますのでぜひ。 エックス等で様々なインフルエンサーが取り上げていますのでご存知の方は多いと思います。 「アプリが3分で完成！！」「エンジニア不要！！」なんて暴論は置いておくとして、
タスクマネジメント_基本編 | ドクセル
レッドジャーニー(https://redjourney.jp/) 所属のアジャイルコーチ 元ギルドワークス 所属 様々な規模のSIerでのシステム開発を経て今に至り、約10年で40の組織、80のチームを支援している。 「ええと思うなら、やったらよろしいやん」を口癖に、社内のみならず社外のチームがより良くなるお手伝いなど日々活動中。 ・認定プロフェッショナルスクラムマスター(CSP-SM) ・認定プロダクトオーナー(CSPO) ブログ：サウスポーなエンジニアの独り言
スクラムマスターの 「真のリーダー」を考える
J.K (コサカ ジュンキ) スクラムマスター / Agile Japan EXPO 代表理事 Agileで日本から世界を楽しく！ 三島から日本を楽しく！ Agileの世界とエンジニアコミュニティにどっぷりハマっている元製造業の人。三 島のアジャイルオタク。三島サテライトオフィス長(New) ソフトウェア開発でプロセスやコミュニケーションに課題を感じていたところア ジャイルに出会い、以降、アジャイルの世界へのめり込む。 開催した研修から200名の有資格者を輩出。現在はAgileとScrumの専門家と しての知識や経験を活かしながら組織開発に従事。カンファレンス運営などを 通じ、日本にAgileが楽しく広まることを夢見て日々活動中。
アジャイルにおけるフロー効率を追い求めた結果、開発メンバーのエンゲージメントが低下したので改善した話 - バイセル Tech Blog
はじめに こちらは バイセルテクノロジーズ Advent Calendar 2023 の 2 日目の記事です。 前日の記事は早瀬さんの「開発効率を上げるためのモダンなフロントエンド構成」でした。 こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部開発 2 部でバックエンドのテックリードをしています藤澤です。 現在私の所属しているチームではアジャイル開発を取り入れて開発に取り組んています。その中でフロー効率を重視して価値提供のスピードを上げる取り組みをしていたのですが、思わず開発メンバーのエンゲージメントが低下していまうという問題が起きました。今回はその問題の経緯とそれをどのように改善したかについてまとめたいと思います。 はじめに 元々チームが目指していた姿 実践していたこととその成果 フロー効率を重視して起きた問題 機能が完成し切らない時がある 個人の成長実感がない 自身の重
この記事は元々LinkedInに英語で書いた記事を、せっかくだから日本語に翻訳してちょっと手直ししたものです。先に英語で書いて、その後日本語にざっくり訳してるので何か日本語が微妙ですが許して。 最近、Org Topologies というフレームワークに興味を持っています。アジャイル組織の成熟度、ケイパビリティを評価するツールで、それを2軸のマップ上にある、16種類のアーキタイプにシンプルに可視化・分類することができます。 www.orgtopologies.com その Org Topologiesを、最近支援に入っているログラス社内に紹介してみました。同社では、1つのプロダクトを複数の機能領域に分け、それぞれの領域を独立したスクラムチームが担当しています。各スクラムチームは、単独のチームとしての能力は高いのですが、チーム間の連携はそれほどしていない状態です。 そんなログラス社内で有志を集
はじめに こんにちは。カケハシでPatient Engagementという新規事業に関わるプロダクトマネジャー（以降PdM）を担当している渡部と申します。現在はこれらの事業を加速させるために、いわゆる0→1フェイズ、かつ、SoE(System of Engagement)の側面が強いプロダクト・サービスの企画開発をしております。 カケハシではスクラムでのアジャイル開発が共通して採用されていますが、前述のプロダクト特性上、お客様ごとに置かれている状況も考え方も異なる状況下であるべきを模索し続ける必要があります。いわゆるVUCAそのものなサービス開発に日々取り組んでいます。 そんな不確実性が高い状況下で仮説検証サイクルを最速にできるよう、我々のチームのスプリントのタイムボックスは1週間、スクラムチームの成果物の一つであるインクリメントを生み出していくという活動をしています。このとき、日々プロダ
「Hatena Engineer Seminar #26 エンジニアリングマネージャー編」は、開発組織のエンジニアを統括するCTOとはてなブックマーク・マンガ投稿の開発を担当するチームの3名のEMが、組織づくりの観点または各人のキャリアやチームで実践した取り組みについて紹介するイベントです。ここでマンガ投稿チーム EMのshimobayashi 氏が登壇。EMになり、自身が知らない2つのチームを任せられた時に行った施策について発表します。 EMという働き方になってマインドチェンジが必要になった shimobayashi氏：よろしくお願いします。それでは「『いい感じにしといて』を支える技術」ということで発表しようと思います。 自分はid:shimobayashiと申します。2023年2月頃から「EMってことでよろしく」となり、そのタイミングでこれまでいたチームから別のチームに異動することにな
地球の裏側アルゼンチンのiOS技術カンファレンス Swiftable 2023 参加レポート (DAY 2) | DevelopersIO
はじめに 多くのクラスメソッドの社員さんはアメリカ・ラスベガスのAWS re:Invent 2023に参加していた中、一人だけアメリカ大陸を南下したリルオッサです。 この度、アルゼンチンのブエノスアイレスで開催されるiOS技術カンファレンス Swiftable 2023に提出したプロポーザルが採択されたのでスピーカーとして現地に行きました。 アルゼンチンで開催と言っても、スピーカーや参加者の方の国籍は多種多様でスペイン、ドイツ、オランダ、ウクライナ、アメリカ、メキシコ、ウルグアイ、ブラジル、ペルー等といった国際的なカンファレンスになっています。 Day 1の記事は地球の裏側アルゼンチンのiOS技術カンファレンス Swiftable 2023 参加レポート (前夜祭 ~ DAY 1) Day 1の雰囲気はこんな感じでした。 This is Swiftable - Day 1 🧉 🇦🇷
その人の人生を狂わせるくらいの巻き込む能力が必要 吉羽龍太郎氏（以下、吉羽）：2つ目の「ヒトを巻き込む」という話も出ました。このペースでしゃべったら絶対終わらないので、そろそろ次のテーマにいきたいと思います。 次が今、及川さんから振りがあった、「ヒトを巻き込む覚悟」ですね。ちょっとこっちについて話していきたいと思うんですけど。 これもいろいろな話がありますよね。人といっても、自分のチームのメンバーも人じゃないですか。それから、ステークホルダーも当然巻き込む対象になってくると思うんですけど。 ユーザーに関しては、下で触れようと思うので1回置いておいて、チームとステークホルダーという観点でいうと、どんな覚悟が必要ですかね？ 及川卓也氏（以下、及川）：人の人生を狂わせちゃうかもしれないわけで。 吉羽：（笑）。 及川：スタートアップは、「俺の会社でこのプロダクトを作って世界を変えようぜ」と言って、
どっちもハッピーじゃない受託開発の問題 坂東孝浩氏（以下、坂東）：先ほど「納品が邪魔だよな」と言ったんですけど、たけちゃんももともとITの会社を経営していて、IT業界では「納品が邪魔だよね」って普通に思うことなんですか？ 武井浩三氏（以下、武井）：いや、普通ではないですよね。まだまだマイノリティです。基本的には受託開発とか請負とかって言われますけれど。僕らはよく「IT土方」とかって言うんですけど。 坂東：土方ね。 武井：家を建てるとかビルを建てるとかと一緒で、設計図を作って、建物を作って、完成したら引き渡す感じで、システムも引き渡しするんですよね。でも、引き渡しした瞬間に基本的には「もう後のことは知りません」となるんですね。 もちろんメンテナンス契約とかはあったりしますけど、どこまで責任を持つのかというのが、作る側と金を払う側で（話が噛み合わない）。だからしょっちゅうでっかい訴訟があるんで
スタートアップの開発責任者から上場ベンチャーのPdMに転身して1年を振り返る - JMDC TECH BLOG
こんにちは、こんばんは。株式会社JMDC 製薬本部企画部 兼 プロダクト開発部の小邦です。 当社が製薬企業向けに提供しているヘルスビッグデータの分析を行えるプロダクトであるJMDC Data Mart（愛称：JDM）のプロダクトマネージャー（以下、PdM）を務めています。JDMは提供16年目を迎えたご長寿プロダクトで、今なお社内における売上貢献度が高い重要なプロダクトの1つです。 今年、JMDCではアドベントカレンダーに参加しています。 qiita.com この記事はJMDC Advent Calendar 17日目の記事です。 記事を書いているのは2023年12月1日。昨年の12月1日に入社してから、ちょうど1年を迎えました。 この記事では前職でスタートアップ企業の開発責任者を務めていた私が、上場ベンチャーであるJMDCでPdMを1年間務めて感じたことや、気づきを述べていきたいと思います
アウトプット自体は元々個人ブログで書いていたのですが、それも2年前くらいから始めたにすぎなかったはず。 個人ブログからZennに移ったのは、「やっぱり技術の情報を求めて人が集まっているところに情報を投下しないと見てさえもらえない」事実に気づいたからです。 そこからコツコツと0からアウトプットを続けた結果、LaravelのMiddlewareに関する記事を出したあたりから認知度が上がったように思います。 PHPer界隈で有名な方々の多くが記事を取り上げてくださったことが今振り返ると非常に大きかったです。 それからコツコツと記事を積み上げて来たわけですが、ようやくZennで記事を書き始めてから1年が経ったようです。体感時間的には3年前ぐらいから記事を書いてるような感覚でした。 そんな節目を機に、この1年で書いた記事の中で反響が大きかったものを振り返ってみようというのが今回の記事です。 「どうい
TRACERYプロダクトマネージャーのharuです。 システム開発チームのメンバーとして、ユーザーから「この機能が欲しい」と依頼されたとき、どのように対応しますか。 このような場合に役立つのが、依頼された内容を要望、要求、要件に明確に分類する考え方です。 本記事では、依頼された内容を要望、要求、要件に分類し、要件を導き出す方法について説明します。 要件定義の目的とゴールについては、以下の記事を参照してください。 tracery.jp 要望、要求、要件の3段階で考える 要望 要求 要件 要望、要求、要件の例 要望の発生 要望をうけてすぐに開発するリスク 背景、目的の確認 目的を実現するための手段の再検討（要求の完成） 要件の検討（要求から要件へ） 機能要件 非機能要件 要件の合意 要件から、設計、実装へ 最後に 要望、要求、要件の3段階で考える 開発の依頼内容は、以下のように要望、要求、要件
就活生向けにIT業界の各種業態について説明などをさせて頂いていることもあり、就活生からの相談で「経験を積みたいのでSESが良いと思いますがいかがでしょうか」などとご相談を頂くことが定期的にあります。 一方でXでは定期的に盛り上がるSESに関する論争があり、System Engineering Serviceという元々の名称では一括りにできないほど多様化が進んでいます。今回はSESを巡る論争を整理していきたいと思います。 有料設定していますが、最後まで無料でお読みいただけます。もしよければ投げ銭感覚で応援をお願い致します。 SES界隈を整理する結論としては「会社に依る」のですが、ある程度のゾーニングはできると考えています。 SES企業の分類（目安）親会社が大手のSES親会社が大手企業であるSESの場合、しっかりと予算をつけて採用を展開する傾向にあります。人材紹介から未経験を積極採用しているの
表題の通り、株式会社はてなを退職します。本日が最終出社日でした。 はてなでお世話になったみなさま、本当にありがとうございます！ はてなでは何をしていたの？ 開発のこと、何もわからないけどスクラムマスターになった 念願の記事の有料販売機能を出せた！ いろんなイベントに出店してユーザーさんと交流できた！ 【付録】直近のお仕事 次は何をするの？ 改めて感謝！！ はてなのみなさま ブログユーザーチームのみなさま 仕事を通じて関わってくださったみなさま はてなでは何をしていたの？ はてなには2018年12月にアルバイト入社し、正社員を経て、まる5年間、ユーザー向けのはてなブログを担当してきました。 アルバイトから、2021年にプランナーとして入社して、できることはなんでもやるぞ、という気持ちで色々なことに手を出し、たくさん失敗し、怒られつつも、最終的には、サブディレクターとして、ユーザー向けのはてな
はじめに エンジニアに転職してそろそろ1年になります。 この1年で読んだ本、良かったサービスを紹介します。 書籍の紹介 Python1年生 第2版 体験してわかる！会話でまなべる！プログラミングのしくみ 転職活動を始める前にプログラミングの向き不向きを判断するために読みました。 基本的なプログラミングの概念やPythonの基礎が分かりやすく解説されています。 独習Python Pythonの基礎文法はこれ一冊で十分です。 多くの文法書がありますが、一冊終える頃には自分で調べて問題解決できるレベルになるので、この本に限らず自分に合った文法書を一冊学習すれば良いと思います。 スッキリわかるPythonによる機械学習入門 教師あり学習・教師なし学習など機械学習の基礎が学べます。 これ一冊だけでもかなり分かりやすくなっていますが、Pythonの文法を一通り学習した後で取り組むと、よりスムーズだと思
人気の開発手法であるアジャイル型開発は開発作業を複数のフェーズに分割することを奨励している。だが、アジャイルは「分割する各フェーズに何を含めるべきか」といった詳細なガイダンスはほとんど提供していない。それは、アジャイルが“開発哲学”といったもので、具体的な手順を説明するものではないからだ。 こうしたギャップを埋めるのに役立つのが、「機能駆動型開発」（Feature-Driven Development、以下、FDD）などのフレームワークだ。FDDは本質的にはアジャイルを実現する手法の一つで、「機能」を軸にしている。“開発作業を5つのフェーズに分割する”という具体的で構造化されたアプローチを採用している。 FDDとは何か 繰り返しにはなるが、FDDはアプリケーションの“機能”を軸にした開発手法だ。FDDを採用する開発者は、実装または改善する機能を特定してから新たな機能セットの開発に取り掛かる
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flakyテストから学ぶテスト自動実行分散システム設計入門 - Tabelog Tech Blog
多様な職種を交えてデザインスプリントをした話 - BASEプロダクトチームブログ
アジャイルの価値を活かせる受託開発案件の取り方・始め方 | ドクセル
ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（後編）
GraphQL Server実装におけるSchema FirstとCode Firstの比較
生成AIの進化に置いてかれないためにフォロー必須なアカウント47選 - Qiita
顧客理解のための定量調査、なぜ結果が「腑に落ちない」のか？ 「定性調査 x 定量調査」による顧客の解像度を高める“型”
「理不尽な要求にはサラリーマン人生を懸けてでも『NO』と言う」 プロダクトマネージャーにとって重要な“NOと言う覚悟”
Driving Value with Sprint Goals - Qiita
変化の早い時代は「リリース→バグ→修正」で完成度を高める 「ポケモンGO」に見る、アジャイル開発の極意
コードレビューのコメントすべてに対応する必要があるか - 日々常々
予約販売長期化 PJ の開発の裏側 - BASEプロダクトチームブログ
freee 権限管理基盤を開発するチームの今を語ろう！ - freee Developers Hub
Org Topologies を少し使ってみた - bonotakeの日記
VUCAと共にあるプロダクトバックログ - KAKEHASHI Tech Blog
EMに求められる「いい感じにして」を叶える4つのステップ 課題が示されない中で、課題を発見して管理・解決する
「チームの理想の状態は“巻き込み巻き込まれ”になっていること」 及川卓也氏が語る、プロダクトマネージャーの「ヒトを巻き込む覚悟」
システム開発を進めるのに「いっぱい人を入れる」のは間違い 一流の人が集まってもトラブル続きの“負の遺産”ができてしまうわけ
ここ1年間のはてなブックマーク数の多かった記事から、Zennでウケそうな記事の傾向を考える
要件定義の重要ポイント〜要望・要求・要件を見極める - TRACERY Lab.（トレラボ）
SES界隈が混とんとしてきたので分類してみた｜久松剛／IT百物語の蒐集家
はてな退職！感謝の気持ちを込めて #ありがとうはてな - ♡rariwow.info♡
エンジニア1年目に読んだ技術書 - Qiita
テスト駆動でもデータ駆動でもない 「機能駆動開発」とは何か