blog.kyanny.me 一年経ってしまった。いろいろあった。一年前はオフィスのことしか書かなかったので、今年は自分のことだけ書く。 Engineering Manager 今年の1月に会社の組織変更があり、 Engineering Manager というポジションができた。国単位・技術分野単位などで開発者をいくつかのチームに分け、それぞれに Engineering Manager がいるという、いわゆるふつうのピラミッド型の組織になった。で、俺が東京オフィスの Web Developer チームの Engineering Manager になった。 上司（CTO）から話があったのは去年の11月頃だった。プロダクト開発チームがグローバル全体で50名くらいになってきて、そろそろ CTO 一人で見るのは無理がでてきた、そこでローカルに Manager をつくり各種の業務や権限を委譲していき
仕事の能力には「差」があります。「仕事のできる人」もいれば、「それなりの人」もいます。ここで僕は「人は業務能力は均等だ」と口角泡を飛ばして力説することはしません。なぜなら、それは「事実」と反するから。 また、「仕事への熱意＝仕事へのやる気」も明確な「差」があります。ワンセンテンスでいえば、「やる気もある人」もいれば、それなりの人もいます。もちろん、僕は、「どんな人でも、人は、みなやる気に満ちている」とはいいません。なぜなら、それは「事実」とは異なるから。 ところで、これらの「明確な差」を認めつつ、皆さんに、ひとつご質問がございます。 もし皆さんが、職場を率いるリーダー・マネジャー・管理職ならば、どのような人材を「自分の職場」に欲するでしょうか？ １人自由に部下を選べますよ、と言われたら、どんな人材を皆さんは欲しますか？ 能力のある人、ない人？ やる気もある人、ない人？ ２軸４象限で整理すれ
こんにちは。新規広告開発部所属エンジニアのレオ（@lchin）です。 ここ2年ほどは、大きな事業部のなかの小規模なエンジニアチームのリーダーを務めてきました。エンジニアリーダーとしては、1人のエンジニアとしてソフトウェア開発をしつつ、チームのメンバーの力をまとめて、事業部のゴールを推進しました。事業部のマネージャほど、マネジメント業務が中心になるわけではありませんが、多くのエンジニアが苦手な人間関係スキルはエンジニアリーダーにも必要です。 メンバーは何か大きな不安を抱えていないのか？ポテンシャルを発揮できていないメンバーにどうフィードバックするのか？メンバー間に何かトラブルはないのか？見えないところで仕事の妨げはないか？チームでソフトウェア開発を行う上のよくある悩みだと思いますが、皆さんはどう解決していますか？私は、個人面談はこういった悩みを解消するための大変有効な手段だと思います。 なぜ
チームでの自分の振る舞いを考えるために、1分間マネジメントシリーズの「1分間リーダーシップ」を読んだ。 1分間リーダーシップ―能力とヤル気に即した4つの実践指導法 作者:K.ブランチャードダイヤモンド社Amazon この本ではいくつかの種類のリーダーシップを状況によって使い分けると良いということについてフォーカスし、リーダーシップの使い方について言及されている。マネジャーになった時にリーダーシップは必要な技術なので参考になる。 この本で言いたいことは、その人の目標を決め、その人の目標に対する現在の発達度から、リーダーシップのスタイルを使い分けるべきである、ということ。それを言うためにその前提としていろいろなことを教えてくれている。マネジャーになった人なら参考になると思う。 目標と発達度によってリーダーシップを使い分けるというのが、これまでなかった観点だったので面白かったので、今回はそれにつ
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
20141010 万葉帰社日発表 万葉積み重ね from tatsuo sakurai 内容 チーム積み重ねっていう前に公開したものと似てる、チーム開発とか社内での工夫とか、あいかわらず僕の好きそうな内容。 なんとなく万葉で中の人達がやってることを小出しにしたいなって思っていたんだけど、どこでやろうかなあ…みたいなのが思いつかなくて、社内で発表した。 万葉は僕にとって働きやすい環境で、なんでかっていうと、自分達で会社の制度や仕組みなどをリファクタリングしたり、機能追加したりしてるからかなあって思う。 もっと効率を良くする仕組みを、効率よく採用できる。（や、まあ、普通にどこでもそうしてますよね…^^;） その理由として、社長が現役プログラマーというのは大きいと思う。（実際社内でも一番書いてるくらい書いてる。っていうのを意外と知らない人がいるって話をちょいちょい聞くのでスライドにもいれてみた。
今さらなのだけれども、「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」を読んだ。仕事で活用できるかと問われると微妙だけれども読んで良かった。避けていたのはいろいろな誤解があった。複雑なソフトウェアを作る為の考え方。 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者:エリック・エヴァンス発売日: 2011/04/09メディア: 大型本 Eric EvansがDDDのアイデアを著書のドラフトというかたちでWeb上で公開し始めた2002年以来、この知恵の書は多くの識者の間で話題の中心となり、「徹頭徹尾有用な書籍（most thoroughly useful book）」とまで評された。記述されている内容の一言一句すべてにおいて役に立つことしか書かれていない、と賞賛
しばしば政策的な意味での「技術者育成」が話題となる。 これに対する私の答えは、「別に日本の技術者は貧弱じゃないんだよ。むしろ貧弱なのは経営者の方だろ」であり、これは今のところ変わる様子もない。日本のコの業界の問題点はまさにそこにあるからだ。 ということは、わかっている人はわかっているんじゃないかと思う。でも、なぜ「技術者育成」がしばしば政策になるか。それは単なる「上から目線欲」の満足のためではないか？ 若干ひねくれつつよく考えてみれば「育成」なんて語はとても上から目線だ。イメージ的には、 こいつだ。「育成」という目線は、まさしくこれだ。もちろん、もっとマトモな会社もあるのだろうが、結局目線はこれなのだ。上手く育てて食う。ブラック企業はブラックなりに、そうでないとこはそれなりに。「いや、俺は豚じゃねーよ」って声はわかるし、「私は従業員を豚扱いなんてしてません」って声もわかるし、私もそう言いた
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
私は文系の大学中退（まぁ高卒ですよね）です。最初に入ったのがソフト会社で、その次もソフト会社でした。最初の会社では未経験のど素人だったのでオペレータやパンチャー、運用と保守からやらせて頂きました。その後転職した2番目の会社で、絶対に忘れないと感じる出来事に出会いました。 ＃ とりあえず、以下のエピソードのあと、新婚早々に残業400時間/月とかやってて ＃ さすがに「これは死ねるかも」と思う程度に、月に200時間残業とかするのは ＃ 当然と思っていた、それでもそれが苦にならなかったほどに一体感を持つことが出来た ＃ 今思うに幸せな時代の話です。私は当時の会社を今でも誇りに思っています。 2番目の会社にはその年の1月に入社しましたので、その年の夏のボーナス（賞与というよりも私にはボーナスという言葉の方がゴージャスに聞こえるのでこれで押しますｗ）は当然出ません。というわけで、お金に困っていた私は
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
