クラウド時代のシステム開発

bohnen（草食系SA） @bohnen

セールスフォース認定上級デベロッパーというのになりました

bohnen（草食系SA） @bohnen

@marblejenka http://bit.ly/kLLN0a こんな感じ

bohnen（草食系SA） @bohnen

@ura_58_58 そうですね、管理者資格ではなくて開発者資格なので、たとえばJava認定試験と同じで、合格したから「で？」という感じだと思います。気にするお客様は気にするでしょうが、普通は開発者より成果物を気にするのではないかと。

Ryo Asai @ryoasai74

@bohnen セールスフォース関連のお仕事をされているのですか。なんか意外な感じもしましたが。それとも、今後は開発者としての基礎体力ということですかね。

bohnen（草食系SA） @bohnen

@ryoasai74 仕事です。開発が早いので、Scalaの勉強をする暇もできました :-)

bohnen（草食系SA） @bohnen

誤解を恐れずに言えばforce.comはクラウドプラットフォームになったAccess。AccessがWeb対応したときのあのがっかり感を覚えている人は、force.comを触ると「そうそうこうなって欲しかったんだよ!!」という感動が得られる

bohnen（草食系SA） @bohnen

Java開発者がforce.comを触るのは・・・個人的には最初の一週間で投げ出すと思う。なまじApexがJavaに似ているので、同じような「言語」だと思ってしまうけど、あれは別物。AccessのVBAに近い。

@ura_58_58

@bohnen なるほど、ありがとうございます。あと暗黒面というのが気になったのですが…？細かいところ気にしてすいません。

Ryo Asai @ryoasai74

@bohnen そうですね。SIer案件でAccessアプリをStrutsにするくらいなら余程低コストで高品質なアプリケーションを作れるでしょう。ベンダーロックインのところも似ていますが、まああそこまで広まってしまえばよいし、独自のだめアプリよりよいですね。

bohnen（草食系SA） @bohnen

エンタープライズ開発者としてみたときのforce.comのデザインは良いですよ。勉強になりました。imp/expがもう少し簡単なら良かったかな・・・

Ryo Asai @ryoasai74

@bohnen 最新は試してないですが、昨年に試したところだとEclipseの開発環境がいまいちで、ローカル上で単体試験もできず、Apexで大量のコードを書く気にはなれませんでしたね。SIerが普通に開発するTXスクリプトレベルの業務ロジックなら十分ですがDDDには向かない感じ。

bohnen（草食系SA） @bohnen

@ryoasai74 僕はAccess肯定派なのですが、Accessは「フルスタックC/S業務アプリ」だったのです。UIからDB、帳票出力までを一つのプラットフォームで行え、自動データ連係機能を備えた。ただ世の中でAccessの特性を活用していないアプリがあることは残念です

Ryo Asai @ryoasai74

@bohnen これもVBAと同じですが、SVNのようなバージョン管理や細粒度での名前空間もないので、複数人数でのプログラミングは難しいところがある気もする。結局スマートUIが適する案件用というイメージはあります。

bohnen（草食系SA） @bohnen

@ryoasai74 あれは本当に最悪なんですが、逆の発想でWeb IDEでApexコードを書くこともできるんですよ。UIを確認しながらコントローラー・モデルを修正する感覚はなかなか良いです。業務ロジックはトリガーやワークフローといったコーディング外との棲み分けが重要になります

Ryo Asai @ryoasai74

@bohnen あとは、ApexにDIコンテナがないことが気になりました。サービスクラスを分けることはできるけど、staticおじさんのレベルのコードが限界と思われます。SFのSIやってる外資の面接を受けたこともあるのですが、その辺が物足りないのが正直なところで断ってしまった。

bohnen（草食系SA） @bohnen

@ryoasai74 名前空間とバージョン管理は本当に採用して欲しいですね。そこは本当に困るところです。開発モデルがそもそも既存のバージョン管理の思想と合っていないので、Herokuの買収に合わせて強化してくれないかな・・・

Ryo Asai @ryoasai74

@bohnen だから、今のところの僕のイメージだとWebインターフェースでエンティティやフロー、Apexを定義できるレベルの案件には最適だけど、Eclipseでゴリゴリコードを書く開発には不向きな印象です。もちろん、サービス経由でオンプレやAWSと連携するのはありですが。

bohnen（草食系SA） @bohnen

@ryoasai74 そこが「Javaプログラマが１週間で嫌になる」と書いた理由でもあります。正しくマクロ言語と認識して、他の手段を模索するのが吉と思います。

bohnen（草食系SA） @bohnen

@ryoasai74 Herokuやvmforceといったものの存在意義はそこにあるんじゃないかと思いますね。私もそう思います。ただ、ワークフローとか、glueとしてシステム間をつなぐものとして特化して使えばすごく使い勝手は良いですね

Ryo Asai @ryoasai74

@bohnen AWSやオンプレ環境のカスタムアプリとSFのアプリがESB的に連携して、全体として大規模な業務システムを作るというのはアピリオなどの成功例を考えてみればわかるように実際海外ではすでに実績があるようですし、日本のSIerも目指すべき方向の一つだと思います。

bohnen（草食系SA） @bohnen

@ryoasai74 何をクラウドにするか、何をオンプレミスにするか、という選択は今後開発する上では必須の検討項目になると思います。PaaSはクセが強いので、論理的にはそういうアーキテクチャは描けても、リスクを嫌って全部オンプレミスってなっちゃうケースも多分に出るでしょうね

bohnen（草食系SA） @bohnen

@ryoasai74 またPaaSに乗っかるときはやはり、このPaaSベンダーつぶれたら自社システムどーなっちゃうの？という懸念は出てくるでしょうね。PaaSベンダーの情報公開や、信用リスク評価というのも一つ重要なテーマです。

Ryo Asai @ryoasai74

@bohnen 本来のエンタープライズアーキテクトは今後そういう視点が大切になると思いますね。でも、SI業界だとPaaSはもちろん、OSSすら抵抗があってなんでも内製したがるお客さんとかもいるのですよね。クラウドといっても実態はSIerのPrivateクラウドというのが多いし。

Ryo Asai @ryoasai74

@bohnen はい、そうですね。そういうのも含めて客観的に判断できるアーキテクトが重要ですね。そういう人がSIerの側だけでなくて、ユーザー企業側にいる必要があります。

bohnen（草食系SA） @bohnen

@ryoasai74 一つの開発標準でどんな類型のシステムでも開発できるぜーっていう万能論は結局、コストもアジリティも損なってしまったんですよね。現在は過渡期で、新しいアーキテクチャの形を模索する時期なのかもしれないなと思います。アーキテクトも対象領域によって形を変えるのかも。