チーム間の垣根づくりってどうすればいい？
チーム間の情報共有が、
うまくいかないなーって思うことあって、
どうすれば解消できるのかなーと思って考えてみました。
- 指標の可視化
インフラの監視って、zabbixとかmuninとか、Nagios、cactiとか
いろいろあるんですけど、フロントエンドのパフォーマンス監視で
new Relicで計測したりしてます。
サービスに関わる人、全員が見えるようにしないと、
意識って根付かないんですよね。
そうゆうのって、エンジニアがどうにかするしかないっていうのは、
分かるんですけどね・・・
目的が周知されてないと、
みんな考え方、バラバラだったりするから、
もったいないなーって、思っています。
そうゆうのから根付かせる必要があるのに、いきなり、
マネージャーの考え方を押し付けてきたり、
意見変えてくるから、何も期待していない。信用もしていない。
この環境では、何も生まれない。何も変えられない・・・
開発サイクルってどうすれば高速に・・・
リリースして機能を提供して、
価値があったかどうかのフィードバックを受け取り、
改善することが必要なんですよね。
実装 => リリース => フィードバック => 実装・・・
このサイクルは、サービスを作る上で、
変わらないものだと、思ってます。
ということは、サービスを運営していく上で、
このサイクルをどう高速にしていくかっていうことが重要になってくるので、
実装・リリースに時間をかけるわけには、いかないんですよね。
- テスト駆動開発とプロトタイプ
TDDは、仕様が明確に決まっている時、たとえば、課金フローとか、
ライブラリとか使っているときに導入すると、速度が上がると思ってます。
プロトタイプは、見せ方の問題とかあったり、
実際、動かしてみないとわからないってこと多いんで、
何度も書き直すのであれば、何個か提示してみて、比較して、
試して、ブラッシュアップしていく方が速度は上がると思ってます。
ただ、問題点として、使われないコードが入り混じることが多いです。
デプロイ・安全性に関しては、悩みどころ多いので、
また別の機会に・・・
プロジェクトマネジメントって具体的に・・・？
自分の業務は、社内基盤のライブラリ・ツール作ってるんですが、
各ラインのリードエンジニア、もしくは、ディレクターさんと綿密な話し合いをすることが多かったり、ディレクター部門の長と１対１で話すことが多いです。
そうゆうことをやっていたので、システムのマネージャーって必要ある？
ってふと、疑問に思ったので、考えてみました。
結論から言うと、現場の空気感とか、わかってない人に口挟まれても、
現場の人からすれば、イラっとするんで、
そうゆう人なら、必要ないです。
立ち上げ、計画、実行、完成っていう、
サービスの流れがある中で、
いくらでも現場と触れ合う機会はあるのに、時間がないとか
適当に理由つけて、やってない人は、
必要ないって意味です。現場ですべてやります。
プロジェクトマネージャーっていう肩書きがほしいだけであれば、
いなくなってください。
PMBOKにのっていることは、不正解ではないし、適切だと思いますが、
正解ではないんで・・・
マネージャーから【リーダー行動指針を出します。】って、
言われたけど、マネージャーの行動指針はないですかね？
個人的な見解だけど、
チームって、全員がリーダーであり、全員がメンバーだと思ってます。
そうしないと、とてもじゃないけど、意識が根付かないから。
そうやって、繰り返してチームって強くなるんじゃないかなー。
200msを実現するインフラ
インフラ、サーバ構築を考える上で、必要なのって、
【リクエストに対して、高速、確実にレスポンスを返す】
っていう考え方だと思ってます。
オペレーションとかもそうなんですけど、
バックエンド部分、パフォーマンスとかも考えるから、
多岐にわたるんですよね。
今まで自分が関わってきた、ざっくりとした構成ですけど、
こんな感じ(台数は案件によって、だいぶ変わるかな・・・)
- ロードバランサ
AWSのELBでリバースプロキシに振り分けたりする
- リバースプロキシ
静的ファイル(画像とかCSSとか・・・)をリバースプロキシで返して、
mod_proxy_balancerを使って、キャッシュサーバに振り分ける
- キャッシュ
Varnishでページキャッシュサーバとして構築する
- アプリケーション
Railsのアプリケーションの場合、NginxとUnicornで動作させることが多い。
Apacheだけの時とかもありますけど・・・
- データベース
Mysqlを使用して、２台のマスタに複数台のスレーブを構築して、
レプリケーションさせる。
Railsのアプリケーションでは、ActiveRecordのact_as_readonlyableプラグインを使用して、更新系のクエリは、マスタにアクセスして、参照系はスレーブで動作させる
こんな感じで構築してますとかあれば、
教えてください。業務に取り入れます。
リーンスタートアップとかって・・・？
【不確実なものの中からいかに早く成功にたどり着くか】を
まとめた手法のことなんですけど、
失敗することを前提にして、利用しながら、早く成功するようにたどり着くかっていうことなんですよね。
プロセスとしては、３つあります。
仮説の設定
仮説の検証
ピボット(方向転換)
クックパッドの事例だと、
ユーザーの欲求をもとに課題を発見し、解決策とその価値を考える
解決策を形にしたものを限定したユーザに実際に利用してもらい、価値の検証を行う
利用データを見ながら、適宜方向性を見直す
プロダクトの分析ができてないのに、改善とか仕様追加とかしていっても、
本当に追加機能に価値あるのか、リリース後に価値があったのかって、
わからないんですよね。
個人的には、使われない機能は、価値のない機能だと、
思ってます。結果的には、価値のないコードを作っているってことになります。
価値を作り上げてリリースを繰り返していければ、
チームとしての学びも多いんじゃないかな・・・と思います。
最初の投稿(自己紹介)
最初の投稿なので、
自己紹介をしたいと思います。
- 22歳〜24歳
大学卒業後、新卒で入った会社がSIerで
CとかJavaで開発してました。
真っ白で何も知らない状態でしたし、情報とかもあんまりなくて、
仕事も楽しいとか思ったこともなかったですし、
先輩とかもいましたが、希薄な感じでした。
そんなこんなで、１年した後、リーマンショックで、新卒〜３年以内の社員は、
全員、退職させられました。
みんな実家に帰ってしまったり、すでに、この業界にいない人もたくさんいます。
半年ほどフリーターでバイトを３つかけもちして、生活していましたが、
仕事中に倒れて、病院に行きました。
倒れた瞬間、しんどいけど、仕事って楽しいなー。って、
漠然とした記憶ですが、そんなようなことを思ったのを覚えてます。
そして、フリーターを辞めて、
第二新卒でも雇ってくれる会社にお世話になることになりました。
- 25歳〜28歳
言語はPHPで、モバイルサイトの構築をしていました。
LAMP環境です。
初めてのことばかりで、何もわからず、
わからないことがわからないような状態でした。
それでも、一つ一つ、地道にやってきましたが、
お客さんと話したり、派遣業務みたいな感じで、
いろいろな会社でいろいろなやり方を見て、学んでいきました。
ずっと派遣で働くのは不安だなーと将来に対して感じ、
上長に【１年後、自分の描いているイメージと変わっていなければ、退職します。】と
言ったことを覚えています。１年後、変わっていなかったので、退職することにしました。
こんなことを言ったのは、
自分を変えたいと思っていて、でもどうすればいいのかわからなくて、
今の自分の想像できる範囲であれば、それは視野が狭いので、きっと、新しいイメージというか、想像できるものを取り入れる必要があるんだな・・・と考えた結果です。
- 29歳
最初は、ゲーム開発にアサインされたのですが、自分が入った頃には、売り上げよくなかったですし、クローズするだろうな・・・っていうのは、１週間でわかりました。
でも、それでも続けられたのは、すでに配属されていたチームの人たちのおかげでした。
みなさん、よくしてくれて、本当に助けられた部分がありました。
最終的には、コアメンバーとして、クローズまで見届けることができたのは、
自分の記憶に強く残っているし、こうゆうサービスを生まないように、反省を生かして、改善していきたいです。
クローズ後は、社内基盤のツールを作ってますが、
ディレクターさんから要望がきたり、ネットワークさんとサーバ構成のやりとりをしたり、各ゲームのシステムリーダーと、機能についてのやりとりをしたり・・・
シームレスに作業ができるのは、自分もそうゆうことがしたいと思っていたので、とてもありがたいと思っております。
けれども、すでに、退職の話はしていて、
今回のは、システムのマネージャー陣への不満、思うことが積もってきた結果です。
この辺は、後日、書いていきますが、今回は割愛します。
以上、自分の自己紹介でした。
