Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
- アンラーニング -
たのしい社内SE業と
アジャイル
2015/09/12 XP祭り2015
渋川よしき

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
お前だれよ？
 社内SE歴 10年超
⁃ ホンダだったりDeNAだったり栃木だった
り東京だったりサンフランシスコだったり
 いちおう、XPユーザグループ設立準備委員会か
らのメンバーです
渋川 よしき
 プログラミング
 C++とかPythonとかGolangとかJavaScriptとか
 本
 つまみぐい勉強法、アート・オブ・コミュニティ(翻訳)、
Mobageを支える技術、オブジェクト指向JavaScript(翻訳)、
ポモドーロ・テクニック入門(翻訳)、etc

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
新書出ましたよ！
 JavaScriptの、最速クライアント用MVCフレームワークの本です！
⁃ 速いのが好きな人や、変化が多いブラウザ周辺技術に疲れた人に
オススメ
 電子書籍のみです
 表紙は黒ムツの仲間
⁃ 南オセアニアの深海魚
⁃ 最大75cm
⁃ 確認された再高齢は
100歳を超えるとか

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
今日のお話
 アジャイル的な社内SE業務の進め方
⁃ 10%ではなくて、10倍、100倍の業務改善を行う方法
⁃ レイヤーとしては、計画ゲームとかプロダクトオーナーとか
そのあたり
 俺のXP
⁃ XPの本を読んでも、アジャイルの本を読んでも、どのようなイン
スタンスが生成されるかは人によって異なる（午前の角さんのお話
にあったように）
⁃ 僕の中でできあがったインスタンスのお話

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
事例
 ゲームのマスターデータのデプロイツールのリプレース
⁃ 第6回DeNAゲーム開発勉強会で紹介したもの
⁃ 入出力フォーマット(UIとなるツール)は変更せずに、
アーキテクチャは大幅変更して100倍の高速化を実現
 他にもいろいろやっているけど、今のところ外部に出している情報は
これぐらい(そのうちもっと出したい)
http://www.slideshare.net/dena_study/final-fantasy-record-keeper

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
アジャイルと社内開発業務
 日本で話題になるのはアジャイルと契約が多い
⁃ 規模が大きくなるとシステムインテグレータ的な
ソフトウェア開発が多い
⁃ ユーザ企業はソフトウェア開発部門はあまり持っていない
 社内開発業務の話はそこまで話題になっていない？
⁃ XPが生まれたプロジェクトとして有名なクライスラーの総合報酬
プロジェクト(C3)は社内開発案件
⁃ 社内開発とアジャイルは相性が良い
→トートロジー的

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
社内SE業
 開発者数は極めて少ない
⁃ 社内の位置づけ的には利益を生まないコストセンター
⁃ 戦略的なツール・ミドルウェア開発以外は少人数
(1人)で短期決戦ということも多い
⁃ フルスタック(ワンオペ)エンジニア
 営業活動大事
⁃ 自分で探す
• ブランディング大事。「この分野なら俺に聞け！」
• 社内勉強会で発表する
⁃ 上司の信用貯金をかりる
• 他の部署の困り事に対して「お前に任せる」と仕事を振ってもらう
• 仕事のやり方を他の部署の人に変えてもらうには信用がないと無理
• 上司から信用貯金の前借りでレバレッジを利かす
• 信用借金はきちんと返す

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
社内SE業務のジレンマ
 社内SEだから業務プロセスに合わせたシステムを手作りできる？
⁃ そんなことはない
⁃ 人手が豊富じゃない。いつまでメンテの工数が捻出できるか
分からない。
⁃ 圧倒的なメリットが無ければ、社内専用ツールとかミドルウェアと
かライブラリとかを使いたくない人が多い
(使う人のキャリアプランにとってマイナス)
 いかに業務プロセス側を動かしていくか？
⁃ これをうまく(ストレスなく、リスクなく)やっていくのが大事
 ユーザ事情は最大限勘案する
⁃ ユーザの仕事のスケジュールを見て投入タイミングを決める
⁃ リリース時期が合わずに1月半に渡ってブランチをメンテし続けた
ことも

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
アジャイルとMoving Target
 なぜターゲットは動くのか？
⁃ そもそも人間は未来予測が苦手
• 現物を見てコメントする方が圧倒的に楽だし確実
⁃ エラー処理や失敗ケースが抜ける
• 見えてても、優先度低にしたが実は致命的だった、とかも
⁃ ツールを使って慣れてきたら、新しい課題・アイディアが出てきた
http://www.slideshare.net/hiranabe/project-facilitation-at-kanazawarb

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
ユーザが既存のやり方から新しいやり方に慣れる時間を見込む
 既存のやり方を捨てて(アンラーニング)、新しいやり方を学ぶ
⁃ 時間はかかる
⁃ イテレーションの枠内には行儀よくは収まらない
⁃ 今.netやJavaをやっている人が「明日からErlangで開発してね」
と言われて慣れるのにかかる時間とほぼ同じぐらい(のイメージ)
⁃ 使い込み初めてようやく出てくるフィードバックがある
⁃ 「経験」してから選択(朝の角さんの基調講演)
質問数
期間機能リリース
開発へフィードバック

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
アンラーニング
 弊社ファウンダーの南場さんの本に書いてあった言葉
 コンサルティングの方法論は自社経営では使えなかった
⁃ 一度知識を意識的に捨てて新たに学び直す

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
僕の開発のイメージ
http://www.city.nishitokyo.lg.jp/kurasi/kankyo/animals/dogs/inusoudan.files/situkekata.pdf

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
何を基準にプロジェクトを進めるか？
 計画ゲームやバックログで優先順位を一位に決めるのは可能か？
⁃ 今見えている課題(バグを含む)は大事
⁃ リストの中から、完成に向けて開発項目を選ぶのも大事
⁃ でもリスト化は無理かなと(後述)
⁃ 備忘録としてgithub:eのissuesは使っている
 人類に予測は早すぎるので予測に頼る割合を減らす
⁃ 人類の弱さにフォーカス（木下さんの引用した白本のまえがき）
⁃ とはいえ予測をゼロにして全バリエーション試すというのは無理
⁃ 「こうなるべき」という仮説を持ってシステムを実装してみる
• 変更した結果の反応を見て、また仮説を立てて実行する

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
開発のフロー
システムの
境界を決める
理想のデータ
フローを考える
ふつうのUIで
実装する
使ってもらう
フィードバック実装する
リファクタリング

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
まず仮説を立ててプログラムを作る
 まず最良のデータフローを作る
⁃ ユーザが何を入力して何を出力として欲しいか？は基本ブレない
• 外部システムなどから取得できる利用可能なデータなども安定している
• いつそのデータが手に入るの？はブレる可能性が高い
⁃ システム観点で最良のデータフローをまず考える
 UIに関しては21世紀のデファクトのパターンをまず実装する
⁃ アプリの見た目や画面、データの見せ方は変わる可能性が高い
⁃ 技術的に奇をてらっていない「ふつう」の方法で実装する
• ◯ Bootstrapを使ってウェブのUIを作る
• ◯ .netやQtを使ってデスクトップアプリ
• ☓ ターミナルエミュレータをブラウザ上に再現
• ☓ vimスクリプトでウェブサービスを叩く
⁃ いくら要望が強くても、テンキーだけで完結するようなシステムは
棄却する

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
仮説を元にしてプログラマが設計するのはアジャイルなのか？
 最初のリリースまでは手綱は自分で持つ
⁃ 枠組みを決定して、必要な機能のリストを絞り込む
⁃ その中の優先度はユーザにつけてもらうこともある
⁃ どのようなアーキテクチャでどう実装するかは自分で決定
⁃ スケジュールも自分で決めるが1ヶ月程度で動くものは作って出す
 それはウォーターフォールでは？
⁃ 土台だけは決めるがその上のワークフローや、ユーザ体験はユーザ
に使ってもらいながら作りこんでいく
• スクラップ＆ビルドも可能性としてはあるが、
コードを100%捨てることはない
⁃ デファクトのUIは作りやすい(ツールが揃っている)し、
ドメイン初心者の学習コストが最低になるので、やって損はない
⁃ 自社サービス開発だと仮説だけでは足りないかも

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
猟犬のメタファー
ハウンド
※視覚・嗅覚で
獲物を発見
レトリーバー
※撃ち落とした獲物
を回収
セッター
※射撃に最適な位置に獲物を
誘いだして固定
スパニエル
※獲物を広い場所に追い出す
写真はWikipediaの猟犬の項目から引用
ポインター
※獲物の位置を猟師に教える

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
ゴールへ向かわせる3つのフォース
 ユーザが思い描く理想のシステム
⁃ どちらかというと使い勝手の改善や重複作業の除去という観点
⁃ 現実ベース(ポインター)
 プログラマが思い描く理想のシステム
⁃ データフローやアーキテクチャの最適化の観点
⁃ 未来/仮説ベース(スパニエル)
 新システムを使って慣れてから出てくる要望
⁃ システムが持っていた隠れたポテンシャルを引き出す
⁃ 過去の仮説検証の結果(含むバグ)ベース(レトリーバー)

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
日々のイテレーションの注意点
 要求と一言で言っても、その出自がどこにあるのかを気にする
⁃ 期待なのか？
⁃ 希望なのか？
⁃ 現実なのか？
⁃ 不満なのか？
⁃ 仮説なのか？
 きちんと時間配分を行って仮説を検証(実装して提供)して現実を確認し
ていく
⁃ 1/3は仮説の検証に(未来)
⁃ 1/3は希望や期待を叶えるために(現在の計画)
⁃ 1/3は仮説を検証した結果上がってきた現実や不満の解消に(過去)
 要望を聞くよりも「こうやったらうまくいく」という提案が増える

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.
まとめ
 狩猟犬のメタファー
⁃ ターゲットは移動するが、移動範囲は絞る
⁃ まずスパニエル(仮説・一部新機能)を放ってターゲットがどちらに
移動するか観察する
⁃ ただし獲物の移動は時間がかかる。既存のやり方を
「アンラーニング」して新しい手法ベースで考えをリセットする
時間が必要
⁃ 少しずつ追い込み、逃げる方向を絞り込んでいき、そちらに
リソースを投入しトドメを刺す
 10%改善ではなく10倍改善のために時間をきちんと分けて投資する
⁃ 1/3は過去(リリースしたプログラムの不具合)
⁃ 1/3は現在(計画中のタスクの遂行)
⁃ 1/3は未来(将来の仮説のための新機能)