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

Copyright ©Classmethod.inc All Right Reserved.
Date
http://classmethod.jp/
Title
Sub
Author
VersionVol.
1
"GIGSI" CASE OF CLASSMETHOD
おおはしりきたけ
2013/4/23
1.0 1.0
～クラスメソッド開発ブログ課外授業7日目～

Copyright ©Classmethod.inc All Right Reserved. 2
アジェンダ

アジェンダ
・クラスメソッドについて
・クラスメソッドブログでの情報発信
・プロジェクトを成功させるためには
・これからの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万円に増資
飯田橋へオフィスを移転
秋葉原へオフィスを移転
沿革

クラスメソッドの歴史

スマホ＆クラウド期
8
クラスメソッドの歴史
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へ

Java期からRIA期
■なぜ変化する必要があったか
・現場常駐型のn次請け
⇒本当のエンドユーザーの声が分かりにくい
・当時JSPでのUIが酷かった
⇒使い勝手が悪いシステム
■変化による効果
・直エンドにこだわることにより、エンドユーザーの声が聞けるようになった
・Flexを利用することで、UIの表現力が上がりシステムの使い勝手向上
⇒裏側は今までの技術を利用できた。FlexとJavaの相性は良かった

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

RIA期からスマホ＆クラウド期
■なぜ変化する必要があったか
・Flash/Flex以外にAjaxやSilverlightなどの他の技術も発展してきたため、
競争力が高くなってきたところにスマホの勢いが半端ないことになった。
・バズワード的にクラウドという言葉が出てきたが、実際にAWSに触れてみて
とてつもない可能性を感じた

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/

クラウドという武器

AWSとは
○インフラを貸し出すサービス(IaaS)
・データセンター、ネットワーク、ハードウェアまでも仮想化でき
既存OSの環境を利用することが可能
○先進性と事業継続性
・クラウド事業者としては最先発
・Amazon自体の事業も好調でサービスも継続と成長が見込まれる
○コミュニティーも活発
・JAWS-UG(AWS User Group Japan)といったユーザーグループも活発

AWSのサービス一覧
No サービス
1Amazon Elastic Compute Cloud (EC2)
2Amazon Elastic MapReduce (EMR)
3Auto Scalling
4Elastic Load Balancing (ELB)
5Amazon CloudFront
6Amazon Relational Database Service (RDS)
7Amazon DynamoDB
8Amazon SimpleDB
9Amazon ElastiCache
10AWS Identity and Access Management (IAM)
11Amazon CloudWatch
12AWS Elastic Beanstalk
13AWS CloudFormation
14AWS Data Pipeline
15Amazon 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 Marketplace
21Amazon Route 53
22Amazon Virtual Private Cloud (VPC)
23AWS Direct Connect
24Amazon DevPay
25Amazon Simple Storage Service (S3)
26Amazon Glacier
27Amazon Elastic Block Store (EBS)
28AWS Import/Export
29AWS Storage Gateway
30AWS サポート
31Alexa Web Information Service
32Alexa Top Sites
33Amazon Mechanical Turk
34Amazon Redshift
35Amazon Elastic Transcoder
これだけのサービスがあるのはAWSだけ！

AWSとオンプレ
オンプレのものを、そのままAWSに置き換えるだけでは、AWSの価値を発揮で
きているとは言えない。
単純に比較したらオンプレの方が安く済む場合もあるし、EC2だけ単純に比較
したら他クラウドのほうが良い場合もある。
AWSはオンプレの置き換えではなく、別の軸で検討
オンプレ脳ではAWSのポテンシャルは発揮できない、
クラスメソッドではAWS専属チームを作った

クラウドという武器
■AWS利用時の注意点
・EC2だけがAWSじゃない
・オンプレ脳ではAWSは扱えない
・AWSの進化スピードは、速いので片手間ではできない

これからのSI

開発の現状
ラーメン好きですか？

ラーメンはどこで食べる？
■昔のラーメン
・中華屋
・屋台
■今のラーメン
・中華屋
・屋台
・カップラーメン
・袋入り麺
・ラーメンチェーン店
・ラーメン専門店
減っている
増えている

システム開発に置き換えてみると？
■旧型SI
・中華屋
・屋台
■ユーザー利用型
・カップラーメン：パッケージ
・袋入り麺：Saas
■新型SI
・ラーメンチェーン店：早い！安い！十分満足！
・ラーメン専門店：ユーザには作れない。特化している！美味しい！
ラーメンもシステム開発も選択肢が増えた

開発の現状
旧来のSIは減っている。
これからは何処に軸を置いて
SIをやっていくか
クラスメソッドは、スマホ＆クラウド
特化型のSIとしてやっている

まとめ

まとめ
・小さい企業が生き残るためには圧倒的な何かが必要
⇒クラスメソッドの場合は、「情報発信力」
・エンジニアがどんどん営業にかかわろう
⇒１枚岩でやらないと成功しない
・AWSはオンプレの置き換えではない
・SIは、減っているけど無くならない
⇒危機感があるなら変化しましょう。

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

Similaire à 課外授業7日目"GIGSI" CASE OF CLASSMETHOD (20)

Plus de クラスメソッド株式会社

Plus de クラスメソッド株式会社 (12)

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