DevLOVE現場甲子園2015 東日本大会に行ってきました #devlove
DevLOVE現場甲子園2015 東日本大会に行ってきました。現場甲子園への参加はたぶん3回目。
ミッドタウンはとても綺麗でした！！！
テーマは4つありましたが、わたしはほぼSIの現場を聞いていました。
以下、聞いた発表
- [サービス] ベルク田向 選手『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
- [SI] 岩本 選手『ハラキリのない時代でよかったね。』
- [SI]石崎、西 選手「君が居て僕が居る マネジメントと開発メンバのDiffトーク（そして現場からは、誰も居なくなりそう）」
- [SI]TIS 川島 選手『週刊Webサイトのアーキテクチャ』
- [SI]ゼンアーキテクツ 岡 選手『俺の背中について来い』
以下めも
『受託開発の会社が自社サービスを開発・運営する中で見つけた自分たちにあったスタンス』
自社サービス board
請求書作成、見積書、発注書発行、販売管理・クラウド業務効率化ソフト board
受託と自社サービスの壁。
受託開発脳から自社開発脳へ切り替えの７つの壁。
いきなりはうまくいかないので、段階を踏んで行こう！
うまくいくには、並行している受託案件の安定化が不可欠。
創業社長がエンジニアの会社にありがち＝社長依存度が高い。
社長がいつまでも現場にいたら、会社が成長しない。とはいえ一気に抜けると、ダメになるから何年かかけて徐々に。
細かい進捗管理（朝会、日報とか）なし、めんどくさいし。ヤバイ！ってときにはちゃんと相談してもらえるように、メンバーとはリスク感覚の一致を重視してる。
boardは書類を作るだけじゃなくて、売上の見込みを把握する（経営者視点で設計・開発） 自分が使いたくて作っている。自分はこの機能を使うかどうか？という視点でいつも考えている。ドッグフーディング。
ドッグフーディングの落とし穴
自分たちに最適化しすぎる（オレオレ業務だとイケてない機能になる）
ドッグフーディングしたからといって、それが正しいとは限らない（疑わなくなってしまう）
システムや新機能を初めて見たときの感覚を失う（自分たちで、これが使いやすいか？などの感覚がなくなってしまう）
新規ユーザへの配慮を忘れがち（ドッグフーディングのなかでは気づきづらい）
小さいチームで素早く開発する。無駄なものを作らない。少し足りないくらいでリリースしてみる（これあったほうがいいよなーと思っていた機能をあえて追加しないでリリースしてみる）。意外と要望が上がってこないものもあるので、なくてもよかったんだなーってなる。
コミュニケーションコストを最小限に。企画と開発が同じなのでコミュニケーションコストがかからない（受託と比べるとここの違いはかなり大きい） 中途半端な関わりのメンバーはなくす。
他のタスクとの兼ね合い
受託と自社サービスを並行しているので、バランスが大事。受託が忙しいときは自社サービスは軽微な改善のみに。受託が手を離れたら自社サービスに注力する。
自分たちの適した進め方を自分たちで考える
受託で稼いだお金を自社サービスに投資している。ので、コストはかけられない（負のスパイラルに陥ってしまうため）必要なスキルの人を全部集めたら固定費が上がってしまう（サービスの継続判断がむずかしくなる）ため、できる限り自分たちでできるようにする。
受託も自社も大きな山を作らないようにする
→小さな会社で自分で見切れてるからできることだとおもう
２軸ではしらせている
小規模（１、２週間）と中規模な開発（１ヶ月）を並行してすすめていた。
それにより、素早い改善と機能追加のペースを維持。ユーザからも好評のよう。
正式リリースしてから１年間は、大規模な開発（３ヶ月）には手をつけなかった。
話し合って決めると中途半端になる気がしている。一番詳しい人が責任を持って一貫してきめる。迷ったときはもちろん相談している。
詳しい仕様は自分しか知らないまま、テスト担当のメンバーがテストを実施するので、ユーザビリティテストも兼ねているような状況になった。（想定していなかったけどタナボタ的な）そこでの気づきから機能を改修したこともある。
要望対応の判断基準
受託の場合は、エンドユーザから直接要望をもらったことがなかったので最初は戸惑った。最重要！なのは、自分自身がその機能を欲しいか。
つぎは自分が利用しない機能の場合は納得感があるか。
boardの方向性とあっているか。
会社ごとの独自ルールによる要望は断る。断れる勇気が必要。
開発ロードマップの開発
今この機能はないけれど、ここで追加されるのであれば、導入してみようかなって思うユーザもいる。
次の一年
開発体制の強化。
新規メンバーを採用するのではなく、受託の合間に各メンバーにやってもらうようにする。
サポート体制を強化する。
まとめ
受託と自社サービスのバランスが大事。
継続には固定費を下げることが大事なので最小限の体制の維持につとめる。
答えはないので自分たちにあったスタンスを探す。
ハラキリがない時代でよかったね
全身全霊全力
それまでのプロジェクトはウォーターフォールで失敗することが多かった。
肝に命じている言葉
「今まで出来なかったことは、やり方を変えない限りできない。」（スミセイ情報システム 小浜さん）
それまでの自分はお父さんだった。
メンバーにたまに関わるお父さん。
１週間に一回こんなことを聞いてる→進捗どうですかー、なんでできてないんですかー？
決意後のわたしはお母ちゃんになった。
逐一聞く→ご飯食べろ。勉強したんか。風呂入れ。
泥臭くなっていかないといけないんじゃないかってことでお母ちゃんになろうと思ったから。
アジャイル初めてだったんでインセプションデッキからやった。
メンバーとはどうも初めましての状態でやったんで、シーンてなるし内心どうしようと思いながらやってた。
初めてだったんでリスクを減らしていかないといけないなと思っていた
どうもコミュニケーションが大事そうだ。
委託先は場所が離れているので、上司を説得して
チームを呼び寄せた。
プロパーと業務委託席が分かれていた。
せっかく一緒の職場になったのに、席が離れていたんじゃ意味ない。
わたしが業務委託席に行った。
一通りの本はよんだ。
アジャイルサムライ
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ ←これどうしようーって困ったことについてだいたいのってた
などなどいっぱい
やらなかったこと
コーチにきてもらう。会社にお願いしたらお金も出してくれると思ったけど。
せっかくやし自分でゼロからやってみたかった。
どうしてもダメならお願いしようと思っていた。
いろいろやった！
朝会 good
朝会終了後、数人に別れて課題を話し出す。
固まっているとメンバーが寄ってくる。
神社 good
雑談しつつ仕事の話をして課題が出たりした
技術書はあんまりよんでもらえなかったので、読まざるものお菓子食べるべからずってしたら、
いつのまにか本そっとどかされてたw
ステッカーとか置いといたらみんなノートに貼ったりしてた。
そしたら、他のチームから見たら、なんかあそこすごいな。あのチームできる人おるんかな、ってエセ雰囲気が醸し出されてたみたい。
神社 bad
みんな体格がよくなっていったw
お菓子の買い出しが地味にめんどくさかった。
文化 good
山のようなwikiができあがった。
同じこと聞かれたら負け文化。
聞かれる前に「wikiにはもう書きました！！」
文化？bad
検証フェーズでバグが出ないw
検証チームはなんでバグが出ないかわからないけど、こちら側からすると結構単純なテストで出るバグは潰していた。
意地悪テストとかになるとバグは出てきたけど。
バグを出せない検証チームが上に怒られるというwやった！って思った。
環境をイマドキに 開発が進んでいくと、ちょっとした時間が取れないと思うので 思い切って改善担当？として一人置いた。
思い切って方向転換した。
大事なこと
どっちがわくわく？
あとで後悔しないか
自分を信じる（いろいろ言われるけど）
納得がいく判断をするのは大事
人の採用について偉い人との対決
あなたは採用に反対するけど、それだけではわたしの課題はなにも解決されない。
その人は少なくともわたしの稼動やグループやチームが困っていることに対して助けてくれる。
あなたはなにをしてくれるのか？
チャンスが来る
他のプロジェクトから相談が来る（プロジェクトの進行について）
組織改善
おもしろい
昔言われたこと→仕事というものは生活のもので楽しいはずない
アジャイル、devloveを知ってからは、仕事って楽しいんだって思った
越境し続ける。
半歩でも一歩でも進められるってのが当たり前になってきた。
diffをとるとdiffに気づく。ちょっとだけ頑張る。
このままでいたいか？ 安心安全のご時世。 所詮サラリーマンなので。 そう、切腹しろとは言われない。
君が居て僕が居る マネジメントと開発メンバのDiffトーク（そして現場からは、誰も居なくなりそう）
同じ現場で、マネジメント側と開発側をやっていたお二人でのトーク形式でした。 まさかのライトセーバーで笑ったwライトセーバーの不協和音がリアルだったw
或る日突然、スクラムをしろといわれたので、 とりあえず本を読み噂を聞きスクラムを始めてみた。 もともと、ウォーターフォールなんで課題がいっぱいあるとは思っていた。 なのでやらなくていいだろってものをなくすとか、課題を改善してきた。 それが課題を片付けていったら、することなくなった。成果が出なくなった。
やりたいやりたいで進めて拡げても、その背景にある想いとかを共有できていなかったら、 あいつやりたいから言ってるんだろってなる。
組織としての形とチームとしての形がちがう。
転換期
昔は何か変えようとすると反対勢力がおおかったけど、最近は半々くらいになってきた
開発部門の現場が変わってきた
変化を受け入れる
横断活動の活発化
クラス制度
→考える場を持つ。
やってもいいんだ！ってきもちになってきた
- ギルド制（仲間を見つけてチャレンジ！業務に関係ない）
- またぎの会（チームを超えた課題を共有）
- クラス会（全員集まって共有）
クラス会については、とにかくコストがすごかったと思う。。。でも、認識を合わせるためにはあれくらいのコストが必要だってことはわかった なにをやったら正解かということがわかっていなかったので。
組織の形を自分たちで考える
皆んなで見るものが変わった。
モノをみてしごとしていたけど、半年後、１年後の会社について考えるようになった。
開発だけじゃなくて運用、企画と横断的に会社の中全体に拡げていった。
会社の事業リストを見るのは当たり前だと思うけど、それまでに３年かかった。
事業的にどんな価値があるのか気になるようになった。
なんか目の色が変わった。
各チームのエース集結して世直しチーム結成した。
エース抜けた各チームはそれなりに苦労している。世直しチームはエースが集まっているので、すすむスピードはかなり早い。
スクラムのすすめ
- 現場がすげー活性化する
- できるやつから出て行く
週刊Webサイトのアーキテクチャ
ふつうの受託開発のやりかた 受託開発でアジャイルって難しいよね〜ってなることが多いと思うのですが、実際にやっています。 相当細かいマニュアルになっていると思うけど。
顧客のための最善とは？
最善を尽くさない理由
自分の知らなさ加減を把握してない（無知レベル）
技術系メーリングリストで質問するときのパターン・ランゲージ
新人が来たら、結城先生のこれを１００回読めって言ってる。
世の中のエンジニアにみられる傾向
今必要な知識しか欲しない
最善を身近にしよう
qiita.com
今、エンジニアランキングで24位。1位になりたい。
ブログいっぱい書いてるけど、趣味っていうか仕事のためにもなるから書いてる。
『俺の背中について来い アジャイルチームを一気に立ち上げる方法』
「俺の背中について来い」アジャイルチームを一気に立ち上げる方法
がちがちウォーターフォールの会社に、アジャイルチームを立ち上げる支援をしている。NAISEI build-upと名付けている。 固くて無駄が多くて古臭い開発のやり方を、いかに柔らかくしていくか 効果がありそうなお客さんのお仕事をしている。効果がなさそうならやってない。
社員は２人で、どうやってるのか？って聞かれることも多いのですが、その秘訣、本日初公開！！！
- まっさらな企業にアジャイルチームを立ち上げ（たのしいお仕事。じぶんたちでも助けなくいい感じにすすむ）←なのでこれはやってない。
- しがらみの多い企業にアジャイルチームを立ち上げる
→もともと中の人もアジャイルやってみようとしてたりするが、いろんな妨害をうけて最後くじけてやっぱアジャイルはだめだなと結論に至る。が、それはそのひとたちのせいじゃない。しがらみのせい。
→もはや、何と戦っているのかわからない。プロダクトを開発したいのに、目の前のおっさんと戦っている。アジャイルとは関係ない世界に昇華する。そしてくじけてアジャイル反対派に転向する。
→若者がアジャイルをはじめたいときに、反対するおっさんになってしまう。
→おっさんが増殖していく。
文化に馴染む形で一発で成功させないと、敵が増える。 ダラダラしてたら即終了。 垂直立ち上げが必須！ 潰してくる気満々なひとがいるから。
なので、必要なのは圧倒的な成功のみ（そこがハードルが高い）
開発プロジェクトの４種類のリスク
- スキルリスク
- 技術リスク
- 要求リスク
- 政治リスク
垂直立ち上げするには
- いつもの技術
- いつもの回し方
- いつものエンジン
→試行錯誤（リスク）を最小化
絶対に負けない確信を持って始める（ちょっと検討が必要、ってなったらやめたほうがいい）
顧客が一番欲しいものを最初につくってみせる、１スプリント（２週間）で、つくってビルドデプロイしてデモして見せてはじめて！ 反対してくるおっさんがゼロになる。 こいつできるのか？ →できそうだな →ほんとにできるんだな →なかなかやるじゃん →ミスしても多めにみてやろう ここまでに半年かかる
始める前に確信がないなら、その前にすることがある。
淡々と走り続けることが大事
感想
ミッドタウン、迷った。インフォメーションのお兄さんに、ミッドタウンのパンフレットもらった。
開会式で市谷さんが「diffを取ったらそれでおわりじゃない。現場を前進させる。diffをもらった相手？にはなんらかのフィードバックを返しましょう」ってお話をしていて、わたしもそろそろ前進するスピードを上げないとな、勉強会とかイベントに参加してるだけで満足してちゃいけないな、と思いました。
なんとdevlove甲子園への参加も3回目だし！！
今年の10月に異動したのですが、前の現場と今の現場にもかなりdiffがあるなーと思ってて（どっちがいい悪いではないです）とりあえず、今の現場には勉強会って文化がなかったのでそれをやってみようと思っています。（って来週わたしが第1回の発表をするんだけど） ←ブログ書くのが遅くなっちゃったから、昨日もうやったけどな！
うまく根付かせたいな。
川島さんのお話しにでていた無知レベルに、勉強会とかに出てくる前の自分と今の自分、今の自分と職場の人とを重ねてみて、そこにあるdiffについて仕事中もぼんやり考えてた。テストコードとかアジャイルとか、やってみようって人と、反対派な人と。
小さくても一歩ずつ。
