hiroktsのブログ

IT開発系の勉強会の感想とか雑記とか

アジャイルとスクラムについて

ソフトウェア開発に限らずアジャイルを組織やプロジェクトのマネジメントに活用している会社が多くなってきている。
変化を前提としていないと時流に対応できないという一般的なビジネスの流れに対して、不確実性の高い複雑な領域であるソフトウェア開発やプロジェクトマネジメントに用いられてきたアジャイルプロセスが経営的なプロセスでも実践されてきているらしい。
日本でもそのような企業は存在するのだろうか?

アジャイル、そしてその中の一つの手法であるスクラムについて説明をしてみたい。
個人的な観点のため、偏った説明になるのはご容赦いただきたい。

アジャイルソフトウェア開発宣言

ソフトウェア開発に関するベストプラクティスを、旧来の開発の問題点を様々な方法で改善しようと取り組んでいる有名エンジニアが集まって考えた。
「このやり方がいい、あのやり方がいい。」
結論は出ず、宣言だけが採択された。

宣言とその背景にある原則を忠実に読み込めば、最終的に顧客がほしい「有益なプロダクト」をつくるためには、「動くプロダクトを見ながら常に顧客と対話して、その時々に発生する必要な変化に向けて一緒に戦う。」ということが書かれていることがわかる。

アジャイルソフトウェア開発宣言

アジャイル宣言の背後にある原則

アジャイルソフトウェア開発宣言の「左と右」

アジャイルソフトウェア開発宣言では左に旧来のやり方の特徴、そして右にアジャイルで実現したい特徴が書かれている。
旧来のやり方を否定するのではなく、目的のために最速な手段を右側に書かれているもので見つけてやっていこうという感じになっている。
左に書かれていることを疎かにするとアジャイルに詳しい人に怒られる。

左:プロセスやツールよりも   右:個人と対話を

取り決めやマニュアルに書かれている手順通りツール、プロセス、プロトコルを守る、ということよりも何か変化が必要なのだったら直接対話しましょう。

ただし対話はSlackなどのチャットツールのこともあるのだから、ツールを重視しないというわけではない。

左:包括的なドキュメントよりも   右:動くソフトウェアを

プロダクトについての全ての内容をドキュメントとして起こすと(例えばExcelでつくってそれをプリントアウトする)、キングジムのバインダーに途方もない量の紙が挟まれたものが何冊か用意される。 そしてそれは、殺人バインダーとよばれる。
ちょっとしたカイゼンの修正をするたびに、そのドキュメントを書き直すというのが本当にほしい価値だろうか?

ただし、ドキュメントを書かないというわけではない。
検索性のあるツールを使って、開発の段階から必要な内容を書いていくのが普通。
必要であればマニュアルなどを後追いででもつくる。

左:契約交渉よりも   右:顧客との協調を

有益なコントラクトはとても大事。ただし、本当にいいコントラクトならば顧客と協調できるはず。
プロダクトをつくることに対して顧客を巻き込めるかどうかが、本当にいいプロダクトを作れるかどうかの分岐点になる。

左:計画に従うことよりも   右:変化への対応を

反例として「分析・設計・開発・テストと3ヶ月ごとなど長期的なスパンで計画を区切って、テストの段階で分析が問題だったことがわかったけど計画にはないのでもどれない」みたいな状況を作らないということ。
変化が常に発生する前提のフィードバックループが大事である。

ただし、計画を立てないとそもそも目標がどこにあるのかわからないのでループを回して進む方向がわからなくなる。

スクラムについて

アジャイルソフトウェア開発宣言の前後の流れとして生まれたものの一つがスクラム
スクラムは軽量な開発プロセスフレームワーク。基本的にはチーム開発のためのもの。
アジャイルソフトウェア宣言に則しており、シンプルで「特定領域にしか当てはまらない」ということがないため、アジャイルの主流になってきた。

スクラムの特徴

リリースなどの価値提供を短いスパンで行い続ける、フィードバックループが基本
大きな計画を立てて最後に一斉にアウトプットするのではなく、常にアウトプットし、「フィードバックループ」で軌道修正し続けながら価値提供を行う。

スクラムの原則

スクラムの原則は、透明性・検査・適応の3本柱に支えられている。

透明性

フィードバックループで重要なのは透明化・つまり見える化されていること。
特に結果責任を持っている人、要するにお金を出す決定をする(執行役員などの)責任者に対して見える化されていること。
スクラムは透明化に対する【仕組み】が組み込まれているチーミングフレームワークである

検査

フィードバックするためには、作成物や進捗を検査し、「カイゼン」が必要なものを見つけないといけない
ただし、検査を頻繁にやりすぎて作業の妨げになってはいけない。
あくまでチーム単位で行い、最大限の効果のある改善ポイントを見つけ出す。

適応

検査で見つけた不備について、「カイゼン」が必要な場合にはプロセスやプロダクトの構成要素を調整する必要がある。
カイゼン」はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
スクラムは検査と適応に対する【イベント】が組み込まれているチーミングフレームワークである。

アジャイルスクラムで何が生まれるか?

素早い価値提供・素早い学習
ただし、開発プロセスが高速化してもインプットするものがだめだと、高速にゴミが量産されることになる。

というのが売り文句なんだけど、副作用としてチームでの働きやすさを提供してくれる。
働き方ディバイドやコミュニケーションのロスがイベントや仕組みで軽減される。
チームがチームとして透明性やカイゼンを考える頭を持つようになれば、お金出す人としては権限委譲がしやすい。

(IT系の)エンジニアは尖っていたり、コミュニケーション嫌いだったりすることが多いわけだが、結果としてこっちのほうがうまく行くと納得するルールであれば守りやすい。
こうしたことはエンジニアに限らずチームやプロジェクトの進め方の問題だし、構成員の複雑性や多様性が増す社会の中では経営的な視点でも活用できる。

事業会社でのソフトウェア開発と現場コーチについて

事業会社の現場の実例

2017年8月29日に実施された下記のイベントに参加してきました。

guildworks.doorkeeper.jp

エウレカ」 の正しいものを正しくつくる事例

Pairsというデーティングアプリを含む複数プロダクトの開発・運営
累計500万ユーザくらい
自社内のビジネス・経営層とやり取りしながら強いチームを作り、自社プロダクトを開発することについて話されていました。

エウレカとしてCTO室長の梶原成親さん、Guildworks側として中村洋さんが話されていました。

www.slideshare.net

こちらがおそらく梶原さんの講演資料です。

「ポレット」 の正しいものを正しくつくる事例

オズビジョンから派生した金融系のスタートアップ。
ポイントをまとめるサービス
カード会社や金融会社などと、excelやメールベースでのやり取りしかできないなどの超固いコミュニケーションしなければいけなかった困難さがあった。
そういう固いやりとりやスケジューリングを外部と握る必要がある状態で正しい開発をやることについて話されていました。

PolletとしてCEOの鈴木良さん、Guildworksとして市谷聡啓さんが話されていました。

www.slideshare.net

こちらは市谷さんの講演資料です。

エムティーアイ」 の正しいものを正しくつくる事例

SNSなどでの共有を控えてほしいとのことだったので書けないですが、エムティーアイでのリーンスタートアップのお話などをされていました。

エムティーアイとして高橋知朗さん、Guildworksとして川瀬浩也さんがお話しされていました。

以下の話は主にエウレカさん、及びポレットさんの話に基づいています。
しかし、発表された内容をそのままでは書いていませんし、全然講演で話されていないキーワードも書いています。
アジャイルの導入やアジャイルリーンスタートアップの現場コーチなどに興味がある人向け、(導入に向けて)上司や周りの人に話をするためにどういうキーワードを出せば筋がいいのか、といったことを考えながら書いています。

事業会社の開発の中でどのように「アジャイル もしくは DRR」が機能するか

  • プロダクトの課題(エウレカの場合は=経営課題)を解決する
  • 「ソフトウェアの価値をユーザーに正しく早く届けたい」
  • そのための自己組織化されたチームとアジャイルな開発

(※DRR = 正しいものを正しく作るというGuildworks社のキャッチコピー)

自己組織化されたチーム

エウレカさんのお話です。

自己組織化されたチームとは何か

  • 会社の「自立、自律」という行動規範を満たす
  • チーム自身にスキルがある、どうすればそのスキルを得られるか知っている状態にある
  • 自分たちで意思決定できる
  • 「週1回の会議でステークホルダーに意思決定してもらう」といった承認待ち・判断待ち・仕様決定待ちではなく、自分たちで最も良いやり方をチームで合意

自己組織化するメリット

  • 現場で判断し、問題、課題を解決することによって早いサイクルで改善できる
  • デリゲーションが適切にできている
  • 仲良しチームでなく、厳しい指摘をフィードバックしあって改善し、視座が上がる
  • デリゲーションはゼロか1かではなく、エスカレーションすべきものは適切にエスカレーションする。

アジャイルな開発

アジリティ、透明性の担保とは何か、スクラムとの関連性

  • アジリティとは敏捷性のこと
  • ソフトウェアは計画をひたすら厳密にやるよりも、動くソフトウェアを常に見ながら改善するほうが届けるスピードが上がる
  • 価値を届けるスピード(アジリティ)を追求する = アジャイル開発
  • アジリティを追求するにはどうしたらよいか? スピードを測れる状態が必要条件となる。つまり進捗状態や障害の有無などの「透明性」
  • ソフトウェア開発の透明性を常に担保し、可能な限りPDCA的なサイクルを早くクルクル回すためのフレームワークスクラム
  • 透明性に重点を置いて、チームが自己改善を進める = 自己組織化されたチーム
  • スクラムも出自はトヨタ生産方式

線表を引いて、マイルストーン(約束)を守りましょう 

  • スクラムアジャイルも計画を立てないということでは決してない
  • 着地までのリリース計画を全員で見立てる
  • いつ、終わるのかという現実感を全員でもつ
  • どうなれば完成と言えるのかの認識を揃えることで、プロジェクトに背骨が通る
  • チームを守る外堀としての線表が存在することになる (not チームを締め付けるもの)

割り込みとバッファのマネジメントについて 

  • チームの開発を守る内堀としてのバッファマネジメント
  • 割り込みや仕様の変更などの遅れは発生するとわかっている -> マイルストーンを使って空のスプリントで受け止める
  • CCPM的に全体の長さを見て、割合でバッファを入れられるのがベターかもしれない
  • 内堀、外堀で守っているものが仮説検証やアジャイルを中心とした「正しいものを正しく作る開発」。

アジャイルコーチについて

「正しいものを正しく作る」に対してアジャイルコーチが果たす役割

  • 「自分たちで考えて行動する」 ことの習慣づけ
  • アジャイル開発やウォーターフォール開発の開発プロセスの知見全般、見える化や課題解決のためのアイデア = 生き字引、あるいは道具箱
  • 様々な場でのファシリテータ 中立性 言いづらいコミュニケーションの橋渡し
  • 変化を推進するチェンジエージェントの最初の仲間

アジャイルコーチのメリットなどについて

  • CTOやスクラムに詳しい人がスクラムの伝道や運用にフルコミットした場合、他の仕事ができなくなるリスク
  • 書籍などで自習した場合、うまくいかなかったときに立ち直るコストが高い
  • トータルのパフォーマンスやチームの成長スピードを考えるとお得

結局のところ、どういう効果を目指しているのか?

  • チームが自己組織化される
  • プロダクトの価値を追求することに集中する
  • (自己組織化とかぶるが)エンジニア組織として当事者意識を持つ、学習する組織になる、ビジネスや目的に対する意識を持つ
  • ITプロジェクトの実行が変な方向に行かない

現場コーチなどのサービスの効果はこのような感じだろうと思っており、そんなもの自給自足できるよという組織もあれば、難しいという組織もあるだろうと思います。 本当にそんな効果あるのかみたいなのは現場の実例を詳しく聞いてみるしかないと思います。

なぜプログラミングを教育することが必要なのか?

将来的に働くのに必須となる可能性が高いから

単純明快

将来的に働くのに必須となる根拠

GEの採用ではプログラミング能力を義務付けているらしい。
今はGEだけかもしれないけど、将来的に多くの企業がこうなる可能性はある。  

GE: 今後採用する全社員に対してプログラミング能力を義務付け・採用職種に関わりなく 

プログラミングを中心とした情報技術はすでに社会的基盤

現代ではどんな仕事を選んでも、モノづくりや仕事の進め方についてITとは切り離せなくなっている。
例えば、メール、会議室の予約できるカレンダー、Excel

こうした企業活動の現場でモノをつくったりして働いている人たちは、「プログラミングを始めとした情報技術と密接に関わっている人たち」になっている。

情報技術と密接した社会で働いていくとき、プログラミングの基本的な知識の有無でリーダーシップや他者とのコミュニケーション能力に大きな差がついてしまう。
乱暴な言い方をすれば、プログラミングをわかっているふつうのリーダーとわかっていない情弱リーダーという感じ。
アップル、グーグル、アマゾンのような企業と渡り合っていくには、リーダーとなる人が『ITをインフラとして活用する考え』を理解できないと辛い戦いとなる。

ITをインフラとして活用する考え

ITをインフラとして活用するには、プログラミングを中心として『論理的思考力』を身に着けるのが必須になる。

論理的な思考力をさらにブレークダウンすると以下の2つになる。

  • 課題定義能力
  • 問題解決能力

社会的な課題があったとして、それをIT的な課題としてちゃんと定義する(プログラミングで作ったソフトウェアで解決する問題とする)のはかなり難しい。
そうした課題の定義能力の前提となるのが、「作業を分解し、分解した作業を順番通り行うことで問題が解決できる」というプログラミングの経験や知識であり、問題解決能力になる。

「ITをインフラにする」というのはこうした論理的思考力で「こういうシステム(プログラム)を構築すればこの課題は解決できるはずだ」ということがわかることが重要。
実際に手を動かしてプログラミングをやる必要がなくても、手を動かす人と協働を効果的に行うためにはプログラミングの実践や知識が非常に重要。
だからプログラミングの教育が必要なのだ。

プログラミングでどんなことを学ぶのか?

一般的なプログラミング書籍、たとえばプログラミング言語の入門書などでは以下のようなことを学ぶことができる。 順番は適当です。

動かし方

Windows, Mac, Linuxなどでプログラムを動かす方法

ifでの分岐

「もし、〜ならば」でyesならこう動かす、Noならこう動かす

ファイル操作など

多分テキストファイルなどを読み書きする

繰り返し

何回でも同じ操作を繰り返しできるのはプログラミングの魅力かもしれない。
ちょっとだけ変化をつけて繰り返す、というのもできる。

関数

自分が書いた処理を再利用しやすいように関数にする。 たとえば、テキストファイルを読み込む処理を関数として「file_load」のように名前付きで用意したら、「file_loadでメモ1.txtを読み込む」ということが簡単に書けるようになる。

データ構造(型、データ形式

プログラムで処理しやすいデータ形式とは何かを学ぶ。
例えば、Excelの3行目に入った数字を左から順に処理していくのには『繰り返し』で学んだことを使うが、そのためには処理しやすいデータ形式(たとえば配列)にポンポン入れていくことが必要。

エラーと例外

エラーと例外を学ぶ

Debug、テスト

エラーじゃなくても自分が期待した動作をしなければプログラムは意味がない
ちょっとずつプログラムを動かして動作を確認するのをデバッグという。
また、期待している動作かどうかをプログラム自体で判定するのをテストという。
ちょっとずつ、漸進的にやるというのはプログラミングにとって基本的な戦術になる。それを学ぶ

オブジェクト指向

プログラミングをより構造的に出来るようにするやり方。
ちょっと難しいので頑張って理解する

システム・インテグレーション

大きめの課題をプログラムとして実行するにはどうするか?
たぶん簡単なWebアプリケーションとか書いたりする 動くときっと楽しい

ギルドワークスの「中の人」ミートアップ! 〜エンジニア編〜

2017年5月30日に表題のイベントに参加してきました。

guildworks.doorkeeper.jp

以下メモです。

コードを書くほうに携わっている3名

ギルドワークスで働くエンジニアってどんなかんじ? 〜ギルドワークスで過ごした半年間〜

越 智明さん

入社するまで

先輩エンジニアDさん
会社の外で話した
「今どんな開発しているのか?」
Dさんが一番成長した瞬間は?
新規案件でゼロから立ち上げるというのが一番勉強になっている

ほかの現場もみてみたいな

DevTab開発

開発言語
Ruby, go, java

週一開発定例 skype or 六本木オフィス

学びたい人はこの記事を読めばいい

社外の人と接点をもって開発する

採用試験 面接

日々の働き方

slack 入社してすぐ50~80チャンネルくらいに一気に招待された

Guildworks遠方に住所を持ってる人が多い
朝誰もオフィスにいないことが多い

slackは5時6時からフル稼働している

コーディングが主な業務

プルリクだけだとテキストだけになる
skypeをやることが多い

MoviePrint

動画を制作したい人 動画を作れる人
マッチングサイト

会社をまたいでという開発は初めて

開発合宿2人で缶詰

Sonitech

建築資材に的を絞ったEC
ゼロから

スピード感のある開発
一緒に組んだメンバーが良かった

Programing Boot Camp

3周年パーティー
ギルドワークス全員集合

結論
短期間で新しい経験を複数
経験豊富なプロジェクトメンバー

ギルドワークスに入ってやったこと・学んだこと

佐々木将之さん
UXデザインが好き

宮城県松島町
ほぼ毎週東京出張

2014年4月
創業メンバーを除く初めてのメンバー

実家に預けていた娘が小学校にあがる
宮城の企業をまわったが
UXリサーチを必要としてくれるきぎょうはなく

リモートワークでの勤務を模索
やりたいことを探っていたら出会った

スマートカート

顧客開発に追随するアジャイル開発
システム開発よりビジネスとして顧客を見つけないと始まらないよ

設計不足はマジ大変
「MVPなので作り直す」はほぼ作り直さない

シェアウィズ
仮説検証
開発マネジメント

サーバサイドScala
ReactNative

クライアント側の開発メンバーと1チームで開発

境界を越えて開発チームへ踏み込む

RODEM
開発マネジメント プログラマー

事業レベルの相談 市谷さん
コード1行まで

学んだこと
チームあってこそできた

一番学びが多い

学んだこと

一人でできることできないこと
チームとして成果を上げることを考えないと成果を出せない

リモートワークのありがたみ・大変さ
家にいるのに何で働いているといえるのかと家族にきかれたりする
通勤ラッシュに合うみたいなのは減った

いいものを作るためのアレコレ

利用者に役に立つものを作りたい

大学院時代

生命倫理
全12回 オムニバス 毎回講師が違う

倫理に関する 問いかけをする 答えがない

施設見学
西多賀病院 仙台

筋ジストロフィー

入院生活上で、何がほしいですか?
「鏡がほしい」
いつもと違う景色が見たい

利用者がどう利用していいかわからない

開発者のソリューション
ギャップ
顧客のほしいソリューション

大規模メーカーからギルドワークスにJoinした二年間

前川 博志さん

Application Lifecycle Management

開発者 兼 現場コーチ

Java iOS Android

大手企業から転職してきたギルドワークス

ナデラに変わったころにMSMVPをとったので、オープンに変わっていくMSを知ることができた

手段の目的がになりがち
入れるのが大変すぎる

自分は一流のエンジニアでいられるだろうか?
会社の枠を外して一人のエンジニアとして自立できているだろうか?

クラウドを使うルールの制定が一年くらい続いていた

現場感覚とマネジメント層のイメージの差
同世代もどんどん次のステップに進んでいる

このままでいいんだっけ

ギルドワークス
7人目の社員

前職が圧倒的に優位
100年 福利厚生もいい

くいっぱぐれることはないはず
本当に?

自分の仕事はつぶれないか?
ほとんどの仕事はAIになるのでは

10年後あんな仕事がしたいか?

Join to Guildworks

自分が動けば会社が動く
会社で何が起こっているか全部わかる

めまぐるしくってついていけねー
自分が動かないと何も起きない

会社のことを全部知ろうとしないとついていけない

印象的なエピソード
craful

イデアだけがあって ゼロから作っていた
ベンチャー経営者の熱を感じた

iOSエンジニア 四国
API 仙台
デザイナー東京

開発終わってから飲んだ
craful第2弾

人材系の新規立ち上げ

SPA
自分の見立てのあまさから、かなり危ない開発になってしまったプロジェクト

技術的な見立ての大切さ(SPAをはじめてつかった)を痛感

危ないとなったポイントから巻き返しプラン

大企業の新規サービス立ち上げ
大きな企業の中で、新しい取り組みを始める人の熱さ
データ・プロセスをプロジェクトを通して学んでいく楽しさ
どんどん「自分のサービス」と思えるようになってきた

これまででまなんだこと
プロダクトに本気で向き合うこと
本気のクライアントが多い

リスクを冷静に見つめること

パッションが大きいからこそ冷静にリスクを見つめなければならない
計画の遅れ、未確定事項、不安なこと、それらは必ず後で火を噴く

ギルドワークスの創業メンバーは血として持っている
それを体験することができた

これから

正しく作るのこだわりを出していかなければ

QA

プロジェクトの入り方

飛び込みじゃなくて紹介が多い
こういう話あるんだけど興味ある人いる?

洋さんとかが仕事をもってきて

誰も手をあげないときは?
ほんとにやれる人がいないときはお断りする
本気でやるクライアントじゃないと受けない
顧客が適当だとやりがいがなくなる

開発から入るみたいなのはお互いにバリューを感じられない

プロジェクトの巻き戻しよりもつらかったこと

自分の成長につながるからこそつらかったこと

大企業だと事務の人に言えば派遣さんくる
社会人として何も知らなかったということでへこむ

クライアント次第で柔軟に契約が決まる?

準委任にはしない 基本請負
差し引きは合う いいものが作れないときはゆるやかに合意する

スコープは相談するなどは割と気にする

Slackの話

透明性は高い 経営などの話
全員収支を見て 案件取ってくる 案件にジョインするなどが期待されている
どのクライアントにどのくらいお金払ってもらってるなどは意識している

リスク

技術的に困ったとき
社外のメンバーに頼る
仕様がどうしてもわからない
skype
Googleカレンダー 30分間の隙間
タクシーの中から応答

リモート力高まる いかにカフェがうるさいか 相手の声聞こえない こまめにマイクを切りながらしゃべる

Guildworksだけでなくエンジニアカルチャーはあるのか?

Guildメンバー = パートナー

差し引き 会話ができる
緩やかな個々人の会話

開発は制御しきれない

ブルドーザータイプ
整えていくのが得意なタイプ

いってもフリーランスの人が多い
組もうと思っても別の案件のときがある

経営判断 人ひとり入らないと終わらないでしょ
案件を受け入れない

評価について

基本は任せる方針
残業が云々などは言われたことはない

半年ごとに目標 創業メンバーにレビュー
人の評価は難しい

Guildworks定例のアジェンダ
同じことやるのが嫌いなくらい変わる

市谷さんが思考停止が嫌い
常に考えさせられる

全体の感想

参加人数は少なかったんですけど面白かった。
社員それぞれに得意技が違う感じというのも伝わりました。 順調に利益も出しているとのことなので羨ましい感じがします。
大変だけどやりがいがありそう、楽しそう。

Guildworksは理念が「正しいものを正しく作る」なのでわかりやすいです。
本当にそういうことを言い続けるのって大事なんだと思う。自分としても何を大事にして仕事していくのかを常に考えていきたい。

DevLOVE200 Bridge に参加しきました

2017年6月18日に、表題のイベントに参加しました。

基本的にメモの内容をそのままのせています。それと一言感想です

誤りなどある場合もあります。。ご容赦を

新規事業が対峙する現実から エンジニアリングを俯瞰する

黒田 樹 さん
エンジニアリングマネージャー

オートスケールより殺しに来る力のほうが強い

開発の秩序を保つためにスクラム

どんなに開発チームがいけて
ボトルネックが開発からビジネスへ推移
ても、チームに行けてないものをインプットしてると価値が出てこない

従来のプロダクトバックログ
仮説完成型のバックログ
必ず仮説検証してから実装する

企業内での新規事業得意なのか?

海外事業をグロースさせてこいと言われた

なんだかよくわからない日本人がお前らをグロースしてるよ

バイスプレジデントの席に3DSがおいてあった
任天堂の国から来たことを見せつけた
ゲームの腕前を見せつけて「おまえすごいな」と

膨大なビジネス企画のシャワーを浴びる

経験した各フェーズでの立ち回り

事業が対峙する現実

エンジニアリングはどうすればいいんだっけ?

ビジネスモデル わからないよというとき

どこで売り上げが発生しているか

エンジニアの書いたコード上で立つか? そうでないか

成果課金型の広告

深堀していると画面遷移がある
if bookedのロジックに入ったら ちゃりーん

そうすると離脱率をさげる
KPI CPA

エンジニアが成長貢献になりやすい
数値目標を持ったプロダクトチームがジャンジャン改善サイクルをよいパターン

アウトソースやってる会社 内製
どうやったらいいの?

そこのビジネスモデルのエンジンは何なのか?
営業に最適化されたエンジンになっている

AARRRモデル

Acquisition
マーケ、営業

売上、 CV >= CVR(プロダクト)
マーケ側 プロダクト側

コード上で売り上げが立たない場合

純広告
CVRの改善 は 次回発注への信頼獲得

売上 > CV >CVR(プロダクト)

いけいけなコードなどいくらでも活躍する場合がある

でもドメインコモディティ化 ビジネス貢献が可視化されない

エンジニアはコスト削減や生産性向上のような、ビジネス指標からは程遠い目標設定になる

守り中心でも攻めの要素があるよね

勘所

ビジネス戦略やプロダクト戦略

ビジネス貢献するとおもってやってることが実はそこまで重要ではない場合

前提の書き方が間違っている

目的意識はもってるものの ビジネスと目的がすりあっていない

ビジネス側とひざを突き合わせて語り合いお互いを理解しあうこと

目的に忠誠を誓う

目的に対してのIT戦略
SOE, SORの共存

SOEかSORかの2極化になりがち
チームのCaperbilityを考えよう

https://martinfowler.com/bliki/BusinessCapabilityCentric.html

過度な原理主義

それぞれの方法から光を当ててみる
2軸でグラフを作っちゃおう

戦略や各種優先度

ビジネスフェーズからエンジニアリングを見る

ビジネスフェーズ
検証する
顧客発見フェーズ

魅力発見

顧客実証フェーズ
当たり前品質 買ってもらうには性能も商品レベル

顧客開拓スケールフェーズ
すべてを振り切っていく

ビジネスフェーズ(アーリーフェーズ)
職種を超えたマルチロール型
一緒に企画を考える
なんでもやろう

顧客実証フェーズ
エンジニアの中でフルスタックエンジニアリングでやろう
数値を上げるためにはどんなエンジニアリングでもやる

顧客開拓
セグメント

何でもやる -> クロスファンクショナルに フェーズで推移

DevOpsやりましょう

柔軟にやりましょう なのに 予算一年でろっくしてるじゃないか

年次予算計画の圧 ウォーターフォール型に注力されてしまう

行動様式
自分流の行動様式

それぞれの特化された領域 それぞれの光の当て方に特化しちゃっている
顧客開発、リーン開発、リーンUX など並行に 思考実験が必要

真の目的を理解して それらを複合的に利用する

制約理論やFlow Efficiencyが全体を照らしている

リソース効率性とフロー効率性

リソース効率
稼働率は100パーセントにしやすい
働いている感は出やすい

フロー効率

This is Lean という本に書いてある

フロー効率

全員の机に一時置き場(書類受け)をつくる
大量の待ちタスクができる

1個のタスクが届くまではすごく長くなる

100パーセントの利用率の高速道路は駐車場と一緒

走っている最中に靴紐は結べない

コード上でチャリンチャリンいうモデル

基本的にフロー効率をあげる

同期するようなタスクを減らす

でっかいサービスのアプリチーム
アジャイルウォーターフォールが混在している

各部門が外側にある マーケ企画営業分析
SOR ウォーターフォール 
SOE アジャイル

SOR
リソース効率

フロー効率
ー> CCPM

UIUX改善
フロー効率
一こ流しを目指す

ビジネスを考えいて提案 受け入れられない
前提が間違っている

開発手法は手段
我々が忠誠を誓うのは目的

感想

コードが直接お金を生んでいるのか、いなければどうするのか、ということは今の現場に当てはまることだ。
守りの中でも攻めがある、という姿勢なんて本当にできるんだろうか? リーンでもアジャイルでも制約理論でも光の当て方がちがうなら何回でも違う方向から当ててみることをしたい

ソフトウェア開発の中心にあるのは『情緒』である

新井 剛さん

組織の壁 疲弊

アジャイル推進会
現場集め

ハイタッチする 最高のプラクティス

共感 のっと 問題解決

透明性がすごく大事
カンバンとか見える化

多忙表明 ニコニコカレンダー 手伝ってもらえる余裕

もやもやボード
言語化すらできないことをぽんぽんはる

データ更新の管理 国盗り合戦 地図で

レゴバーンダウンチャートを作る

いと楽し作戦
ワクワクする会社いっぱい ザッポスとか

宮本さん
人材交流

つながり作戦

会社見学ツアー
来ていただいている

メリットは会社のブランド強化
ファン
働いている環境を見てもらう

コミュニティの人たちとつながっていることが重要

アジャイルコミュニティへの恩返し

社内編(スライド参照)
すごい勇気づけ

いろんなことを会社のホームの文脈で話せる

喜びのほうがなぜいいんですか?
喜びながら働いている社員のほうが生産性が高い

新井さんが有利な点 役職

ワクワクする会社を目指す
ハッピーチームは生産性が高い
モチベーションよりもハッピーを目指すほうがいいんじゃないかな

悩み 人間関係
マネジメントは人である

エンジニア 理屈っぽい
同意はするが 感情が

知識を信じるしかない。。。

「情緒」

岡潔さん(数学者)

田畑を耕しながら数学をやってた
生涯で10篇の論文

「数学の中心にあるのは情緒である」

数は5感で感じられない

実態がないのに先にわかろうとする 分析過多

論証主義

日本文化では経験として知っていることを重視していた

理解は対立的にわかるのであるが「体取」は自分に取り入れる

数学も一緒

心を攻めていく

計算する能力 推論の能力すすんだとしても
他社の心を理解することが必要

クリエイトする力が未来のカギ
U理論
7つの習慣
学習する組織

同じことを言っている

逆説のスタートアップ思考

やりたいことはやってみないとわからない

始めるから情熱が生まれる
情熱があるから始めるのではない

内面からスタートするしかない

妄想する
発見が後からついてくる

自分が観測できる範囲を徐々に徐々に増やしていく

次の時代

誰もがこの働き方を気にいるわけではない

仕事は喜びにつながる
つながることが喜びにリンクしていく

DO Agile Be Agile どっちでもいい

その昔えきすぱぁとがなかった時代 紙の時刻表

ITで時計の針をちょっとでも進めたい

たどり着く場所 ないかもしれない
数学者 自分の人生の中でその論文が解けるかわからないけど必死こいてやっている

ソフトウェア開発
人と技術と文化が織りなす

感想

Do Agile, Be Agileどっちでもいい、かー。
逆説のスタートアップ思考でも「始めるから情熱が生まれる」という言葉に着目できていなかったなと思う。
ちゃんと始めなければ、と思わされました。

CROSS∞BORDERS 越境の果てに辿り着いた彼岸、さらにその彼方へ」

鍋島 理人さん

キャリアの話

ぬーらぼ バックログ カスタマーサクセス担当
4月ジョイン

翔泳社
DevLove Co founder

越境を愛するようになったか

翔泳社 2番目の職場

ゲーム会社のサウンドクリエイター

未経験の広告営業職

逃げとか迷いが前職へ導いた

コミュ障なので大変

営業と制作の相互不信
潜在的には合った

広告業界リア充オーラにあてられる

地道にこつこつ

予算
上限に対して行動目標
振り返りを行う

営業と編集の間
どうすれば喜んで仕事をもらえるか

圧倒的感謝

越境という言葉と出会う

違いを超えて目的を探る

ロールモデルがいた

デブサミの母 岩切さん

一番大切な贈り物
コミュニティに参加できたこと

ジェダイマスターではなくシス卿のイメージ
岩切さんが越境を体現 それを体験

エンジニアの祭り

世はまさに大エンジニア時代

デブサミのビジョン(スライド)

心は常にエンジニア
いろんなコミュニティ いろんな思い

場の理論
場へのコミット

越境をエナジャイズする場

テクノロジーが社会のためにできること
コミュニティを超えた連帯
東京一極じゃない 日本のそれぞれの場

デブサミの志を「だんだん」自分事化できた

転機2
世界ってひろーい
たーのしー

BPStudy
エンジニアコミュニティが培ってきたナレッジ
エンジニアコミュニティが企業をドライブする

Joyinc

人はみな自分の時間の投資家である

世界は何が起こるかわからない
やり残したことがないように悔いなく生きていこう

ご飯でも食べに行きませんか?

ぬーらぼ

社員60人
海外8拠点

エンジニアコミュニティがそのまま会社に

作ってるツールが絶え間ない越境を可能にしている

日本の会社のひとつの可能性を見た

感想

自分たちのプロダクトで戦ってみたい、ていう気持ちがあったんじゃないかなぁと思う
デブサミの志を「だんだん」自分事化できたっていうのがすごくよかった。

SIerの中心でSIerを語る

TIS
川島さん
大虎ぶる

会社の公式な活動
Qiita

実質一位

Devlove2008年くらいから

2010年くらいからスライドシェア
定年してから勢いが増している

定年を機にGitHubを使い始めた
定年超えてからプログラムかく量が増え始めた

PCの移行の時
プライベートで残していたノウハウやコードも断片的で使えるものになっていない

定年してからの活動
全部残っている

人の目にさらし、すぐに使える状態にしておくことにもっと気を使ったほうが良い

Sierとは何か?

SIerは技術力が低い?
LTフリースタイルバトルへ

Sierの生きがい

いろんな要素技術に携われる(かなり自由に選択できる)
かかわる人の多さ
圧倒的感謝を得られる

SIER最大の問題

隣のチーム・部門とやっていることが違いすぎてサイロ化しやすい

客先常駐などにより別の部署・チームとの交流が得られない

自分だけに対するインパク
ツールによる自動化で楽をする

公開しにくいVBAはやめておこう
先々の資産 使えるツールを開発

OSSを作り業務で使う
GitHubリポジトリ
区分けして作る

JP1 クラウド展開すると金がかかりすぎる
ジョブコントローラ

自由は作れる

外で話題にして顧客
部内に持ち込む

技術力はコミュ力を超える
世間話をしなくても お客様の言っていることを理化して解決してあげる

社内勉強会 どんなに頑張っても意識高い系しか巻き込めない

Advisory Team
部門をまたいで話ができるようになった

社内のソリューションを自分の持ちネタに寄せれるようになってきた

課題と出会いの多い職場で働くのはエンジニアの成長機会に事欠かない
35歳で定年している暇はない

感想

35歳で定年している暇はない、という言葉が良かった。
実のところ一番考えさせられたかも

モブプログラミングを通して見たアジャイルの真髄

及部 敬雄 さん

エンジニアの立場で

Why, What

複数の現場でやってきた
再現できる自信がある

ビジネス、エンジニアリング、チーム

自分の得意な エンジニアリング、チームから初めて
ビジネスに切り込む

そこまでできれば早くいきたい

モブプログラミングという働きかた

チームで一つの画面

常にモブプログラミング
もぶへのではいりはじゆう

プラクティスではなく働き方
志村-うしろうしろげんしょう

おかしをおいていく

達成感がある
使えるけど楽しい

やってよかったこと

生産性 スピード 相対的スピード
はまっても最小限
後追いコミュニケーションが減る
集中してやったら疲れる 定時に帰られる

やることモブしかなくなる
振り返り レビュー 常にやっているので定期的にはやらない
全員でダメだったらしょうがないと思える

心理的安全性
終ったらやったーといえる
ノウハウ スキル
全員が知っている状態で進む

動くプロダクトに常に集中する
チームの中心にある モブ自体が仕事の中心

アジャイルソフトウェア宣言のアジャイルゾーン(右側)

分担することを前提にしすぎている アジャイルでもウォーターフォールでも
仲間と一緒にやったーといっているか?

誰もがこのやり方を気にいるわけではない
一緒に働く人どんな人がいい?

一緒に影響してくれる人たち 戦友

モブプロはどうでもいい
DevはLoveですか?

感想

確かにピュアなアジャイルアジャイルソフトウェア宣言の右側だと思った。 同期がいらなくなるモブプロいいよな、って思う。 この話聞く前は、すべてのカイギをモブプロにしてみたらいいんじゃないかとか考えていた。
あと、楽天さんだからできるんでしょ、に、はいそうですと答えるのがいいな 一緒に働く人が最高である、そのために自分も最高であるのを目指している状態になりたいですね。

”越境”することを伝える現場コーチ自身の”越境”の話

中村洋さん

自分の越境の話

ミッション:「正しいものを正しく作る」現場を増やす

ある程度整ってきたら 背中を押してあげるだけで解決できるように

越境をできるようになるいこと

今は難しくても学んでいくことで越境できる
何か学んでいないと2回目、3回目で越境できない

前提や制約を置かない
ハンコ 予算 経緯

目的に忠誠を誓う
レンガを積んでるんですか? 境界を立ててるんですか? 祈りをささげられる場を作っているんですか?

目的のためなんでもやる
できないのは仕方ない

デザインの邪魔者は捨て去る

えっきょうする

できることが増える

武器を取り換えるではなく 武器を増やす

それまではモノづくりしか見えない ユーザーの風景 がみえる

客先常駐
自分がどこの所属会社かわからない

業務を知ろう ビジネスを知ろう
ビジネス課題

営業が案件をとってきて、、、みたいな状態から
交渉ができるようにすること

巨大組織の巨大プロジェクト
発注者からその先のユーザーの声 まったくわからない
小さいチームを作った
大きな案件は花形扱いだった
小さい案件だからこそチャレンジブルな人が多かった

お客さんではなく、使う人のことを考える

良いバックログ
「ユーザーの何割かがこういうことを言っています」
悪い
社長が言っています

えっきょうすることにフォーカス

自分なりの越境のやり方

やりたいこと やれること やるべきことを知る

ガッツとパッションがあることをまず見つける

機会と経験
まず、どれだけ自分で取りに行けるかが大事

経験からどれだけ学びを取り出されるか

発見がないなーと思ったら越境先を見ていくことが必要

感想

耳に痛いことを言ってくれる存在で、銀河英雄伝説のムライ中将を思い出した。
オライリーのデザインスプリントにあったように、好意的な懐疑論者であることが重要なんじゃないかと思う。

経験からどれだけ学びを取りに行けるか。。

発表内容とは少し離れるが、直近で気がかりな質問をぶつけてみた。
「チームでスクラムをやっていて、わりと漸進的にスクラムのプラクティスが導入でき、チームのモチベーションも高まっている」
「ただ、チームがお互いにスクラムの導入などに最初から合意できていることが理由ではないか?」
「豚として身を差し出さない上からの意見や、もし新しく入ってきた人に一緒にバスに乗ってほしくない人が来たらどうすればいいのか?」

チームの目的を話し合ってみて。
そこからの自然発生的なワーキングアグリーメントが存在しているはず
そうすれば自分たちがどんな人と一緒に働きたいのか、
逆に働きたくない人がどんな人なのかが可視化、明文化することができるはず
そうすれば自分たちはこんな感じにやってるので、チームに入っていない人にも「自分たちはこういう考え方で、こういうやり方でやっているんだけどどうですか」といえるだろう。

DevLOVE 立ち上げから学んだ、サービスを創り育てるということ

竹本 和彰さん

DevLove Co founder

得意技
スタートアップ 新規事業での開発

DevLove立ち上げ 一緒に見ていた目線

どういう風に巻き込まれたのか

スタートアップでゼロイチ

RubyKaigiの帰り道に

開発って楽しい? 楽しい
たまたま隣に座っていた

Rubykaigiの帰り道に至る前の話
越境への準備の話

  • なぜそこにいたのか
  • なぜその話になったのか

TISカイギ 社内版のデブサミ
マッシュアップアワード

TISカイギ
なんで手を挙げたのか?
おもしろそうなめんばーがいたから
ワクワク感があった

できたこと
部門の壁が大きい

マッシュアップアワード
藤原さん
並河さん
竹本さん
それまでサービスをチームで考えるという機会がなかった

すごい人たち
別世界の人ではない

開発は楽しい

社内読書会
社外の人も入ってきた
その回からDevLoveになっていた

漢訳者を呼ぶ
読者だけの読書会を超える

コミュニティ自体が越境していく
普通のエンジニアだった 越境していくことがすごく普通のことになった

何が自分の中で変わったのか あまり覚えていない

システム開発が自分の仕事

サービスを育てることが自分の役割

リフォームのマッチングサービス
多重下請け構造
SIERで経験していた

エンジニアができること
プロダクト開発、だけじゃない

何が目線として変わったのか 役割として変わったのかがこの辺

「生産性の高い組織づくり」

感想

2008年のRubyKaigiの帰り道の話は目にしているけれど、その前夜の話はあまりしらなかった。 エンジニアができること
プロダクト開発、だけじゃない
100パーセントできることをやっていきたいなと思った。

時を超えた越境への道

市谷 聡啓さん

Guildworks
チームのレビューが顧客・関係シャットのスプリントでもよりもはるかに厳しい

当事者の人より 当事者らしい目的を持とうじゃないか
ふわっとしたことから始まることが多い

目的に対して コミット、共感しないとたどり着けない

クライアントワーク 自社開発ということがいいわけに使える というのは気のせい

忠誠を誓うのは目的

目的のために目的を問い続ける
本当にそれでいいのか?

どこかでまちがってしまうことがある

一行のコードから、事業戦略まで
さかのぼっていけばいくらでもさかのぼることができる

大げさな話ではない
関係者のこうなってほしいという思い

考え方と活動
越境すること そのもの

2006年
塹壕の中 隣の部署 わからない

追い込まれていた
2007のデブサミ
特別なデブサミ
Rubyアジャイルの話
Rubyアジャイルでなく、これすげーなー そこにいきたい

どこからか現れる救世主を待つほど人生は長くない
自分たちでやってみる
社内版のデブサミTISカイギ

Repeat Dath March
生死の世界
本当に健康を害したりするから笑い話ではない

2008年
自分たちの好きな技術でいいものをいっぱい作るぞーみたいな人たち
正しいものを正しくつくりたいんだ、ということに立ち戻った

2人で始める安心感
なんかやろうとしたときにまわりにひとがついてきてくれるのかな

最悪一人ぼっちにならないで済む

ひとつ大事にしている考え方
自分が経験してないことを 見聞きして

稲作、一生かけて、たかだか60回
ソフトウェア開発 たかだか300人月

HangarFlight
どういう時にどう飛べば安全だ
格納庫に集まって話し合う

無謀な開発を止められない
ビジネスモデルの限界

たちどまったほうがいい
でも、会社にとっては対価を得られない事態になる

正しいものを正しく作りたい、といことに立ち戻った

当事者意識の境界を超える

越えるべき境界はそれぞれに違う
目的をとらえられている限り、境界は越えられる

越境 一人で突き進んで回り誰もいない

周りの人も巻き込まれていき 結果としていい方向に向かう

安定と混沌の

越境のための視点と技術

どこからどこを見るか

どこから?
意思決定 
プロダクトの目的から考えていく

目的の高さを視座という
同じ範囲を見ていても視座が変われば見えるものが変わる

視座が高ければ高いほどいい というわけではない
視座が高い、視野が広いところから 低い、狭いところを行き来できることが重要
可能な限り早く

実験とフィードバックによる調整
よくわからないことについて決め打ちでやるわけにはいかない

仮説検証 アジャイル

リーン原則とアジャイル原則

指し示す指ではなく 指の示す先を見る

ときどきによって必要な原則をもってきて 光を当てる

越境は孤独

プロフェッショナルは励まされ、動機づけられたときに、最高に実りのある仕事をする

Enagile

クラウドエナジャイズ
越境支援

感想

8年越しの再会、再開という話と2人の安心、という言葉が響いた 最悪2人に戻るだけ 共同創業者がいることがどれだけ心強いことなのかということがよく分かった。 目的のために目的を問い続ける「本当にそれでいいのか?」というのもすごく印象的。

越境していく、ていうのは目的のための自然な動きにすぎないかなぁと思った。 どこまで当事者になれるかということが、どんなことでも大事だと思う

Djangoで特定のmigrateをやったことにする

メモ

別のブランチでmigrateを実行したあとに、もとのブランチでmigrateを追加してやろうとするとエラーになることがある

django.db.utils.ProgrammingError: column "expires_month" of relation "profile" already exists

そういうときは、特定のmigrationファイルやディレクトリを指定して、fakeオプションを使って実行する

python3 manage.py migrate --fake auths/migrations/0009_hoge.py

docker-composeと組み合わせるとこんな感じ

docker-compose exec app python3 manage.py migrate --fake auths

リーンに、スモールチームでものごとを進める意味

Harvard Business Review 2017 4月号にのっていた三枝 匡さんのインタビューを読み直して、以下のようなことを考えた。
他にも、リーンスタートアップの本や以下のリソース効率についての記事も参考にしている

i2key.hateblo.jp

リソース効率やフロー効率についての考え方や、リーンの意味についてはまだまだ勉強中なのと、実践も足りなすぎるので誤りなどがある可能性があります。

トヨタ生産方式については、エクストリームプログラミングや、リーンスタートアップといった書籍でも言及されている

在庫を減らすことではなく、「時間の価値」つまり「フロー効率」を追求している

人はみな「リソース効率」を求めがち。 機械や人の稼働が100パーセントに近い状況、Googleカレンダーのスケジュールがいっぱい埋まっている状況がリソース効率が高い状態。

よく言われるたとえ
CPU使用率100%のコンピュータを使いたいと思うだろうか?」

リソース効率を追求すると結果として在庫がたまって、停滞してるところが出てくる。よくない。

フロー効率は、1個単位の製品の生産で見たときに一番速く生産ラインを回すための効率。
必然的に、製品が生産や改善をされないという待機時間を減らすことが優先される
たぶんここまではわかりやすいけど、その次が意識がついていかないかもしれない。

1個流しの生産フローがフロー効率を最大化する。

トヨタの生産方式の理想的な想定では、問題があったときに全体のラインを止めてでもラインに関わる人全員で改善を行う「アンドン」が実施される。
「アンドン」はリーンスタートアップで、名前付きで言及されている。

「モノ」や「儀式」を考えた生産のサイクルは次のようになると思う。

  1. Plan
  2. Product increment(出荷可能な単位の製品の増分)をつくること
  3. Metrics(メトリクス)あるいは顧客の声のチェック
  4. Retrospective(振り返り), Adaptation(適応)を行うこと

このサイクルをまわすのに一番速くなるのは「1個流し」。
複数のものを回すと最適化などに労力を取られたりするから、ってのもあると思う。

フロー効率を追求することは「時間の戦略」でもある。

製品の待機時間を減らすという意味で。

「1個流し」を実現するためにはスモールチームのほうが勿論いい。
チームにリーダーがいて意思決定や、決済的なことまでできることはすごく重要。

「競合」「顧客の声」にたいして、チームが敏感になることができる。

ここが、「リーンに、スモールチームでものごとを進める意味」ではないだろうか?

それ以外の問題

スモールチームを目指すだけだと、組織全体の事業などとのシナジーが薄くなる、といった問題も出てくる。
その先の話は三枝さんのインタビューを読めばよいかと思う。