社員数が100人に迫っても社員と社長との距離を保つ「CEO Radio」の取り組み - TechとPoemeの間
今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。 この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。 adventar.org 組織の「100人の壁」 自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアま
良いテックリード、悪いテックリード - 小さなごちそう
本記事は、下記の記事の翻訳です。著者の許可を得て翻訳しました。 この記事はフォースクエアの技術的リーダーシップを簡潔に説明したガイドだ。 ベン・ホロウィッツの「良いプロダクトマージャー、悪いプロダクトマージャー」からインスピレーションを得ている。 チームワーク / Teamwork 良いテックリードはチームの一員として振る舞い、自分の成功とはチームが成功することだと考える。面倒で退屈な仕事の一部を担って障害物を取り除き、チームが100%のパフォーマンスで稼働できるようにする。チームの技術的能力を拡大し、システムの重要な知識が属人化しないように務める。 悪いテックリードは注目の集まる仕事で自分の成果を示すことを好む。その成果は部分最適に留まり、開発チームのアウトプットを増やすにはエンジニアの人数を増やすしかない、という状況から脱することができない。 技術的ビジョン / Technical v
Design in Tech Report 2016 | Kleiner Perkins
Kleiner Perkins is committed to respecting and protecting your privacy; please contact sbiglieri@kpcb.com with any questions regarding our privacy practices. Download Design in Tech Report Last year, John Maeda published his inaugural #DesignInTech report to reveal the impact Design has made in Silicon Valley. Now, in his second annual report, Maeda doubles down by delving deep into design trends
プロダクトマネージャーの3分類 - Yamotty Blog
rebuild.fm 今回はTaro Minowa (@higepon)さんの回について。 higeponさんについてはこちら。 Software Engineer@Twitter. OSS projects: Mona (OS from scratch), Mosh (Fast Scheme Interpreter), Mio (KVS). (Twitterからプロフィール転載) この回は内容が大きく2つから構成されている。 エンジニアにとってのTech Leadというキャリアパスについて プロダクトマネージャーの分類と難しさについて 本題として扱いたいのは2についてなのだが、1のTech Leadという役割、キャリアパスが新鮮かつエンジニアの組織を考える上でとても有用だったので、簡単に触れたいなと思います。 なおTech Leadに関する @higapon さんの考察サマリはご自身がブ
テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
Design Technologists: Front-End Development in the Design System Era
Let’s be honest. The relationship between designers and the engineers who execute their designs can be rocky. A historical reenactment of the designers and engineers working together.Engineers get frustrated when designers design things that were “impossible” (read: would be hard to build, don’t play nice with the API, or are likely to cause cross-browser issues) and that it is the engineers who a
StackShare - Tech Stack Intelligence
Tech Stack Intelligence provides real-time visibility into all the developer tools, services, and packages you're using internally, down to the version level, across all your Git repos. StackShare EnterpriseOur platform gives companies real-time visibility into all the tech stacks in use across their engineering teams. StackShare Enterprise helps CTOs and other technical leaders make smarter decis
Tech Lead（TL/テックリード）の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
Tech Lead（TL/テックリード）の役割。聞きなれない名前かもしれない。リードプログラマやテクニカルリードと呼ばれることも。過去にいくつものチーム（最大で10人以上）の Tech Lead をやってきた自分の経験を踏まえて書いてみる。 Tech Lead の主な役割 Tech Lead はエンジニア班長と言いかえるとイメージがわきやすいかもしれない 顧客に提供したい価値（プロダクトゴール）を正しく理解する エンジニアチームの生産性を可能な限り最大化。プロダクトマネージャ・デザイナと顧客に価値を提供する Product の Launch に責任を持つ Product の Launch 後のメンテナンスに責任を持つ エンジニアを過負荷から守る ときにはマネージャ、プロダクトマネージャのアイデア、スケジュールに NO を言う。代替案を提示する チーム内のテクニカルデザイン、採用技術などに責
7年働いた時点での私の仕事の極意 - Kengo's blog
最重要 実行に重きを置く やらないで後悔するよりも、やって反省する。 反省は成長を産み生産的だが、後悔は精神の無駄な消費。 時間は有限で貴重な資源だが、たぶん今の段階では行動する前に得るものや結果を予測するのは難しい。 正しい反省の方法とは何か、考え続けること。 「正しく反省するために、何を記録しておくべきか」実行前に明らかにしておくこと。 反省の結果は組織的な何かに落としこむ。組織構造、戦略、静的解析、自動テスト、教育など。意識しないでも巨人の肩に乗れる状況を作ることが、組織の成長につながる。 Done is Better Than Perfect ただし、思考停止の言い訳にしないこと。詰めの甘さを擁護する言葉ではない。詰めの甘さは立場や考え方が違うひと3人くらいに意見を求めればだいたい炙り出せる。 長期的視野を持ちつつ、それに引っ張られない。進展を作ること、現状を少しずつ変えることを意
2015年、ベイエリアではスマートハウス系IoTと日本企業の進出が活発に～btraxブランドン・ヒル氏に聞く - エンジニアtype | 転職type
転職・求人情報サイトのtype エンジニアtype ITニュース 2015年、ベイエリアではスマートハウス系IoTと日本企業の進出が活発に～btraxブランドン・ヒル氏に聞く 2015.01.05 ITニュース 2014年もさまざまなトレンドが登場したTech業界。その振り返りをしていく上で、IoTの話題は避けては通れないだろう。 NIKEなどのスポーツメーカーが昨年から発売を開始していたスマートウォッチの分野でも9月に本命だったAppleが『Apple Watch』を発表したり、10月には高級時計メーカーとして知られるタグ・ホイヤーがスマートウォッチへの参入を発表するなど、ウエアラブルデバイスに関しては普及しているとは言いがたいものの、話題に事欠かない1年だったといっていいだろう。 また、注目を集めたといえば、ロボット分野も熱かった。 6月のソフトバンクのPepper発表、9月のSDK配
クラウド環境の設計指針をどう決めるか - たごもりすメモ
クラウドに限らず、データセンタの設計全般に言えることだけど。 コンピューティング基盤をどのように設計するかには根本から異なるアーキテクチャが様々あって、ある特定の方向のアーキテクチャについても実現するためのソフトウェアやハードウェアに様々なものがある。 合議制で決めてはいけない。何を採用するか、どのように設計するかについては、誰かが英知をもって決断するべきだ。それも可能な限り素早く。 今更言うまでもないことだが、この世界は技術の変化が非常に速い。おそらく3年経てば優位な技術は入れ替わっていて、何か新しいトレンドとか技術要素だとかいったものが登場しているだろう。 そんな中で何を採用するかについて、長い時間をかけるのは簡単だ。3年かけて実機を多数揃えて比較検討すれば、検討開始からの3年間で何が優位だったかが確実にわかるだろう。 おそらくその頃には別の技術が登場し、更に3年の比較検討が必要になっ
Ruby嫌いがアンダースタンディングコンピュテーションを読んで - ぐるぐる～
アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 一番最初にはっきりさせておきますが、Rubyは嫌いな言語です。 が、この本はRubyが嫌いな自分でもいい本だと言える*1本でした。 自分が対象読者に入っているかどうかは実際に読んでみるまで微妙かな、と思っていましたが、とても楽しめました。 以下、書評です。 Rubyという選択 説明用のコードとして本書はRubyを使っていますが、 これに関してはその理由が1章にあります。 私はその明瞭さと柔軟さに魅かれてRubyを選びました また、続けて 本書にはRuby独自の機能に依存しているところはありません。 そのため、もしあなたにとってわか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
時雨堂を支える技術