フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
![開発組織のマネジメント](https://cdn-ak-scissors.b.st-hatena.com/image/square/d9c79b0771d6d594cecb1e28c1ad074c3ecb8653/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fe410b2c066f5013212a26e47992228f9%2Fslide_0.jpg%3F4262900)
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
こんにちは、岡崎です。最近はグリーのインフラチームにおける開発のマネージメントを担当しています。 このエントリーは「GREE Advent Calendar 2014」2日目の記事です。昨日は岸田さんによる「イノベーションが失われた組織から脱却する10のルール」でした。 さて、気がつけばここに書くのも昨年のAdvent Calendar 2013「開発ワークフローを、いつどう変えるか」以来です。去年は開発プロセスについてやってきた事の振り返り記事でしたが、今年も同じようにこれまでのプロジェクトを振り返りながら今回はエンジニアリングのマネージメントについて考えてみます。 エンジニアリングマネージャーとはどのような責任を持っているか エンジニアリングマネージャーとはどのような責任を持った役割でしょうか。本題に入る前にまずは「責任」という言葉の定義について確認しておきます。 「責任」と一言で言う
【 第27回】企画とエンジニアだと企画が偉い。(川上量生の胸のうち) 面白い記事だったのでまたかいつまんで、勝手な感想を書く。 反論とか全面賛成でなく井戸端話的に。 でもうちの会社って、エンジニアを大事にする文化があるので、企画は地位が低いんです。それっていうのは、あまり企画者がバリューを出せてなかったからだと思うんですよね。企画者って、ポジションで偉いわけじゃなくて、企画そのものの影響範囲が大きいから偉いんですよ。 素晴らしいなー。一文でほとんどの問題点を触っている。 企画屋がそのポジションを使って仕事をすると、他の人が苦労する。 俺の言う事を聞け、俺が企画だ文句を言うな。的な進め方。言い方だけ丁寧で中身は一緒とか。 もちろんこれで成功する場合もある。だがその場合周りが苦労する。 大規模開発ならばサポートする人が苦労を背負い込んで上手くまわす手があるが、少人数開発で回りに負荷を一定以上か
2014/9/6に開催されたXP祭り2014で「アジャイルを手放して得られたこと」という講演をしてきました。Togetterはこちらから。 元々は「アジャイルのダークサイド」の話がしたくて応募したのですが、その後、いろいろと考えているうちに僕自身にも気づきの多い内容となりました。 さて反応を見てると前半のアーキテクチャとマネジメントの話に興味を持っていただいたようです。なので、このブログでは「なぜアーキテクチャとマネジメントの話からアジャイルの話をしたのか」ということを書いてみます。 アジャイルがさまたげたもの アジャイル開発手法が大きく注目されるのは1999年の「Extreme Programming Explained」の出版であり、2001年の「アジャイルソフトウェア開発宣言」です。1990年代後半から2000年代初頭というのは、IT産業が大きく成長する時代であり、同時に、当時主流で
伊藤直也氏が語る「仕事の流儀」の第2回は、KAIZEN platform Inc.の立ち上げに参画して実感したリモートワークツールの重要さについて。 スタートアップ企業でエンジニアが快適に開発できる環境とはどのようなものか、KAIZENでの事例をもとに、いま感じてることを語ってもらった。 by 馬場美由紀 (CodeIQ中の人) リモートワークをしながら「全員同席」するためのツール KAIZENのようなスタートアップ企業で、かつリモートワークをする社員もいる環境で、どんなふうにアジャイル開発を進めていくか。 それが最近の僕の重要な関心事です。 ちょっとKAIZENのリモートワーク風景を見てほしいんですけれど……(Sqwiggleというオンラインミーティング・ツールで自宅で仕事をしているエンジニアを呼び出し、会話を始める)。 Sqwiggleを起動すると、カメラが有効になっていて、こんな感じ
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
数年前から身内で時々集まって開発合宿をしていて、成功失敗あわせて知見が貯まってきたので備忘録として記事にしておきます。 なお、ここで開発合宿と言っているのは1,2部屋に1泊して済ませるような規模のもので、ホワイトボードでブレストしまくりといったものではなくて淡々とみんなでパソコンするみたいなものを想定しています。 宿選び あえてオススメの宿リストみたいなのは書きません。なぜなら開発合宿向けの宿まとめみたいな記事を真に受けて失敗したことがあるので、そのようなリソースをインターネットに増やしたくない。 開発合宿で有名な某旅館は、割安ではあるが無線LANが弱すぎ、温泉はぬるすぎ、メシもいまいちという品質なのに、開発合宿に選ばれがちである。○○旅館に行ってきましたという開発合宿レポートをみんながブログに書くから検索にヒットしてみんなそこに行くみたいになってて、負の連鎖が起こってる。 無線LANより
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く