この発表は個人の見識であり、所属する組織やこの勉強会の公式見解とは一切違います

本日の概要

日々新しいソフトウェア技術が開発され続けている現在の中において、僕が考えた最強のどうぐ選びの基準を話してみようと思います。

agenda

• 自己紹介
• Web系エンジニアにとってのどうぐとは
• 今まで採用して良かったどうぐ、ダメだったどうぐ
• まとめ

自己紹介

• 基本的には Perl で server side application を書いてます
• あ、役職ない普通の社員です、意思決定権とか何も無いです

See Also:

http://yappo.github.io/ の 20111014-yapcasia2011-ikachan 以降の話題とか

会場のみなさんに質問です

Web 制作に関わっている方?

実際にコードを書いている方?

主に Perl で書かれている方?

ありがとうございました

では質問の結果をふまえて、あまり Perl の話に拘らない感じでいきます

本題に入る前に

僕が考えるエンジニアの働き方や、ある程度の規模感のサービスのありがちな話をします。

特定の会社やサービスは関係無いです。

エンジニアが組織で働く理由

• お金?
• 福利厚生?
• 名誉欲?

それエンジニアじゃなくても満たせるよ?

じゃぁ何?

よくわかんない

たぶん

自分の力で困ってる人が救えるというヒーロー欲みたいのがあるんだと思う。

その目的を達成するのに高効率なのが Web サービスのエンジニアってだけ。

名誉欲にも見えるけど、道ばたで財布無くしておろおろしてるチャラ男に1000円渡して助けてあげる程度の影響度。

どんな人を助けるか

• 仕事と職種が関係のないけど同じ会社の人
• サービスを使ってくれるであろう見知らぬ人
• 同じサービスを作っている仲間
• 同じ会社の同じエンジニアの仲間
• 会社とは関係ない同じエンジニアの仲間

どのような手助けができるかをたまに意識する

物事を見る視点を増やそう

広範囲に視点を持つ

• 自分の作り方が世間とズレてないか
• 周りに、変な事してる人がいないか
• ちょっとした事で困ってる人がいないか
• 自分の仕事範囲+ちょっとだけでも良い
• 本当に全部見るのは偉い人に押し付けとけば良い
• 少しは自分がやってるサービスの評価とか見ようぜ

将来を見る力を養う

• オープンな仕様の動向
• 仕事で使ってるソフトウェアの情勢
• 担当サービスの予定、同僚の仕事の予定
• 本当の会社の先の事は偉い人にでも考えさせとけば良い
• ちな「3カ月先の計画なんて無意味」って言ってる会社もあるらしい

整合性を求める

• 自分の担当分野だけでなく、会社全体の整合性
• 今現在だけではなく、将来を見据えた整合性
• 自分の中だけで整合性もとってもだめ周りと相談して決めよう
• もちろん企画やマネージャなど、様々な人と協力しないと整合性は取れない
• 仕様の食い違いが起きるのって、99%くらい整合性とるのさぼってるから
• ああ、全体の整合性見るのも偉い人の仕事でしたね＾＾

エンジニアに重要な3つの視点

• 広い視野
• 将来を視る
• 整合性を視定める

おんぶにだっこだめ

エンジニアの使命は、世界中の人が喜ぶ製品を作り出す事。その指名を果たすには使える手段全てを使うのがエンジニア本来の仕事。

とにかく考える

「一人でずっと考えて、他のプロジェクトと連携も考えないで、とにかく良い物を本気になって考える」って良い事いってる人もいました。

質問おじさんになる

• 考えるより聞いた方が早い
• なぜ自分の価値観と違う事をしているのか? を相手に聞かずに自分だけで消化しない
• 自分の周りはみんな優秀で賢い
• 専門家が5秒で答えられる事は結構多い
• 結果的に正しい事がわかり整合性が取れる

人に丸投げする

• 特定の処理を専門に行ってる人が居たら全てを任せた方がいい
• ノウハウの蓄積は最初は集約すべき
• 自分の周りはみんな優秀で賢い
• そして DRY になる

人から仕事を投げられる

• 案件以外の人からお願いされる時は大体相手が本当に困ってる
• 自分の専門の領域や、ノウハウを溜めている案件だったら積極的に手伝おう
• 自分も周りよりは優秀で賢い
• そして DRY になる

エンジニアに重要な3つのアクション

• 質問力
• 委任力
• 巻き取り力

巻き込み力とも言う?

これらのアクションは、人の労力を増やすので空気感を読み取る事と相手との信頼関係の構築が最も重要である

エンジニアを取り巻く環境

• ヘッドハンティング
• 解雇
• 会社合併
• 担当サービスの変更
• 担当サービスの影響力が高くなる

「変化に強くなれ」って誰かも言ってました

変化に耐えるエンジニアとは

• 臆病
• コミュニケーション
• 汎用化
• 応用力

(各項目の詳細ないから、ここで説明して)

僕の好きなマインドの話からしようと思ったら、こんな感じになった

• 視点
• 行動
• 耐性

1 2 3 4 5 6 7 8 9 10 次へ ＞ 最後へ ＞＞

現場レベルでエンジニアが考える事

• 自分が使いやすいか
• 自分が居なくても運用可能か
• 安定して運用ができるか
• 障害からの復旧フローは正しく設定できるか
• 継続的なメンテナンスが可能か

逸脱をすると、全て自分で面倒をみなければならない、若しくは面倒を見なくても問題無いようなシステムを作り上げなければならない

適材適所を間違えない

• 新しいどうぐを手に入れたら、なんでもそれで解決しちゃう?
• 長く使っているどうぐがいつまでも安全で確実だと思ってる?
• xxx 使ってるやつはクソ、 ooo 使わないとか信じられないと思う?
• ブランドに流されるやーつw

人が採用している方法を使う

• 結局実績があるやりかたになる
• チーム全体で整合性が取れる
• 自分の周りはみんな優秀で賢い
• 他人の学習コスト下げられる(重要)
• メンテナンス担当の替えが効きやすい

え?「ずっと僕はこのサービス担当する」って?

自分は他人、先週の自分は無理難題な企画以上の敵である。来週の自分がメンテナンス出来る事を考えて常に生きよう

世の中はあなたのサービスを放置し続ける保証は無い

• 人員増員
• 世界中で流行ったら多国籍化
• スケール戦略の為のコンポーネント分割
• コンポーネントごとの専任チーム
• コンポーネント間の連携

人員増員

• middleware／ライブラリ の選定
• コードのクオリティ
• DB Schema のクオリティ
• パフォーマンス
• メトリクス

多国籍化

• ドキュメント
• 管理ツール
• 数値の単位
• 商習慣

コンポーネントが分離される

• コンポーネント間通信
• 多数のコンポーネントと連携する
• 1つのコンポーネントの乱れはサービス停止
• 担当同士のコミュニケーション

小さいコンポーネントだからこそパフォーマンスに命かける

• バーストトラフィックに対応するにも限界値のベンチマークは必要
• 基本はサーバを増やしたら対応出来るように
• 簡単に増やせるようにする
• 今の方法がダメだった時の10手先まで考えておく

だんだんエンジニアらしい話になってきたので、この辺でいったんまとめます

まとめ

ちゃんと考えよう

Web系エンジニアにとってのどうぐとは

さて、そろそろお気づきだとおもいます

我々エンジニアにとってのどうぐとは?

さっきのまとめ

まとめ

ちゃんと考えよう

そうです

考える頭脳こそがエンジニアの唯一無二の道具なんです。エディタ何使うとかプログラム言語どうするとかマジどうでも良い話なんです。そこ本質じゃないんです。

そして、どうぐを一番研ぎすませてくれるのは、やっぱり同じ考える事が出来る良識あるエンジニアだけなんですね

ほんと、資料の前座部分かいてて発見しました！本当は、前座の後に色々実際のソフトウェアの選定基準はなそうと思ってたけど、纏まった感すごいです！ぼくさとりました！なんだか賢者になったきがしました！

今まで採用して良かったどうぐ、ダメだったどうぐ

この発表は個人の見識であり、所属する組織やこの勉強会の公式見解とは一切違います

だいたいオチがついたので、僕が現職よりずっと前に仕事で使った事のあるソフトウェアから、今現在使っている製品などについて、さとり目線からの選定理由や反省点等を話してこうと思います。

(時間がないので割愛)

え?以外とすくないって?忘れてるのも結構あるけど仕事では色んな種類つかったから良いって事にはならないって事を遠回しに前座でやったので。。w

このセッションのまとめ

• 困った時に相談出来る人を作ろう
• 自分より他人の方が優秀
• 優秀な人とパーティ組むと捗ります

以上です