WEBサービス開発みたいな界隈でもう5年マネージャー業をしているので、おそらく人並みにはプロジェクトマネジメントの手法に触れてきている。実際やってきたこともあれば、やってはいないが事例やテクニックとして知っていることも含む。*1 そうやって過ごしてきたが、結局プロジェクトマネジメント手法よりも絶対にどうにかする覚悟、つまり精神論の方が重要だという個人的な結論に至っている。 どんなに精緻に工数とリスクを見積もって振り返りを繰り返しても、「まあ遅れてもいいや」という空気ではプロジェクトは遅延し続ける。逆に見積もりが雑でも「どうにかする覚悟」さえあればなんとか目標とした期日に間に合う。 もちろん覚悟と精神論でやっていると残業が常態化して炎上と言って差し支えない状態になるのだが、覚悟がなくて遅延したプロジェクトも最終的に炎上としか言いようのない状態になるので、同じ炎上なら期日に間に合っている方がマ
「DevOps」とは？〜超基本から実践のポイントを解説〜|インシデント管理プラットフォーム│PagerDuty
変化の激しい市場に対応するための開発手法として、アジャイル開発を導入する企業が増えるとともに、「DevOps」への注目が高まっています。しかし一方で「DevOpsという言葉は聞いたことはあるけれど、実際にはよくわからない」という方もいらっしゃるのではないでしょうか。DevOpsは「開発担当者と運用担当者が密に連携することで、柔軟でスピーディーな開発を実現する」というソフトウェア開発手法の一つです。DevOpsは単なるトレンドではなく、現代のソフトウェア開発において非常に重要な考え方でもあります。本記事では、DevOpsを一から理解したいという方にもわかるように、DevOps誕生の歴史を簡単に紐解きながら、DevOpsの考え方をご紹介します。また、アジャイル開発との違いやDevOps導入のメリット、実践のポイントなどをDevOpsを実践する3社の事例を交えて解説します。 「DevOps」とは
初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ - プログラマの思索
初中級プロマネがIPAデータ白書の統計情報をどんな観点で活用できるか、説明した利用事例がとても良かった。 理解できた内容をラフなメモ。 【参考】 初中級プロマネのための 現場で活かせ！統計情報１ 初中級プロマネのための 現場で活かせ！統計情報２ 「ソフトウェア開発分析データ集2020」の発行：IPA 独立行政法人 情報処理推進機構 「ソフトウェア開発データ白書」のダウンロード：IPA 独立行政法人 情報処理推進機構 初中級プロマネのための現場で活かせ！統計情報 2019年4月19日| CITP Community CITPアニュアルレポート2018を公開しました | CITP Community 【0】「ソフトウェア開発分析データ集2020」をIPAデータ白書と呼ぶことにする。 【1】IPAのソフトウェア開発データ白書を使いたい動機は2つある。 1つ目は、プロマネとしてシステムの企画書や
アジャイルをスケールさせる手法に正解はない 自社のモデルを探す事例と課題 平鍋健児さんに聞く - Agile Journey
仕様書の通りのITシステムをカッチリと時間をかけて作っても、顧客に「依頼したものと違う」と言われてしまう。ソフトウェアエンジニアの「いいものを作りたい」という気持ちがビジネスに生かされていない。そう感じていた平鍋健児さんは、ピラミッドのように大きな建築物を数十年かけて作るやり方ではなく、生鮮食品のように鮮度を大切にしたアジャイルの開発手法に出会い、この20年を実践と普及に取り組んできました。 近年はビジネスの立場からも語られる「アジャイル」ですが、このインタビューではアジャイルを導入する企業がステージや事業規模に応じてどのような課題に直面するのか？ とくに、小さなスタートアップ企業がアジャイルネイティブから大きくなったメガベンチャーだけでなく、旧来の開発手法を続けてきた既存の企業が、自分たちにフィットしたアジャイルを見つけるときに参照できるいくつかの事例とあわせて紹介します。 アジャイルが
昨年の10月頃から締め切りのある大きなプロジェクトに参加し、部分的にではありますがプロジェクトマネジメントを担当しました。この記事では、その業務を通して得た見積もりに関する知見をまとめます。教科書的な知識は「アジャイルな見積もりと計画づくり」に依りますので、詳しくはそちらをご参照ください。 見積もりの基礎知識 見積もりは、提供したい機能をどれくらいの期間で実装できるかを予想し、計画について議論をするために行います。見積もりを行うことによって、全くアタリがつかない状態から、「プロジェクトのフェーズがこの辺りなので、平均で N 週間、最悪で 2N 週間くらいかかる可能性があります」などと答えられるようになります。さらに、プロジェクトのフェーズが進んで不確実性が減少すれば「平均で M 週間、最悪で M+1 週間くらいかかります」と答えを正確にできるかもしれません。まさにこれが「アジャイルな計画づ
初めに 本記事 『ゼロから始めるシステム障害対応フロー』 の内容について タイトルの「ゼロから始める」には二つの意味があります。プロダクトのリリースを間近に迎える中、チーム内での障害対応体制の枠組みがなかったこと。そして体制づくりを担当することとなった私の知識・知見が（ほぼ）ゼロだったこと。この二つです。 この状態から、リリース前〜リリース後の約2月間でなんとか形にすることができました。本記事ではその過程でぶつかった問題とそれに対する課題、それらにどう対応したのか、何を学んだのか、の紹介。 そして、障害対応体制の策定・構築や改善の流れの中で私が起こした失敗から、人としてリーダーとして何を心がけなければいけなかったのかの反省を共有させてもらいたいと思います。 本記事は以下の構成です。 0. 始まり ※ スクラムチームでの話。スクラムチームの登場人物は以下の三つ PO：プロダクトオーナー（Pd
公開日 2024/06/25更新日 2024/07/01モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 ご好評頂いているアーキテクチャ特集の第三弾となる今回は、BtoB SaaSを提供する企業10社にご協力頂き、技術選定のこだわりや今後の展望をご寄稿いただきました。アーキテクチャを通して、各社の事業特性や設計思想にも触れられる内容となっております。※ご紹介は企業名のアルファベット順となっております 株式会社あしたのチーム あしたのチームは「誰もが "ワクワク" 働ける世界を創る」をビジョンに掲げ、人事評価制度の構築・運用・クラウド化で "人と組織の成長" を支援しています。今回は、2024年4月にリリースされた同社の新サービス：パフォーマンスマネジメントプラットフォーム『Cateras™』のアーキテクチャについてご説明します。 アーキテクチャ選択の背
先日The Registerを見ていたらアジャイル開発の失敗率は268%も高い Study finds 268% higher failure rates for Agile software projectsという記事が目に入りました。 The RegisterはITニュースサイトで、日本で言うところのITmediaやWIRED、GIGAZINEみたいなところですかね。 その記事は元記事を紹介しているもので、『元記事はImpact Engineeringの宣伝ではあるが、アジャイル開発は期待ほどうまくいかないという疑念を抱かせるのにも十分である』というようなまとめになっていました。 ではImpact Engineeringってなんなんだよと元記事268% Higher Failure Rates for Agile Software Projects, Study Findsを最後まで読
最近にわかに話題のLLMツール「Dify」を僕も使ってみた。 いいところと「?」となったところがあったので纏めておく Difyとは、GUIでワークフローを組むことができるLLM-OPSツールだ。 ComfyUIのようにワークフローが組めたり、GPTsのように自分専用のアシスタントを作れたりできる。 特に、OpenAIのGPTシリーズとAnthropicのClaude-3、そしてCohereのCommand-R+なんかを組み合わせて色々できるところは良いところだと思う。また、ローカルLLMにも対応しているので、企業内でのチャットボットを作るんだったらGPTsよりこっちの方がいいだろう。 元々色々なテンプレートが用意されているが、テンプレだけ使うとGPTsっぽいものを作れる(それだってすごいことだが)。テンプレを改造するだけでも欲しいものが作れる人はいるし、ここはノーコード環境と言える テンプ
デジタル庁の求人要件がTwitterで話題になっている。政府職員が使う基盤サービスの開発エンジニアを募集するもので、必須スキルとして「Webアプリの開発経験5年以上」や「C#によるWebバックエンドアプリケーション開発経験3年以上」「TypeScript、React、Vue、GitHubなどを用いた開発経験2年以上」など10項目を記載している。 業務内容は「公的機関で使用するID管理基盤の設計・開発」「連携サービスとの相互運用・相互接続、プロビジョニングを行うサービスの設計・開発」などの他、各設計の最適化や品質向上のための分析、改善業務など。必須スキルは下記10項目。 Webアプリケーション開発経験5年以上 TypeScript、React、Vue、GitHub等を用いた開発経験2年以上 DevOpsの設計・開発、アジャイル開発経験2年以上 C#によるWebバックエンドアプリケーション（M
アジャイル開発の契約は「準委任」が適切、契約前にユーザーとベンダの共通理解が大事。IPAが「モデル契約書」やチェックリストなど公開。
情報処理推進機構（IPA）は、ユーザー企業が開発ベンダにアジャイル開発手法を用いたシステム開発を発注する際の、契約書の見本などを含む「「アジャイル開発版『情報システム・モデル取引・契約書』（本版）」を公開しました。 本作はスクラムを想定したアジャイル開発を外部委託する際の、契約条項とその解説、および補足資料で構成されたもの。 IPAは本作を作成するにあたり、ユーザー企業とベンダ企業が緊密に協働しながら適切に開発を進めることができるモデル契約となるように、ユーザー企業、ベンダ企業、業界団体、法律専門家の参画を得て検討を重ねたとしています。 契約前チェックリストも 本作の作成に関わったIPAの「DX対応モデル契約見直し検討ワーキンググループは」、ユーザー企業とベンダが契約する前に、以下の2つのことを理解しておくことが必要だと説明します。 ユーザ企業及びベンダ企業が、開発に着手する前にアジャイル
「アジャイルテストの4象限」はアジャイル開発を補完するソフトウェア開発手法である - mtx2s’s blog
従来のプロジェクトにおける「テスト」は、リリースや納品前の最終工程として行われるものだ。多くのケースでそれは、前工程までの遅れと、それでも固定されたままのリリース日に挟まれ、予定された期間を食いつぶされた中で実施される。その上、時間に追われる中で実装されたソフトウェアは、動作確認も十分にされない状態でテストフェーズをむかえることになる。こうして品質の保証は、テスターに丸投げにされるというのが実態ではないだろうか。もちろんここでテスターに丸投げされているのは外部品質、特に機能面での品質の保証のみだ。非機能面での品質の保証は手薄になり、内部品質は顧みられることはない。 これは、ウォーターフォール開発を採用するプロジェクトで私が頻繁に経験した失敗パターンであるが、アジャイル開発でも遭遇する。その理由は、そのままのテストモデルがアジャイル開発の中でも用いられるために、同様の失敗パターンに陥りやすく
さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog
こんにちは、エンジニアリングマネージャーの id:onk です。 Hatena Developer Blogの連載企画「卒業生訪問インタビュー」では、創業からはてなの開発に関わってきた取締役の id:onishi、CTOの id:motemen、エンジニアリングマネージャーの id:onkが、いま会いたい元はてなスタッフを訪問してお話を伺っていきます。 id:onkが担当する第9回のゲストは、さくらインターネット株式会社の組織内研究所であるさくらインターネット研究所の上級研究員で、SRE （Site Reliability Engineering）の研究者としても活躍する id:y_uuki さんこと、坪内佑樹さんです。 2013年にはてなに新卒でWebオペレーションエンジニアとして入社後、サーバー監視サービス「Mackerel」をはじめとするサービス開発やはてなのインフラ開発・運用にSR
![さくらインターネットで活躍中の id:y_uukiを訪問 | はてな卒業生訪問企画 [#9] - Hatena Developer Blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5b5961cfe7e9736ef0e88bc0290b1599481d2626/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fh%2Fhatenatech%2F20240319%2F20240319125826.jpg)
【資料公開】プロダクトオーナーアンチパターン
みなさんこんにちは。@ryuzeeです。 技術顧問先からの依頼でプロダクトオーナーのアンチパターンについて話をしたので、そのときの資料を公開します。 今回紹介するのは以下の6つのアンチパターンです。アンチパターンに陥っている可能性を示す兆候もあわせて示しています。 顧客やユーザーの軽視 兆候 社内のミーティングでスケジュールが埋まっている 機能の必要性の根拠はユーザーからのフィードバックではなく仮説（というか妄想）にもとづいているものが多い ユーザーがプロダクトを触っているところを見たことがほとんどない 不十分なステークホルダーマネジメント 兆候 ステークホルダーをスプリントレビューに招待していない ステークホルダーと個別にコミュニケーションしていない ステークホルダーに何か言われるとすぐに対応している 「◯◯さんの指示なのでやらないといけない」のような口癖 不在がちなプロダクトオーナー
※この投稿は米国時間 2019 年 10 月 4 日に Google Cloud blog に投稿されたものの抄訳です。 運用チームにエンジニアを絶えず増員しても、お客様の拡大には対処しきれません。Google のサイト信頼性エンジニアリング（SRE）の原則を適用すれば、運用上の問題にソフトウェア エンジニアリングによる解決手法を取り入れることで、うまく対処できます。本稿では、従来のネットワーク エンジニアリングの通例にとらわれず、SRE に転換することで、Google がグローバル ネットワーク運用チームを変革した方法をご紹介します。Google の本番環境ネットワーキング チームがこの問題にどのように取り組んだのかをお読みいただき、ご自分の組織に SRE の原則をどのように取り入れることができるのかを検討してみてください。 スケーリングの限界2011 年、Google の本番環境ネット
上流品質を担保するために必要な3つのこと 高橋寿一氏（以下、高橋）：Dailyで上流品質を担保するために必要な3つのことです。単体テスト、リファクタリング、要求仕様、ユーザーストーリーのテストケース展開という3つのアクティビティをしっかりやっていただくと、上流でも品質がかなり担保されていくんじゃないのかなと思っています。 単体テストに関しては、基本的には「網羅率を担保してください」みたいなことなので、シンプルです。ただ、まだまだ知られていませんが、0から70パーセントとか80パーセントに持ってくるのは地獄のような作業なので、だいたいみなさん諦めちゃうんです。 でも、テクノロジーが進んでいるのでそこまでやる必要はなくて、「2：8の法則」ですよね。ソフトウェア全体の2割の危ないところだけをテストすれば、だいたい品質は担保されますという。超いい加減な言い方をしましたが、そういうものがあります。
「コード全捨て」で覚悟が決まった。Bill Oneチームが“売れない新規事業”を脱却した方法 | レバテックラボ（レバテックLAB）
「コード全捨て」で覚悟が決まった。Bill Oneチームが“売れない新規事業”を脱却した方法 2024年7月26日 Sansan株式会社 VPoE 大西 真央 SEとしてエンジニアのキャリアをスタートさせ、2012年以降はアジャイルやDDDなどの開発スタイルを経験。2016年にSansanに入社し、営業DXサービス「Sansan」の大阪開発拠点立ち上げやインボイス管理サービス「Bill One」の立ち上げにプロダクト開発責任者として携わる。2024年4月より現職。 X（@mmmmao0530） これまでの経歴 新規プロダクトをつくり始めたものの、なかなか売れずに苦しんでいる開発チームも多いのではないでしょうか。Sansan社の2本目の柱として現在急激に売上を伸ばしている請求管理SaaS「Bill One」も、実はそのひとつでした。 Bill One開発チームは、多くのユーザーに必要とされる
プロダクトバックログアイテムの分割方法
みなさんこんにちは。@ryuzeeです。 プロダクトバックログアイテムは、複数スプリントにまたがって1つのものに着手することはありません。 必ず、1スプリントで完成できる大きさになっている必要があります。 これは、複数にまたがってしまうと変化に柔軟に対応できなくなること、成果の量の把握が難しくなること、大きいものを扱うのはそもそも難しいことなどが理由です。 そのため、プロダクトバックログアイテムがプロダクトバックログのなかで上位になっていくにつれて、リファインメントなどを活用しながら、適切なサイズに分割していきます。 最初の段階から細かく分割してしまうと、変化に対応しにくくなったり、数が多くなりすぎて管理しきれなくなったりするので避け、着手が近づいてきたらジャスト・イン・タイムで分割していくのがポイントです。 こうすることで、チームの成長にあわせてプロダクトバックログアイテムのサイズを変え
以降では、このテスト設計改善の取り組みに対する質問に回答していきます。 テスト設計改善についての質問の回答 【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い？ 開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。 【質問2】テストと設計の比率を出していらっしゃいましたが（テストをいっぱいやるようにした）、数える単位は何ですか？人数？時間？その他？ 説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「（開発の設計ではなく）テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。 【質問3】改善後の成果物サンプルやアク
ミルクボーイがデザイン思考を説明したら｜広野 萌
これをみてひとしきり笑ったあと、デザイン思考バージョンもやりたいなと思って書いてみた。 挨拶内海「どうもお願いします。ありがとうございます。今、ブロックチェーンをいただきましたけどもね。ありがとうございます。こんなんなんぼあってもいいですからね。」 駒場「いきなりなんですけどね、うちのおかんがね、好きな問題解決の考え方があるらしいんやけど」 内海「そうなんや。」 駒場「その名前を忘れたらしいねん。」 内海「問題解決の考え方の名前忘れてまうってどうなってんねん。」 駒場「いろいろ聞くんやけどな、全然わからへんねん。」 内海「そうなん？」 駒場「うん。」 内海「ほんだら俺がね、おかんの好きな問題解決の考え方、一緒に考えてあげるから、どんな特徴言うてたかとか教えてみてよ。」 定義駒場「おかんが言うには、デザイナーがデザインを行う過程で用いる特有の認知的活動やって言うてた。」 内海「ほぅ。……デザ
TOPインタビュー「3年前に戻れるなら、同じ意思決定はしない」マネージャーをなくしたサイボウズから学ぶ、フラット型組織でできないこと サイボウズ株式会社 開発本部副本部長 兼 New Business Division 副本部長 岡田 勇樹 2007年に新卒でサイボウズに入社。エンジニアとして「サイボウズ Office」や「kintone」の開発に参画。2014年に東京から地元大阪にUターンし、マネージャーとして大阪開発拠点の立ち上げを主導。現在はエンジニア採用に携わりつつエンジニア組織のマネジメントに注力。阪神タイガースのファン。 3年前、「kintone」や「Garoon」などを手掛けるサイボウズの開発本部が発した「マネージャーをなくす」宣言。多くのエンジニアを抱える大所帯で、業界でも先駆けとなる組織階層の撤廃は、大きな驚きをもって受け止められました。職能ごとに整理された組織から、プロ
一括請負契約はソフトウェア開発にやっぱり向いていない、と改めて感じた。 理由は2つある。 【参考】 ERPの落とし穴part4～システム移行という名のデスマーチ: プログラマの思索 システムのリプレース案件が最も危険な理由: プログラマの思索 請負契約がソフトウェア開発者を苦しめている: プログラマの思索 【1】1つは、発注者は外部ベンダーにリスク転嫁しているつもりでも、リスク転嫁できていない。 結局、発注者に全てリスクで跳ね返ってくる。 発注者は、要件定義でガチガチに仕様を固めて、その仕様通りにリリースできたとしても、もし本番障害があれば、瑕疵担保責任でベンダーに追求できる。 民法の請負契約では、受託側は成果物の完成責任があるからだ。 しかし、その契約スタイルはソフトウェア開発になじまない。 たとえば、発注者が要件定義や外部設計をまとめて、ベンダーに開発工程を一括請負で委託したら、それが
アジャイルを推進するチームの基本とは？ カイゼンアドバイザー・新井剛さんが教える始め方と続け方 - Agile Journey
現在ではさまざまな企業が変革に取り組むため「アジャイル」な手法に注目しています。しかし具体的に推進していくとなると、どこから手をつければよいか、またどう広げていけばよいか、導入して実践するだけでもハタと悩む場面が多いようです。 アジャイルコーチ、カイゼンファシリテーターとしてさまざまな企業のカイゼン・変革を支援してきた『カイゼン・ジャーニー』著者の新井剛さんに、そもそもアジャイルな手法がなぜ注目されていて、何に対して取り組んでいくのか、どのようにチームに取り入れ、組織全体に浸透させていくことができるのかを聞きました。 プロダクト・チーム・プロセスそれぞれをカイゼンする チームで「もやもや」を整理することより始めよ ノウハウや情報を横展開しやすくする取り組みを進める アジャイル実践時に陥りがちな3つの課題 受託・ウォーターフォール・日本的な計画への対応 まとめ：アジャイルを継続していくために
こんにちは！ エンジニアマネージャーの森住（@t_morizumi）です。 現在 SmartHR は saiyo-tasukete プロジェクトの名の下、エンジニアの採用ブランディングと再び向き合っている真っ只中にあります。 「普段取り組んでいることをきちんとテックブログで発信する」という、ぐうの音も出ないほど当たり前のことが大切であることに CTO が気づいてしまったため、僕もこうして筆を取っている次第です。 さて、今回はエンジニアのキャリアについてということで、SmartHR がエンジニアのキャリアアップにどのように取り組んでいるのかをご紹介したいと思います。 SmartHR のエンジニア組織について まずは大前提として、SmartHR のエンジニア組織は以下のような構造になっています。 （※ 組織構造の概略をお伝えすることが目的のため簡略化しています） CTO がマネージャーを支え、
アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ - Test Automation
はじめに こちらは食べログAdvent Calendar 2021の23日目の記事です[1]。近年、IT業界では働き方改革によるリモートワークなどの浸透や、アジャイル開発やDevOpsなどのソフトウェア開発プラクティスの普及を受け、Developer Productivity(開発生産性)が鍵になってきています[2][3]。組織のDeveloper Productivity（開発生産性）が向上すると、ソフトウェアのデリバリーだけでなく、ビジネスパフォーマンスや社員のモチベーションが向上することが知られています。 私の所属する株式会社カカクコムの食べログシステム本部でも2021年10月に「Developer Productivityチーム」という「 開発サイクルのフィードバックを素早く、リッチにすることで最高の開発・テスト体験を実現する 」をミッションとして持つチームが爆誕しました[4]！
昨日、4月1日に株式会社カケハシへ入社した。 株式会社カケハシに入社しました - Mitsuyuki.Shiiba 明日から仕事が始まるので、ひとつの区切りとして、この3ヶ月半をふりかえっておこうと思う。ちょっと長くなっちゃった。 前職を退職 ウェブアプリケーションエンジニアとして転職活動をしますー！ - Mitsuyuki.Shiiba 12月15日付けで前職を退職することになったため、ブログを書いて「転職活動します！」とツイッターにポスト。ありがたいことにたくさんの方が声をかけてくれたり、応援してるよって言ってくれたりして嬉しかった。 外資への応募も少し考えてたけど、こんなに声をかけてくれたので、その中で探すことにした。レイオフじゃないと、こういう形で転職活動をすることもないから、いい経験だなと思いつつ。 カジュアル面談 12月から1月にかけて77社にお声がけいただき、42社とカジュア
はじめにこんにちは！Unit～E2Eのテスト自動化を生業にしている、いしいと申します。 ユニットテストに限らず、何かを始めようと思ったとき、人は様々な壁に直面しますよね。知識・経験の問題、コストの問題（金銭、時間）、メンタルの問題（納得感、不安感）、それらが複合的に結びつく社内政治的な問題などなど・・・。そして、それらの壁を乗り越えて第一歩を踏み出すことには大変な困難を伴います。 この記事では、ユニットテストを書いていくのにあたって、どのような壁・問題があるのかを確認し、それに対してどのようにアプローチをすれば乗り越えられるのかを考えていこうと思います。 ユニットテストの壁とその乗り越え方メンタルの問題根本的にモチベーションが上がらない それはユニットテストのメリットや魅力に理解、納得がいっていないからです。人間、無駄なことをやりたいとはなかなか思えません。仮に、無駄と思いながらやったとし
Git 2.27.0 から git pull をすると表示されるようになった "Pulling without specifying how to reconcile divergent branches is discouraged." について - ESM アジャイル事業部 開発者ブログ
最近の趣味はもっぱら L7 より下のお勉強、な @yucao24hours です。 梅雨入りもどこ吹く風の暑いある日、いつものように git pull を実行すると、以下のような警告が出るようになりました。 $ git pull warning: Pulling without specifying how to reconcile divergent branches is discouraged. You can squelch this message by running one of the following commands sometime before your next pull: git config pull.rebase false # merge (the default strategy) git config pull.rebase true # rebas
はじめに こんにちは。私はN予備校のバックエンド開発に携わっています。 N予備校バックエンドでは2021年度に1名の新卒エンジニアが配属となりました。 ドワンゴの新卒エンジニアはエンジニア研修を受けたあと、配属された部署で個別研修や実際の業務を通じてOJTを受けます。 本記事では、メンターとして2021年度新卒エンジニアが入社してから1年のあいだに行ったフォローアップについてまとめます。 メンティーの len さんが執筆した記事は こちら になります。 新卒エンジニア研修の内容については、別の方がまとめた記事を公開しています。 2021年度 エンジニア新入社員研修のご紹介 ドワンゴ21新卒がフルリモートでの入社から機能をリリースするまで メンティー入社前 メンティーが入社するまでは、パーソナリティの把握に務めました。 パーソナリティを把握しておくことで、苦手な部分をメンターが迅速にサポート
【ryuzee｜吉羽龍太郎】アジャイル開発のエキスパートが語る「エンジニアはビジネス視点を持て」の裏に隠れた本当の問題 2023年9月11日 株式会社アトラクタ Founder兼CTO アジャイルコーチ 吉羽 龍太郎 1973年生まれ。野村総合研究所、Amazon Web Servicesなどを経て、2016年1月から現職。アジャイル開発、DevOps、クラウドコンピューティング、組織開発を中心としたコンサルティングやトレーニングを専門とする。著書に『SCRUM BOOT CAMP THE BOOK』（翔泳社）、訳書に『チームトポロジー』（日本能率協会マネジメントセンター）、『エンジニアリングマネージャーのしごと』『スクラム実践者が知るべき97のこと』『プロダクトマネジメント』『みんなでアジャイル』『レガシーコードからの脱却』『カンバン仕事術』（オライリー・ジャパン）、『ジョイ・インク』（
FLEXY編集部の麻衣子お姉さんが、現場の最前線で活躍するエンジニアへ会いに行くこの企画。 「聞いたことあるけど良く分からない」「ざっくりと教えて」という非エンジニアならではの問いに答えてもらいます。技術書やWebで調べてもいまいち難しくて理解できないあんな技術やこんな技術。プロに優しく教えてもらいましょう。 今回のテーマは「アジャイル」。麻衣子姉さんもアジャイルという単語は聞いたことがあるものの、なぜ巷で流行っているのか、そもそもスクラムとの違いが何なのかは知らない様子。LINEの横道稔さんに伺いました。 アジャイルの基本をわかりやすく教えて！ 麻衣子：エンジニアの方がよく口にする「アジャイル」って何ですか……？「ウォーターフォール」との違いはなんでしょうか？ 横道：まず初めに、ウォーターフォールとアジャイルは対となる概念ではないということからお話させて下さい。 麻衣子：対比で語られるこ
【学びたい技術分野別に50冊】高額な技術書がKindleで50%以上セール開催中でお買い得 - 仮想サーファーの日常
Amazonで、【最大50％OFF】高額書籍キャンペーンが開催されています！ 開催期間は2020年7月10日（金）～2020年7月23日（木）です。 Docker、CI/CD、Python、Ruby、Flutter、Vue.js/Nuxt.jsなどなどエンジニアが学びたい技術の本が多数セール対象になっているので、ぜひともチェックしたいですね。 【最大50％OFF】高額書籍キャンペーンを見てみる この記事では、一気に技術書を読んで技術力を伸ばしたい方向けに、学びたい分野別にKIndleセール本をまとめました。 JavaScriptに入門したい JavaScript逆引きレシピ 第2版 山田 祥寛 (著)、翔泳社 (出版)、2018年10月15日 (発売) 50%OFF Kindle¥1,540、単行本¥3,080（2020年7月12日現在） JavaScript開発必須の知識・現場のテクニッ
New!!（2024.1.11） 本記事の内容をよりブラッシュアップし、さらに使いやすくなった「ふりかえりカタログ（コミュニティ版）」をリリースしています。 今後はそちらをご利用ください。 ふりかえりカタログ（コミュニティ版） はじめに あなたのふりかえりを拡張するふりかえりカタログを公開いたします！ ふりかえりカタログは、ふりかえりの手法（現在）71個とその特徴を網羅したカタログです。下記画像はイメージです。 pdfはBoothで無料DLできます。 DLはコチラ => ふりかえりカタログ（Booth版） スライドはSpeakerDeckから参照できます。 DLはコチラ => ふりかえりカタログ（SpeakerDeck版） ふりかえりカタログとは ふりかえりの様々な手法をまとめたカタログです。 ふりかえりの各手法を「手法名」「手法を使う場面」「手法のイメージ」「出典」「進め方」「いいところ
ジャーニーマップとは、1人のユーザーが目的を達成するためにたどるプロセスを視覚化したものである。 Journey Mapping 101 by Sarah Gibbons on December 9, 2018 日本語版2019年8月6日公開 ジャーニーマップはよく使われるUXのツールだ。あらゆる形やサイズ、フォーマットがあり、コンテキストに応じてさまざまな方法で利用できる。この記事では、ジャーニーマップとはどういうものか（そして、どういうものがジャーニーマップではないのか）、関連用語、よく使われる変化型、ジャーニーマップの活用方法といった、ジャーニーマップの基本を取り上げる。 また、カスタマージャーニーマップは、いつどのように作るべきか、その5段階のプロセス、ジャーニーマップ作成の実際を論じた記事も閲覧可能である。 ジャーニーマップの定義 定義：ジャーニーマップとは、1人のユーザーが目的
以前からAmazonの欲しいものリストにはあったのですが、なかなか読みたい気持ちにならずリストを整理するときに削除しちゃっていたのですが 2月ぐらいからTwitterでこの本についての言及が増えたし、ちょうどそのころ開発生産性とは何か、について一考していたこともあったので、読んでみました。 LeanとDevOpsの科学 一旦さらっと読んで、面白いなー、やっぱデリバリ大事だなーと思って読了したんですが 先日texta.fmでこの本のことが取り上げられており、あー、そんな読み方があったかーと思って改めてちゃんと読み直してみました。 構成 第一部: 調査結果から見えてきたもの(パフォーマンスを向上させるケイパビリティとは何かの話。特にデリバリを中心に多面的に検討している) 第二部: 調査・分析方法 第三部: 改善努力の実際(いろんな会社の取り組みの事例) 読み方 常に付録Aの図A.1を開いてお
目標設定は好きですか? アジャイルとともに目標と向き合い続ける方法 / Do you like target Management?
Developers Summit 2024 Summer での登壇資料です https://event.shoeisha.jp/devsumi/20240723/session/5111
みなさんこんにちは。@ryuzeeです。今日は小ネタです。 3分くらいでスクラムをざっくり分かってもらうための説明を以前作ったのですが、意外と役に立っているのでブログで公開しておきます。 この記述については、CC BY-SA 4.0ライセンスとします。 クレジット表記（@ryuzee / Ryutaro Yoshiba）のもとで共有や派生物を作って構いません（その場合は元のライセンスを継承します）。 製品の目標や方向性、成果に責任を持つ人を1人決めます（＝プロダクトオーナー）製品の目標や実現したいことを一覧にして、常に最新の状態にしておきます（＝プロダクトバックログ）製品を作るのに必要な作業は色々な能力を持った開発者たちに任せます（デベロッパー）頻繁に動くものを見たほうが安心なので、固定の短い期間に区切って繰り返します（＝スプリント）短い期間をうまく過ごして成果を出すには計画が必要です（＝
日本人ってホントにミスが嫌いだよね
なんかうちのソフトウェアにバグが見つかったらしくて それの修正をやってるらしいんだけどホント不毛 まずはバグの原因を突き止めてそれが何故テストをすり抜けたかを調査 調べてみるとテスト中に出てくるエラーメッセージが微妙に違うけど気付かずにスルーしてしまったらしい 再発防止策としては社員のマインド醸成とか言い出しててアホかと 上流工程でもっと詳細な検討をするべきとかも言い出しててホントアホかと そんでその報告書を大量に作ってるんだけどその間バグは放置 報告書を上司の上司の上司まで報告し終わったらようやくバグ改修の予算が下りるらしい そんでその予算を使って契約書作って上司の上司の上司まで承認を貰えたら修正開始 修正そのものは3行ぐらいなんだけど、もう一回テストやり直すんだって 多分だけどマインド醸成するための研修とかもやることになるんだろうね この手の人達にアジャイルをいくら説いてもそりゃぁわか
期日より、優先順位を決めろ！~freee Tech Night出演にあたって~ - freee Developers Hub
まずはじめに、2022/01/28のfreee Tech Nightを楽しみにお待ちいただいていた皆様、当日直前にLiveを延期してしまいまして、運営にかわりまして申し訳ございませんでした。この記事はLiveで話す予定の内容の一部を深堀りした内容になっておりますので、文字でもお楽しみいただければと思います。 Abstract 期日を決めることには様々な利点があるが、期日通りに終わらせるにはとてもじゃないが避けづらい問題が多すぎる。 特に期日を先々まで決めてしまうことで直近の期日さえ守れなくなる状態になる。 期日を決めず、優先順位を決め、短い間隔で機能や価値を出すことで、方針の柔軟さを確保し、ランダムに発生する事象に対応しやすくなる。 現在地と予測地点を確認するためにまずは「バーンダウンチャート」をつくって運用してみよう。 はじめに なにか目指したい姿があると、その姿に対して何かしらの案を考
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。アジャイルコーチの荒瀬中人です。 スクラムガイドが約3年ぶりに更新されました。スクラムガイドとはスクラムについて書かれている唯一無二のガイドです。 スクラムの取り組みの中で活用できると思い、最新版のスクラムガイドに沿ったスクラムのフレームワークの各要素や目的をシンプルにまとめた1枚の概要図にしました。 私自身簡単に見直せるとともにセミナーなどでスクラム説明する際に活用しています。このブログを読んでくれている方のお役に立てればと思い、今回公開することにしました。 こちらからダウンロードください スクラム概要図ダウンロード（PDF 332KB） さて、今回のスクラムガイドの変更点に“指示的な部分を削減(*1)”、“幅広い読
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクトマネジメント手法 vs 絶対にどうにかする覚悟 - ミネムラ珈琲ブログ
見積もりの基礎知識と「ストーリーポイント vs 理想日」の考察 - yigarashiのブログ
ゼロから始めるシステム障害対応フロー - Qiita
モダンな開発環境のBtoB SaaSアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
『アジャイル開発の失敗率は268%も高い』のコメント欄が面白かったので紹介するよ - Qiita
噂のノーコードAIシステム開発環境Difyを使ってツールを作ってみた。使った感想｜shi3z
デジタル庁がエンジニアに求める“必須スキル”は妥当？ 求人要件に賛否 同庁に経緯を聞いた
ごく普通のエンジニアリング運用チームを強力な SRE チームに変える | Google Cloud 公式ブログ
単体テストは「2：8の法則」でだいたい品質が担保できる 網羅率・期待値を担保した適切なソリューション
効果を維持しつつテスト工数を削減した話 〜テスト設計改善の質問回答編〜
「3年前に戻れるなら、同じ意思決定はしない」マネージャーをなくしたサイボウズから学ぶ、フラット型組織でできないこと
一括請負契約はソフトウェア開発にやっぱり向いていない - プログラマの思索
エンジニアのキャリアについて【SmartHRの場合】 - SmartHR Tech Blog
明日から、仕事するー！ - Mitsuyuki.Shiiba
なぜ我々はユニットテストが書けないのか？｜SHIFT Group 技術ブログ
新卒エンジニアのメンターとして1年間取り組んだこと - ドワンゴ教育サービス開発者ブログ
【ryuzee｜吉羽龍太郎】「エンジニアはビジネス視点を持て」の裏に隠れた本当の問題
アジャイルとは？LINEアジャイルコーチ 横道さんがわかりやすく解説！ | FLEXY（フレキシー）
ふりかえりを拡張する「ふりかえりカタログ」 - Qiita
ジャーニーマップ作成の基礎
『LeanとDevOpsの科学』まとめ - Qiita
3分でざっくりわかるスクラム（スクラム用語を使わないスクラムの説明）
スクラムガイドの変更に伴うヤフーのスクラムの変化