フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
ディレクターがプログラマーとうまくやる方法を全部教えます : LINE Corporation ディレクターブログ
こんにちは、櫛井です。 プロジェクトマネージャーやディレクターの仕事というのは多岐に渡りますが、特にプログラマーと上手にコミュニケーションを取り一定の目的を果たすというのはわりと大変なことだったりするらしいです。私は比較的プログラマーとうまくやれているタイプのようなのであまり苦労した覚えが無いのですが、過去10数年で培ったプログラマーと上手くやる方法を紹介していきたいと思います。おまけで「プログラマーに嫌われる６つのこと」も紹介します。 ※うまくやれてるイメージ図 プログラマーと上手くやる方法をざっくり言うと 役割分担として求められていることをやる お互いのTODOを把握し区切りをつける スケジュール管理をしっかりする といったカンジです。ではそれぞれ説明していきます。 役割分担として求められていることをやる そもそもディレクターが求められる役割とはなんでしょうか。Web開発案件におけるデ
辞めたくなる会社 | mediologic
mediologic my thoughts on media/communication/marketing and everyday life. Search Primary menu 以前にいた会社の、自分がいた組織の離職者率が増えているのを聞いていると、それまで「働きたい会社」だったのが「辞めたくなる会社」になってきているということなのだろう、ということに悲しくなる。 ベンチャー的な気質をもった会社だと、「この会社、このプロダクトを使って何かをしてやろう」というチャレンジャーが集まり、その“志”がエンジンとなって前進していくものだが、あるタイミングからその会社がメジャーになってしまうと「入りたい会社」となってしまい、学歴だけよかったり、対して仕事ができないのに過去の会社での経歴を“華麗に言う”人間が増えてしまう。つまり実力者が入ってこない。またそういう傾向になると、「マネージャー」
第9回 NHN Japan執行役員/CTO 池邉智洋氏に訊く（前編）―「放置」と「無茶ぶり」の裏に隠されたNHN Japan流の学習環境 | gihyo.jp
Webクリエイティブ職の学び場研究 第9回NHN Japan執行役員/CTO 池邉智洋氏に訊く（前編）―「放置」と「無茶ぶり」の裏に隠されたNHN Japan流の学習環境 NHN Japanといえば、「ハンゲーム」「NAVER」「livedoor」を展開する国内最大手のインターネット企業。2012年1月1日には、ネイバージャパン、ライブドアと経営統合し、今後さらなるパワーアップが期待されています。今回は同社を訪問し、ライブドアの前身、オン・ザ・エッヂ時代から技術部門を支えてこられた現NHN Japan 執行役員/CTOの池邉智洋さんにお話を伺います。技術力に定評がある同社ですが、「研修はほとんどやらない」職場環境。「放置」と「無茶ぶり」の裏側に、どんな人材育成の仕組みが隠されているのかを探ってきました。 NHN Japan 執行役員/CTOの池邉智洋氏 大前提は、独特の「Webの
ミーティング：仕事が死ぬ場所
寂しい気分ですか？自分で仕事をするのが嫌になりましたか？自分で決断をするのが嫌ですか？ それならミーティングを開催しましょう！ 皮肉なネタ画像と共にミーティングについての5原則がCoding Horrorに掲載されていました。 1時間以上のミーティングをしたものは死刑 ミーティングが1時間以内に収まらない場合は根本的な過ちがある。まずはそれを正すべき。 全てのミーティングは明確なミッションステートメントが必要 ミーティングの目的を簡潔な短文で定義できますか？ ミーティング前に宿題を済ませる ミーティングのアジェンダを明確にしたら参加者には事前に何を話すべきかを伝えます。ミーティングルームに入る前に宿題を済ませて準備ができている事が1時間以内にミーティングを終わらせる秘訣です。 任意参加にせよ 必須参加は甘えです。ミーティングの参加者はそこに居たいと思っているべきです。 ミーティングの最後に
デブサミで僕が話したことの簡単なまとめ - 宇宙行きたい
デブサミが 10 周年でした。 残念ながらオファーなかったのですが、一昨日くらいに急に参加していいよって言われたので 「From Legacy to Agile 〜レガシー開発からアジャイル開発へ〜」に乱入してきました。 そこでチームビルディング的な話を話させてもらいました。 資料とか特に作っていなかったので僕がリーダーとしてチームメンバーにお願いしている決まり的なことを簡単にまとめておこうと思います。 テストを書け 問題を根性で解決するな 人を殺す以外なら何やってもいい 失敗を引きずるな 個別に補足書いて行きます。 一応状況の簡単な説明をしておくと、最初は 3 人しかいないチームに 「手伝ってくれないか？」と言われ合流しました。その後、僕がリーダーになり 今は 15 人前後のチームで動いています。 テストを書け これは僕がチームに入るときに最初に宣言しました。 「テストを書かないようなプ
数千人が利用する楽天Redmineの過去と未来 #47redmine
第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
コードを書けることで僕は本当に救われている - ihara2525's blog
普段僕が仕事でコードを書くことはほとんどありません。 コードを書くことでチームや組織に貢献したい、という思いは常にあります。 同時に、僕はそうすることで自分の価値を一番出せるんだろうか、という思いもあって、やっぱりこっちが強いので、一年ほど前に僕は基本的にマネジメントに徹することにしました。 それでもたまにコードを書きたくなったりしますが、自分が中途半端に参加すると、結局他の人の動きを止めてしまったりすることになるので、やらない方がよっぽど良いです。 「いや、採用とか組織作りとかやめて、本気でやったら俺の方が絶対に書ける！」みたいなのもなくて、集中してやってもたいした結果にならないでしょう。逆に、そうなっちゃうようだったら自分よりも優秀な人を採用できてない、自分の仕事をできてないってことです。 なので、最新の技術への理解や、素晴らしいコードを書くことに関して、僕は確実に、簡単に、僕の周りの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
