SI事業者のアジャイル開発はなぜ失敗するのか：ITソリューション塾：オルタナティブ・ブログ
「アジャイル開発に取り組んではみたのですが、うまくいかないので、元のやり方に戻そうと思っています。」 あるSI事業者での講演の後、こんな話しを伺った。同様の話しは、他でもよく耳にする。 私は、エンジニアでもなければ、アジャイル・コーチでもない素人だ。ただ、成果をあげているアジャイル・チームの連中との付き合いは多く、「門前小僧」程度には、アジャイルについては理解しているつもりだ。そんな、私でさえも、これは失敗するだろうと、思うことが多い。 うまくいかない取り組みに共通しているのは、おおよそ以下の3つに整理できそうだ。 ひとつは、「システムを作ることを目的にしていること」だ。 ビジネスを成功させること目的とせず、そのための手段である「システムを作ること」を目的としている「アジャイル開発（？）」では、うまくいかないのは当然のことだ。 2001 年初頭、ユタ州スノーバードで、ソフトウェア開発の将来
『要はアジャイルは行き当たりばったりってことですか？』へのコメント
どちらにしても会計法と予算制度の想定からは外れているので、アジャイル開発よりも前に調達制度を見直さないことには聳え立つ糞を建立し続けることになりますぞ、と
『日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance』へのコメント
スクラムの教科書的にはPOは顧客じゃないほうがいいって話じゃなかったっけ。/ https://www.ryuzee.com/contents/blog/7143 で書かれてるような印象がある。/ ソース https://scruminc.jp/training/owner/ POは顧客でない想定に読める。 <blockquote class="hatena-bookmark-comment"><a class="comment-info" href="https://b.hatena.ne.jp/entry/4683781687071625954/comment/tpircs" data-user-id="tpircs" data-entry-url="https://b.hatena.ne.jp/entry/s/gothedistance.hatenadiary.jp/entry/202
日本のITの未来を担うSES、あるいはプロダクトオーナーの重責について - GoTheDistance
先日、アジャイル開発を推進するために大変有意義な資料が公開されています。ESMの木下さんといえば、アジャイル開発の現場にずっと携わってきた著名な方です。 note.com でも、令和2年にこちらの記事が何百もはてブされるのも、おいおいマジかよって思う所がありまして。今までどうやってたのだろうか...。準委任(時間単位のチャージ)以外の選択肢がないやり方だと思っていたので。請負でアジャイルを取りに入れるわけないですよね。一般的なSIerさんでは、どういう理解をされて、どう取り組んで来たのだろう。 アジャイルと受託開発の相性は最悪では ムービング・ターゲットを請負で追いかける自傷行為を誰がやるんだって話と、要件固めて下請けに出せないから誰もやりたがらないよねという話を書き散らしています。 10年前に書いた記事の内容がまだ通用してしまうのも、自分でも少し寂しい気持ちがあります。 gothedis
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた | DevelopersIO
「アジャイル開発ってのに取り組むことになったんだけど、何を読んだらいいの？」という質問を受けたので答えてみた 事業開発部の塩谷 (@kwappa) です。 いきなり家庭の私事で恐縮なのですが、今朝出がけに妻からタイトルのような質問を受けました。 そのまま「Slackにリンク投げといてね！」と言い残して出て行ったので（我が家では家庭の連絡にSlackを使っています）、やっきになってぺたぺた貼ったリンクをご紹介しようと思います。 といっても、アジャイル開発の経験がある方ならお馴染みのものばかりです。「あーなるほど」と納得していただけたら幸いですし、「これも読んどけ！」という推薦もお待ちしています。 「まずはこれを10回読む」 …と最初に貼ったのが「アジャイルソフトウェア開発宣言」 (Agile Manifesto)です。すべての始まりですから、ここを読まなければ始まりません。ほんとうは「100
XP祭り2019 B-6 アジャイルソフトウェア開発への統計的品質管理の応用
English Version： https://www.slideshare.net/sakataakinori/xp-fes-2019-b6-application-of-statistical-quality-control-to-agile-software-development XP祭り2019 B-6 「アジャイルソフトウェア開発への統計的品質管理の応用」の資料です。 On 2019年8月20日, in XP祭り2019, XP祭り2019セッション 【セッション情報】 セッションID：B-6 時間：14:45～15:15（30分） 会場：B（1F 102室・後） タイプ：講演 【セッション内容】 アジャイル開発のマネージメントやチーム運営のお手伝いをしていく中で、ウォータフォールで使われている品質メトリクスを利用しようとしているプロジェクトを見かけることがあります。 ウォー
デザイナーとスクラム開発｜といとい
こんにちは。@toi_toi_yです。 サイボウズという会社でkintoneというプロダクトのデザインをしてます。 自分は数年前、kintone開発チームがスクラム開発を始めた頃にkintone専任のデザイナーとしてチームにジョインしました。 それから様々な変化がありつつもずっとスクラム開発のなかでデザイナーをやってきました。 というわけで、デザイナーとスクラム開発の話を書きます。 サイボウズのスクラム開発については弊社スクラムマスターの資料をご覧ください。 https://speakerdeck.com/ama_ch kintone開発チームのスクラム（2019年現在）- スプリントは1週間 - 開発チームはPG×3〜4人のサブチームが4つある - デザイナーは1人（+ チーム外のデザイナーが手伝ってくれてる） - 開発はモブプログラミングで進める。デザイナーも適宜必要に応じて参加するき
How Scrum boosts your innovation in Japan
How Scrum boosts your innovation in Japan 1. Scrum Inc. Japan 株式会社 取締役 平鍋健児 2 ⽇本のイノベーションを 加速するScrum 2. 平鍋健児 (株)Scrum Inc, Japan 取締役 (株)永和システムマネジメント社⻑ (株)チェンジビジョンCTO アジャイルジャパン初代実⾏委員⻑ • アジャイルを⽇本に広めたい • システムズエンジニアリングツール astah* 開発、起業 3 3. COO Toyota Research Institute - Advanced Development, Inc. ⾍上 広志 5 4. こちらからご覧ください https://scruminc.jp/scrum-consulting-and-coaching/casestudies/tri-ad/ 5. 9 6. ⽇本の⽼舗
「正しいものを正しくつくる」は、エンジニアの傲慢が詰まった書籍か - ビープラウド社長のブログ
「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで」の著者、市谷聡啓さんが2019年6月に出版した「正しいものを正しくつくる プロダクトをつくるとはどういうことなのか、あるいはアジャイルのその先について」を拝読しました。 本書をおすすめしたい人 プロダクト開発において、アジャイル開発での進めかたを知りたい人 アジャイル開発チームのプロダクトオーナー(ビジネスサイド、企画者） プロダクト開発チームが所属している会社の経営者 アジャイル開発を新たに学びたい人 アジャイル開発をひととおり知っているが、あらためて学びたい人 「正しいものを正しくつくる」という中心理念 本書のAmazonレビューを見ていたところ、星1つのレビューを見つけました。 エンジニアの傲慢さが詰まった本 「正しい」という言葉を使うエンジニア、同じエンジニアとして非常に恥ずかしい思いです。 「正しいも
LeSSでつなぐビジネスとIT
アジャイルジャパン2019で発表させていただいたスライドです。 時間が余ったら話そうとしていたおまけスライドも付けてあります。
14. なぜ、エンタープライズ業界でアジャイル・リーンは普及しないのか？ | fukabori.fm
話したネタ なぜ、企画と開発が責任を押し付け合う会社の前途は暗いのか？ 計画が悪い vs 実装が悪い、というどっちが悪い論 問題の理解と、その実装（人・システム）が時間軸で離れると学習がない、課題の理解は実装で深まる 市場、世界は悠長に回っていない 将棋でのメタファーとRTSでのメタファー 上手くいかないのは全体という前提をどこまで作れるか？ 仕様が固まってから開発の後半で発生する変更を怖がる あたかも世界の時間が止まっているように振る舞う オーシャンズ11 その場の状況にあった計画を立て直していく、情報を得続ける 現代の戦争は火力戦・物量戦から変わってきている 企画と開発も同じコンテキストで話さないと、リアルな変化に追従できない ピラミッド構造は例外処理が役割の1つ 手順書はQ&Aに答えてくれない Q&Aに答えられる人が現場にいない リーンスタートアップやアジャイルなやり方が出てきた背景
2023年になっても日本企業の基幹系システムの80％はオンプレミスで商用RDBを使い続ける。臨機応変なデータ分析ツールはExcelであり続ける。ガートナーの予想
2023年になっても日本企業の基幹系システムの80％はオンプレミスで商用RDBを使い続ける。臨機応変なデータ分析ツールはExcelであり続ける。ガートナーの予想 ガートナー ジャパン株式会社 は、今後3～5年間で企業の顧客戦略に大きな影響をもたらす動向に注目した、アプリケーション領域における2019年の展望を発表しました。 発表にはいくつかの項目が含まれています。その中から3つの予測をピックアップしました。 ■2023年を迎えてもなお、日本の大企業における基幹系システムの80%が商用のリレーショナル・データベース管理システム (RDBMS) を使い、オンプレミスで運用し続ける ガートナーが日本企業に行った調査によると、ERPとその中でも汎用化しやすい業務を除いた基幹系システムににおいてはクラウドの採用が進んでいないことが明らかになっています。同様のことが、基幹系システムに利用されるRDBM
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと
新人SEがアジャイル開発を学ぶ価値
「新人SEに学ばせるべき開発手法は、ウオーターフォール開発か、アジャイル開発か」。筆者が最近気になったテーマだ。 日経 xTECHでは先日、IT企業の新人SE研修を取り上げた特集記事を掲載した。人工知能（AI）やクラウドといった新技術の広がりや新人のスキルの多様化、ビジネス環境の変化などに対応すべく、新人SE研修を見直す企業の取り組みを紹介した。 各社が様々な工夫を凝らす研修の中で、筆者が注目した取り組みの1つが、システム開発プロセスの教育に関するものだ。NTTデータは2019年の新人SE研修で、アジャイル開発をウオーターフォール型開発プロセスよりも先に教えるという。 従来国内の多くのIT企業では、ウオーターフォール型の開発プロセスを習得したエンジニアが、アジャイル開発を学んでプロジェクトに入るのが一般的だったと言える。日経BP社が実施しているアジャイル開発の講座でも、中堅やベテランと言え
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the it
スクラムで失敗する5大理由とその対策としてできること | POSTD
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Ryutaro YOSHIBA on Twitter: "スクラムってカタカナ語が多くて人に説明しにくいって言われたので、スクラム用語使わないで説明する資料作ってみた https://t.co/KiFxXjMNgs"
改善失敗して学ぶ、
レガシープロダクトに立ち向かうチーム作り。
Ryutaro YOSHIBA on Twitter: "スクラムチームの成熟度モデルに関する基準の例がCCライセンスで公開されていたので、日本語化したものを共有します。元ネタは、https://t.co/lFsD9KDUf1 https://t.co/v1HlDK3z1k"
12 Principles Behind the Agile Manifesto | Agile Alliance
