エンジニアの技術力ってコーディングとかだけじゃ無いよね

昨日こんな酒を飲みながらエンジニア仲間の佐藤さん（仮称）と話をした雑談です。
たまにはGoogle関係無い話もしてみます。

以前一緒に仕事してた田中君（仮称）についての論評だったのですが、
佐藤さん曰く、非常に技術力があるんだけどなぁ、という評でしたが、僕的には違いました。
というか、「技術力」ってものの定義の違いかもしれませんが。

田中君は、技術力の中でもコーディング力や新しい技法やフレームワークに対する対応力は非常に優れて居ました。確かにそれだけを持って技術力が高いと言う見方もあるかも知れないのですが。
僕的には、技術力ってのはアウトプットというか他者と調整して技術自体が活かせる形に持っていかないと意味が無いのでそれも含めての技術力という考え方を持ってます。
残念ながら田中君は、狭義の技術力は非常に優れていたのですが、それを展開したり、自分が作ったものの意義を周りに理解してもらったりというところがあまり得意でないようでした。
新しいプロジェクトで使う新技術を習得して展開するというところの中で活躍してもらってたのですが、複数のオプションの中で彼の作成したものが採用されなかったということで、結果的にプロジェクトを離れてしまったのでした。

これは僕の反省でもあり、もっとうまく活かせるように出来れば良かったのになぁと言うところもあるのですが。
技術者としての能力として田中君についても、せっかくなのでもっと他の部分も伸ばせて行ければいいのになぁと思ってたんですよね。

昨日酔っ払った上でのたとえですが。仮に「計算能力」というので例えると。
暗算で四則演算がものすごい速度で出来たとしても（私もそろばんやってたのでそこそこ出来る）、国語能力ゼロだと小学生の算数も解けないんですよね。
A君が1000円持って買い物に行きました。100円払ってお釣りが・・・・って問題文があった時にそれを解釈する能力が無いとたとえ暗算で3桁×3桁の掛け算が一瞬で出来ても全く意味ありません。
同様に、「技術力」ってのもコーディングや新しいものの理解だけでなくそれを外部に伝えたり、プロジェクトの状況や達成したいことに合わせてフィットするように適用したりとか、いろんな能力が必要になってきます。

そう言った意味で、技術者の人にもコミュニケーション能力とか、国語とか英語とか、コーチングとか、デザインとか、周辺の能力も是非磨いてもらいたいなぁと思った次第。

難しいこと書いたな。。。

apps-gaeのお薦めコンテンツ

さて、今回は弊社で運用しておりますapps-gae上のお薦めコンテンツをご紹介したいと思います。

○EC2とGCEのDisk I/O比較
必読です！
色々なインスタンスタイプ別に調査してみました。
結構たくさんデータを取ったので、時間がかかりましたが、非常に面白いと思います。
この結果からすると圧倒的にGCEの方がお薦めと言うことになります。

○Google App Engine Modules のScalingを試す
24時間までは正しく動くことを確認しました。バッチ処理等でもまぁ十分な時間動かせると言うことのようです。


○たった1つのCloud SQLインスタンスで複数のWordpressを動かす
まぁ要は複数のGAE環境から1個のCloudSQLインスタンスだけを使って複数サイトをホスト出来るか、というところです。
GAE部分はある程度までは全て無料で1個のCloudSQLにだけ費用を払えば良いので、非常に安く運営出来そうです。SEO的にも良いので弊社は今後色々WordPressOnGAEでサイト展開していこうかなと思います。apps-gaeもGoogleサイツで今ひとつ見栄えとかがしっくりこないので、WordPressOnGAEにしてしまおうと思っています。

○Google App Engine コンソールの小技
これはGAE使って開発されている方は必読というか、必須のツール作りました。
是非入れてみてください。

○GAE負荷テスト その２「吉積情報株式会社の旧トップページ」
弊社のコーポレートサイトのトップページを無料範囲でどれだけ表示出来るか、という検証です。
結果、15万PVくらいはイケそうと言うことで。1日あたりなので大概の企業のコーポレートサイトはこちら（GAE）で良いのでは？と思います。

○Datastoreモデル変更の影響調査
Datastoreのモデルにプロパティを追加、削除したりした時の挙動を詳細に調査してみてます。ちょっと難しめですので、開発を真面目に検討されてるSEの方のみ向けかなと思います。

いかがでしょうか？
結構色々と調査してます。一応目指しているのは昔非常にお世話になった、「おら！オラ！Oracle － どっぷり検証生活」です。

今後も順次記事は追加して行きますので、是非チェックしてみてください。
何かこれを調べて欲しいとかのお題もいただけると嬉しいです。

業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その2

『業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1』の続きですので、未だお読みで無い方はまずそちらをお読みください。

インフラに関わる費用としてざっくり以下がありますが、このAについてはお話しました。
>A.インフラ自体の購入・保守サポート費用
>B.上記の組み上げ・保守費用
>C.運用管理設計、導入費用・保守費用

Bについて書きますと。
ここはまさにSIerの構築ノウハウをベースに、必要な性能を達成させるべく購入した製品を組み合わせ、設定して、テストする、という一連の作業になります。EC2とかIAASのサービスを使っても通常このレイヤの作業は必要になります。
確かに、昔は（10年くらい前とか）色々なサービス毎に異なるSLAを設定し、それぞれに適切な構成、というのがあったしそうする意味もあったのですが。
ここ数年で言うと、業務システムに求められる要件て同じで、私がインフラ構築を提案する時にふと全く同じ事をしていることに気づきました。

簡単にいうと以下のようなものです。分かる人だけ分かればいいですが。
VMWareをベースにブレードを並べてリソースプールを作成して、DBサーバだけ別途4Uくらいのを購入、ストレージはそこそこ高価なものにしておき筐体単位でのバックアップは基本取らない（お金に余裕があれば2台構成にしてDR）、代わりに筐体内では全て冗長化される構成のストレージを購入。
DBMSにOracleを入れ、ストレージの機能との組み合わせでスナップショットを取って、テープにゆるりとバックアップしていく。
監視は監視サーバ・MWを入れて、JP1等を入れてスケジュール連携する。

これ、ほぼ全く同じで無いですか？
また、ここに関わるコストも馬鹿になりません。監視サーバとかJP1とかってそれなりに高価ですし、ストレージの冗長化とかの設計とかストレージの論理領域を切ってもらったり、ストレージの冗長化とかってびっくりするほど高価なSI費用を請求されます。（特殊技能だからでしょうけど）
繰り返しになりますが、これもGAEだと不要です。


私は行くプロジェクト毎に毎回9割方同じ設計書を書いて、ベンダーさんに組み上げて貰ってテストして。。。。
ばかばかしい、と。
このレイヤに価値がある時代は終わりました。
システム（インフラ）に求められる要件は、
-止まらない
-データなくならない
-スケーラビリティが確保されている
-セキュアである（データを持って行かれない）
-アプリの変更が容易
これで全てだと思います。皆ほぼ同じです。で、既にそのインフラはあるのです。
GAEではこのレイヤも全く必要ありません。これがEC2等の通常のIAASと大きく異るところです。


Cについて
監視やバックアップの仕組み、またそこで障害発生時やパッチ適用時に発生するコストです。
ここについては、GAEでもある程度（構築部分以外の運用）は必要になります。

運用って例えば、1回何らかエラーが吐かれたとしたら、
その調査を行い、再現性があるのか無いのか、リスクは？等の判断をして、対処の優先順位（対応しない）を決めて、
他の仕様変更とかと合わせてリリース計画を立てて、利用者側に告知して、（場合によっては夜間）リリース作業する。
という流れを全て調整してやってかなきゃいけませんが。

が、インフラレイヤの障害に対応する必要がほぼなくなりますので、その分まるまる対処必要無くなります。
実際、3年くらい全くノータッチで動いているものも弊社の管理している中にはあります。（そのぐらい通常システムでもあり得ますけどね）

まぁその部分はそれほどGAEと他とで違うってことは無いように多みます。
逆にAPIにはある程度依存するのでその変化の速度等が通常の枯れたフレームワーク等と比べると多いかも知れないので、それには対応する必要があります。
そこの点は敢えて書いておきますがデメリットになり得ます。

とは言え、総じてA,B分のコスト減がかなり大きいので、私としては構築難易度やAPI等の変更の速度が早いことに対する対処はプログラム上の工夫でかいけつしてしまって、インフラレイヤ迄クラウドで吸収する、という形で圧倒的な低コストが実現出来ると考えて居ます。

以上、インフラのコンサルタントとしての視点から見たGAEで安くなる理由でした。
次回は、apps-gaeの興味深い記事について私の目線から幾つか紹介させていただこうと思います。

業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1

先週書いた、『GAE（Google App Engine）での費用見積りについて：業務システムの場合』という記事が非常に好評を頂いたようで、アクセスが急増しました。
ありがとうございます。今後も出来る限りの内容を公開して、GAEでの業務アプリ開発を盛り上げて行ければなと思います。

さて、本日はその記事中でも触れた、表題のお話をしたいと思います。
私のこれまでの経験上、インフラの費用については大きく分けて以下の３点を考慮する必要があります。

A.インフラ自体の購入・保守サポート費用
　→HW/MW/OSの購入代金と保守サポート費用です。当然ですね。

B.上記の組み上げ・保守費用
　→上記を業務要件に合わせた形で組み上げて、テスト含めて動作・保証する費用です。SI費として計上されることが多いですが、しっかりテストすると結構馬鹿になりません。

C.運用管理設計、導入費用・保守費用
　→バックアップ・リカバリや監視等の仕組みを構築、導入し、障害時の切り分けルールやワークフロー等を整備し、それを運用して行く費用です。
　　これには、障害レベル・レイヤ（HW層、データセンタ層、OS層etc）に応じたワークフロー定義や障害が発生した際にどこまで検証するのかなどの定義とその都度の確認等の時間も含まれます。

ざっくり私の感覚で分けるとこんな感じになります。
一口に「インフラ」と言うと広義にはフレームワーク定義や実装とその業務システム開発チームへの展開まで含めて呼ぶ場合もありますが、ここでは実行・開発・運用環境を担保する、という所までとしておきます。

ここにおいて、個別にGAEとオンプレとでの費用イメージを比較して行きますが。
私のざっくりしたオンプレでの費用感のイメージは非常に大雑把ですが、
A:B:C=5:3:3　くらいの感触です。
（値引きをどこで頑張るかとか、何年運用するかによってもかなり誤差がありますが）

1点目のAについて、まずはGAEにおいては初期の購入費用は全く不要ですね。ここが非常に強調されるところでもあります。

業務システム開発においてどのようなHWを用意するかというと。
まず、通常のオンプレのシステムの平均CPU利用率なんかは10%を切るのはザラであります。ある程度見積りがうまく行ったとしてもシステム屋さんの考え方だと40%を超えるともう追加が必要という認識に至ります。最近は仮想化前提としても4割を超えるとリソース追加しようと言う話が出てくるはずです。要は必要なリソースの何倍かの箱を用意するということになります。
また、業務システムにおいては冗長構成を取る部分に非常に費用がかかります。
余剰な性能の担保＋冗長構成が必須、の2点を考えるだけでどれだけAの費用が業務システムで過剰に必要になるかがわかると思います。
GAEは利用した分だけしか請求が来ません。冗長化についてのコストはその中に完全に含まれていますが、おそらく全体で共同担保しているという設計の関係上個別に見たらほぼゼロに限りなく近いレベルの冗長化コストなのでは無いでしょうか。

また、ここで運用設計とも絡んで来ますが、仮想化してリソースプール化するのは良いのですが、考えなきゃイケないのが稼働のインスタンスをどのように分割するか、です。
一般的に業務システムにおいてはその責任分界を非常に厳密に仕切りたがることが多いです。作る所管が違うとなおさらです。なので、非常に小さなリソースしか必要無いシステムでも責任分界上そのまま別のOSである必要が出てきます。（Tomcatあいのりで全然良いじゃん！ってものでも）
仮想化して気軽に出来るようになってるので、なおさらその傾向は高いと思います。
そうすると必要になってくるのが、じゃぁそのOSは誰が管理すんの？パッチ誰が当てるの？という話です。
GAEでは勿論いくつでも必要に応じてapp-idを作れますが、そこに付随する追加コスト（運用保守料）は一切ありません。何ならapp-idを分ければ分けるだけ無料枠が増える格好になります。

ちょっと長くなって来たので、B,Cの観点については次回にしたいと思います。

ちなみに、GAEの無料枠でどこまで使えるのか、という記事がapp-gaeにあります。

引っ越しました！八丁堀と新富町の中間

少し遅くなりましたが、先月引っ越ししました！

新しいオフィスは以下の広さです。奥に見えるのが入り口でワンフロア丸々です。

新富HJビル4F

上記の写真の左奥側から撮ったもの。

 皆様遊びに来てください。
年明け迄には会議室を作りたいなぁと思ってます。

以下、丸3年お世話になった銀座オフィスを最後に。Paulにはまた行きますが。

取り敢えずこの新しいオフィスで30人超までは頑張るつもりです。さて、何年で出て行かざるを得なくなるのか。

GAE（Google App Engine）での費用見積りについて：業務システムの場合

GAEの導入にあたって良くある質問の費用見積りについてです。

弊社で良くやる方法でして、これが100%ではありませんが概ね問題無いというものですが、
参考になればと言うことでまとめてみます。

まず、前提としては業務システムであるということで、特徴として。
-ユーザ数は少なめ
-利用量は人・業務によって多かったり少なかったり幅広い
-可用性は結構必要
-アクセス時間は結構偏る

という所が言えると思います。

この場合に弊社でGAEの利用料を見積もる場合には以下のステップで行います。

1. 業務毎に仮の業務量を調べる勤怠登録は修正も想定して一人が必ず1日1.3回（月30回とか）、管理者は月に2回DLを行う。
2. 各業務をこなすのに必要なトランザクションを仮置きする
   例えば、勤怠の1回の登録するにあたり全てAJAX通信で書き込み3回、読込5回とする。
3. 上記トランザクションあたりのDataStore ReedとWriteを仮置きする
   これはモデル設計にもよりますが、1transあたり10回とか20回とか、そういう数字になると思います。
4. 上記をベースに1トランあたりのオンライン起動時間を見積り
   1処理あたりのmsecを概算する。
5. 1業務あたりのデータストア量を見積もる
   これはメインのデータ量平均に対して3～5倍くらいを見ておく（Indexやログ等）ようなイメージです。
6. 保存期間の仮置き
   無限に保存するとすると無限になってしまうので、取り敢えず直近2,3年でみた時、とかそういう形で定時することが多いです。
7. 個別要件での調整
   例えばメール送信システムの場合はメール送信数が跳ね上がるのでそれは個別に盛り込みますし、SearchAPIやCloudStorageについては別途見積ります。
8. 上記に課金額を入れて計算
   細かい所は省きますが、後は上記で見積もった量に対して課金額を入れて行きます。
9. ざっくりその他を倍から3倍として乗っけます
   データDL量とか色々他にもあるんですが、それらはまぁ上記の見積りの倍から3倍って所でまずはざっくりといってしまいます。ここを精緻にやるのは神様でも無理でしょう。
10. これまでの経験、近しいシステムの現況と比べての微修正
    ある程度近しいPVとか想定される業務に近い既存システムとユーザ数や業務数等を考慮してマスで一応大きく違わないかチェック・微修正を行う

結局これまでの経験からはFrontEndの時間、DataStore Read/Write数、DataStore量、DLデータ、あたりが大半の課金金額を締めることになるので、主な部分を見積もって、それ以外は倍も行かないでしょうという経験則で出してしまいます。

勿論場合によってはもっと精緻にやってもいいでしょうし、稼働・テストしつつ見直しをするというのも時間と手間があれば是非やるべきだとは思います。

が、現実的には業務システムの場合上記で見積ると概ね相当低い金額になりますが、おそらくほぼそれで越えてしまうことは無い（概ね倍程度バッファ見てるので）ので問題にならないことの方が多いです。

以上、簡単ですが、当社で実施している見積りノウハウになります。

当社ではある程度ほぼ全てのシステムをIZANAMIフレームワーク化しているため設計・開発手法を似ているので、過去事例との比較がある程度容易・有意になる、と言った特徴があると思います。

こういった見積りだけ、などGAE導入の段階でお困り・お悩みの方へのサポートとして、当社でも『GAE導入支援サービス』として提供出来ますので、是非ご相談ください。


次回は何故GAEでのインフラ費用が通常（オンプレミス）より安くなるのか、ってところを考察してみようと思います。
→2013年11月25日公開『業務システムにおいてGAEでのインフラ費用が通常（オンプレミス）より安くなる訳：その1』

開発案件失注

先日、RFIの提示から約１ヶ月に渡り提案活動をして来た案件の失注が確定しました。
ブライダル業界の案件で、結婚したこと無いのでブライダル業界本を2,3冊読み込んで、
それなりに力を入れて取り組んだ案件だったので非常に残念です。

自分で直接お客様にヒアリングした上で自分で提案して負けたのは記憶にある限り初めてのことなので、その辺りも若干ショックでしたねー。
数すくないけど負けたこと無い、ってのは自慢だったので。
その反省も含めて記載しておこうかなと思いました。

RFI上は、以下のように読み取れました。
-業務理解が第一である
-実現性が無いとダメ
-同等の実現範囲の場合は価格が決めてになる

結論としては、価格が高い、ことがネックになりさっくり落とされてしまった感じです。
GoogleApps＋GAEでの非常に先進的な提案だった点は評価頂いたのですが。
この優先度を鵜呑みにしてしまったのが間違いだった、と。

やはり予算枠はあるわけで。何でもかんでも実現すれば良いということでは無いですよね、と。
まぁそりゃそうなんですが、今回はそこが少し気になったので、要件定義をしっかりやりたいという提案で良いか事前に確認したのですが、、、、
予算感もちゃんと確認しておけば良かったです。そこに向けてある程度前提事項を調整しないとダメだったなぁ、と。全然ずれた提案になってしまっていたと言うことのようで。
まぁでもオープンソースのパッケージをベースにしたカスタマイズってのと比べるとさすがに費用では勝てないわなぁ。。。

いやぁ、残念でした。ご協力頂いた皆様ありがとうございました。
また、採用された方のシステムが無事完成することをお祈りしております。

次回以降の反省として。