昨今、「リーン」という言葉がソフトウェア開発や経営の世界で1つのキーワードになっている。では、そもそも「リーン」とは何か？ アジャイル開発の国内第一人者である平鍋健児氏が、リーンの本質と、本質に触れるための関連書籍を紹介する。 (3/4)
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
前回，タスクかんばんが，現在の状況を見える化するものであり，先を見通すような視点は持ち合せていないことを説明した。この「先を見通す視点」で「進ちょく状況の見える化」を実現するのがバーンダウン・チャートと呼ばれるチャートである。バーンダウン（burn down：燃え落ちる，全焼する）チャートは，一般的なチャートにありがちな右上がりではなく，右下りになっている。チャートを作成する際には，縦軸に残りの作業量を，横軸に時間を割り当てて日々の残り作業量をプロットしていく。右下，つまり残り作業量がゼロ(=全焼)になれば，すべての作業が完了するというわけだ。 バーンダウン・チャートは，元々リリースまでのバック・ログ（プロジェクトとして実施する必要があるすべての作業）の残量を視覚化するチャートだったが，現在はイテレーション単位でのタスクの残作業量（デイリー・バーンダウン・チャート）の見える化にも使われてい
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（後編）。QCon Tokyo 2014 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 （本記事は「アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014」の続きです） アジャイルを組織に浸透させるTips ここまでの経験で、アジャイルを組織に浸透させる上でのTipsを紹介したいと思います。 まず、組織を丸ごと変えてやる、と気張ってしまうとやはりだめです。 無理矢理「君たち全員アジャイル開発を始めよ」と言って始めるのは、そもそも自律的な組織ではありません。アジャイル開発を
アメーバ事業部が混乱から立ち直ってスクラム導入を成功させるまで（前編）。QCon Tokyo 2014 スクラムのようなアジャイル開発手法を採用して開発をうまく回している現場も、最初からうまくいっていたわけではありません。現場ごとに試行錯誤を重ね、よりよい方法を模索する中で少しずつ改善が進んできているはずです。 4月30日に都内で開催されたイベント「QCon Tokyo 2014」では、サイバーエージェントのアメーバ事業部が混乱の中からどうやってスクラムを導入してきたのか、その経験とそこで得られた知見が語られています。セッションの内容をダイジェストで紹介しましょう。 Ameba流 Scrumを浸透させていく方法 サイバーエージェントの大﨑浩祟です。アメーバ事業本部コミュニティ事業部というところで、現在は24Logのシステム責任者をしています。
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
IT業界で特に最近大きな注目を集めているのが、迅速なソフトウェア開発を実現する“アジャイル”や大きなビジネスイノベーションをもたらす“リーン”といったコンセプトだ。国内のIT産業がグローバルでより高い競争力を獲得していくために、これらの手法をどのように活用していけばいいのか。マネックス証券 常務執行役員CTOで、セーフキャストジャパンの創設者であるピーテル・フランケン氏が、自社での開発活用例やボランティア団体での取り組み事例について語った。 4つの課題に対して有効な「アジャイル」と「リーン」 はじめにアジャイルとリーンの概要について簡単に触れておこう。前者は一般的にアジャイル開発という言葉で使用され、アジャイル（＝agile：俊敏な、機敏な）という名の通り、コアとなるシステムを小さく作ってまずは動かし、ビジネス側のフィードバックを受けながら繰り返し改善を加えることで完成形に近付けていくとい
システム開発と言えばいまだウォーターフォールが多い日本だが、IPAが6月11日、海外でのアジャイル型開発の拡大を分析した報告書「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」を発表した。 この調査は日本のソフトウェア産業の強化を目的とし、欧米におけるアジャイル型開発の普及要因を明らかにすることを意図して行われたもの。アジャイルが普及している各国ごとの要因として、米国では「ユーザ企業にIT技術者が多く、内製化率が高い」、ブラジルでは「米国からのオフショア・受託開発が多く、また国内でもアジャイルにおける成功例が認知されている」、デンマークでは「政府調達においてアジャイルが推奨されている」といった点が上げられており、またIT技術者の評価が高く流動性も高いため、知識が業界内を伝播しているといった分析がなされている。 一方、こういったアジャイルが普及している国においても「I
アジャイル手法を実践できるプロジェクトは恵まれている。それは、「理解ある管理者」がアジャイル手法を了承してくれたからではない。管理者がそう判断できるほどに参加メンバーが優秀だからだ。 アジャイルの特徴のひとつが「少数精鋭」である。いっぽう、アジャイルの対立手法として理解されているウォーターフォール型手法では「人海戦術」で進められる点が対照的だ。じつは「少数精鋭」というのはアジャイルの特徴であるだけでなく、あまり触れられたくない弱点でもある。なにしろ「精鋭」しか関われない。 しかしアジャイル手法の推進者は、自分が優秀であることをそれほど意識していない。それどころか彼らは「いえいえ精鋭である必要はありません。じっさい私はアジャイルが大好きですが、凡庸な技術者ですよ」と自嘲的に語るだろう。そしてそれは本心でもあるだろう。なぜなら、彼らは「超」がつくほど優秀な技術者たちがいることをアジャイルコミュ
59 views 長年の現場経験からうまくやっているアジャイル チームが暗黙的に理解/共有している秘訣についてまとめました More… アジャイルチームの秘密 — Presentation Transcript アジャイルチームの秘密 ©2009-2012, Sertice Inc. All rights reserved. 1 はじめに• 弊社はコンサルティングサービスを通じてアジャ イルチーム立ち上げのお手伝いを行っています• 長年の現場経験からうまくやっているアジャイル チームが暗黙的に理解/共有している秘訣について お話いたします• また、この秘訣をチームとして組織として達成/維 持するためのポイントと弊社事例も紹介いたしま す• 最後に、御社が外部のエンジニアリングリソース をうまく活用して開発部門のアジャイル対応を実 現するための課題について提案いたします 2 ©200
2012年に@ryuzeeが研修や社内トレーニングで使っていた資料を公開します。2013年からは別のマテリアルを使って研修を行う予定です。利用は個人や社内の学習の範囲とし営利目的では利用しないでください。
CEDEC事前インタビュー：アジャイルで大規模開発？ スクラムを使ったゲーム開発の可能性とは 編集部：aueki ゲームリパブリック技術部部長 田中宏幸氏 コンピュータというものが世に現れて以降，プログラム開発は常に重要な課題だった。現状のコンピュータの祖となるEDSACが登場して60年あまり，パソコンが登場して35年あまり，ゲーム機だとファミコンが登場して27年，その間に数多くのハードウェアが登場してきたものの，より重要だったのはどんなソフトウェアが動くかであったといえるだろう。産業としては，まだ数十年の歴史しか持たない分野ではあるが，ソフトウェア開発で方法論の蓄積は進んでおり，いかに効率を上げていくかという学問が「ソフトウェア工学」として成立している。 そのなかの一つに「アジャイル開発」と総称されるものがある。 「アジャイル」は「AGILE＝俊敏な」，という意味。RPGのパラメータで「
アジャイルフィーバーは、ソフトウェアを開発するために、アジャイルベースのプロセスを採用したり、応用したりすることに関して、その他の点では分別ある人々から常識を奪う１つの条件です。アジャイルフィーバーの結果は、コスト的影響を伴って、アジャイルベースのソフトウェア開発プロセスの誤適用、誤使用、誤解に寄与してきた。例えば、マネージャのパフォーマンス基準に、いくつのプロジェクトでアジャイルを採用したかを用いた。例えアジャイルの採用が適していなくともである。ROIの望みがない状況なのに、アジャイルを採用したプロジェクトもある。また他の例では、トレーニングや再編に投資したが、以前と全く同じ方法でソフトウェアを開発し、アジャイル辞書から取ってきた新しい用語を使っていた。 この記事を読んでいるかもしれない、あらゆる Fragilistas1 が怒る前に、この記事は、アジャイルに対する攻撃で、その著者に対し
「アジャイル開発の本質とスケールアップ」で「アーキテクチャ助走路」というプラクティスがあったので考えたことをメモ。 ＃ラフなメモ書き。 【1】「システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践)」にもあるように、アジャイラーとアーキテクトの間には緊張関係がある。 小規模リリースとアーキテクチャの作り込みは、多分組み合わせが良くない。 アジャイラーとアーキテクトの緊張関係: プログラマの思索 アジャイル開発とソフトウェアアーキテクチャの緊張関係: プログラマの思索 WF、XP、RUPではアーキテクチャの考え方が違う。 WFでは、アーキテクチャは計画される。 XPでは、アーキテクチャは出現する。 RUPでは、アーキテクチャは成長する。 XPでは、「アジャイル開発の本質とスケールアップ」によると、最初のイ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
