「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016
「本番環境などという場所はない」マイクロソフトがSaaSの失敗と成功から学んだ、アジャイルからDevOpsへの進化（前編）。Regional SCRUM GATHERING Tokyo 2016 アジャイル開発手法の1つであるスクラムをテーマにしたイベント「Regional SCRUM GATHERING Tokyo 2016」が1月19日と20日の2日間、都内で開催されました。 そこでマイクロソフトが行ったセッション「マイクロソフトが実践したScrum導入7年間の旅。そしてDevOpsへの進化」は、アジャイル開発からクラウドサービスの提供へと進んだマイクロソフトが、サービス開発の過程で学んださまざまな知見を共有するものとなりました。 そこには、アジャイル開発の延長線上にあるDevOpsを成功させる組織と技術、そしてマインドのあり方が紹介されていました。セッションの内容をダイジェストで紹介
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム（ITS：Issue Tracking System）で運用する開発プロセスは、チケット駆動開発（TiDD：Ticket Driven Development）と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1．Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
先日、2013/3/23（土）に弊社でチケット駆動と開発環境に関するイベントを開催しました。リンク先には資料も上がっていますので参照ください（※アトラシアン製品関連のイベントです）。 基調講演にはチケット駆動開発を推進されている関西XPUGのあきぴーさんをお招きして「チケット駆動開発をパターン言語で読み解く」という話をしていただき、最終枠ではパネルディスカッションをしました。 チケット駆動開発とウォーターフォール パネルディスカッションでは、僕が「チケット駆動開発を作業計画に使うのは難しく、WBSとの併用が現実的」と話し、あきぴーさんが「作業計画をチケット駆動開発で回していくには」というノウハウを紹介されていました。 この違いは僕がウォーターフォール的な新規案件を、あきぴーさんがアジャイル的な開発/保守運用案件を前提にしているためです。 僕自身はBTS（Bug Tracking Syste
2001年、17人のメンバーによって アジャイル宣言 が発表されました。私はその立案者そして著者の1人であることに誇りを感じます。この出来事は、何かをする上でより良い方法を導き出すことへの期待、そしてソフトウェアを開発することで世界をより良くするといった、私自身の活力の源となり、極めて重要なターニング・ポイントとなりました。 あれから14年が経ち、私たちは行き先を見失っています。”アジャイル”という言葉はスローガン化してしまいました。本来の意味をなさなくなっただけならまだいいですが、最悪に考えれば排外的な存在になってしまったとすら言えます。2～3のソフトウェア開発のプラクティスを、不十分に生半可に試みるといった”軟弱なアジャイル”を行う人が数多く存在します。本来の目的を忘れて努力を重ねるといった、口先だけのアジャイルの 狂信者 がたくさんいるのです。 更にひどいのは、アジャイル開発手法その
tl;ldr ウォーターフォールという言葉を悪口として使うのは良くないんじゃない？ 空想上の開発手法ウォーターフォールと進化したウォーターフォール アジャイル開発の説明がされるとき、アンチパターンとして「ウォーターフォール」が使われることがあります。これは「ダメな開発現場」と同義で使われており、共通仮想敵としての空想上の開発手法とも言えます。 それは、曰く、硬直化していて変化や手戻りを許さず、一本道でフィードバックサイクルがない、数十年アップデートされていない古臭い手法のことらしい。 もちろんそういう開発をしている現場もまだ数多く存在するでしょう。ただ、ウォーターフォールをカイゼンし進化させている人達もいます。そういう人たちの話を聞くと、例えば以下のような話を聞きます。 一ヶ月で１ウォーターフォールを回す 前の手順に戻る手続きが定められている 初期フェーズから開発者を巻き込む 定期的なレビ
ブルシットプロダクトからチームを守れ! ｢顧客が本当に必要だったもの｣を追求するプロダクトマネジメントを実現するぞ
ユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。 ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。 Regional Scrum Gathering Tokyo 2022 概要 https://confengine.com/conferences/regional-scrum-gathering-tokyo-2022/proposal/16109 発表者 https://twitter.com/_N_A_ https://note.com/mryy/n/n6f01561a6253
倉貫さんの資料プロエンジニアになるための「アジャイル開発」再入門が素晴らしいのでリンクしておく。 新入社員向けのアジャイル研修の資料は、これを使えば十分ではないかな、と思った。 以下はラフなメモ書き。 【研修資料】 【参考】 アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索 アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change! ソフトウェアは完成しても価値はない ? アジャイル開発は何を解決するのか | Social Change! アジャイル開発とは：「アジャイル開発」をエグゼクティブサマリにまとめてみた | Social Change! ドキュメントをなくしてもうまくいく？ ? 人に依存するリスクへの対処とは
自律的に現場を改善できるチームをつくるための「ふりかえり」の進め方 〜 KPTと進め方のノウハウ | Social Change!
現場のオペレーションを改善するために、最初に着手するなら何か？と聞かれたら、いつも「ふりかえり」から始めましょう、と答えています。かつてトラブルの起きているプロジェクトに入ったときも、まず始めたのは「ふりかえり」からでした。 「ふりかえり」とは、文字通り現場の活動を振り返って、改善のアクションを考えることです。反省会のようにも思えますが、すべてが終わってから反省する訳ではなく、現状分析を行って、うまく続けていくための未来を向いた活動です。 この記事では「ふりかえり」という習慣について、そして、ふりかえりを実践するにあたって、進め方とポイントについて紹介します。 ふりかえりの進め方”KPT”とは 上の写真は、私たちソニックガーデンで「ふりかえり」をしている様子です。ソニックガーデンでは弟子を採用していて、その弟子と師匠とのふりかえり風景です。このように、特別な道具はなにも必要ありません。必要
SUUMOアプリチームがスプリントを廃止してカンバン方式に移行した話 | リクルートテクノロジーズ メンバーズブログ
このエントリは全9回を予定する18卒新人ブログリレーの第4回です！ 今回は、SUUMOのモバイルアプリ開発の現場から、企画と開発が一体となったチームでの開発プロセスについてご紹介します！ はじめに はじめまして。リクルートテクノロジーズ新人の三田涼介です。現在は不動産検索サービスSUUMOのAndroidエンジニアとして働いています。 今回はSUUMOアプリチームの開発プロセスについて紹介します。 SUUMOは巨大なサービスでありながら日々高速に改善を行っており、週1回以上の頻度でiOS、Androidの各OSでリリースを行っています。このスピード感を実現するために、開発プロセス自体も日々磨き込みが行われており、私が配属された3ヶ月前にも開発プロセスに大きな変化がありました。 この記事では、私が新人としてキャッチアップしていく中で学んだ、 なぜ開発プロセスを選ぶことが必要なのか どうやって
DevLOVE200 Bridge の登壇資料です。 https://devlove.doorkeeper.jp/events/60269 デブサミの以下の資料の焼き直しです。 https://www.slideshare.net/i2key/devsumib
ゲーム開発 プロジェクトマネジメント講座
ゲーム開発 プロジェクトマネジメント講座 ２０１１年１０月８日 株式会社スクウェア・エニックス CTO 橋本 善久 1©SQUARE-ENIX 2011 SQUARE ENIX OPEN CONFERENCE なぜプロジェクトは 失敗するのか？ 2©SQUARE-ENIX 2011 プロジェクトの失敗ポイント • 見込みより売上が少ない • 計画よりもコストがかかっている • 発売時期が遅れた • 発売に間に合わせるため内容が削られた • ユーザーの評判が悪い • 不具合が発生 • スタッフの満足度が低い、故障者が出た、辞め てしまった • など・・・ 3©SQUARE-ENIX 2011 プロジェクトの失敗ポイントの分類 • スコープ（コンテンツの範囲）の問題 • 品質の問題 • コストの問題 • 時間の問題 • リソース（人員・環境）の問題 • ビジネスの問題 4©SQUARE-EN
これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策(スクラム＆リーンスタートアップ導入)について #devlove #devlove創
★最新版の45分拡大版はこちら http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib 社内スタートアップが成長していく過程で直面した様々な問題についてcameranの事例を元にお話します。また、その問題に対して、スクラムやリーンスタートアップを用いてどのように解決していったのかについて説明します。 ※スクラムやリーンスタートアップについての基本的な説明は省略Read less
第16回プログラミング言語とTDDは、どちらを先にマスターすべきか？ 和田卓人 2007-12-21
(Image by Pixabay) 最近になって、こんな素晴らしい資料が公開されていたことを知りました。 この資料自体は著者のMoe Uchiikeさんが東大での講義に用いられたものだとのことですが、その内容の汎用性の高さから「これは全ての機械学習や統計学を実務で用いる人々が必ず読むべきドキュメント」と言っても過言ではないと思われます。 正直言ってこの資料の完成度が高過ぎるのでこんなところで僕がああだこうだ論じるまでもないと思うので、内容の詳細については皆さんご自身でまずは上記リンクから精読していただければと思います。その上で、今回の記事では「機械学習や統計学を『社会実装』する」ということがどういうことなのかについて、この資料を下敷きとした上でさらに僕自身の経験や見聞を加えて考察したことを綴ってみます。 機械学習や統計学と、社会との「ギャップ」 機械学習や統計学を、社会に「馴染ませる」
Channel 9
AI is suddenly everywhere. Do you need to go and get a shiny machine learning degree to remain competitive? John Maeda says not to worry. He’ll show you how to cook delicious dishes into your coding repertoire with his new show - Mr. Maeda’s Cozy AI Kitchen. Open at Microsoft is a weekly show for open-source enthusiasts. It features a diverse group of guests including maintainers, software and Dev
質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition
質とスピード（2020秋100分拡大版） 2020/11/20 @ JaSST'20 Kyushu
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
5分で分かる、「スクラム」の基本まとめ
5分で分かる、「スクラム」の基本まとめ：開発チームを改善するためのスクラムTips（8）（1/2 ページ） 「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 これまで、アジャイル時代のチーム・マネジメント手法として主流になっている「スクラム」の手法を紹介してきました。今回は総集編として「スクラムの基本」をコンパクトにまとめます。 そもそもスクラムとは スクラムは、一言でいえば「チームで仕事の進めるための枠組み（フレームワーク）」です。 もともとはソフトウェア開発プロジェクトを成功させる仕組みですが、技術的な要素は取り除かれ、多くのチーム作業に共通して適用できる要素だけが残りました。そのため、ソフトウェア開発以外のチームにも適用できるのが特徴です。 ●バッ
ご存知の通り、はてなのシステムはほぼすべてPerlで書かれています。そもそも僕がはてなに入った一つの理由に、僕が一番得意とする言語であるPerlを使ってシステムを構築していたという点があったりします。 世の中にはたくさんのプログラミング言語があります。Perl、Java、Ruby、PHP、Python、C、C++、lisp、Smalltalk、Cobol...数え上げたらキリがありません。そして、プログラマはかならずと言っていいほど、どれかひとつ以上の言語を愛しています。好き、ではなく愛しているのです。 自分が愛しているものを批判されると感情的になりやすいのは人の常、プログラミング言語の差異に関する議論は炎上しがちで、よく宗教戦争だなんて言われたりもします。その中で、言語なんてどれも一緒だなんていう乱暴なまとめがされることもよくあったりします。 しかし、何年かプログラマというものを経験して
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門：ユカイ、ツーカイ、カイハツ環境！（21）（1/4 ページ） CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI（継続的インテグレーション）ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins（Hudson）は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
MVP（Minimum Viable Product）の意味を理解する。そして、なぜ私はEarliest Testable / Usable / Lovableを好むのか。 | ANKR DESIGN | デザインリサーチ・プロトタイピング・サービスデザイン
数年前、私はこんな絵を書いて、アジャイル開発やリーン開発のついての様々なプレゼンで用いた。 そこから、この絵は急速に広まっていった！記事、プレゼン、さらには本（Jeff Pattonの”User Story Mapping”という素晴らしい読み物なのだが）にまで至る所で姿を見せた。多くの人がこの絵は反復型開発、リーンスタートアップ、MVP(minimum viable product)の本質をよく捉えていると伝えてくれた。しかし、元の文脈から切り離して物事を捉える際にはごく自然なことであるのだが、この絵を誤解している人がいる。簡素化しすぎだと非難する人もいる。（正しい指摘である） この絵はあくまで比喩である。実際の車の開発の話ではなく、車を比喩とした一般的なプロダクトの開発の話なのである。 とにかく、これらのバズからこの考えの背景を話す時だと判断したのだ。 １つ目の例：not like
Agile Studio プロデューサーの木下です。2020年の3月に公開した『リモートアジャイル開発のノウハウ集（第1版）』に続き、このたび第2版を公開しました。こちらからダウンロードいただけます。...
これは、MIT SloanのCusumano先生が本でも授業でもよく言ってる話。 面白いから忘れないうちに書き記しておく。 Cusumano先生は、Microsoft SecretやPlatform Leadershipで有名なソフトウェアビジネスの研究者。 日本の企業研究も色々されているし、一橋大学のビジネススクールで何年か教えてらしたりした日本通でもある。 そのCusumano先生が、ソフトウェア産業への取り組み方を比較して、こんなことを言っていた。 Europe: Software as a science －ヨーロッパにとってソフトウェアは「科学」 Japan: Software as production －日本のソフトウェアは「製造業」 India: Software as a service －インドのソフトウェア産業は「（プロフェッショナル）サービス」 U.S.: Soft
子どもが生まれたのでそちらに時間をとられて、なかなか技術のキャッチアップが難しいことが増えた。こう書くと、隙間時間を使えばよいではないかと思われるかもしれない。実際うちの子はかなり昼も夜も寝る（寝た）し、お世話がかなり楽な方で隙間時間はある。しかし子育てしている方はわかると思うが、子が寝ている間は親も寝ないと体力が持たない。加えて、子はいつまで機嫌良くいるかわからない。いつ中断されるかそわそわしている状態で、まとまった論考を腰を据えて読む気力などない。というわけで、隙間時間を使っている気力はない。 数ヶ月前に仕事に復帰して以降、どうも最新技術の動向やトレンドを追えなくなっているのが悩みだった。ちなみに、「最新の話題を常日頃から追うべきか」という議論は時折見かけるが、私は今より高い給与得たい、かつ（たとえば組織全体を見るような）難しい仕事をしたいのであれば追い続けるべきという立場だ。というわ
こんにちは！クックパッド編集室メディア開発グループ長の @yoshiori です。 今回はウチのチームの開発の進め方や見積もりの仕方を説明しようと思います。 実はコレ系の話は 5 年前にもデブサミで発表 したのですがこの時はリリースまで 1 年とかのレベルのプロジェクトの進め方の話でした。今回は 1,2 ヶ月でリリースまで持っていく開発の進め方を説明します。 動画サービス部分を microservices 化するときに実際に行った事を元に説明します。開発者は 3 人で 1.5 ヶ月位の開発です。 何故このようなことを行うのか 誰だって楽しく仕事がしたいし、なるべく不安などは無い方が良いはずです。 例えば自分がやっている作業がどうなったら終わりなのかわかっていなければ不安でしょうし、いつまでに作ればいいのかわかっていなければ不安でしょう。 そういった不安をなるべく無くすためにうちのチームでは
サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 前回からの続きです。 以下、３部作の３本目となります。 ウォーターフォール開発とアジャイルの本質 - プロマネブログ サルでも分かるアジャイルとウォーターフォールをハイブリッドしたマネジメント・デザインパターン - プロマネブログ 炎上プロジェクトの責任はプロマネが９割 - プロマネブログ 追記)ブコメで誤字の指摘がありましたので、訂正します。。。お恥ずかしい NetPenguinさん、ご指摘ありがとうございます 改めて考えたいプロマネの仕事 プロマネの仕事とは、PMBOKのプロジェクト管理に関する観点をマネジメントする、と言えます。 統合 ・・・ チーム内の意思統一 スコープ ・・・ 目標、成果決定 タイム ・・・ 期限、スケジュール管理 コスト ・・・ 予算、費用管
社内でLTしたネタ。去年からサポートしているチーム作りのお話。 1週間スプリント 最初は短いサイクルで試行錯誤したいから1週間スプリントでやることにした。 スプリントの終了と開始 金曜日にスプリントレビューとレトロスペクティブとプランニング。 プランニングは2部制にして 第1部では次のスプリントでやりたいことの認識合わせを全員で 第2部では細かいタスクの話をエンジニア中心で やってる。 ストーリーポイントと理想時間を併用してみてる これはだいぶあとの方の話。 最初の頃はチケットのサイズを見積もるのにストーリーポイントだけを使ってたんだけど、半年くらいした頃にストーリーポイントに加えて理想時間の見積もりも併用することにした。 最初の頃に理想時間を導入しちゃうと、頭では分かってても「時間」に引っ張られてしまうので、ポイントだけで始めることにした。で、半年くらいしたころには新しいやり方にも慣れて
技術的負債の生態 - maru source
@t_wadaさんが翻訳されていた技術的負債の記事をあらためて読んでみたら非常に面白かった。技術的負債の本来の意味が説明されているので、まだ読んだことがない人は一読をおすすめする。 その翻訳記事を読みながら、Jasper（僕が開発しているGitHub用のIssueリーダー）のv1.0で技術的負債を返済したことを思い出した。そこで、その翻訳記事を参考にして技術的負債の生態について自分なりに考えてみることにした。すると面白い生態がいくつか見えてきた。例えば「生態③: むしろ技術的負債が生まれることそれ自体はポジティブである」などである。今日はそのことについて書いてみようと思う。 ちなみに今回は技術的負債への対処までは解明することができなかった。いつか続きを書けたらいいなと思う。 技術的負債が生まれる背景 まずはJasperで経験した技術的負債を紹介する。負債の内容自体はそんなに重要ではないので
デザイン思考 ファシリテーション・ガイドブック｜イトーキ
2012年11月にイノベーションを生み出す場のつくり方、スタンフォード大学d.schoolの研究・実践書「make space」を出版したが、場とともにイノベーションの生み出し方のメソッドを知り、実践したいとの要望が多く寄せられ、同じくスタンフォード大学 d.schoolのイノベーション教育の中核である「デザイン思考」を実践するガイドを株式会社イトーキ オフィス総合研究所と一般社団法人デザイン思考研究所にて作成しました。 目次 はじめに デザイン思考の概要 第１章 理解 ステップ1：チームビルディング ステップ2：課題設定 ステップ3：知識の把握 ステップ4：観察対象の設定 第２章 共感 ステップ１：観察 ステップ２：インタビュー 第３章 問題定義 ステップ１：情報整理 ステップ２：ストーリー抽出 ステップ3：問題定義 第４章 創造 ステップ１：テーマ設定 ステップ２：アイデア創造 ステッ
全てのRubyエンジニアはだいたい糞である
汎用系のエンジニアからRubyのエンジニアとして転職して1年。 コボラー（笑）なんて言われることも多いが、この1年で出会ったRubyエンジニアは全て糞だった。 その特徴はだいたいこの3つだ。 1.テストを甘く見ているやれテスト自動化だ、やれテスト駆動開発だの口だけ達者なエンジニアの多いこと。 そもそもブラックボックステスト、ホワイトボックステストを分かっていない奴が多すぎ。 テストコードでカバレージが100%だったとしても実際の打鍵結果でエラーは弾けることが多いのにリリースしてしまう。 そもそもテストケース表を若いうちに書く習慣が無いからだ。 ドキュメントを揶揄し机上デバッグも行わない、こんな状態で「アジャイルですから」とかドヤ顔でいってしまうRubyエンジニアは糞である。 2.パフォーマンスを考えないRubyエンジニアはパフォーマンスを考えない。 どのメソッドがどれくらいの負荷なのか意識
昔から、さまざまなコミュニティをつくってきた。ただ、どれも長続きはしなかった。結局、今も残っているのは一つだけ。最初は集まってきたみんなもこれから始まることに期待でいっぱい。すごい盛り上がりを見せる。ところが、たいていの場合わずか2回目の集まりを経たところで、もう衰退期に入っていく。3回目には集まる人数が激減する。ここまで2-3ヶ月程度のことだ。コミュニティは2回集まると死ぬ。 長らく、その理由が分からないでいた。どういう工夫をとっても、たいてい死んでしまう。どういう集まりだったとしても。顔ぶれが違っていても。同じ道を辿る。まるで私だけタイムリープを繰り返しているかのように。2回目で死を迎えることになれてしまっているし、特に驚きもしない。ただ無力さだけはいつも感じていた。 ある時、一つの仮説に思い当たった。ヒントはリモートワークだった。仕事として、リモートワークを基本とする日常を送り、組織
TODO.md Kanban Board - Visual Studio Marketplace
Todo Kanban Board Todo Kanban Board manages tasks and save them as TODO.md - a simple plain text file. Features The syntax is compatible with Github Markdown TODO.md file is portable and can be committed with Pull Requests (PRs) to git repositories. Support custom file name, multiple task lists. Checkboxes are optional (if your task titles don't have them). Task title can also have markdown for st
2014/02/12の楽天Tech Talkに登壇させてもらったときの発表スライドです。 2013年に発表したいくつかの内容をまとめました。 基本的に、ソフトウェアテストの絶望を聞きたい人向けです。Read less
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
昨年秋頃から年明けにかけてRailsで顧客のサービスをひとつ作った 久々のチーム開発で。チーム人数は3名。 せっかくなので使ったツールややり方などを備忘録的に残しておく。次いつまたチーム開発する機会があるのか知らんけど。 実践したこと プルリクベースの開発 Webサービス開発現場から / 近頃の開発のやり方 ･･･ Github と Pull Request とコードレビュー 上記のやり方が面白そうだったので試してみた。 Githubを使っていれば拍子抜けするほど簡単に流れに乗ることができた。 Git力が足りないので最初は少し大変だったが、馴れてくると細かくブランチを切ってフィーチャーごとに対応するということが開発のテンポを良くしてくれた。 コードレビューはイージーミスによるバグや既存のコードと大きく流れの違うコードが混ざるのを未然に食い止める事ができたりと、一定の成果はあった。 一方でい
最近、IT業界における「心理的安全性」の重要さは広く知られるものとなってきました。 一方で、心理的安全性が誤解・誤用されるケースも見聞きすることもあります。 よくあるパターンは、「心理的安全性」とは「居心地の良さ」である、という認識でしょうか。なんとなく似た意味にも感じますが、実際はまったく別物です。 しかし上記の違いを説明するのはちょっと大変なため、『心理的安全性 最強の教科書』を頼りながら要点を押さえてみようと思います。 心理的安全性は「ゴール」ではない まず心理的安全性とはなぜ必要なのでしょうか。本書は次のように説明しています。 もうひとつ、ありがちな誤解があります。それは職場の心理的安全性を高めることを「ゴール」だと考えてしまうことです。もちろんマネジャーにとって、職場やチームの心理的安全性を高めることは大事ですが、心理的安全性はあくまで組織の生産性を高めるための手段のひとつであり
SIビジネスの本質は保険屋であり、受託開発でアジャイル開発が失敗するのは受託開発が製造業だから。11月19日に行われた楽天テクノロジーカンファレンスでの講演「プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン」では、ソニックガーデン代表取締役社 倉貫義人氏によるこのような示唆に富む内容が語られました。 さらに倉貫氏は、ソニックガーデンで行っているクラウド時代の受託開発の新しいモデルについても詳しく紹介しています。 同氏の講演の内容を、配信されたUstreamの動画を基にして紹介しましょう。 プログラマを一生に仕事にできるビジネスモデルで目指す未来のビジョン ソニックガーデン代表取締役社長 倉貫義人氏。 倉貫です。今回のオファーをいただいたときに「技術者の人が元気になるような話をしてほしい」というのがあって、私自身がずっとエンジニア、プログラマやマネージャ、営業などいろいろや
「やってみないとわからない」という思考停止
「やってみないとわからない」だから、試すんだ。そのことは間違いじゃない。確かにその通り。 立派な計画を立てても実行しなければ、1ミリも社会に影響を与えない。 頭でっかちにならずトライアンドエラーで、逐次修正しながら進めよう。 アジャイルにやっていきましょう。少しずつ小さく試していけば大丈夫。 そう、世の中には、やってみないとわからないことばかりだ。正解が決まっていないことの方が多い。 だから、やってみる、行動してみるということに価値はある。 ・・・だけど、それ、本当にやってみないとわからないことなのか？と考えたか。「やってみないとわからない」といって、考えてみることも放棄してないか。 考え尽くしたあとに、やってみないとわからないことを試さないと、やってみたことが良かったかどうかもわからない。 やってみることに仮説があるかどうか。 なぜやるのか。仮説をもって取り組めば、仮説が正しかったか、間
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
脱Excel！ Redmineでアジャイル開発を楽々管理
チケット駆動開発で作業管理はしないほうがいい - arclamp
アジャイルの破綻―原因、そして新たな提案 | POSTD
高度に発達したウォーターフォールはアジャイルと見分けがつかない - An Epicurean
「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい - プログラマの思索
大企業アジャイルの勘所 #devlovex #devlovexd
意識も理想も高いけど実現には至れない人｜FromAtom
［動画で解説］和田卓人の“テスト駆動開発”講座 記事一覧 | gihyo.jp
機械学習や統計学を「社会実装」するということ - 渋谷駅前で働くデータサイエンティストのブログ
今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
僕やはてながPerlを選ぶ理由 - naoyaのはてなダイアリー
「Hudson」改め「Jenkins」で始めるCI（継続的インテグレーション）入門
詳説！Redmineを使ったスマートな開発プロセス改善（画面キャプチャ付き）
リモートアジャイル開発のノウハウ集 第2版を公開しました | Agile Studio
日本のソフトウェア産業は「製造業」 - My Life After MIT Sloan
毎日始業直後25分の技術キャッチアップがよくワークしている話｜helloyuki
チーム開発の進め方 - クックパッド開発者ブログ
炎上プロジェクトの責任はプロマネが９割 - プロマネブログ
アジャイルな開発とチームづくり - Mitsuyuki.Shiiba
コミュニティは2回集まると死ぬ。｜papanda｜note
自動テストの誤解とアンチパターン in 楽天 Tech Talk
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
久々にチーム開発したのでメモ - ひげろぐ
「心理的安全性」と「居心地の良さ」のちがい - Qiita
プログラマを一生の仕事にできるビジネスモデルで目指す未来のビジョン（SIビジネスの本質編）