課外授業7日目"GIGSI" CASE OF CLASSMETHOD

Copyright ©Classmethod.inc All Right Reserved. 1

Date

http://classmethod.jp/

Title

Sub

Author

VersionVol.

"GIGSI" CASE OF CLASSMETHOD

おおはし　りきたけ

2013/4/23

1.0 1.0

～クラスメソッド開発ブログ課外授業 7 日目～


アジェンダ


アジェンダ

・クラスメソッドについて

・クラスメソッドブログでの情報発信

・プロジェクトを成功させるためには

・これからの SI のやり方

本日のアジェンダ


プロフィール

プロジェクトマネジメント / プリセールス / 営業 / 採用などを担当しています。

クラスメソッド開発ブログ課外授業の主催者でもあります。

大橋　力丈 ( おおはし　りきたけ）


クラスメソッドについて


クラスメソッド会社概要

社　名

代表者

設　立

本　社

資本金

従業員

U R L

事業概要

許認可

関連会社

クラスメソッド株式会社

横田　聡

2004 年 7 月 7 日

東京都千代田区神田佐久間町 1丁目 11番地産報佐久間ビル８階

46,100,000 円

50 名（パートナー含む、ほぼ全て社内勤務）

http://classmethod.jp/

・モバイルアプリ企画・開発・運用・クラウドアプリ企画・開発・運用・サーバーインフラ設計・構築・ユーザーインタフェースデザイン

一般第二種電気通信事業者JIS Q 27001:2006

アノテーション株式会社

2004 年 7 月2005 年 8 月2007 年 7 月2007 年 7 月2009 年 3 月2009 年 11 月2012 年 6 月

・東京都 BCP 策定支援事業（東京都支援）・短時間正社員制度導入支援事業（厚生労働省支援）・ワーク・ライフ・バランス推進宣言企業（新宿区支援）・平成 23 年度男性の育児・介護サポート企業認定　（新宿区支援）・平成 23 年度ワーク・ライフ・”ベスト”バランス賞受賞　（新宿区）・安全衛生委員会

・平成 24 年度東京ワークバランス認定企業　多様な勤務形態導入部門

高田馬場にて Java の開発会社として業務開始資本金 2,000 万円に増資ISO27001 取得高田馬場 2 丁目に開発室を増設資本金 4,610 万円に増資飯田橋へオフィスを移転秋葉原へオフィスを移転

沿　革

オープンな発想と高い技術力により　　　全ての人々の創造活動に貢献し続ける


クラスメソッドの歴史


　　　　スマホ＆クラウド期

クラスメソッドの歴史

2004

2005

2006

2007

2008

2009

2010

2011

2012

2013

RIA 期Java 期

■Java 期

　・ Java の業務システム開発や Struts のコンサルなどをやっていた

　・現場常駐での作業が主にメイン

■RIA 期

　・ Adobe Flex に注目し、 RIA(Rich Internet Application) 業界に参入

　・代表の横田が Flex User Group を立ち上げる

■ スマホ＆クラウド期

　・技術を AWS 、 HTML5 、 iOS 、 Android などにシフト

　・クラスメソッド開発ブログを開始


Java 期から RIA 期

Java から RIA

へ



■ なぜ変化する必要があったか　・現場常駐型の n次請け

　　　⇒本当のエンドユーザーの声が分かりにくい

　・当時 JSP での UI が酷かった

　　　⇒使い勝手が悪いシステム

■変化による効果　・直エンドにこだわることにより、エンドユーザーの声が聞けるようになっ

た

　・ Flex を利用することで、 UI の表現力が上がりシステムの使い勝手向上

　　⇒裏側は今までの技術を利用できた。 Flex と Java の相性は良かった



RIA から

スマホ＆クラウ

ド


RIA 期からスマホ＆クラウド期

■ なぜ変化する必要があったか　・ Flash/Flex以外に Ajax や Silverlight などの他の技術も発展してきたため、

　　競争力が高くなってきたところにスマホの勢いが半端ないことになった。

　

　・バズワード的にクラウドという言葉が出てきたが、実際に AWS に触れてみ

て

　　とてつもない可能性を感じた


RIA 期から色々期ＲＩＡ市場


RIA 期から色々期

スマホ＆クラウド市場


RIA 期から色々期

■変化による効果　・ AWS を絡めた SI が増えた

　　⇒ AWS の構築　＋　その上で動くシステム構築

　・ RIA 期からの UX を意識した開発はスマホでも継続して役に立っている


数字でみるクラスメソッド


数字で見るクラスメソッド

159.25



ここ 4 か月の平均稼働時

間3 月： 177 時間

2 月： 152 時間

1 月： 155 時間

12 月： 153 時間



19



３月のプロジェクト数開発人数： 35 名

PJ最少： 1 名

PJ最大： 10 名

PJ 平均： 3 名



1331



ブログの記事数2013 年： 304

2012 年： 519

2011 年： 508


なぜ情報発信を行うのか？


クラスメソッドの営業スタイル

インバウンド営業


インバウンド営業

■Java 期

　・知り合い経由

■RIA 期

　・ Flex Use Groupe 、メディアに記事を書く

　　⇒アーリーアダプターかつ実績多数なので問い合わせが常にあった

■ スマホ＆クラウド期

　・ AWS 、 HTML5 、 iOS 、 Android 全てにおいて後

発。。。。

じゃあどうする？


クラスメソッド開発ブログ

情報発信！


ブログの効果

■ よかった効果　・仕事の問い合わせが増えた！

　・採用の問い合わせも増えた！

　・会社の認知度も上がった！

　・お客様にも「ブログ見てます！」と言われて会話が弾むようになった！

■ 課題　・フロント系の技術記事の人気が高いので、フロント系の会社だと思われが

ち

　　　⇒「えっ！御社サーバーもやってらっしゃるんですか？」といわれるこ

と

　　　　　も。。。


ノウハウの公開

■良く聞かれる質問

「あんなにノウハウ公開して大丈夫ですか？」■回答

ノウハウを隠しそれを売りにできる時代ではない

技術の進化スピードが速いので隠しても意味ない

色々なノウハウを持っているんだと

知ってもらうことが重要


開発サイクル


悪い開発サイクル

定時で帰れない

技術調査する時間がない

日々業務に撲殺されてい

く

良くわからない案件を

受注

見積もりも曖昧だしハ

マる


クラスメソッドの開発サイクル

定時で帰れる

技術調査ができる

会社ブログにアウト

プットとする

顧客から問い合わせが

ある

実績ある技術なので見積もりしやすく、ハマりにくい


なぜ悪い開発サイクルになってしまうのか

・安い値段

・無理なスケジュール

・技術的な不安

・丸投げ

・人月の神話


受託あるある

■ 安い値段受託をやっていると、要員の空きを埋めようとし、空いているなら安い値段の案件

でも受けがち、安い値段で受けてしまうのと、受注のため焦って取ってしまいリス

クの検討などもしないまま受注結果的に大赤字に。。。

■ クラスメソッドでは・値段が合わない案件はそもそも乗らない。（我慢が必要な時もある）

・受注時にしっかり準備を検討する


受託あるある

■無理なスケジュール　○○月リリースですという無理なスケジュールでプロジェクトを始めてしま

う。元々無理なスケジュール（残業、土日出勤あたりまえ）で進めているので、

スケジュールにバッファがなく結果としてデスマーチに

■ クラスメソッドでは・そもそもスケジュールは本当に死守？

・現実的なスケジュールをしっかり説明し、納得していただく。

　⇒死守と言われお断りした後に、結局スケジュールに間に合わなかったんで

　　どうにかなりませんか？という問い合わせもあったりする


受託あるある

■ 技術的な不安技術的な検証をせず不安を抱えたままプロジェクトを始めてしまい、技術的な

課題にはまってしまい予定外の工数がかかってしまう。最悪技術の変更もある

■ クラスメソッドでは・新しい技術については、調査しブログに書く

　⇒結果的にその技術でお客様から問い合わせをいただくことも

　　⇒把握している技術のため技術的なリスクが無いまま始められる

・受注前に技術検討を行う


受託あるある

■丸投げ上流工程だけやって、あとは外注に丸投げ。結果品質の悪いものが返ってきて、

結局自社でリソース投入。結果自社でやり直し大炎上

■ クラスメソッドでは・外に投げない

　⇒すべて内製で行っている。


受託あるある

■ 人月の神話人を入れればどうにかなると思いがち。プロジェクトは人がいるだけでは終わ

らないので、できる人に負荷がかかるだけ

■ クラスメソッドでは・身の丈に合った規模の受注

・少数精鋭で効率化


プロジェクトを成功させるために


プロジェクトを成功させるためには？

プロジェクトの

成功確率を上げ

る



どうやって？



営業契約

管理設計

要求管理実装

自動化技術選定

開発プロセス

コミュニケーションやりとげると

いう意思

調達

品質

スコープ調整費用

手段は沢山


どこで成功確率を上げる？

受注前私見ではここで 8割決まってい

る


見積もりの流れ

発注者営業

管理者

エンジニア

①見積もり依頼

③見積もり

④見積もり確認依頼

⑤見積もり確認

⑥見積もり提

出

⑦見積もり提出 ②見積もり依頼


見積もりの流れ

発注者営業

管理者

エンジニア

①見積もり依頼

③見積もり

④見積もり確認依頼

⑤見積もり確認

⑥見積もり提

出

⑦見積もり提出

この時点でエンジニアの頭の中にある前提が明記されていないことが多い

②見積もり依頼


見積もり時の注意点

■ 注意点　・機能毎の見積もりは、バッファ積みがち

　・プランニングポーカーは、その場の空気感大切

　・営業時からエンジニアと一緒に進めていく


見積もり時に決めておくべき前提条件

１．見積もり範囲について

２．見積もり対象外範囲について

３．使用技術

４．開発プロセス

５．プロジェクト期間

６．要件

７．プロジェクトの運営方法

８．インフラ／開発機

９．テスト

１０ .納品物

詳しくはココ

http://dev.classmethod.jp/project-management/systemdevelopment-precondition/

http://dev.classmethod.jp/project-management/systemdevelopment-precondition/


クラウドという武器


AWS とは

○インフラを貸し出すサービス (IaaS)　・データセンター、ネットワーク、ハードウェアまでも仮想化でき

　　既存 OS の環境を利用することが可能

○先進性と事業継続性　・クラウド事業者としては最先発

　・ Amazon自体の事業も好調でサービスも継続と成長が見込まれる

○コミュニティーも活発　・ JAWS-UG(AWS User Group Japan) といったユーザーグループも活発


AWS のサービス一覧

No サービス1Amazon Elastic Compute Cloud (EC2)2Amazon Elastic MapReduce (EMR)3Auto Scalling4Elastic Load Balancing (ELB)5Amazon CloudFront6Amazon Relational Database Service

(RDS)7Amazon DynamoDB8Amazon SimpleDB9Amazon ElastiCache

10AWS Identity and Access Management (IAM)

11Amazon CloudWatch 12AWS Elastic Beanstalk13AWS CloudFormation14AWS Data Pipeline15Amazon CloudSearch 16Amazon Simple Workflow Service (SWF)17Amazon Simple Queue Service (SQS)18Amazon Simple Notification Service

(SNS)

参照：http://aws.amazon.com/jp/products/

No サービス19Amazon Simple Email Service (SES)20AWS Marketplace21Amazon Route 5322Amazon Virtual Private Cloud (VPC)23AWS Direct Connect24Amazon DevPay25Amazon Simple Storage Service (S3)26Amazon Glacier27Amazon Elastic Block Store (EBS)28AWS Import/Export 29AWS Storage Gateway 30AWS サポート31Alexa Web Information Service 32Alexa Top Sites 33Amazon Mechanical Turk34Amazon Redshift35Amazon Elastic Transcoder

これだけのサービスがあるのは AWSだけ！

http://aws.amazon.com/jp/products/





AWS とオンプレ

オンプレのものを、そのまま AWS に置き換えるだけでは、 AWS の価値を

発揮できているとは言えない。

単純に比較したらオンプレの方が安く済む場合もあるし、 EC2だけ単純に

比較したら他クラウドのほうが良い場合もある。

AWS はオンプレの置き換えではなく、別の軸で検討

オンプレ脳では AWS のポテンシャルは発揮できない、

クラスメソッドでは AWS専属チームを作った


クラウドという武器

■AWS利用時の注意点　・ EC2だけが AWSじゃない

　・オンプレ脳では AWS は扱えない

　・ AWS の進化スピードは、速いので片手間ではできない


これからの SI


開発の現状

ラーメン好きですか？


ラーメンはどこで食べる？

■昔のラーメン　・中華屋

　・屋台

■今のラーメン　・中華屋

　・屋台

　・カップラーメン

　・袋入り麺

　・ラーメンチェーン店

　・ラーメン専門店

減っている

増えている


システム開発に置き換えてみると？

■旧型 SI 　　・中華屋

　・屋台

■ ユーザー利用型　・カップラーメン：パッケージ

　・袋入り麺： Saas

■ 新型 SI　・ラーメンチェーン店：早い！安い！十分満足！

　・ラーメン専門店：ユーザには作れない。特化している！美味しい！

ラーメンもシステム開発も選択肢が増えた


開発の現状

旧来の SI は減っている。

これからは何処に軸を置いて

SI をやっていくか

クラスメソッドは、スマホ＆クラウド

特化型の SI としてやっている


まとめ


まとめ

・小さい企業が生き残るためには圧倒的な何かが必要

　　⇒クラスメソッドの場合は、「情報発信力」

・エンジニアがどんどん営業にかかわろう

　　⇒１枚岩でやらないと成功しない

・ AWS はオンプレの置き換えではない

・ SI は、減っているけど無くならない

　　⇒危機感があるなら変化しましょう。

Copyright ©Classmethod.inc All Right Reserved.

Documents

課外授業7日目"GIGSI" CASE OF CLASSMETHOD