「納期コミットのオーダーは結果的に納期を遅らせること」を逆手にとる - @i2key のBlog
これは Recruit Engineers Advent Calendar 2022 - Adventarの13日のエントリーです。（書いているのは21日です。） 1. 納期コミットのオーダーは結果的に納期を遅らせる 先日、興味深いエントリーを読んだ。 bufferings.hatenablog.com これにつてはほぼ同じようなことを社内のtimesチャネルでも会話しており、スケジュールへの向き合い方についてメタ的理解に昇華させたい。 我々が納期をコミットしなさい、確実に守れる日を教えてと言われたときにやることは、、、 確実に納期を守れるように、余裕をみる。である。 ------------------------------------------------------------ ■：実作業日（問題なければできそうな工数） □：バッファ日（例えば50％の確率で問題おきたときに使う予
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021
アジャイル開発の外部委託が「偽装請負」だと疑われないためにすべきこと、厚労省が公表した疑義応答集を読み解く（前編）。Agile Japan 2021 アジャイル開発において開発担当者を外部のベンダに依頼した場合、必然的に発注側の企業とベンダ側の開発者が1つのチームとなり密なコミュニケーションを行います。 すると、発注側の企業がベンダの開発者の業務遂行に対して具体的な指示を行う、いわゆる「偽装請負」とみなされる可能性があるのではないか？ という疑義が以前から呈されていました。 この疑義に対して、どのように対処すれば偽装請負と見なされないか、その指針が今年9月に厚生労働省から「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」として公表されています。 オンラインで11月8日に開催されたイベント「Agile Japan 2021 Day 0」では、この疑義応
“オブジェクト指向”と“テスト駆動開発”は非常に相性がいい 2010年前半におきたツールのムーブメント
受け入れテスト駆動開発（ATDD）が2013年からどのように変化してきたかについて、デロイトトーマツコンサルティング合同会社執行役員のkyon_mm氏とBASE BANK株式会社テックリード兼マネージャーの東口氏がトークをしました。全4回。1回目は、ATDDの歴史とkyon_mm氏の試みについて。 ATDDについて8年越しのリプライ kyon_mm氏（以下、キョン）：今日のイベントについて説明します。みなさんconnpassでお集まりいただいたと思うんですが、1990年代に広まりはじめたTDD（テスト駆動開発）について、2013年くらいに私がちょっと話をしました。 先日、日本でも有数の優秀なエンジニアたちが集ってプレゼンテーションする「July Tech Festa」というカンファレンスの中で、東口さんがATDD（受け入れテスト駆動開発）のプレゼンテーションをしていたんですね。そのときに私
なぜスクラムチームをスケールしたくなるのか - だいくしー(@daiksy)のはてなブログ
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか？」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか？ そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
ついに、Scrum Inc Japan 設立！ 社会変化をプログラマの力で。
ついに、念願の Scrum Inc, Japan が設立しました。永和システムマネジメントからのニュースリリースはこちらです。 永和システムマネジメント、KDDIと共同でイノベーション組織に変革するアジャイル教育プログラムの提供を開始 ～不確実なビジネス開発を成功に導くスクラムの普及を目指す～ 3/8 Scrum Inc, Japan 設立記者発表会 一昨年から、KDDI さん 米国 Scruminc社と組んでスクラムの日本での研修およびコーチングを提供し始めました。日本でも、イノベーションを企画する大企業からセミナー参加者が増え、コーチングにも声がかかるようになり、ビジネス側もアジャイルに注目する状況になってきました。 私の思いは、Scrum の Co-creator である Jeff Sutherland の会社と、永和でこれまで培ってきた現場のアジャイル導入実績、さらにKDDIさんが
スプリントバックログを活用して強いチームを作ろう | Graat（グラーツ）-グロース・アーキテクチャ＆チームス株式会社
スプリントバックログはアジャイル開発におけるToDoリストである、という説明を目にしたことがあります。 この「バックログ＝ToDoリスト」という説明、半分間違いで、半分正しいと思います。 確かに、スプリントバックログは、タスクリストの役割を持っています。が、スプリントバックログの目的は、タスク管理だけではありません。 というか、スプリントバックログを、タスク管理にしか使っていないとしたら、非常にもったいないです。なぜなら、スプリントバックログは、チームビルディングのツールとしても非常に有効なものだからです。 プランニングを変えれば、チームが変わる これから開始するスプリントのために、バックログアイテム（タスク）が２０件あったとします。スプリントプランニングで、この２０件すべてに担当者をアサインしているチームを、ときおり見かけます。 もし、あなたのチームが該当するとしたら、可及的速やかに、そ
アジャイルを凌駕する「超アジャイル」のすすめ––開発現場の“Why”と向き合う重要性
2018年11月12日、KDDI DIGITAL GATEにて、Tech-onが主催するイベント「Tech-on MeetUp#03」が開催されました。今回のテーマは「アジャイル」。スクラムやカンバン方式などのアジャイル開発をそのまま導入しても、思ったような成果が出ないこともあります。そこで、現場でうまくいっている事例を実際の開発メンバーに語っていただき、その成功の秘訣と知見を共有しました。プレゼンテーション「超アジャイルのすゝめ」に登壇したのは、楽天株式会社の及部敬雄氏。彼がアジャイル開発に出会ってから今日までの軌跡と、その過程で学んだこと。そして「超アジャイル」という考え方の重要性を語ります。講演資料はこちら 超アジャイルのすゝめ 及部敬雄氏（以下、及部）：カレーのようにすべてが詰まったお話をさせていただきます。よろしくお願いします。 （会場笑） 『超アジャイルのすゝめ』というタイトル
チケット駆動開発で作業管理はしないほうがいい - arclamp
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance
言いたいことがストレートに伝わる良い文章だと思います。 simplearchitect.hatenablog.com ウォーターフォールはなんのメリットもない。プロジェクトの工程間のつじつまを合わせることができないやり方でオーダーメイドのソフトウエアが正しく作れるわけがない。正しいし、それなら一切のメリットが無いという話も理解できる。 では、ここで小噺をひとつ。受託開発の要件定義フェーズであなたは要件を変えないと顧客にとって不都合が起こることがわかったとします。社内で相談した結果、えらい人がこう言いました。 確かに不都合はあるかもしれないけど、固まった要件を自分から揺り戻すなんて出来ないぞ。これ以外やりませんって合意を取らないと前に進めないだろ？ その変更が違う変更を産むかもしれないし、お前それ膨らんだ時に責任取れるの？ 僕の実体験を一部脚色してお伝えしています。簡単に言えば、ソフトウエア
厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016
厳格なウォーターフォールの金融系IT企業が、スクラムを採用した初のアジャイル開発プロジェクトの経緯と成果を語る（前編）。Regional SCRUM GATHERING Tokyo 2016 金融系システム開発会社として、しっかりしたプロセス管理の下でウォーターフォールによる開発を続けてきたニッセイ情報テクノロジー株式会社。 同社は、1月19日と20日に都内で開催されたアジャイル開発手法の1つ「スクラム」をテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」で、同社として初めてスクラムを採用したプロジェクト開発の事例を紹介しました。 金融系の開発で求められる高い品質などをアジャイル開発の特性を活かしながらどのような手法で確保したのか。そして厳格なプロセスで開発してきた文化を持つ企業の中でアジャイル開発を成功させた要因は何だったのか。事例から読み取る
マネージャのいない組織に進化する現実と幻想 - ワザノバ | wazanova
マネージャのいない組織へのチャレンジについては、一昨年から話題になっていますが、ここにきてかなり論点が絞られてきていると思います。 1) 非同期 & 可視化が進む GitHubなどのツールに親しむエンジニアが、進捗が可視化され、非同期で仕事を進めることに先に慣れてきたが、SlackのようなコミュニケーションツールやTrelloなどのタスク管理ツールの浸透で、非エンジニアにもじわじわその理解が進んでいく。 2) マネージャの役割が変わる 上記1) が進むことで、進捗を報告させて情報を集約、また逆に、全社 / 業界の情報をフィルタリングして伝えるという、情報操作ハブとしてのマネージャの役割はかなり減る。情報の透明性があがることで、情報を握っていることがマネージャのパワーの源泉である時代が終わる。 プロジェクトの進捗 / 開発のクオリティ / 売上 / 評価とフィードバック / メンバの士気の向
永和さんの「価値創造契約」が大苦戦を強いられている件 - GoTheDistance
この資料、非常に衝撃的だった。中の人がここまで公開していいものなのか、という意味でも。 俺の価値創造契約 from Fumihiko Kinoshita 永和さんの価値創造契約とは 新しい契約形態での受託開発サービス「価値創造契約」 ｜ 永和システムマネジメントに詳しくありますが、簡単にいえば「初期費用無料で、常に改善・運用をしながら月額定額制でシステム利用料を頂く」というビジネスモデルです。価値あるシステムは必ず長く使われ変更を伴うのだから、その変更を受け入られるモデルを提供すれば双方にメリットがある。これが立脚点のようです。 2013年営業実績、0件 資料によればテレアポを800社行い、様々な展示会にも出展されたそうです。12社にコンタクトできたけれど受注は0件だと書いてあります。マーケティングに失敗してしまったと言って良いでしょう。 受託開発の弊害と指摘される「価値あるシステムを作り
なぜアジャイル開発はうまくいかないのか 〜 Don’t just do agile. Be agile. | Social Change!
私たちソニックガーデンの「納品のない受託開発」に取り組むソフトウェア開発のスタイルは、一般的に「アジャイル開発」と呼ばれるものに近いです。 しかし実際のところ、私たちは「アジャイル開発」をしようなんてかけ声をかけたこともないですし、普段から社内で「アジャイル開発」が話題になることもありません。「アジャイル開発」をしようと思ってしている訳ではないにも関わらず、「アジャイル開発」をやっているように見えるというのです。 この記事では、「アジャイル開発」について私たちが考えていること、そして、なぜ多くのアジャイル開発は失敗してしまうのか、うまくいくためにどうすればいいのか考えてみました。 2012-12-28 / Giåm 結果としてのアジャイル開発〜究極のアジャイル 「あなたにとってのアジャイルとは何ですか？」 先日、ある勉強会で質問されました。ちょっと想定外の質問だったので、しばし考えたあと私
読んだ: アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント - ひだまりソケットは壊れない
開発手法としてスクラムを取り入れているチームに所属しているが、アジャイルやスクラムといった手法についてあまり知識を持っていないソフトウェアエンジニア、という立場で本書を読んだ。 本書のカバー袖には 『企業の経営層に向けてソフトウェア開発手法の 「アジャイル」 とその手法の一つである 「スクラム」 を体系的に解説する』 とあるのだが、経営層に限らず、アジャイル的な開発手法を採用して開発プロセスを改善していこうとする人であれば、誰にとっても有益だと思う。 アジャイル開発については、ウォーターフォールとの比較として 「小さなサイクルを回して変化に柔軟に対応しながら開発を進める」 という程度の理解しかなかったので、本書を読んで 「人が知識を運ぶ」 とか 「人と人のコミュニケーションで知識を伝える」、「顧客と協調して開発を進める」 といった、どちらかというと社会的な活動やその意義についての部分が非常
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
アジャイル開発がSIビジネスと相性が悪い本当の理由：ITソリューション塾：オルタナティブ・ブログ
「NTTデータ、アジャイル開発の専門組織を設置・人材育成も展開（ZD Net Japan）」 こんな記事が目にとまった。大手SIerも取り組みに本腰を入れ始めたのかと想いながら、記事を読み始めて、いろいろと疑問がわいてきた。 最近、アジャイル開発を実践される方に話を聞く機会が増えている。先日出版した拙著「システムインテグレーション崩壊」でも、SIerのアジャイル開発への取り組みについて、ページを割いて事例を紹介しているが、そういう方々の話を聞けば聞くほど、アジャイル開発は手法ではなく、働き方や組織運営のあり方だと感じる。 先日も某大手SIerの方に話を伺ったが、アジャイル開発について、いまは自社の研究所で研究している段階で、手法の有効性を検証しているとのことであった。果たして、そういう研究成果が、働き方や組織運営のあり方を変えることになるのだろうかと、疑問に思った。 NTTデータの取り組み
要求開発にて”「これだけ」モデリング”：An Agile Way：オルタナティブ・ブログ
これだけモデリング！というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 （※6/5 追記： 以下に、当日の資料を公開します。） これだけモデリングとは、 誰が？ ー 情報システム部門の人（と開発の人が共に） いつ？ ー システム開発の前段階、すなわち「要求開
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（後編）。QCon Tokyo 2014
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（後編）。QCon Tokyo 2014 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 （本記事は「アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014」の続きです） アジャイルを組織に浸透させるTips ここまでの経験で、アジャイルを組織に浸透させる上でのTipsを紹介したいと思います。 まず、組織を丸ごと変えてやる、と気張ってしまうとやはりだめです。 無理矢理「君たち全員アジャイル開発を始めよ」と言って始めるのは、そもそも自律的な組織ではありません。アジャイル開発を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
実行可能解を理解できないコンサルタント | 杉浦技術士事務所 （情報工学部門）
Yahoo! Japanがアジャイル開発の採用と改善で現場から変えた“サービスの作り方”（前編）。Developers Summit 2016
