Blogこの広告は、90日以上更新していないブログに表示しています。はやいもので、気がついたら今年も残すところあと1ヶ月。12月の恒例行事といえばアドベントカレンダー!ということで、マイネットのアドベントカレンダーを今年もやることになりました。この1年を振り返ると、社内外のいろんなエンジニアのひとたちと、面談やらなにやらで1on1で話す機会の多い1年でした。思い返してみると、エンジニアって本当にいろんなタイプの人がいるなあと感じます。本稿では、そんな機会を重ねるなかで感じてきた、エンジニアのタイプ別分類と、それぞれの生き方戦略というか強みの伸ばし方、みたいな話をまとめてみようと思います。モチベーション・達成感を感じるポイントによる分類エンジニアとして働くこと・ものづくりをすることについて、どこにモチベーションを感じるか。いうときに達成感を感じるか。いう観点で、下記の4つに分類してみました。独断と偏見によるとても主観的な分類ですが、多くのエンジニアがおそらくいずれか(1つ以上)に当てはまるのではないかなと。つくること自体に興味が強く、手段や方法にこだわるタイプ使ってくれるユーザーさんの喜ぶ姿が見たい、という思いが強いタイプ技術そのものを追求することに生きがいを感じるタイプ効率化やリソース最適化に情熱を燃やすタイプそれぞれについて詳しく述べていきます。本日クリスマスイブが誕生日のhirashiがお送りします。マイネットの創業から各種開発に携わってきて、気がついたら10年目です。会社スタートしたときはまだ27歳ピチピチの茶髪若造だったのが、知らないうちに歳を重ねてしまったものです。節目のタイミングでもあるので、せっかくなので本記事では、自分および会社について、この10年の技術的領域のあゆみを、いくつかのトピックで振り返ってみたいと思います。振り返るとだいたいは反省反省の歴史ばかりで胃が痛くなるような話だらけなのですが、誰かにとってなにかしら有益な振り返りもあるかもしません。OSSのフレームワークを採用して、数年経ったら典型的な技術的負債になった話。そのとき時流で話題になっていたものだったり、担当エンジニアが個人的に使ってみたいという思いで選定したようなOSSフレームワークを採用して、サービスつくって、幸いそこそこ軌道に乗って、サービス運営を続けて2〜3年もするとたいてい古さが見えてきます。枯れていなかったがゆえに独自カスタマイズを加えていった結果、導入した人にしかコード触れないようになり、そのうちその人が別の担当に異動したりするとアンタッチャブルになっちゃいます。ああ、自分もいっぱいそういうものを引き継がせてしまったなあ。これという銀の弾丸となるような対策は難しくて、負債発生するのは不可避なことで、サービスが長く続くことはむしろ幸運なことなんだと愛でる気持ちで向き合っていくのがよいと思っています。そのうえで、まずは選定時点で、そのような将来にわたっての重みになりそうなものは慎重に検討すること。しても古いものは適切にリプレイスしていくのがよいですが、ユーザーさんにどんな価値を今後提供していくか、それをどんなスピード感で実現していくか、というあたりの目的を見失わないことが大事と思います。ほら、エンジニアってどうしても、手段に興味が沸く人が多くて、どうしても目的と手段とを取り違えやすいんですよね。情報発信してるとなにかいいことあるよ、な話。自分が最近ほとんどなにもブログ等のアウトプットしていないのでオマエが言うなですが。以前には積極的にやっていた時期があって、振り返るとこういうことしてるとよいことがいっぱいあったなあと思います。文章に書いてアウトプットすることで、自分自身の知見の整理になる。自分の記憶を高めるにはエピソードを周囲の人に話すとよい、なんて話もありますが、これに直結する行為です。社内外に友達が増える。普段から何かしらアウトプットしてると、対面で会ったときの話も弾みやすいのです。思いもよらぬオファーが来たりする。講師としてセミナー登壇しませんかとか、その知見を書籍に執筆しませんかとか、自分には縁の無さそうな話がひょいっと舞い込んできたりするものです。そんなこんなが自分自身のこれまでの実体験としてあり。今回のアドベントカレンダーも、きっかけとしてよい取り組みですね。いいだしっぺのtakashabeさんありがとうございます。自社の強みをどこに据えるか、な技術戦略の話。自分たちの手数が無限大にあるわけではありません。世の中には数多くの会社さんがあってそれぞれがいろんな価値を提供しています。そんななかで、自分たちはどう生き残っていくか、というのを考えていくにあたって、全方位に手を出していくのではなく、自分たちが強みとすべきところに資源を集中させて、それ以外の部分は極力深みに立ち入らない、という取捨選択をこれまで繰り返してきました。それはベンチャー経営では当然のことですが、技術戦略についてもですね。振り返ると、うまくいったもの、いかなかったもの、両方いろいろありました。データセンターラックを全て解約して自社サービスをクラウドに完全移行させた話はうまくいったケース。一時期「Android集中」を謳っていてiOSへまったく展開しなかった、という時期もありまして、現在では方針転換して両バリしているので結果的にどうよという案件ではありますがw、一定期間中はうまくリソース集中投下ができていたケースでした。環境変化や事業転換に対する心構えな話。インターネット/ゲームにまつわる技術は変化がとにかくはやくて、過去の常識だったことが新しい価値観でガラッと変わってしまうことがままあります。上述の「選択と集中」により、会社の方針としてそれまでの方針が一新されることもしばしばあります。そんな環境のなかで、いかに変化を受け入れて、それでいて第一線での活躍を続けていくか、という命題があります。自分もまだまだ上から偉そうなことを言える立場ではないですが、振り返って感じるのは2点。1つは、変化を楽しむ気持ちでいること。こだわりを持つことはもちろんよいことですが、その一方で1つの価値観だけに変に固執するような思いがあったりすると、精神衛生的によろしくないことになりがちです。1つは、新しいことをできるだけ最速で身に着ける方法論。普通の人がやってるのと同じような方法では、なかなか第一線には躍り出れないです。詳細はここでは省略しますが、なにかしら頭をひねって作戦を練って取り組んだことが結果的によかったな、と思えることが何度かありました。変化が激しい環境だらこそ、こういう急アクセルを踏む訓練が意義が大きいのだと思います。マイネットのエンジニアとしてのこの先にあるもの、の話マイネットはこれまで何度か事業転換をしてきているのですが、現在ではスマホゲーム運営のリビルド事業というものをやっています。見慣れない事業名と思いますが、簡単にいうと、提供中のゲームタイトルを運営移管して、機能や施策の適切な再構築を行い、より長くユーザーさんに楽しんでいただけるようサービス運営をつづけていく、というものです。エンジニアが具体的にやっていることというのは、挙げてみると広範です。再構築にはアプリケーション設計力がなによりも問われたり、エンドユーザーを魅了するフロントインタフェースが重要だったり、大量トラフィックを捌くサーバインフラや対負荷設計が必要だったり、安定提供にはDevOpsの領域が不可欠だったり、データ分析基盤ももちろん活用必要だし、運営には人間のオペレーションも必要ななかでの効率化安定化が重要だったり。一昔前はWebサービスと言われたりしていましたが、今やwebなのかアプリなのか垣根がなくなってきていて、またスマホだけでなくウェアラブルとかのデバイスも普及していたり、既存の家電やゲーム機なんかもネットとつながるようになっていたりして、このへんを総称するよい言葉が見当たらないのですが(社長上原は「オンラインサービス」と呼んだりしていますが)。いった、「ネットとつながっていて、スマホやPCなどなんらかのデバイス/UIを通じてエンドユーザーに提供されるサービス」というのは、スマホゲームに限らず、今後もっともっと増えていくと思っています。ゲーム運営リビルド事業を通じてわれわれが日々実践していることって、これらのサービスを提供していくうえでも、普遍的に不可欠な技術・知識・経験だと思うのですよね。目先は現在の事業に注力していますが、この事業ではない別のことをやるとしても、エンジニアとして様々な方面から求められる有益なキャリアになると思っています。おわりにということで、この10年を振り返って思ったことを順不同でつらつらと書いてみました。読み返してみると、やっぱりどこかしら上から目線になってしまいがちで、どうもこっぱずかしいですね。自分も日々勉強中の身ですので、次の10年も精進していきたいと思います。Calendar18日目の記事です。見方について、江澤がお送りします。|+----+-------------+---------+-------+---------------+---------+---------+------+--------+-------------+idクエリ内のSELECTの連番。UNION内の2つめ以降のSELECTtableアクセスする対象のテーブル。表示される場合はselect_typeが「UNION」で、idが「M」およびidが「N」に由来するテーブルであることを示す。表示される場合はselect_typeが「SUBQUERY」で、idが「N」に由来するテーブルであることを示す。表示される場合はselect_typeが「DERIVED」で、idが「N」に由来するテーブルであることを示す。KEYまたはUNIQUEインデックスのルックアップによるアクセス。KEY利用時のアクセス。KEYが非利用時のアクセス。FULLTEXTインデックス利用時アクセス。refにNULL値を含む行の追加検索時のアクセス。インデックスフルスキャン。フルテーブルスキャン。インデックスが使用されていない。最適化必須possible_keysオプティマイザがテーブルのアクセスに利用可能なインデックスの候補として挙げたキー。NULLの場合は、関連するインデックスがない。keyオプティマイザによって選択されたキー。key_len選択されたキーの長さ。キー長が短い方が高速。ref検索条件で、keyと比較されている値やカラムの種類。定数の場合はconst。結合時は結合する相手側のテーブルの検索条件として利用されているカラムを表示。rowsクエリを実行するために調査するレコード数。InnoDBテーブルの場合、推定値であり、正確ではない。ExtraExtraは項目が多すぎるので良く見るものを抜粋。結合時や重複排除時にテンポラリテーブルを作成する必要があるあとがき次回があれば実際にテーブルとデータを用意し、サンプルを用いて解説したい←最近join、unionしないDB設計が多いので忘れてきている。Calendar15日目の記事です。今回はネイティブ周りを担当している山木がAppiumによるUIテスト自動化についてお送りします。機嫌を損ねる可能性があります。UIAutomator関係でエラーになりやすくなります。本日はito-kenがお送りします。はじめにゼロからずっとプロダクトに関わっている人でない場合、メッセージもコーディング規約と同じノリで「既に決まっているフォーマットに乗っかって書く」事が多いと思います。他ツールとの依存関係上やPJ発足からの慣例、もしくはリーダーの単純な趣味嗜好で「必ず○行で書け」という状態もありえます。「メモ」こんな殺意湧き上がるメッセージの犠牲者も多いのではないでしょうか。このような犠牲者を生み出さない為に、我々に出来る事は何でしょうか。etc...開発が運用と並行してしまうと、何を変えるにもそれなりの労力が要ります。最初が肝心ですが、ツールを変える時などはチャンスでしょう。コミットメッセージ本文gitの標準ですね。これを基準にメッセージを書いている方が多いかと思われます。メッセージ規約ドキュメント作ったよ!読む?皆さん一度だけ読んでくれます。その後、誰も読まないと思います。「誰でも一発で把握できる」位の分量にするのが良いかと。見ただけでだいたい把握できる例文がいくつかあると尚良し外国人メンバーが居る場合は英語での例文もあると幸せといったところでしょうか。おわりに炎上中や、開発者が少数の場合はメッセージが荒れがちですがチームで余計な手戻りや連携ミスなどを回避する為にも自分自身も気をつけつつ、整備されているかは気をつけたい所ですね。Calendar4日目の記事です。1日目に引き続き@takashabeがお送りします。今回はfluentdを利用して開発環境やステージング環境のエラーログをChatworkに流す手法についてご紹介します。弊社では他社で開発した歴史あるソシャゲを引き取って運用するプロジェクトが多数あります。単純にログを見る用途だとSentryなどの専用ライブラリを使ったほうが高機能ですが、その場合アプリケーションの改修が発生するので導入コストが高い可能性があります。fluentdでログを送るだけだと、(もし入っていなければ)fluentdをサーバに入れるだけなので導入と運用コストが低いというメリットがあります。やることChatwork側のAPI準備ChatworkのAPIは現状プレビューとなっており、以下から申請する必要があります。http://developer.chatwork.com/ja/申請後、数時間〜するとメールが届いてAPIが解放されます。その後以下に従ってtokenを発行して控えておきましょう。http://developer.chatwork.com/ja/authenticate.htmlfluentdインストールfluentd自体をgemで入れてもいいですが、ここでは何かと便利なtd-agentを入れておきます。fluent-plugin-rewrite-tag-filterfluentd設定td-agent.confに以下の様な感じで設定します。ここではvirtualhostで2環境(dev-01,dev-02)作っているapacheのエラーログを流すことを想定しています。定常的に出てしまうログなど、特定のログを排除する。%>[/info]"</match>ここまで設定して上手くログを流すことが出来れば以下のようにChatwork上にログが流れるでしょう。まとめfluentdを利用してChatworkにログを流す方法について紹介しました。ソシャゲ運用ではプランナーがマスタを入れて確認というフローが多いため、チャット上にログが流れることによってプランナーが単独でエラーを解消する、もしくはエンジニアに助けを求めるということがカジュアルに出来るようになり便利かと思います。やってることは単純ですが他PJでも採用事例が増えており、こういったもので少しでも楽をしていきたいですね。最近寒くなってきてサンダルが若干辛くなってきた@takashabeです。間が空いてしまいましたがISUCON5に弊社エンジニア勢で参戦してきたので、その内容を紹介しようと思います。社内でメンバーを募って最終的に9名3チームで予選に出場しました。そのうち1チームが予選突破し、本選出場出来ました。今回メンバー募集する際には「チームメンバー募集!」というよりは「ISUCONO出たい人一緒に勉強しましょう!」みたいなノリで集めたため、チーム分けどうしようか悩みましたが、ガチで勝ちに行きたいということで各々1人で過去問を解いてスコア順にチーム編成しました。本選は僕も以下ブログに書いた通り、ただただ実力不足だったなという印象でした。一応Failせずにスコアは出ましたが実装しきれずに終わったことや、盲点だったことが多かったという感じです。ISUCON未参加の方も交えて社内でISUCON大反省会と称したISUCONステマを行いました。反省会に参加してくれた方から「来年は出たい」といった声が多く聞かれ、こういうコンテストに参加する文化が社内に少しでも広まれば良いなぁという気持ちです。反省会中で社内ISUCONやるぞという話をぶち上げたので、ただいま死んだ魚の眼をしながら問題を準備しております。do7beおわりに普段パフォーマンスは重要と思いつつ、実際にパフォーマンス問題に対処したことがない方は多いのではないでしょうか。パフォーマンスチューニングというと大抵社内のデキる人が対応して終わり、みたいなパターンも多いかと思います。フラットな場でガチなエンジニアと同じ課題に取り組み、他者が何をやったのか、自分が何をやれて何が出来なかったのかが分かる環境がISUCONにはあります。今回ISUCONに参加したメンバーも口々に学びがあったと発言していて、僕自身も非常に学びあったし、特に本選後の懇親会がめちゃくちゃ面白かった記憶があります。次のISUCONも開催されるかも的な話も出ているので、出たことのない方は是非出てみると良いかと思います。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。