去年ぐらいから、学習を日常の開発に取り込むことについて考えている。学習は何か特別なことがあるときにだけ実行するものではなく、開発チームの中に常にあるべきものだという気がしているから。だけど、それを周りの色んな考えを持った人たちに伝えられるほどには整理できていない。ので考えている。 そんなときにRSGT2019に参加したのだけど、今落ち着いて思い返してみればChrisの基調講演がまさにそれだった。ので彼の「Learning to Experiment」を思い出しつつ、この辺を参考にしたりしながら自分の中で整理をすることにした。 www.agilealliance.org ## 変化のための実験 変化してなくてもしばらくはうまくいってるように見えるけど、気づいたときにはもう手遅れ。世界は変わり続けてるし、競合は変化に適応し続けてるから。 でも、緊急事態に陥ったときには、これまでのやり方を変えて

TL; DR 「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない． 「HRT」は人に向けるものであり，ソフトウェアに向けるものではない． プログラマの三大美徳 プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる． 詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ． 「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワー

The presentation slides at Forkwell Meetup #5

概要 Nulab様が主催する Geeks Who Drink in Tokyo - Agile Team という勉強会に参加しました。 なるべく具体的なケーススタディ（特に失敗談）を共有したかったので「スクラム開発チームの立ち上げでアンチパターンを踏みまくった話」という発表をしました。 イベントの様子 イベント風景や発表内容は、以下のブログでレポートされています。 モブプログラミング？アジャイル？自分たちに最適な開発手法を本気で考えてみた「Geeks Who Drink Agile Team Edition」をレポート！ | ヌーラボ 会場の合いの手スキルがやたら高くて面白かったです。 発表資料 当日のスライドは以下になります。 PEXELSにラグビーの画像がなく、アメフトでごまかしたことについては、深く反省しております。 内容 かいつまんで説明します。 詳しくはスライドを見てもらえると嬉

サイボウズ kintoneチームの「改善」大公開！ 新人も巻き込んだスクラム導入の成果とは？ 連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのか、伺いました。 若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。 取材に応じてくれたのは、若手プログラマの前田浩邦（まえた・ひろくに）さんと、メンター役だった天野祐介（あまの・ゆうすけ）さん。2人が属するkintone

作りすぎない技術 - API時代の開発努力の在り方について考える / Thinking about the state of development efforts in the API era

2017 - 01 - 30 GoogleにおけるRelease Engineeringとは Google SRE Operation Release Engineering SRE(Site Reliability Engineering)が叫ばれて久しいですが、 Google がこの度 Site Reliability Engineeringに関する書籍 をWeb上で無料で公開したので早速かいつまんで読んでみた。きっとそのうち日本語化されて オライリー のebook上に並ぶのでしょう。 とりあえず Release Engineeringの章 に目を惹かれて興味深かったので斜め読みしてみた。 リリースエンジニアの役割とは Google では リリースエンジニア の役割について以下のように定義している。 Google にはコードの変更を本番環境に反映する時間やビルドを構成するファイルの中で

この記事はProduct Manager Advent Calendar 2016の21日目の記事です。 SkyWayのプロダクトマネージャーをしている@mizuman_です。 ※この発言は個人の見解であr(ry ふとアドベントカレンダーを覗いたら、明日（というか今日）の枠が空いていたので先日行ったチームビルディング合宿について書いてみます。 1行にまとめると、「心理的安全性を高めて、議論が活発になるチームビルディング」です。 新しいチームをこれから作ろうとしている方 リモートワーク中心のチームの方 チーム内で意見を出す人（声の大きい人）に偏りが出てきたと感じる方 KAIZENのネタが小さなものばかりになってきたと感じる方 の参考になれば嬉しいです。 前編は無駄に長いポエムです。 何をして、どんな結果だったのかを知りたい方は後編へどうぞ。 この後、プロダクトマネージャーって毎回書くのが面倒

こんにちは。kintone開発チームの天野(@ama_ch)です。3ヶ月ほど前からスクラムマスターを始めました。 10/18(金)に@ryuzeeさんにサイボウズ東京オフィスにお越しいただき、kintone開発チームのメンバーでスクラムトレーニングを受講しました。 きっかけ 私が開発しているkintoneはクラウドサービスですが、サイボウズはパッケージ製品の開発でスタートした歴史があり、開発プロセスにもパッケージ時代の習慣が強く残っていました。 長大な要件リスト 実装と試験工程の分断 開発後期での手戻り etc... もちろんこれまで手をこまねいていた訳ではなく、開発チーム内では次のような活動に取り組んできました。 タイムボックス(イテレーション)を区切った開発 テスト自動化の推進 ビルドパイプラインの構築 開発者環境への継続的デリバリー ふりかえり KAIZEN DAY, KAIZEN合

現場を改善するというのは難しい。そして徒労である。 こちらの記事を読んで、当時のことを幾ばくか思い出すきっかけになった。 業務改善を現場に求める狂気 私も実際に現場の改善に取り組んだことがある。ただ、その中には失敗だけでなく成功もある。というか、多くの失敗から成功させるために何が必要なのかを得たという感じで、成功したものは後半に行ったものになる。成功といえるものの中で大きめなものは、以下の二つになる。 Gitによるバージョン管理と、タスク管理ツールの導入(当時書いたもの) 開発にJavaScriptフレームワークを導入(当時の検証結果をまとめた記事) 私が身につけた手法が、改善を目指す誰かがくじけないために有用なこともあるかもしれないので、ここで得られた知見を紹介しておこうかと思います。つまりこれは、ポエムです。 前提: 改善できないのは特別なことではない 何かを改善したいと行動してみる。

日々優先タスクをこなすことに追われ、分析や改善が後回しになってしまうことはありがちです。 RedmineではチケットをCSVでダウンロードできるのでExcelワークで分析することはできますが、 Excelでの分析は時間がかかるためKPIとして常に監視するのは難しいです。 チームやプロジェクトの状態を把握し改善箇所を見つけるためにも定量的なデータの分析とKPIの監視が大切です。 最近、Re:dashを使ってRedmineのチケット分析を行ったのでその事例を紹介したいと思います。 これはre:dash Advent Calendar 2016の8日目の記事です。 本記事ではRedmineとRe:dashの連携方法を説明し、 Redmineのチケット分析に必要になるテーブル構成やSQLクエリのサンプルを紹介したいと思います。 こんな感じのダッシュボードが簡単に作れました。 RedmineとRe:

はじめに 十名～数十名ぐらいのプロジェクトで開発することの多いドリコムだが， プロジェクトの中に「プロジェクトリード職」という役割を置いている。 プロジェクトの実現性と健全性を担保するのが仕事だ。 ディレクター，プロダクトデザイン，プランナー，アート，エンジニアリーダーという風に 職種別のリード職を設けていて，エンジニアリーダーの場合はアーキテクチャや安定稼働， (技術的な) ユーザビリティ等への専門性を持って責任を負うのと，エンジニアチームの チーム作りもミッションに加えている。 最近は開発ライン数が増えてきたこともあり，新卒 2，3 年目のリード職が増えてきた。 リード職になった人に「一メンバーだった頃と何が違う？」と聞くと， よく「視野が広くなった」と返ってくる。 視野が広くなるとは具体的にどういうことなのか，掘り下げてみようと思う。 主に 2 年目エンジニア向けのエントリです。 仕

2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。 エンタープライズアジャイルとは 「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。 弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。 顧客は日本企業で社歴が数十年以上 システムはいわゆるSoE領域（間接的にでも売上に寄与する） 10人ぐらいのチームが継続的に維持される規模 こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。 フィードバックサイクル 企業システムではリリースサイクルを「3

フォーカスするためには、たぶんどうやってフォーカスするか（前回）に加えて、何にフォーカスするかを決める必要があって、今回は後者、つまり「フォーカスポイントを決める」方の話です。 スタートアップの初期は Y Combinator 的に言うところの Do things that don’t scale （スケールしないことをしよう）をはじめとした明確なフォーカスポイントがあると思います。ただ次第に自分たちでフォーカスポイントを決めなければいけなくなってきて、そのときにどのようにフォーカス先を意思決定すれば良いのか、どうすれば良い意思決定ができるのか、という問いが出てきて、その際に方法論の必要性が生じます。 そこで意思決定の方法論を検討するのですが、スタートアップのような情報不足や資源の制約下では、ゲーム理論をはじめとしたいわゆる規範的な normative 意思決定理論よりは、行動経済学や認知

2016/10/24 プロダクトマネージャーカンファレンスでの発表資料です http://pmconf.jp/

頭の中を整理するために、新たにチーム開発を始める時に決めることをリストアップしてみました。すべて書き出すと大量になるので、プロセスや開発基盤を中心に書いています。 プロジェクト計画 ゴール マイルストン スコープ リリース計画 プロセス チーム構成 リスクと対策 プロセス スプリントスケジュール（例：月曜開始の1週間スプリント） 会議体の設定（例：スプリント計画、スプリントレビュー、レトロスペクティブ） 複数チームのワークフロー（例：プロダクトオーナー、UXデザイナー、開発チーム、QAチーム） 仮説検証サイクル（例：仮説設定、リリース、分析） 進捗管理方法（例：リリースバーンダウン） 品質管理方法 障害対応のワークフロー プロセス改善の仕組み（例：レトロスペクティブ結果のバックログ化） プロダクトデザイン（略） ソフトウェアアーキテクチャ（略） インフラアーキテクチャ（略） テスト計画（略

プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる！」って感じで読んでてワクワクした。良かった。 ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。 立ち止まる時間 やることが多すぎてチームが疲れている。 その状況において 少しでもタスクを早く終わらせてチームに余裕を作りたい！と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。 そこで 5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り

Developers Summit 2016 KANSAI (デブサミ関西) 【B-4】15:45～16:30 生涯エンジニアというマインドを活かしてYahoo!天気アプリを成長させたPM手法 ヤフー 湯澤 秀人 http://event.shoeisha.jp/devsumi/20160916/session/1179/ Read less

ソースコードを漸進的に改善するための組織的活動のパターン・ランゲージを作りました。リファクタリングはソースコードの改善テクニックですが、ソースコードの品質改善活動を成功させるためにはリファクタリングだけでは足りません。品質改善を利害関係者も含めたチームの活動として捉えることが必要です。このソースコード品質改善パターンを参考にしてソースコードの品質改善を成功させてください。 ソースコード品質改善パターンとは 筆者は、製造業の組込みソフトウェア開発チームに対してプロセス改善や技術支援のコンサルティングを行っています。そのコンサルティングの中で、ソースコードの品質を漸進的に改善することに成功したチームに共通するコツのようなものをパターン・ランゲージとしてまとめたものが、このソースコード品質改善パターンです。 まだ、数チームの事例分析に基づくものなのでパターン・ランゲージとして練りきれていないとこ