XP 祭り 2016
![エンジニアが納期を守れていないとしたら、そこにはいったい何があるのだろう?(あるいはいったい何がないのだろう?)](https://cdn-ak-scissors.b.st-hatena.com/image/square/9e5d3630bb30fd452b2ec570005bdcc74e0b4897/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fd27f17a91d694e13a3444485125296b1%2Fslide_0.jpg%3F6886486)
ここ3ヶ月ぐらい同じRails案件でリードエンジニアとして仕事をしています。 何気にマネジメント的なことをやるのが初めてだったので色々と戸惑うことがありましたが、だいぶ慣れてきて知見が溜まってきたので、自分のしごとの振り返りも兼ねてまとめておきます。 リードエンジニアのお仕事とは 会社やチームによって全くと言っていいぐらい異なると思いますが、私の場合は以下の様なことをしてきました。 開発スタート時 要件確認 仕様書を読んで全体像やどこから着手するかなどを考える Railsアプリのベース部分の実装 rails new DB周りの設定 初期モデルクラスをDB定義に基づいて作成 factoryも使いそうなものについてのみ作成 rspec、rails_config等諸々の設定 ローカル環境動作用のseedsを整備 使いたいGemを追加 共通で使うCoffeeScriptのライブラリを思いつく限り実
ソフトウェア開発者達を育てるには、あなたのリーダーシップのスタイルを変える必要があるかもしれない。彼らは、一般的なマネジメントでは必ずしも輝かないのだ。何が一番重要か?前もってはっきりとした予測を立てる事、そして問題になる前に作業習慣の違いを考慮しておく事だ。 我々はYoung Entrepreneur Council (YECの11人の起業家達に、彼らが開発者を管理する上で経験したリーダーとしての大失敗と、同じ間違いを避けるためのコツを共有してもらった。彼らの回答は以下の通りだ。 彼らが意見を述べてくれると思い込む事ソフトウェア開発者達が自分の課題やアイディア、あるいは手柄についてさえも話してくれると思い込まない方が良い。多くの開発者達はチーム・ミーティングでこういった情報を進んでシェアしようとしない。開かれた、真摯なフィードバックは常にあなたから要求しなければならない。 自分の努力に対
はじめに これは ドリコム Advent Calendar 2014 の23日目です。 22日目は、シモーネことryouichi.horiiさんによる リリース時の負荷対策 - Qiita です。 自己紹介 @tomofusaです。 ドリコム入社9年目。 サーバーサイド出身で、ゲーム/クライアント周りの技術を見るマネージャー。 手を動かさない方の部長です。 CTOを目指しています。 最近気になっているのは、ゲーム開発/アドテクです。 ※一部の方を除いて目標CTOについては、はじめてパブリックにしました。 もうちょっと詳しく 元々は、学生時代に総合工学部的なところからソフトウェア開発に入りました。C/C++の基礎的なものに触れながらwin32/.NETでツールを作って遊ぶ程度のプログラミング経験でしたが、インターネットの画く世界に魅せられて、興味をもったことからweb業界に入ってきました。
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く