チームワーク、努力、勝利 / スタートアップのチームワークとコミュニケーション
これからの時代はチームワークがより重要になってくると思っています。 これまで様々なチームワークをよくする試みが共有されてきましたが、このスライドでは「チームワークをよくするためにどういうプラクティスが良いか」という情報だけではなく、「どういう考え方でチームワークを捉えたほうが良いのか」、というあたりを中心にまとめようと試みました。 特にスタートアップのチームワークに必要な、複雑で創造性を要するタスクを処理するためのチームワークにフォーカスしています。これらの情報がすべてのチームに当てはまるものではないと思いますのでご注意ください。Read less
企業文化をぶち壊すな / Startup Culture
スタートアップの企業文化 (Startup Culture) についてのスライドです。 企業文化やビジョンをスタートアップの初期から気にするべきかどうかは悩ましいところですが、Y Combinator の Jessica Livingston のいうとおり、企業文化はその設立当初から自然と育っていってしまうものだなと 2, 3 人のスタートアップを見てても思います。であれば、初期から考えるためのある程度の情報はあっても良いのかなと思い、今回スライドをまとめました。 企業文化はかなりソフトな概念なので、そもそも把握しづらい上に何が良くて何が悪いのかも分かりにくく、さらに簡単に変えたり作り上げたりできるものではありません。それに加えて、良い（望ましい、心地の良い）企業文化があるからといって、その企業の成功が約束されるわけではありません。 ただ様々な研究を見てみても、良い企業文化は生産性向上や採
Qiitaのエンジニア社長、海野弘成がコード書きをやめて経営に集中する理由 | HRナビ
プログラマーのための情報共有サービス「Qiita（キータ）」は、国内のプログラマー人口が40-50万人と推計されているのに対して、月間100万UUを超える人気サービスだ。 そんなQiitaを運営するのはIncrements株式会社。代表取締役の海野弘成さんが京都大学の学部生だった頃に、ビジネスコンテストで知り合った仲間と3人で、2012年2月に創業した。経営者の顔を持つ一方で、自身もプログラマーとしてコードを書き、Qiitaのサービス向上をけん引してきた。経営者といえば文系出身者が多くを占めるなか、プログラマーが会社を経営したら、どんな会社ができあがるのだろうか？ 創業から丸3年を迎えて引っ越したばかりだという渋谷のオフィスにて、詳しく話を聞いた。 海野弘成氏。1988年兵庫県生まれ。京都大学工学部情報学科在学中にはてなやGoogleにてソフトウェアエンジニアとしてインターンを経験。201
【前編】大先輩のフリークアウトCTOが語ってくれた、マネジメントの深くてイイ話
Twitterでハッシュタグ「#naoya_sushi」が生まれてしまうほど、無類の寿司好きとして知られる伊藤直也氏（@naoya_ito）。そんな伊藤氏をホスト役とし、トップエンジニアをゲストに招いて、寿司をつまみつつホンネで語ってもらおうという、この企画。 第三回のゲストは、エンジニア界隈では知る人ぞ知る存在である「ミスター・アドテク」こと、明石信之氏。オンライン広告の新トレンドとして注目を集める「DSP（Demand-Side Platform）」の分野をリードする『株式会社フリークアウト』で執行役員として活躍しながら、古巣の『ヤフー株式会社』ではシニアフェロー／名誉黒帯を務める明石氏。長年、インターネット業界の最前線に身を置いてきた明石氏だからこそのマネジメント論と独自の視点を、たっぷりと披露していただきます。お楽しみに！ — 伊藤直也（以下「naoya」）：緊張してます！ — 明
優れたプログラマに対しての、管理職への昇進以外のキャリアパス | POSTD
あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、本当にエンジニアたちが望んでいるものでしょうか？ もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか？ 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル
共感力が低いエンジニアのための、とあるスタートアップの現場の話
http://startuptechtalk.doorkeeper.jp/events/17559
Redmineはプロジェクトを横断して使うべきか否かという議論の感想 - プログラマの思索
Redmineはプロジェクトを横断して使うべきか否かという議論をTogetterにまとめた。 過去の僕の経験を踏まえながら、Redmineの運用スコープはどこまでなのか、を振り返ってみる。 ラフなメモ書き。 【元ネタ】 Redmineはプロジェクトを横断して使うべきか否か - Togetterまとめ 【1】当初は、メンバー3人で、短期間の受託開発案件をこなしていた。 その時、Redmineを導入して、Redmineの機能を一つずつ試しながら、アジャイル開発の実現方法を習得していった。 少人数のメンバーで1個のチームだけだから、イテレーションごとにRedmineの運用ルールを軌道修正して、アジャイル開発のプラクティスを1個ずつ試していけた。 一番の発見は「イテレーション・リリースバージョン・マイルストーン一致の原則」と「プロジェクトとブランチ一致の原則」だった。 「イテレーション・リリースバ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
わたしのキャリアチェンジ (仮)
http://file001.shop-pro.jp/PA01252/832/sample/kyouiku/manager-7-jyouge.pdf
デスマーチが起きる理由 - ３つの指標