「チームワークのデザイン」講義資料
「チームワークのデザイン」講義資料 このサイトではサイボウズ・ラボの西尾泰和と竹迫良範が 京都大学サマーデザインスクール 2013で行った 「チームワークのデザイン」の講義資料を公開しています。 わたしたちは、世界中のあらゆるチームを支援できる企業を目指しています。 成果発表会でのスピーチ みなさん、難しい問題を考えるときにはどのようにやっていますか？書き出してから考えることが大事です。目隠し将棋と普通の将棋はどちらが簡単か、暗算と筆算はどちらが簡単か、考えて見れば明らかです。頭のなかだけで考えようとすると、覚えておくために脳の一部が割かれてしまいます。 わたしたちのチームでは最終的に、なんと750枚もの付箋を消費しました。 その大量の付箋をどうするのか？ボトムアップで組み立てることが大事です。わたしたちは予期しないつながりや構造を見出したいのです。トップダウンで構造を決めつけるのではなく
契約なんかこわくない（３） 契約の論理の根底にあるもの - プロジェクトマネジメント ワンポイント講義
プロジェクト・マネジメント（ＰＭ）、タイム・マネジメント（時間管理術）、プロジェクト・スケジューリング、などの分野で理解すべき用語と概念を解説しています。 プロジェクト・マネジメント プロジェクト制の要件 ソフトブレーン（株） の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは 線路 で、プロジェクトはそこを走る個別の 電車 である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。 しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「 プロジェクト 」という仕組み自体が確立していない。製品開発や受注生産といった個別
情報処理推進機構：ソフトウェア・エンジニアリング ｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開
2013年3月19日公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 インターネット販売サイトやSNS(ソーシャルネットワークサービス)等のシステムでは、その構築において要件のすべてが明確にならなくても開発に着手し、要件の明確化や変更には開発と並行して対応します。それは、いかに早くサービスを提供するかに、ビジネスの命運がかかっているからです。 こうした要件の変化に柔軟に対応できる開発手法として、「アジャイル型開発」があります。これは、ビジネス上の優先度が高い順に、短いサイクルで機能単位の開発を繰り返す手法です。 このアジャイル型開発手法は自社開発（内製）が中心の米国で発展したものであり、要件を決めて外部に開発を委託することが多い等、受発注環境が異なる日本でアジャイル型開発を適用するのは難しいと考えられています(*1)。 「アジャイル型開発」には、
IPA版アジャイルプラクティスのパターン言語集 - プログラマの思索
IPAがアジャイルプラクティスのパターン言語を公開していたのでメモ。 これは凄い。 パターン言語というアイデアは、かなりマニアックな考え方と思っていたのに、世間に認知されてきたのかな？ 調査報告書や「アジャイル型開発におけるプラクティス活用リファレンスガイド」を読んでみて、気づいた点を抜粋して書き出してみる。 【元ネタ】 情報処理推進機構：｢アジャイル型開発におけるプラクティス活用事例調査｣の報告書とリファレンスガイドを公開 情報処理推進機構：｢アジャイル型開発プラクティス・リファレンスガイド」を公開～アジャイル型開発の初心者向けに実践ノウハウを事例から分類・整理～ Twitter / IPA_SEC:SECでは、アジャイル型開発で用いられる組織、プロセス、技術等の実践のための指針である「プラクティス」について、先駆的企業を対象に事例調査を行い、リファレンスガイドとしてまとめ、本日3月19
プロジェクトマネージャが抱えるプロジェクト管理の問題 - プログラマの思索
プロジェクトマネージャが抱えるプロジェクト管理の課題について考えことをメモ。 現場リーダーやプロジェクトマネージャの立場になると、単なる開発者の役割だけでなく、チーム全体を鳥瞰する役割も担う。 更に重要な役割が、自分一人の責任だけでなく、チーム全体の責任、更には売上やコストの責任まで背負うようになることだ。 数年前に、別の会社の部長さんから、プロジェクトマネージャに必要なスキルは何か？と質問を受けた時がある。 その時の僕は、進捗管理とチームビルディングが大切です、と答えて笑われた。 その部長さんからは、進捗管理は全体の3割、チームビルディングは1割に過ぎない、リスク管理やコスト管理がそれぞれ3割は必要だ、と言われた時があった。 プロジェクトリーダーやマネージャに問われる能力は何か？: プログラマの思索 今になってその言葉がようやく腑に落ちる。 それらを一つずつまとめてみる。 【1】チームビ
Jonathan Rasmusson さんインタビュー ( 後編 )
前編を公開してから9ケ月も経過してしまいましたが、ようやく「アジャイルサムライ」の著者であるRasmusson さんインタビューの後編の原稿をまとめることができました。 インタビュー後編では、以下について伺った内容を紹介します。 1. 「アジャイルサムライ」の内容について 2. モチベーションとコーチング 3. 日常生活 4. 「アジャイルサムライ」の執筆 5. 今後の夢 1. 「アジャイルサムライ」の内容について -- 次の質問は、Jonathanさんの著書である「アジャイルサムライ」についてのものです。私は「アジャイルサムライ」を読んで少し混乱しました。 アジャイル開発フレームワーク「スクラム」ではプロダクトオーナーとスクラムマスターという2つの役割を設定しますが、「アジャイルサムライ」ではアジャイルコーチ、プロジェクト管理者、顧客が登場します。 なぜスクラムと異なる役割を推奨されてい
トヨタ生産方式 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "トヨタ生産方式" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2013年8月） トヨタ生産方式（トヨタせいさんほうしき、Toyota Production System、略称TPS）は、トヨタ自動車の生み出した、工場における生産活動の運用方式の一つ。多くの企業がこれにならった方式を取り入れており、工場等の製造現場やそれに付随するスタッフ部門だけでなく、間接部門でも取り入れている企業も見られる。 河合満によると、TPSが普及する以前も「必要の時に必要なだけ作る」という考えが現場に浸透していたという[1]。 基本概念[編集] トヨタ生産方式
リーン生産方式 - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "リーン生産方式" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2012年7月） リーン生産方式（リーンせいさんほうしき、lean manufacturing、lean product system、略称LPS）とは、1980年代にアメリカのマサチューセッツ工科大学（MIT）の研究者らが日本の自動車産業における生産方式（主にトヨタ生産方式）を研究し、その成果を再体系化・一般化したものであり、生産管理手法の哲学。 概要[編集] リーン生産方式はトヨタ生産方式を研究して編み出された方式であり、MITのジェームズ・P・ウォマック（英語版）、ダニ
アジャイルソフトウェア開発 - Wikipedia
ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。 概要[編集] ペアプログラミング アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（アジャイルソフトウェア開発宣言）。すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。
ソフトウェア開発工程 - Wikipedia
ソフトウェア開発工程（ソフトウェアかいはつこうてい、英: Software Development Process）はソフトウェアライフサイクルプロセスのうち、開発に関わるプロセスである。すなわち、ソフトウェアの構想から廃止までの流れのうち、開発部分をプロセスとして捉えたものである。ソフトウェア開発プロセスとも。 開発工程はいくつかのサブプロセスからなる。サブプロセスの種類と関係性を示す開発プロセスモデルが複数存在する。また開発工程とその中の各種タスク・活動のための方法論が提案されている。 サブプロセスモデル[編集] 開発プロセスは何種類のもサブプロセスからなる。開発サブプロセスのモデルには様々な種類がある。規格としてISO 12207、能力成熟度モデル統合（CMMI）が挙げられる。以下は代表的なサブプロセス（モデル）である。 ソフトウェア要求分析 ソフトウェア製品を作るにあたっての最初の
新機能および新端末追加のお知らせ | Remote TestKit
2013/11/28 新機能および新端末追加のお知らせ 2013年11月28日（木）実施のシステムメンテナンスが終了いたしましたのでご報告いたします。 尚、メンテナンス完了に伴い新規機種・機能を追加いたしました。 下記のとおり 1. Android 4.4に対応 Remote TestKitがAndroid 4.4（KitKat）に対応しました。 あわせてレンタルできる端末にNexus 5を追加いたしました。 ２．新規機能追加 自動キャプチャ ファーストビュー機能 「複数端末同時操作」による画像保存時にページ全画面のキャプチャに加え、端末ディスプレイに最初に表示される画面を同時に保存する機能を追加いたしました。 本機能によりレンタルした端末でWebページの確認をする際に1画面に表示される範囲がひと目で確認できるようになりました。 ３．レンタル端末の新規追加 最新端末の追加 ご要望にお答えし
＠IT：特集 「テスト駆動開発」はプログラマのストレスを軽減するか？
新しいソフトウェア開発技法へチャレンジできるか？ ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
ビヘイビア駆動開発 - Wikipedia
ビヘイビア駆動開発（ビヘイビアくどうかいはつ、振舞駆動開発; behavior driven development; BDD）とは、プログラム開発手法の一種で、テスト駆動開発から派生した物である[1][2] 。 概要[編集] テスト駆動開発で記述されるテストケースは、作成したプログラムの動作が正しいかどうかを検証するために行う「テスト」である。テストであるという点は同一であるが、加えて、これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する。テストフレームワークのメソッド名も自然言語（英語など）に近い形をとっている。 テストコードの可読性があがる上、テストコードが要求仕様となりうる。要求仕様からテストコードを起こす際も、スムーズにコードに移行しやすい。 BDDではスペック（仕様）とテストは限りな
バグ管理システム - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "バグ管理システム" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2021年6月） バグ管理システム（バグかんりシステム）、バグトラッキングシステム[1]とはプロジェクトのバグを登録し、修正状況を追跡するシステム。バグ管理システムの多くは、ウェブサーバ上で動作し、ウェブブラウザ経由でアクセスできるようになっている。 背景[編集] 近年、ソフトウェアの開発においてはバグの修正が重要な作業と考えられている。バグを漏らさず修正し、再発を防ぐには、バグの発見日時や発見者、再現方法、修正担当者、修正履歴、修正方法、重要度、テスト状況などの多くの情報
チケット駆動開発 - Wikipedia
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。 はじまり[編集] チケット駆動開発が提案された2007年ころはソフトウェア開発環境が充実し、Subversion、trac、ウィキを活用したプロジェクト運営が注目されていた[3]。そのような中で、たくさんの細かな修正を効率よく行う方法として「チケット駆動開発」が現場から生まれた。 チケット駆動開発は、まちゅ氏のITpro Challenge のライトニングトーク「もう
テスト自動化 - Wikipedia
テスト自動化（テストじどうか）とは、テスト支援ツール等を使うことにより、ソフトウェアテストを自動化することである。 ソフトウェアテストを行うためには、以下のような作業をする必要がある。テスト自動化とは、これらの作業の一部を自動化することである。 テストケースの設計 テストの実行と結果の確認 テスト進捗の管理 レポートの作成 テストケースの設計[編集] テストケースとは、テストを行う際に、プログラムにどのような入力を与え、 その結果としてどのような出力が得られるべきかを記述したものである。 テストケースの作成には プログラムの構造に着目した手法や プログラムの仕様に着目した手法がある。 テストケース[1]はプログラムがどのように動作すべきかを理解していないと作れないため、基本的に人の手によって行われる。 JTest等のように、プログラムの構造に基づいて自動的にテストケースを作成するツールも存
ユニットテスト・フレームワーク一覧 - Wikipedia
以下は様々なプログラミング言語のためのコード駆動型のユニット・テスト・フレームワークの一覧である。全てではないが、これらの幾つかはxUnitに基づいている。 表の各列の説明 (分類)[編集] 名前: この列はフレームワークの名前及び、Wikipedia内にその項目があればそれへのリンクを含む。 xUnit: この列はフレームワークがxUnit型のフレームワークであるかどうかを示す。 TAP: この列はフレームワークがTAP準拠のテスト・ハーネスを出力できるかどうかを示す。 ジェネレータ: この列はフレームワークがデータ・ジェネレータをサポートするかどうかを示す。データ・ジェネレータはあるテストの入力データを自動的に生成し、生成した各データについてそのテストを実行する。 フィクスチャ: この列はフレームワークがテスト毎のフィクスチャをサポートするかどうかを示す。テスト毎のフィクスチャは個々の
テスト駆動開発 - Wikipedia
テスト駆動開発 (てすとくどうかいはつ、英: test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行なった後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年[いつ?]はビヘイビア駆動開発へと発展を遂げている。 開発サイクル[編集] 最も基本となる開発サイクルは以下のようになる。 失敗するテストを書く できる限り早く、テストに通るような最小限のコードを書く コードの重複を除去する（リファクタリング） なお、テストの実行環境ツールであるxUnitでは、テストの失敗を赤いバー、成功を緑のバーで通知するため
)
ビルド (ソフトウェア) - Wikipedia
ソフトウェアのビルド（英: build）は、プログラミング言語で書かれたソースコードファイルや各種リソースファイル[要曖昧さ回避]を独立したソフトウェア生成物に変換するコンピュータ上で実行されるプロセス、またはその結果を指す。ビルドの最終生成物はバイナリ形式の実行ファイルであったり、再利用可能なライブラリであったり、バイトコードあるいはそれらをまとめたアーカイブであったりすることもある[1]。 概要[編集] ビルドにはいくつかのステップがあり、その内容はプログラミング言語やビルドツール、開発環境や実行環境（ターゲットアーキテクチャ、オペレーティングシステムあるいは仮想マシン）によっても異なる。例えばC言語あるいはC++の場合、ソースファイル（ソースコード）をコンパイラによってオブジェクトファイル（オブジェクトコード）に翻訳（コンパイル）した後、リンカによってオブジェクトコードを結合し、実行
ソフトウェアインスペクション - Wikipedia
ソフトウェアインスペクション（英: Software inspection）とは、ソフトウェア開発プロジェクトで作成された成果物（仕様書やプログラムなど）を、実際に動作させることなく人間の目で見て検証する作業を言う。 通常のテストでは見つけられない欠陥、具体的にはコーディングルールに対する違反や極めて限定された条件でしか発生しない誤動作に繋がる問題点が検出されることがあり、プログラムを動作させて行うテストと補完関係にあるとされる。一般的に、プログラムを動作させて行うテストを動的テスト、インスペクションやウォークスルーなどのようにプログラムの動作を伴わないテストを静的テストと呼ぶ。 静的テストにはインスペクションの他に、ウォークスルーやピアレビューと呼ばれる技法がある。他の技法とインスペクションの違いは以下の通り。 責任者としてモデレーターが任命され、インスペクション作業全体を統括する 検出
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
