エフスタ in aizu...

「やっててよかったこの仕事」 と言えるようにやってきたこと

株式会社セカイネット 河野康隆

自己紹介• 名前：河野康隆（こうのやすたか）

• 株式会社セカイネット

• 主にGoogle App Engine / Javaでの

開発をしています。

• Facebook: kouno.yasutaka

略歴

• １８歳まで福島県郡山市で過ごしてました。

• ２７歳まで東京でSI系の会社に所属

• ～現在 仙台で起業

AGENDA1. 初日に発覚した危険な兆候

2. チームをひっくり返す

3. 短納期で開発するために

4. まとめ

注意事項• 他の方はマジメなお話の様ですので、すこし砕けた感じにしました。

• フィクションです。

• あえて悪役が登場します。

• 写真の人物はイメージです。

• 笑って聞いていただければ幸いです。

1. 初日に発覚した危険な兆候

２０１３年 １０月 プログラマの募集が来る

プロジェクトについて• 地震等の災害発生時に、職員の安否状況を報告・確認するためのサービスの作成

• マルチテナント・Webサービスとして提供する

• 災害時の急激なアクセス増加に対応するため、スケールアウトして分散処理を行う必要がある

面談に行ってみよう

プロジェクト参入時の前情報• Java EEによるWebシステムの開発 • 開発リーダーはJava EEの経験が豊富

• クラスタ構成の設計・製造ができる • 既存メンバーもJavaのスキルがある • 基本設計はほぼ終了している • 工数は２５人月程度の見込み

よくあるプロジェクトみたいだし問題無いだろう

いざ、参入！

※ 写真の人物はイメージです。

しかし、早くも初日に発覚する真事実

※ 写真の人物はイメージです。

参入後に発覚した事実：１

基本設計はほぼ終了している ← はずだったが

実質は要件定義書(5p)のみ

参入後に発覚した事実：２開発リーダーはJava EEの経験が豊富← はずだったが

以前にJavaでどんなシステム作ってたんですか？

……まぁ、いろいろと

フレームワークとか何使ってました？

……特には

Java書けます？

書いたりはしないかな※ 写真の人物はイメージです。

チーム・リーダー

なんか怪しい

参入後に発覚した事実：２既存メンバーもJavaスキルがある ← はずだったが

COBOL一筋２０年！

組み込みのCを数年

COBOLとVBを少し、Javaは１周間研修しました！

スキルがぜんぜん マッチしてない！

参入後に発覚した事実：２

全員HTMLやJavaのスキルがない！

参入後に発覚した事実：３工数は２５人月程度の見込み ← はずだったが主にやること

• ビジネス・ロジックの設計・製造 • UIのデザイン・実装 • 複数台のサーバーによる分散システム設計・構築 • サーバーの死活監視・運用方法の確立・文章化 • メールの一斉配信・受信 • マルチテナント対応

この工数で足りてるの？

参入後に発覚した事実：３

実質は予算から逆算した人月

工数は２５人月程度の見込み ← はずだったが

他にも、書けないことが多数…

なにより、問題なのは 誰も危機感を抱いていないこと

この状況を見て、感じました

デスマの臭いがする…

※ 写真の人物はイメージです。

デスマーチとは次のいずれかに該当するもの

1. 与えられた期間が、常識的な期間の半分以下である

2. エンジニアが通常必要な人数の半分以下である

3. 予算やその他のリソースが必要分に対して半分である

4. 機能や性能などの要求が倍以上である

※ Wikipediaからの引用

デスマーチとは

平たく言えば明らかに失敗しそうなのに、

継続している（せざるを得ない）プロジェクトのこと

初日にして、絶望

しかし

パンドラの箱の底には ひとつの希望が…

プ　　ロ　　ジ　　ェ　　ク　　ト

それは

まだ、何も作っていない！

昔、失敗したデスマ案件は、 プロジェクト末期で対処できなかった。

今回のプロジェクトは 始まったばかり。

これからの設計や管理次第で どうにかできないか？

面白い！

やってやろうじゃないか！

※ 写真の人物はイメージです。

2. チームをひっくり返す

とはいえ、今の自分に発言権はあまりない。

プロジェクト体制

←イマココ

プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

開発チーム・メンバー

A社

B社

C社

どう見ても外様です。 本当にありがとうございました。

と、諦めたら試合終了なので

プロジェクト体制プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

開発チーム・メンバー

A社

B社

C社

←イマココ

偉い人の信頼を勝ち取る 作戦を開始

作戦１：目的を確認する

ステークホルダーが 何を気にしているか確認する

A社のプロジェクト・マネージャーと相談

今回の案件で気にしてることって何ですか？

リリース後の運用とか保守だね。 あまり大きな体制はとれないから

あと、管理もアジャイルとか やってみたいんだけど、 経験がないから考え中だね

なるほど

A社 プロジェクト・マネージャー

※ 写真の人物はイメージです。

B社のプロダクト・オーナーに相談

今回の案件で気にしてることって何ですか？

３月にプレゼンやるから、 それまでにデモが出来るようにしてほしい

３月以外はなにかあります？

B社 プロダクト・オーナー

特に無いよ。逆にリリース日は 決まってないから少しくらいなら調整できるかな

※ 写真の人物はイメージです。

この情報を元に、 提案資料の作成を開始

作戦２：危機感を共有する

重要な問題点を 認識してもらう

B社のプロダクト・オーナーに相談

メンバーって全員Java開発要員なんですよね？

C社の営業さんからはそう説明うけてるけど

みんなJavaできないらしいですよ？

B社 プロダクト・オーナー

えっ？

ちょっと確認してみますか

※ 写真の人物はイメージです。

全員でJavaコーディング規約 読み合わせ会を実施

当然、ボロが出る

ちょっとC社営業と話してくる…

※ 写真の人物はイメージです。

A社のプロジェクト・マネージャーと相談

スケジュールについて、確認したいことが…

どうしたの？

過去の経験からみて、スケジュールに かなり無理がありそうです

…わかった、確認してみる

根拠だけでも確認してもらえませんか？

A社 プロジェクト・マネージャー

※ 写真の人物はイメージです。

２時間後

なんの根拠もなかった

※ 写真の人物はイメージです。

そして

プロジェクトは序盤で早くも緊張状態に！

これで次の作戦の 土壌が整った！

※ 写真の人物はイメージです。

作戦３：解決策を提案する

ひとしきり問題共有した ところで

今後の方針について 検討しよう

A社 プロジェクト・マネージャー

※ 写真の人物はイメージです。

待ってました！

今回の要求に合わせて 提案書を用意しました

※ 詳細は次章で説明します

※ 写真の人物はイメージです。

その結果

それをベースに進めよう

※ 写真の人物はイメージです。

そして、体制も変化

プロジェクト体制プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

開発チーム・メンバー

A社

B社

C社

プロジェクト体制プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

開発チーム・メンバー

A社

B社

C社↑イマココ

アーキテクト

その時、事件が

メンバーを残して まさかの 出社拒否

C社 チーム・リーダー

※ 写真の人物はイメージです。

しかし

これはチャンス！

よろしければ いいリーダー 紹介しますよ

※ 写真の人物はイメージです。

自社メンバーの参入に成功

※ 写真の人物はイメージです。

プロジェクト体制

↑イマココ

プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

開発チーム・メンバー

A社

B社

C社

アーキテクト

New! →

しかし、また事件が

開発メンバーも 全員撤退させます！

※ 写真の人物はイメージです。

その結果

プロジェクト体制

↑イマココ

プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

A社

B社

開発チーム・メンバーC社

アーキテクト

New! →

プロジェクト体制

↑イマココ

プロジェクト・マネージャー

プロダクト・オーナー

開発チーム・リーダー

A社

B社アーキテクト

New! →

……

ひっくり返しすぎた？

※ 写真の人物はイメージです。

3. 短納期で開発するために

長い前振り失礼しました

ここからは わりとマジメな話です

コントロール権は得ましたが、まだ、不安要素が山積みです

現状の主な課題

1. 開発・運用コストを減らすための検討

2. 開発メンバーの調達・教育

3. ３月までにデモができるようにする

4. 短納期だが品質は落としたくない

不安を解消するために リスクを取る

課題１：開発・運用コストを減らす

方策１：PaaS / IaaSを利用する

初期段階の構想とか要求とか• サーバーのホスティングサービスを利用する

• 耐障害性等を考慮してクラスタ構成にする

• サーバーの死活監視等が行える

※ ただし、インフラエンジニアはいません。

サーバー構成のイメージDBサーバーAPサーバーロードバランサー

死活監視

時間も予算も無いんだよ

ぜったい無理！

なので

Google App Engineを使用する

Google App Engineの特徴

• 勝手にスケールアウトする

• 自動で複数データベース・サーバーに保存

• 同じ環境がすぐに、いくつでも作れる

• 使いやすい管理コンソールがある

なにより、自分たちが得意

インフラのことは 何も考えなくていい

が、実装できない機能も

それらはAWSを使用

AWSを使用して実装した機能

• 気象庁から地震情報を受信するための

FTPサーバー機能

• 携帯キャリアメールへの一斉配信

PaaS / IaaS を使用した結果

• インフラの設計・構築コストがほぼ０に

• 基本的に運用監視対象は

EC2インスタンス１つだけに

課題２：開発メンバーの調達

いろいろあって消えた３名分 メンバーを集める必要があります

方々に募集をした結果 Java技術者２名採用できました

メンバー教育の課題

• フレームワークと

Google App Engine データベースの習得

• HTML / JavaScript等のスキル不足

方策１：１周間ペアプログラミング

なぜ、１週間なのか

プロジェクト・マネージャーとの会話

ペアプロでやってみようと思うのですが…

作業効率が半分になりそうで怖いな。期間も短いし、リスクとれないよ

では、教育のために一週間だけやらせてください

A社 プロジェクト・マネージャー

※ 写真の人物はイメージです。

教育やレビューのコストとトントンなのかもしれないけど…

１周間ペアプログラミング• 参入後１周間だけペアプロする

• 教える側は、ツール、フレームワークの使い方や

なぜこのように作るのかなどの背景も

説明しながらコーディングする

• その人のクセや特徴を知る

• １周間で完了できるストーリー（機能）※を選択する

やってみた感想

チームに早く馴染むことができた

ドキュメントを読まされるより理解が早くて深い

コーディングの方針とかルールが共有できた

新メンバーのスキルレベルが分かった

１機能を通して作成の過程が見えたので、不安が減った

新メンバー 既存メンバー

なかなか好評

ペアプログラミングが 認められない場合に効果的

方策２：作業範囲の限定

新メンバーは HTML / JavaScript スキルが無い

勉強してもらう時間もない ペアプロもできない

ぶっちゃけ

JavaScriptを多人数で いじりたくない

なので

Javaでビジネスロジックだけ 作ってもらうことに

UIとビジネスロジックの分離UI : HTML / JavaScript Logic: Java

JSON-RPC

ビジネスロジックの呼出 ↑

メソッドを呼ぶだけ

ビジネスロジックの提供 ↑

メソッドを作るだけ

疎結合にすることで 作業をシンプルに

ログイン情報以外は ステートレスな（状態を持たない） 機能として提供する。

POINT

課題３：３月までに デモができるようにする

プロダクト・オーナーの要求

３月にユーザーが 実際に操作するデモを行う

プロダクト・オーナー

リスケは不可

デモで使用する機能に バグがないこと

※ 写真の人物はイメージです。

実際のリリース予定は５月なので ３月は開発の中盤となる

ウォーターフォール型だと ほぼ確実にできない！

プロジェクト・マネージャーが 前に言ってたこと

管理もアジャイルとか やってみたいんだけど、 経験がないから考え中だね

プロジェクト・マネージャー

※ 写真の人物はイメージです。

アジャイル開発で行こう！

Scrum？ XP？

……

経験者が一人もいない！

……失敗しそう。

なので、

プラクティスを一部だけ適用

開発イテレーション （１週間～２週間の期間）

���

• ���� �• ��'(�

���

• ���• �����• ��!1-87���

• PG/��.,0�• ��!�

��

• *.58+47/3�

&(#"(�

• �����• 26+.)�

• $%�� �

適用プラクティスNo� fjY`W]� $1�

1� 3*[og� ���?I2,V0:7%�X`lo\inH"��CS]bokoV(�CS8�

2� "�� '"rs�+�H7��PFE@I7��PS@I7�5V�!CS8�

3� OR=<R� X`lo\inL �K7X`lo\inK�CSOR=<RV0;8�

4� `]b/ �� JUnit-V�)B7`]bL/ �V0;8�

5� �DONE� ]bokoP^]YM�K��BG:J?TN��I2JAJ:8p&�#>9S��M7DL^]YM.UFG:J:q�

6� X`lo\inah� X`lo\inL �K7��BEfmZjgLahV0:7"6�=QLeWocd_YV�S�

7� r�t�4� &#BJ:8�

これだけ

大切なのは混乱しないこと

• 今、何をすべきか明確にする

• 今、出来る作業量を明確にする

• 今、どこまで出来ているか明確にする

• 今、対処すべき問題があるか明確にする

課題４：短納期だが 品質は落としたくない

品質を保つために

• テストの自動化する

• メンテナンスできるコードを書く

方策１: Spockの導入

JUnit 書くのスゴくダルい

ここがイヤだよJUnit

• 実コード以上に、読みやすいコードを

書くのが大変。メンテしづらい。

• パターンテストやデータ準備等の

凝ったテストを書くのが大変。

• 純粋に記述量が多すぎる。

中盤ダレてくるとJUnitを 書かない・手抜きする人が続出

そこで

Spockを導入！

Spockとは• Java・Groovyアプリケーション向けの

テスト・仕様フレームワーク

• 美しく表現力の高い仕様記述言語

• JUnitとして動作する。

既存のJUnitの機能は全て使える。

Spockによるテストコードclass Math extends Specification { def “２つの値から、大きい値を取得できること" { expect: Math.max(a, b) == c ! where: a | b | c 1 | 3 | 3 0 | 0 | 0 7 | 4 | 4 } }

条件ミス （cは7が正解）

Spockによるエラー通知２つの値から、大きい値を取得できること FAILED !Condition not satisfied: !Math.max(a, b) == c | | | | 7 4 | 4 false

Groovyの習得に関して

• Javaのコードがほぼそのまま動くため、

とりあえず、すぐ使うことができた

• なれてくると、Groovyらしいコードが

書けるようになり、コード量が少なく

見やすいテストが書けるようになった

本当にすばらしいので ぜひ実践してみてください

方策２: リーダブルコード読書会

しばらく開発していて 発覚した問題点

コードレビューの 成果が出ない

正しく動くけど、読みづらい、 変な設計のコードが増えていく

このままだと メンテできなくなってしまう

なので

読書会の方針

• 毎日、定時後に１章ずつ（一時間程度）

• 持ち回りで担当者を決めて、解説してもらう

• 読んだ章について、ディスカッションする

読書会の効果• 各メンバーが自分で読みやすいコードを

考えるようになった

• レビューの指摘の意図や根拠が

伝わりやすくなった

• 学習意欲の向上

4. まとめ

その後もいろいろな問題が 発生しましたが

残業やトラブルもなく 無事、５月末にリリース できそうです。

いろいろご紹介しましたが

やっててよかった と言うためには

積極的に動くこと！

役割に縛られる必要は無い

積極的に動くと 責任ばかり増えるのでは？

ダメだとわかってて 放置するほうが無責任

でも、がんばったって 給料は変わらないよ

仕事の報酬は お金だけじゃない

それは

信頼

次の仕事

悪い仕事は、信頼を質にしてお金を借りているようなもの

でも、失敗したらどうするの？

失敗したって 100%ダメになる訳じゃない

実際のところ 100%の成功も失敗もない

大事なのは連敗しないこと

プロジェクトの改善に 大鉈を振るう必要はない

最初から完璧を目指すと 大抵、失敗する

まずは、小さな信頼を 得るところから始めよう

ご清聴、ありがとうございました

写真素材についてこの資料は、ぱくたそ(http://pakutaso.com）の写真素材を一部利用しています。この写真を継続して利用する場合は、ぱくたそ公式サイトからご自身でダウンロードしていただくか、ぱくたそのご利用規約(http://pakutaso.com）に同意していただく必要があります。同意しない場合は写真のご利用はできませんのでご注意ください。