ドラクエXマネージャが語る大規模アジャイル開発の極意 － ＠IT
2012/08/29 「ドラクエXのようなトリプルA級タイトルの開発スケジュールは最初から組み替えることが前提。イレギュラーな事案が発生するのは大規模開発では当然のこと。不確実だからこそ、少しずつ良い感じにしていくことができるアジャイルは大規模開発の手法として親和性が高い」 本稿では8月20～22日の3日間に渡り、パシフィコ横浜で行われたゲーム／コンピュータエンタテインメント開発者のためのイベント「CEDEC 2012」（主催：一般社団法人コンピュータエンタテインメント協会）で行われたセッションの中から、スクウェア・エニックス 開発部 ドラゴンクエストX デザインセクションマネージャー 荒木竜馬氏が8月20日に行った「大規模開発のプロジェクト管理 - ドラゴンクエストXにおけるマネージメント事例」の内容を紹介する。 ゲーム開発にはアジャイルが向いている!? ゲームをやらない人でも、ドラゴン
これは便利！JavaScriptのエラーをログする·ErrorBoard MOONGIFT
ErrorBoardはJavaScriptのエラーを監視してログに残してくれるソフトウェアです。 システムでエラーが起きればそれをログに残して対処するというのは一般的です。しかしサーバサイドと違ってJavaScriptでのエラーは意外と放置されているのではないでしょうか。そこで使ってみたいのがErrorBoard、JavaScriptエラーのログソフトウェアです。 エラーを取得しました。 エラーの詳細です。 ソースで見てエラーが起きた場所を確認できます。 対処したらチェックします。 ErrorBoardを使えばブラウザごと、時間ごとにエラーが起きた場所をログに残せます。後はそれぞれに必要な修正を行った後、対処済と印をつけていくのみです。ブラウザやバージョンによって動かないといったケースも考えられるだけに、設置しておくと様々なケースに対する対応が出来るようになりそうです。 ErrorBoar
プロジェクト運営の難所はこうして乗り越える
関連キーワード RFP | IFRS | ERP | Excel | PMO（プロジェクトマネジメントオフィス） 第3回「経営と業務部門の協力を引き出すプロジェクト運営術」では、経営がガバナンスを効かせるための「ステアリングコミッティ」、ならびにIT部門、業務部門の連携を円滑に進めるための「協同プロジェクト体制」について紹介した。今回は、IT部門・業務部門の連携タスク（要件定義、ベンダ選定、受け入れテスト、システム・業務移行など）を乗り切るためのプロジェクト運営術について考察する。 本稿では、要件定義、ベンダ選定を例として、まず始めに推進上の難所を整理した上で、それらをうまく乗り切るための運営術を具体的に述べていく。 連載インデックス 【第1回】実は知られていない「PMO」の基本的な役割 【第2回】事例で見る、プロジェクト別PMO使いこなし 【第3回】経営と業務部門の協力を引き出すプロジェ
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
バグレポートでテストエンジニアとプログラマが持つ“認識の違い”を埋めるには
出典: N. Bettenburg, S. Just, A. Schroter, C. Weiss, R. Premraj and T. Zimmermann: What Makes a Good Bug Report? Figure 3から一部抜粋 アンケートはApache, Eclipse, Mozillaを対象に、(a), (b), (c)それぞれについてバグ報告者と開発者466人に回答してもらったものです。パーセンテージは、報告者の何パーセントが役に立つと回答したかを表しています。1人が複数回答することができるため合計が100%を超えます。 例えば、(a)の報告者の回答として「再現方法」がありますが、アンケートに回答した報告者のうち98%が報告していると回答したことを意味しています。表では、このパーセンテージが大きいもの上位5項目を記載しています。 「(a)報告者が報告している情報
【番外編】見積もりミスによるリスクを契約条件で回避する方法（その1）
ここまでの内容で、正確に見積もる方法、見積もり値の使い方、そして、FP試算法、トリアージュ、SLIMの3つの技法を駆使したデスマーチ・プロジェクトの対処法を理解いただけたでしょうか。これらは、いずれも見積もりミス対策の“正攻法”といえます。 今回は少し視点を変えて、契約条件の面から、実践できる見積もりミス対策を検討していきます。意外に効果がありますので、皆さんのプロジェクトでも適用してみてください。 1．一括請負契約と業務派遣契約 ソフトウェア開発は、発注側と受注側（開発側）に分かれて、契約を結ぶのが一般的です。契約条件にはさまざまなものがありますが、やはり、お金を出す発注側が有利になっていることがほとんどです。こうしたソフトウェア開発に関わる契約条件を工夫すれば、見積もりミスによるリスクを軽減できる場合が少なくありません。 一般的に、ソフトウェア開発の契約は、「一括請負契約」と「業務支援
シンプルで格好いい。親切なコードレビューシステム·Barkeep MOONGIFT
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
「状態遷移表による設計手法」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
状態遷移表による設計手法（7）： 状態遷移表を使用したテスト手法【後編】 状態遷移表による設計手法について解説。今回は「状態遷移表を使用したテスト手法」の【後編】として、パステストについて詳しく説明する。（2013/1/31） 状態遷移表による設計手法（6）： 状態遷移表を使用したテスト手法【前編】 状態遷移表による設計手法について解説。今回は「状態遷移表を使用したテスト手法」の【前編】として、ホワイトボックステストとブラックボックステストについて詳しく解説する。（2012/12/20） 状態遷移表による設計手法（5）： 状態遷移表からの実装 状態遷移表による設計手法について解説。第5回では、「状態遷移表からの実装」をテーマに、状態遷移表（設計書）から実装に落とし込むまでのプロセスとその方法について詳しく説明する。（2012/11/7） 状態遷移表による設計手法（4）： 状態遷移表を使用し
DRY原則の利用: コードの重複と密結合の間
原文(投稿日：2012/05/25)へのリンク DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓：ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 DRYは Don’t Repeat Yourself の略語であり、Andy Hunt氏とDave Thomas氏が書籍「The Pragmatic Programmer: From Journeyman to Master」（邦訳：「達人プログラマー―システム開発の職人から名匠への道」）で最初に言及したソフトウェア開発原則だ。その原則はこう述べている。 知識のあらゆる部分はそのシステムにおいて単一で、曖昧さのない、信頼できる表現でなくてはならない。 ここでHunt氏は重複による負の影響と、それゆえにDRYを利用することの重要性を強調
“開発のよくある問題”を解決するCMMIの3大メリット－ ＠IT情報マネジメント
効率的に開発作業を行うために、どのような業界標準を使っていても、さらなる改善に組織を導いてくれるCMMI。今回はその3大メリットを紹介する。 （→記事要約<Page 2>へ） 前回、CMMIとは「開発から管理、組織運営、定量分析まで全てをカバーした“全部入りモデル”」であり、単一のプロジェクトだけではなく、複数のプロジェクトの成功を狙う「組織としてのビジネスの成功を目指したものである」と解説しました。 また、以下の図1はIT業界で使用されている開発の主な標準モデルと、そのカバー範囲をおおまかに示したものですが、このように、アジャイルとCMMIなど「一連の業界標準はお互いに排他的ではなく、重なる部分が多い」ことも紹介しました。すなわち、今現在スクラムを使って開発作業を行っている場合でも、作業を改善するためにCMMIを有効に使うことができるのです。 図1 IT業界で使用されている主要な業界標準
mixiのコードレビューについてご紹介 - mixi engineer blog
こんにちは技術部たんぽぽグループのmasartzです。でも今日はコードレビューアのmasartzとしてお送りします。 mixiの開発フローにはコードレビューという工程が含まれています。 今回はこの工程を行うコードレビューアな人々と、その業務内容、今後（の予定）などをお話しようと思います。 コードレビュー業務 mixiのサービスがスタートしたのは2004年2月の事ですが、コードレビュー業務が始まった正確な日時は残念ながらわかりません。 レビューツールもemailのやりとり->Tracのチケット->JIRAチケットと変遷があるため、最古のものをトラッキングできないのですが、おそらく5年以上前から様々な変遷を経て、今に至ります。 開発者が増えると、開発されるコード量も増えます。つまりレビューする量が増えるため、コードレビューアも増加します。 そんなこんなで現在ではアプリ開発者に対して、コードレビ
ウォーターフォールのほうが楽だという話 - 勘と経験と読経
わたしはまだ本格的な(?)アジャイル開発をやったことは無いけれども、周りのウォーターフォール脳に比べたらアジャイルプラクティスをプロジェクトに取り込むことが多い（プロジェクトマネージャーの立場で、スクラムマスター的に推進）。いくつかのプロジェクトを終えて、結果を振り返ってみるとチームメンバーの平均的な帰宅時間は早まったし、休日出勤することも減ったと思う。QoELは確実に上がったと思っていたけれども、一部のエンジニアからは「キツかった」と言われて驚いた。 アジャイルの前のほうが楽だった？ 「第5回 TFSUG：ウォーターフォールからアジャイル、リーンへ」での発表で、アジャイル開発に挑戦した方がやはり「前のほうが楽だった」というような事を書いている。 http://kaorun55.hatenablog.jp/entry/2012/04/17/001312 第5回TFSUG WFからAgile
あなたは「バグ」をどう数えていますか？ 組み込みソフトウェアの品質管理を考える
あなたは「バグ」をどう数えていますか？ 組み込みソフトウェアの品質管理を考える：＠IT MONOistゼミナール・レポート（1/3 ページ） あなたの現場では、ソフトウェアの品質管理の考え方をきちんと生かし切れていますか？ ＠IT MONOist編集部では組み込みソフトウェアの品質管理をテーマにしたゼミナール「組み込みソフトウェア開発で問われる品質力」を開催。組織における品質管理の考え方や、実際の開発現場におけるツールの活用・導入に関する事例などが披露された。 ソフトウェアの品質管理をあらためて見直すことで、品質向上のみならず、手戻りコストの削減、開発効率の向上が期待できる――というと、「そんなことは分かり切っている」「うちはとっくに取り組んでいる」など、さまざまな意見が聞こえてくる。では、“実際の開発現場で品質管理の考え方をきちんと生かし切れているか”という問いに対してはどうだろうか。「
プロセスを駆動する - メンタルモデル
プロセスは流れ 7回にわたってお届けしてきた「はじめての開発プロセス」も今回で最終回です。最後はプロセスを駆動させるためのメンタルモデルについて考えてみたいと思います。 プロセスは仕事の流れであり、人の動きです。チームワークを効率的に行うために、プロセス定義によって個々人のつくりだす流れを、大きな流れへと集約します。小さな川の流れが、大きな川の流れへと合流するようなものです。 そして、個々人の仕事の流れが他者の流れと交わるときに混乱が生まれます。「意見が合わない」「足並みが揃わない」「何を目指しているか分からない」「何のために今この仕事をしているのか分からない」といったものです。 その混乱から、「時間が足りないという焦り」「今の状況から抜けられないという諦め」「こんな状況を作った人々へのいら立ち」が生まれます。人それぞれに積み重ねてきた経験、獲得した知識、趣味趣向は異なるものであり、それら
若手から「販売の数字なんていつも全然合ってないですよ」といわれる統括本部長
前回のあらすじ 工場勤務のSさんは生産計画グループに所属しており、毎月の「製販調整会議」を主催している。この「製販調整会議」は営業担当者と生産計画担当者が互いの主張を繰り広げ、とりとめもなく丸1日かけて行われる消耗戦。そこまで苦労しても、売れる製品は欠品し、売れない製品の在庫は山となる現実が起きている。そんな状況にSさんは頭を抱える日々なのであった……（前回記事参照）。 今回は営業事業統括本部長Oさん（仮名）の抱える課題を見ていこう。 何をどのように見直せばいいかの基礎情報がナイ 本社勤務の私は最近いら立ちを隠せなくなってきた。世界的な景気後退の影響で、今年度の販売実績が年初に立てた事業計画に届かない月が続いているのだから無理もないと、言い訳のように自分に言い聞かせる日々がしばらく続いている。販売だけでなく利益も同様。このままでは今年度の事業計画を見直さざるを得ない状況であるが、困ったこと
コガネイは、TRIZを使って本気でコマ設計していた
前回も紹介した通り、今回のコマ大戦は心技隊の“おかしら”、ミナロの代表取締役 緑川賢司氏がふとした思い付きをFacebookに投稿したことが発端だった。そして、その投稿からコマ大戦のFacebookページが立ち上がるまでに数日程度あった――「あれ本当にやるのかな？ と、首を長くして企画発動を待ち望んでいました」と話すのは、今回のコマ大戦に参加したクリタテクノの取締役製造部長 黒田正和氏だ。 ゲージ屋さんとコマとエンゲージリング 今回のコマ大戦では第3位と健闘したクリタテクノは、愛知県北名古屋市のゲージメーカーだ。同社はゲージ製作のノウハウをコマに生かして参戦。 「私のメンタルの状態が対戦結果に大いに響きましたね。1、2回戦はよかったのですが、3回戦に勝ち上がると緊張のあまり手が滑ってしまい、うまく力が伝わらず、失敗してしまいました……」。緊張してさえいなければ、決勝戦までは進めたのではない
Developer summit continuous deliveryとjenkins
CODT2020 ビジネスプラットフォームを支えるCI/CDパイプライン ～エンタープライズのDevOpsを加速させる運用改善Tips～
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch
一度にひとつの作業をして成果を上げる
Charming Python: Functional programming in Python, Part 3
