まさかの日記

最近まともな文章しか書けなくなってきました

2014/08

ちょっとマンネリ化してきたかなと思ったら、こんどはこういう展開か。
  • by

壁にあたると迂回路を探す（それも総当り的に）、そんなやり方をずっと続けてきたけど、時間をかけて壁を叩いて壊すようなやり方もそろそろ出来るようにならないと。。と思っていますが、３年後、５年後にはそれは実現出来ていますでしょうか。

戯言ですが。。自分用メモ。


■既存パッケージの競争力が充分に高いのであれば、そのままAWSなりに乗せて動かすだけでOK。だがそうではないのであれば。。。

もしそうではないのなら、競争力を高めるのが先。
競争力を高め、維持する、という活動が継続可能な状態にすることが先。


■”クラウド”で解決するのはデリバリー上の課題のみ。

”クラウド”に載せたことで競争力がUPすることは無い。
インフラの調達スピードが早くなる、顧客側のインフラ初期投資が抑制できる、などという調達上の課題が解消されるだけ。
それを見て競争力が上がったと勘違いしてはいけない。


■”クラウド版”に「ドアノック商品」を期待するのは、「初期費用の工数で稼ぐSIモデル」を継続することになるが、それがやりたいことなのか？

つまり「初期費用の工数で稼ぐ（＝フロー型）」を続けたいのか、月額課金の顧客数を増やしてストック型にしたいのか、をまず明確にするべき。


■事業計画上で気をつけるべきは、どっちに転んでも大丈夫なように戦略を考えておくこと

工数ベースの事業が拡大するかもしれないし、ストックベースが拡大するかもしれない。どっちもうまくいかないかもしれないが、そのときにどうするか。撤退可能なのか、撤退して致命傷を受けないためにはどうすればいいか。

ストック型が充分な売上に達するまでは、ストック系の事業に充分な人材を張ることは出来ないが、そのことで事業の成長スピードが遅くなることが起きてはならない。（ので繊細な舵取りが必要なのか、あるいは、、、全員が開発も運用もインフラ構築も出来るスーパーな人材であれば当然問題が起きる可能性は減らせるが。。）


観た。小説シリーズ中だとこれが一番好きなんだが、アニメ版でもこれはこれで良かった気が。つかBDちょっと欲しい。

社内でAWSの啓蒙っぽいことしてるけど、かなり引きが弱い。

昔、いろんな会社でUnixとかLinuxとかサーバとかの社内教育を散々やったけど、全然ものにならなかったことを思い出すなあ、と。

期待もしてないし、絶望もしない


やっぱAPI系は必須として何を選択したらいいんですかね？
と地元の知り合いに聞いてみた結果を共有しときます。

＊＊＊

バックエンドは当然REST API
実装よりも設計が難しいので要注意
Jersey、Gsonは必須

WEB Viewならspark
http://www.sparkjava.com/

とはいえWEB Viewは不要とのこと。
AngularJS
bootstrap
でシングルページWEBアプリが王道

ORマッパーは、hibernateか、あるいは薄く自作
パフォーマンス重視するなら最終的には必ず自作になる

Seasar、Seasar2系はもう終わり

ちなみにnode.jsよりはvert.xかも

やっぱDockerすごい


（このへんから脱線して開発方法論の話）


社内でメールは不要
チャットから拾ってチケット管理に登録
なので全チーム共通でのチケット管理ツールは必要

ていうか開発方法論も見積もり手法ももはやどうでもいい
作る人で百倍以上違うのに見積もりしても意味が無い
できない奴は一生出来ないし、できるやつなら一日で作れる

進捗何％ですか？は無意味
あと何日で終わるか？だけが重要
もし無理そうならほかの人に変わってもらうだけ

９時過ぎて会社に残ってる人がいたら、困ってたりハマってたりしていないかを上司がチェックする
毎日１０時過ぎまで会社に居るのは何かが起きているというアラート
単にこだわってるならOK、困ってて何日も進んでないなら担当を変更する
問題が起きたら出来る人のチームで対応する。


UIは、このUIが最適である、というのをデザインチームが決める。
それを元にエンジニアチームが実装する
リリースはエンジニアチームの都合で決める（延期する）


そもそも管理も何も必要無い
良いメンバーで、雰囲気良くしていればものすごいパフォーマンスを出せる

アプリの仕様書は不要。
そもそも仕様はテストケースで表現する。中身はどんどん変えてOK

納品しない開発、ソニックガーデン、あれは良い

このページのトップヘ