エフスタ 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社

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等のスキル不足

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

なぜ、１週間なのか

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

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

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

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



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

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

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

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

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

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

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

やってみた感想

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

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

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

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

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

新メンバー既存メンバー

なかなか好評

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

方策２：作業範囲の限定

新メンバーは 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が正解）

Groovyの習得に関して

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

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

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

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

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

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

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

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

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

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

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

なので

読書会の方針

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

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

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

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

考えるようになった

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

伝わりやすくなった

• 学習意欲の向上

4. まとめ

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

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

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

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

積極的に動くこと！

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

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

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

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

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

それは

信頼

次の仕事

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

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

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

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

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

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

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

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

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

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

http://pakutaso.com

http://pakutaso.com

エフスタ in aizu...

Technology