そもそも、アジャイル開発とは何か。片山氏は「正解がわからない状態で、正解に近づくためのアプローチであり、手法としてはインクリメンタル（徐々に増加する）とイテレーティブ（反復）、つまり、少しずつ繰り返しながらビジネス価値を上げて提供するアプリケーションを開発する点が特徴です。その考え方は複雑だったり、難しかったりするわけではありません」と説明する。 また、ウォーターフォール型開発との違いについて、片山氏は「ウォーターフォール型開発では決められたゴールを目指して直線的に進んでいくのに対して、アジャイル開発では試行錯誤を繰り返しながらゴールに近づくことを目指します」と解説する。 「ある程度の規模を持つシステムを開発する場合、アジャイル開発のほうが工数もかかることがあります。アジャイル開発の特徴が決して『早い』『安い』ではないと理解しておくことが非常に重要です」（片山氏） 片山氏によると、実際のア
今日も今日とて、様々なところで相談を受けている。日本中、そこかしこで課題がある。そんな中で寄せられる一つに「アジャイルができない」という話がある。 話を聞いていくと、アジャイルをやりたいのだけど上手くいかない、という。よくある話だけども、そもそも「なぜアジャイルをやりたいのか」を問うと、ごにょごにょし始めてしまう。 なぜアジャイルなのか？ になると言葉に詰まる、あるいは通り一遍のフレーズ「変化に対応できるために」しか出てこない。どんな変化のことなのか、対応とはどういうことか？ このあたりが言語化できないと、アジャイルを利用しようとしていて、その実、アジャイルという言葉に使われているだけかもしれない。これもよくある話。いわゆるアジャイルをやることが目的になっている。 そんなんじゃダメだから。すぐにアジャイルなるものの意義を確認しよう。 「だから、アジャイルは手段なんだ。あくまで手段なんだ。ア
アジャイル開発における要件定義とは？ 〜DXプロダクト開発における要件定義の理解を深める〜 - TC3株式会社｜GIG INNOVATED.
1. はじめに 前回の「アジャイル開発プロセスの本質」（前編・後編）では、ソフトウェア・エンジニアリングの基本に従いアジャイル開発プロセスを設計していくことにより、アジャイル開発プロセスの進め方、実施する活動、作成する成果物についてなぜそうなっているのかを知り、アジャイル開発プロセスへの理解を深めました。 本記事ではその続編として、DX（デジタルトランスフォーメーション）の文脈におけるプロダクトをアジャイルに開発していくにあたり、特に要求プロセス部分に絞ってソフトウェア・エンジニアリングの基本とアジャイル開発プロセスでの対応をより詳細に解説することで、DXプロダクト開発における要件定義の理解を深めるということを目的としています。 本記事のタイトルにある「要件定義」という言葉はフェーズではなく、要求を決めるまでの活動の分類＝要求プロセスという意味で使っています。この使い方の違いについては、前
調査対象者に、勤務先でおもにどのような開発プロセスを採用しているかを尋ねたところ、「ウォーターフォール型」が58.2％、「アジャイル型」が12.1％となった。 いずれかの開発プロセスに携わっていると回答した人に、開発プロセスに課題を感じたことがあるかを尋ねた質問では、66.3％が「感じたことがある」と答えている。 開発プロセスに課題を感じたことがあると回答した人に、具体的な課題の内容を尋ねたところ（複数回答）、「見積もった工程と実績に乖離がある」（75.5％）がもっとも多く、以下「仕様工程による手戻りが多い」（67.9％）、「テスト工程が削減できない」（30.2％）が続いた。 その他の課題としては、「スロースタートになりやすく、慢性的な遅延が発生する」「手戻りが多く、開発コストがかさむ」といった回答が寄せられている。 開発プロセスに課題を感じたことがあると回答した人に、勤務先が採用している
@koic です。 運用上の作業を開発者が行うというのは、昨今の DevOps ではよく見る光景だと思います。そして、運用手順の実施などにおいてダブルチェックというものを聞いたことあるでしょう。いや、むしろプロジェクトのルールで必要とされ、聞いたことがあるというレベルではないケースもあると思います。 そんなダブルチェック文化について、個人的には「ダブルチェックと聞いたらまず必要性を疑って判断する」という立ち位置で、本稿はそういった音楽性の人が書いた記事となります。 なお、一口に「ダブルチェック」といっても定義は広いため、「リアルタイムでの2人以上の指差し確認」を本稿でのダブルチェックの定義として位置付けます。 そもそも人間は間違えうるもの 本番環境へのショートサーキット 👿 Ops でも Dev のレビューフローにする 👼 形骸化したただの着席プロセスになっていないか疑う そもそも人間
アジャイルソフトウェア開発宣言では、 よりよい開発方法を見つけだそうとしている とあり、またこれに付随する「アジャイルソフトウェアの12の原則」では 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されますチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整しますとあります。 これらが意味するのは、どんな形で開発するといいのかはチームごとに違うこと、それぞれのチームが自分たちの状況にあわせて改善していくことに価値があるということです。 つまり、アジャイル開発標準を作って、それを強制することは、アジャイルの価値観そのものを毀損することになります。 誤解を避けるために繰り返しますが、アジャイル開発の標準を作ること自体は役に立つ可能性はあります。 ですが、この利用や遵守を強制してはいけません。強制したところで標準化自体が生産性や成
メンタルヘルスのための個人的アジャイルの導入
原文(投稿日：2021/01/21)へのリンク 高い品質の成果物を高い完成度で、常に提供しなければならないという意識は、ストレスを生み出し、燃え尽き症候群(burnout)の原因になる可能性がある。何よりもまず、燃え尽き症候群に陥るのを避ける問題を自分が抱えている、ということを受け入れなければならない。個人レベルでアジャイルを適用することが、ストレスを低減し、燃え尽き症候群の可能性を低めながら、高い目標を達成する上で一助となるはずだ。 Thought Machineで品質管理の責任者を務めるMaryam Umar氏は、Agile Testing Days 2020で、メンタルヘルスのためのアジャイル導入について講演した。 燃え尽き症候群のサインは外部からは分からない、とUmar氏は言う。風邪や咳とは違い、自分の内にある心から来るものだからだ。疲れを感じたり、頻繁に頭痛がしたり、仕事に対する
日本の組織を芯からアジャイルにする「シン・アジャイル」というコミュニティを立ち上げます。 - The Dragon Scroll
「組織を芯からアジャイルにする」の発刊に際して、新たなコミュニティを立ち上げます。 長らく組織というもの向き合ってきました。特に、この数年はデジタルトランスフォーメーションの名の元に行われる、組織の数々の取り組み支援を続けてきました。そこで垣間見たのは、日本の組織が直面する「組織的負債」とでも言うべき根本課題です。 次の話で示しているとおり、日本の組織はそれまでの判断基準、価値観である「効率への最適化」だけでは勝負にならなくなっている。しかも、その事実に気づいていながら、これまでのモメンタムに抗うことができずにいる。 www.docswell.com 多くの組織が「最適化」に代わるすべを必要としているのではないでしょうか。効率への最適化だけではなく、組織を取り巻く環境、状況の変化に対応できるようにする。それは、変化への適応力のことです。 変化への適応こそ、ソフトウェア開発の世界が先行して取
この記事は、Arnab Gupta さんの記事 "The Ever-expanding Agile landscape as of 2020" をもとにしたものです。Agile はその定義上、変化する...
オープンデベロッパーズカンファレンス(ODC)2020 Online で10冊くらい紹介しました。 https://ospn.connpass.com/event/190996/
予測型マインドセットと適応型マインドセットの違い、アジャイル思考の本質 | Social Change!
多くのマネージャや経営者に会ってきた中で、マネジメントの手法や組織のあり方の背景には、大きく二つの流派があるのではないか感じています。 一つは、未来の目標を決めて突き進もうとする考え方。もう一つは、将来は予測しきれない前提に立ち、変化に対して柔軟であろうとする考え方。 この本質的な部分で考え方（マインドセット）が合っていないと、世の中にある多くの手法や制度を真似てもうまくいかない。これは、どちらが正しいといった話ではなく、違いを認識することが重要ではないかと考えて整理してみました。 本稿では、この２つのマインドセットを「予測型マインドセット」と「適応型マインドセット」と定義して、その違いについて深掘りをしてみましょう。 未来の想像を先にするか、現在が続く先に未来があるか 「未来の働き方はどんな風になっていると思いますか？」 先日、とある大企業のイノベーションを担う部門の人たちから、リモート
リモートでアジャイル開発ってどうしてる？〜メルカリ、LINE、クオカードでの取り組みを公開します〜【後編】 - Findy Engineer Lab
2020年8月26日（水）、Findyが主催するエンジニア向けイベント「アジャイル開発最前線〜メルカリ、LINE、クオカードのエンジニア組織を徹底解剖！〜」がオンライン上にて開催されました。 新型コロナウイルスの影響により、私たちの働き方は大きく変化しました。こうした状況の中で、より良い製品を作り出すためには、単に働き方を変えるだけでなく、多様な働き方に適した組織体制やコミュニケーション、さらにはツール選定など、エンジニア組織や開発手法自体も、時代に合わせて考える必要があります。 今回は、長きに渡ってアジャイル開発を進めてきたゲストの方々をお呼びし、アジャイル開発のこれまでと直近の変化、今後のあり方について語っていただきました。その内容を、前編のパネルディスカッションパートと、後編のQ＆Aパートに分けてお届けします。 前編はこちらから ■登壇者プロフィール 鎌田 正浩／LINE株式会社 [
Rubyでできる！RISC-Vシミュレータの作りかた 〜 From 4649 To HELLO WORLD 〜 - ESM アジャイル事業部 開発者ブログ
HELLO WORLD〜 はじめに こんにちは、永和システムマネジメントの自作CPUおじさん、はたけやまたかし( @htkymtks )です。 今回はRubyを使った小さなRISC-Vシミュレータの作り方をご紹介します（以前もシミュレータの記事を書いたのですが、シミュレータに大幅に手を入れたので、それに対応したHDリマスター版です） リポジトリ （今回ご紹介するシミュレータのリポジトリはこちら） thata / rv32sim https://github.com/thata/rv32sim RISC-Vとは RISC-VはCPUの命令セットアーキテクチャ(ISA)のひとつで、使用料のかからないオープンソースライセンスで提供されていることや、命令セットの美しさから最近注目を集めています。 仕様 RISC-Vの仕様にはワード幅(32ビット、64ビット)や浮動小数点数サポートの有無など、いくつ
スピーディにテストケースを再利用するノウハウや技術、そしてテストの「実行」ではなく「設計」の自動化に着目したアプローチ法について考える「品質か？開発スピードか？大規模アジャイル時代の品質確保」。ここで株式会社ベリサーブの朱峰氏が登壇。最後に、大規模アジャイルにおけるソフトウェアテストの2つの課題と、課題に対する3つのアプローチについて話します。前回はこちらから。 ソフトウェアテストの2つの課題 朱峰錦司氏：ここからは課題の話になります。冒頭で取り上げたとおり課題はいろいろありますが、今日はソフトウェアテストに話題を絞ります。 ポイントは大きく2つあると思います。1つ目は「早くしないといけないのだから、遅くなっちゃいけないよね」です。当たり前の話です。ソフトウェアテストが足を引っ張らないこと。 でも、扱うものがどんどん複雑になって、どんどん大きくなっていくので、テストにかかる時間は当然延びて
生成AI利用プログラミング：誰でもプログラムが書けると 世の中どうなる？/open-campus202408
新規事業に取り組む企業の増加や方法論の普及などにより、新規事業の数は増えてきている印象です。一方で、新規事業のマネジメント手法については、あまり見かけません。本記事では、新規事業の運用に適したアジャイ...
スピーディにテストケースを再利用するノウハウや技術、そしてテストの「実行」ではなく「設計」の自動化に着目したアプローチ法について考える「品質か？開発スピードか？大規模アジャイル時代の品質確保」。ここで株式会社ベリサーブの朱峰氏が登壇。ここからは、過去と現在のITプロダクトへの考え方の移り変わりから、大規模アジャイルへの向き合い方について話します。前回はこちらから。 過去と現在のITプロダクトの前提の違い 朱峰錦司氏：主題の1つである「大規模」についてお話しします。スライドにチャートを貼りました。私見ではありますが、アジャイルという開発の文化はわりと小規模なWebプロダクトだったり、モバイルというアーキテクチャの拡大が伴ったものだったり、そういった製品ドメインから、小さなチームで素早くやるところから始まったものととらえています。しかし、今ではどこもスケールの課題にぶち当たりつつあると考えてい
「アジャイルやスクラムはソフトウェア開発に適用するもの」というイメージが強いかもしれない。しかし、イーロン・マスク氏が率いるTeslaやSpaceXでは、電気自動車やロケットというハードウェアにもアジャイルやスクラムの考え方を取り入れ、これまでのモノ作りでは考えられないような短期間で新しいバージョンの製品をリリースするサイクルを確立している。そして今、その先を目指そうとしているという。 認定スクラムトレーナーとして活躍し、MicrosoftやAmazon、TeslaやSpaceXでアジャイル導入支援の経験を持つAgile Business InstituteのCEO、Joe Justice（ジョー・ジャスティス）氏が2022年7月に開催された「Agile Tech EXPO 2022」の基調講演に登場し、その「凄さ」を紹介した。 「アジャイルは何もソフトウェアだけのものではありません。もち
「HRMOSタレントマネジメント」目標・評価チームでは日々スクラムを実践し、アジャイル開発を目指しています。 私たちのチームは開発の中で、以下の課題に直面しました。 🚨 開発者にとって、他の開発者やプロジェクトへのサポートや連携に入りづらい 仕様や見積ドキュメントが標準化されておらず、開発案件の進め方や知識が属人化していました。 これにより、開発者がどう他の開発者やプロジェクトへのサポートや連携に入って良いのかわかりづらくなっていました。 🚨 PO・EMにとって、開発の計画が立てづらい サポートへの入りづらさによるコミュニケーション工数の増加、および仕様見落としによる手戻り工数の増加により、ベロシティ見積の信頼性が低下していました。 これにより、プロダクトオーナー（以下、PO）・エンジニアリングマネージャー（以下、EM）は不測の事態に備えたバッファ工数込みで見積らざるを得ず、開発の計画
アジャイルを機能させるには心理的安全性が不可欠である プロセスやツールばかりを重視していないか | 戦略｜DIAMOND ハーバード・ビジネス・レビュー
アジャイル手法はソフトウェア開発の枠を超えて、人事、プロジェクト管理、営業など、ビジネスに関わるさまざまな領域に応用されている。しかし、目立つ成果を上げる組織が存在する一方、アジャイル化に頓挫する企業も多い。その原因は、プロセスとツールばかりに目が向けられ、個人との対話を軽視していることにあると筆者は指摘する。対話を促すうえでは、心理的安全性の担保が不可欠だ。本稿では、心理的安全性を高めるための5つの方法を紹介する。 21年前、17人のソフトウェアエンジニアが、アジャイルソフトウェア開発宣言――通称「アジャイル宣言」を発表した。これは直線的な工程と大量のドキュメンテーションを伴う、官僚的なウォーターフォール型のソフトウェア開発に対抗したものである。彼らが提唱したのは、目まぐるしく変化する環境において適応と成功を可能にする、より柔軟なアプローチだ。 価値観と原則を示したこの簡潔な宣言は、その
翔泳社のアジャイル・スクラム関連書
ソフトウェア開発の現場で用いられている「アジャイル」の考え方や手法が、組織運営などのビジネス現場でも注目されています。 これから「アジャイル」や「スクラム」を導入しようと考えている方、もっとうまく活用したいと考えている方におすすめの書籍を紹介します。 『アジャイル開発とスクラム 第2版』著者 平鍋健児氏からのメッセージ 日本でアジャイル、スクラムの導入が進んでいる2021年、みなさんの現場は元気ですか？ アジャイルをやれば、スクラムをやればうまくいく、なんてことはまったくなく、日々自分たちの現場で起こるのは、一つ一つが個別具体の問題であり、「あなた」が自分で考えていかないといけない、という宿命が白日に晒されたのです。この宿命に最初に気づいたとき、「聞いてたのと違う」と思うかもしれません。そこが最初の起点になり、みんな道を歩むのです。 このラインナップは、その道々での問題を解決していくための
はじめに DX（開発体験）の向上によって、チームやプロジェクトの持続的なパフォーマンスにプラスの影響を与えると考えられています。また開発体験とは、以下の4つの要素で構成されると言われています。 Fitting architecture（アーキテクチャの適合） Great tools（優れたツール） Processes to back that all up（すべてをバックアップするプロセス） Nontoxic team culture（毒のないチーム文化） この記事では、2番目の優れたツールについて、弊社の開発で使っているものを紹介します。 導入ツール Google Workspace 有名なグループウェアですが、メールやドキュメントよりも、各サービスへアクセスするSSO認証としての側面が強いです。 Slack こちらも有名なチャットサービスです。特にハドルが実装されて以降、社内の場合はわ
アジャイル開発というシステム開発の方法論がある。システム開発、とりわけ要件定義の難しさは「見えない」ことから来るという問題意識のもとで生まれた手法である。 「スクラム」と呼ばれたりする少人数のチームをつくって、対話を繰り返しながら小さな範囲で要件を固め、それをもとにソフトウエアをつくって要件を見える化する。見える化した要件を確認し、さらにその要件を深掘りし、次の範囲の要件を検討する。これを繰り返しながら、段々大きなシステムをつくり上げていくというやり方である。 従来のウオーターフォール方式は、最初に全ての要件をしっかり固め、そこから後戻りすることなく、プログラム開発・テストといった具合に、その名の通り「滝」のように上から下へとプロセスが流れていく手法である。検討が進むにつれて要件が変わることもあるため、「見えない」システムを全て工場生産のようにつくるのは難しい。したがって、アジャイル開発に
アジャイルとは、トライアンドエラーを効果的に行うための知識群、だと思う トライアンドエラーするのはどういうときかというと、やってみないと分からないとき やってみないと分からないときはどういうときかというと、その時点での能力を超えた仕事をするとき 能力を超えた仕事をするとき、成功が目的であることに変わりは無いけど、計画と実行よりも学習と軌道修正が重要になる 最初に立てた計画は間違っているため プロダクト開発の領域は大雑把には、ディスカバリーとデリバリーに分けられる ディスカバリーにおいて十分な能力を有している=つくるべき正しいものを見極められている場合、ディスカバリーにおいてアジャイルである必要は無さそう 例えば、受託開発のような場合はつくればお金がもらえるということになっているので、アジャイルになろうというモチベーションは低そう デリバリーにおいて十分な能力を有している=やるべき正しいつく
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~ - Qiita
『アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明』は不明瞭 ~書籍「Impact Engineering」を読んでみた感想 ~アジャイルポエムプロジェクト管理メンタルケアコミュニケーション 「アジャイルを採用したソフトウェアプロジェクトの失敗率はその他の手法と比べて268％も高いことが判明」 という記事が話題になっています。 言及している著書がCEOを務めているイギリスの調査・コンサル会社であるEngpraxが挙げている元の記事はこちら（その調査自体を行なったのもEngprax社） 記事に書かれていることの考察や要約は下記で分かりやすく纏めて下さっています。 記事への反応 記事への感想・反応はだいたい下記のパターンのどれかに該当すると思います。 失敗の定義は？ そもそもアジャイルできてなくね？ 下記が失敗するのはアジャイルかどうかとは関係
アジャイルやスクラムに関するよくある質問
アジャイルコーチングや各種トレーニングの際によく聞かれる質問についてまとめました。 なお、内容については十分注意を払っておりますが、有効性等は状況によって変わります。お客様の自己責任にてご利用ください。 https://assets.attractor.co.jp/wp-content/uploads/2023/11/0098.webp 675 1200 admin https://assets.attractor.co.jp/wp-content/uploads/2019/12/logo_attractor_medium-300x138.png admin2023-11-10 21:00:162023-11-11 22:16:21Q. プロダクトバックログアイテムはいつ見積もればいいですか？ https://assets.attractor.co.jp/wp-content/upload
不確実性が高い状況において、Mustを事前に詳細に計画する方法は機能しにくい。そこでMustの抽象度を上げ、詳細は個人が決定できるようにする。そうすると個人は自分のWillとCanに基づいて具体的な計画を自己決定し、高速に変化への対応を行うことができるようになる。
こんにちは。プロダクトエンジニア兼アジャイル推進室メンバーの長田（shooen）です。 今回はアジャイル推進室連載企画第２弾として、SmartHRにアジャイルコーチとして参画いただいている豊田さんのインタビュー記事をお届けします。 開発の現場に限らず組織全体がアジャイルになっていく上での困難や必要なチャレンジについて、参考にしたりヒントを得たりしてもらえたらと思います。 豊田 聡 2020年9月にSmartHRへジョイン。開発組織におけるスクラム/LeSSの導入支援をはじめ、ピープルマネジメントや組織開発の支援、組織全体のマネジメント力向上施策などに力を入れている。 直近3年間のSmartHRの変化 豊田 聡さん。趣味は筋トレ。スクワットとデッドリフト100kg上げている。 長田： まず豊田さんがジョインした頃のSmartHRの印象を教えてください。 豊田： 会社の7つのバリューが特にいい
rails new してから steep check が通るまでにやってみた作業をまとめておく。 GitHub コードはGitHubで公開しているので、詳細な手順を知りたい方は参照してください。 github.com 手順 gemを入れる steepとrbs_railsをGemfileに追加する。 # Gemfile group :development do gem 'rbs_rails', require: false gem 'steep', require: false end bundle install を実行する。 $ bundle install rbs_rails のREADMEの手順に従って lib/tasks/rbs.rake を作成する。 # lib/tasks/rbs.rake require 'rbs_rails/rake_task' RbsRails::Rak
Railsアプリの開発環境を速くするための調査 その1 - gemの読み込み時間 - アジャイルSEの憂鬱
その1って書いたけど、続くかは不明。 今回は使っているgemの読み込み時間を測ってみた。 Benchmark を仕込む config/application.rb でgemを読み込む前に Kernel.require を上書きして、計測する。 +require 'benchmark' +$result = {} +Kernel.singleton_class.prepend(Module.new do + def require(feature) + ret = nil + $result[feature] = Benchmark.realtime { ret = super } + ret + end +end) Bundler.require(*Rails.groups) +$result.sort_by { |_, t| -t }.take(20) + .each { |featur
「アジャイル型価値開発」という言葉をはじめよう
この数年は、「探索」と「適応」の必要性をひたすらに訴え、その実践に向けて組織に動いてもらう、そのためのあらゆる支援を行う、ということに取り組んできた。「探索」と「適応」という言葉が決して、伝統的な組織に馴染むわけではないが、他に言いようもなく、この言葉を押し通してきた。 正直なところ、探索適応という概念の普及は端緒についたばかりである（ついていると思いたい）。「探索適応がいかに伝統的な組織の現有ケイパビリティや指向性と合わないか」ということを数々の機会で語ってきたが、その必要性についてはもはや確信の域を超えている。「効率への最適化」に最適化していた組織が、かえって目の前のことに、顧客の声に対応できなくなっている、「非効率での安定化」に至っているこの現状を突破するには？ 「探索適応」という手がりは小さな、小さな「希望」になりうる。 探索適応を組織に宿すためには何かしら拠り所が必要だ。そこで、
Scrum fest sendai 2022
はじめに アジャイル開発では、技術やビジネスといった側面だけでなく、開発を担う人々の「人的側面」への取り組みが欠かせません。この記事では、その「人的側面」を強化する効果的なアプローチとして、「システムコーチング®」を紹介します。 特に「アジャイル・フルーエンシーモデル(アジャイルのプラクティスを包括的にまとめるモデル)」とシステムコーチングとの相互補完性に焦点をあて、ログラスの事例を交えて具体的な効果を探ります。システムコーチングを導入することで、チームや組織にどのようなインパクトがあるのか、そのポイントをお伝えします。 アジャイル開発とは アジャイル開発は、顧客の要求に迅速に対応するためのソフトウェア開発手法の総称です。短期間のイテレーションを通じて、開発チームは頻繁に製品のリリースを行い、顧客のフィードバックをすばやく取り入れることができます。 このアプローチはその柔軟性と迅速性により
アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 予測可能性を求めるビジネスの要求とは 分かりやすい例でいうと「業界の繁忙期に合わせて新機能をリリースしたい」などです。 また、BtoBビジネスの場合、開発チームがフィーチャーセットとリリース時期をある程度担保することができれば、 企業のお客様に対し事前のご案内がしやすくなります。 そのことは、リリース直後からその機能を最大限ご活用していただける、という大きなメリットがあります。 事業部一体となって
アジャイル開発で役立つセキュリティプラクティス / Agile Security Practice
RSGT2024の発表資料です！
GovTech東京 エキスパートの杉井正克氏と東京都デジタルサービス局の下家昌美氏が、東京都庁でアジャイルを実践するための「都庁アジャイルプレイブック」を紹介しました。 登壇者の自己紹介 下家昌美氏（以下、下家）：よろしくお願いします。では始めさせていただきます。「東京都庁でアジャイルを実践するための『都庁アジャイルプレイブック』のご紹介」です。 アジェンダです。自己紹介、なぜ都でアジャイルを行うか。R4年度の取り組みと、最後はプレイブックのご紹介です。 まず私、東京都デジタルサービス局の下家の自己紹介です。写真は恥ずかしいので、なるべく掲載したくないというところで、ごめんなさい。所属はデジタルサービス局です。アジャイル型開発を知るきっかけですが、家庭と仕事の両立でいろいろとどうすればいいかなと、タスクがいっぱいあるなと。でも全部はこなせないなと考えた時に、新聞のコラムでアジャイルを知りま
「アジャイル開発に取り組んではみたのですが、うまくいかないので、元のやり方に戻そうと思っています。」 あるSI事業者での講演の後、こんな話しを伺った。同様の話しは、他でもよく耳にする。 私は、エンジニアでもなければ、アジャイル・コーチでもない素人だ。ただ、成果をあげているアジャイル・チームの連中との付き合いは多く、「門前小僧」程度には、アジャイルについては理解しているつもりだ。そんな、私でさえも、これは失敗するだろうと、思うことが多い。 うまくいかない取り組みに共通しているのは、おおよそ以下の3つに整理できそうだ。 ひとつは、「システムを作ることを目的にしていること」だ。 ビジネスを成功させること目的とせず、そのための手段である「システムを作ること」を目的としている「アジャイル開発（？）」では、うまくいかないのは当然のことだ。 2001 年初頭、ユタ州スノーバードで、ソフトウェア開発の将来
アジャイル開発やスクラムにもマネジメントは必要だ
Photo by Pixabay on Pexels.com 最近、よくお客さま向けに「アジャイル開発やスクラムにも、マネジメントやプロジェクトマネジメントは必要だ」と話すことが多い。事の背景はこんな感じ。 背景 よくあるのが「アジャイルチームは自律して動くからマネージャはいらない」という意見だ。この意見はおおむね正しいと思う。「おおむね」の理由は、マネージャという役割は自律型組織にとって必要なくなってくるだろうけど、マネジメントという仕事はなくならないからだ。 会社全体が自律型であれば、もしかしたらマネジメントすらいらなくなるのかもしれない。ただ、ほとんどの組織がそうではないのが現状だろう。よって、四半期ごとに目標設定と評価が発生するし、人材を採用したり育成する計画は必要だし、予算管理や体制変更も検討しなければならない。 こんな状況から「マネージャとマネジメント」を引っこ抜いてもうまくい
株式会社メルペイ UXリサーチャー。2014年株式会社リクルートジョブズへ入社し、人材領域のデジタルマーケティングやプロダクトマネージャーを経て、UXリサーチチームの立ち上げを経験。 株式会社メルペイでUXリサーチャーをしている松薗です。 2019年9月に開催されたUX MILK Fest 2019にて、「アジャイルUXリサーチ」という、弊社のUXリサーチの取り組みについてお話をしました。UXリサーチのマニアックな話にどれだけ興味を持っていただけるかドキドキしていましたが、当日は会場後ろで立ち見が出るほど多くの方にご参加いただきました。 今回は登壇の際、お話した内容を記事に再編集してご紹介します。 メルペイについて まずはじめに簡単にメルペイについてご紹介させてください。メルペイは、日本最大のフリマアプリを提供する株式会社メルカリのグループ会社である、株式会社メルペイが運営するスマホ決済サ
スクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なるさまざまな人々が集まる学びの場でもあるスクラムフェス大阪2020。「今あえてのスクラム」のテーマで登壇するのは、株式会社アトラクタのFounder兼CBOでもある永瀬美穂氏。後半となる今回は、いよいよスクラムの話に突入します。スクラムについての振り返り方や、今までの価値観に囚われていてはダメで、新しい価値観の構築が必要など、これからのスクラムとの接し方について話してもらいました。 スクラムとは 永瀬美穂氏（以下、永瀬）：まずは、そもそも「スクラムって何ですか？」という話になります。本当に頼んだわけでもないのに、最初のオープニングトークというかネタがうまくハマっていまして。「マネジメントのためのフレームワークなんですか？」とかを考えている人ももちろんいるでしょう。例えば「スプリントを回すことによって改善し続ける方法、開発
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発はなぜ失敗するのか？ ガートナーが絶対押さえるべき6つのポイント解説
アジャイルは手段ではないよ。｜市谷 聡啓 (papanda)
6割超のエンジニア、現在の開発プロセスに「課題あり」、大規模開発にはアジャイル型を求める声
ダブルチェックを低減する技術 - ESM アジャイル事業部 開発者ブログ
社内でアジャイル開発標準を作るときの注意点を教えてください
アジャイルをスケールするフレームワーク徹底比較 - Part 1 | Agile Studio
2020年のアジャイル開発書籍をつまみ食い / agile books 2020
アジャイル開発のボトルネックにならないために ソフトウェアテストの2つの課題と3つのアプローチ
大規模なアジャイル開発の現場と技術負債 / Technical Debt
新規事業の進め方。アジャイル型プロジェクトマネジメントとは？ | Growth Hack Studio Blog
今の時代に増えている「いきなり大きく始める」開発 変化する“大規模アジャイル”のかたちにどう向き合うか？
アジャイルやスクラムでも遅い？ TeslaやSpaceXがイノベーションを生み出せる理由
アジャイル開発の「安定感」を高める、「スプリントゼロ」
アジャイルでの開発体験をよくするための優れたツール集
アジャイルでウオーターフォールよりひどい失敗、原因は経営とSEの双方にあり
アジャイルにならなくてもいいんじゃないか - 下林明正のブログ
Will/Can/Mustとアジャイル - 西尾泰和のScrapbox
組織全体がアジャイルになっていくには 〜アジャイル推進室連載企画第2弾〜 - SmartHR Tech Blog
RailsアプリをRBS + Steepで型チェックするまでの手順 - アジャイルSEの憂鬱
アジャイルであり続けるために技術スキルと向き合う
アジャイル開発の「人的側面」の課題を解決する「システムコーチング」
見積もりでアジャイル開発の予測可能性を高める - 「キャリトレ」での実践例
東京都が初のアジャイル型開発にチャレンジ 新しい取り組みを内部に浸透させるために作成した『都庁アジャイルプレイブック』とは
手法を真似ただけのアジャイル開発、業務をデジタル化しただけのDX | ネットコマース株式会社
メルペイが実践する「アジャイルUXリサーチ」とは
先が読めないからこそアジャイルが役に立つ 予定調和にハマらないためのスクラム活用術