前回は組織であるあるな二極化を「ビジョン・ミッション・バリュー」に当てはめて考えてみましたが、今回は「バイモーダル（2つの流儀）」という視点で組織の二極化を考えていきます。 前回の記事へ、興味深いコメントを頂きました。 （みなさんのご意見・感想とても勉強になります！ありがとうございます！） 「バイモーダル」と「ガーディアン」というワードが気になって、調べてまたひとりごとのように考えてみました。 ＊ バイモーダル＝2つの流儀検索すると「バイモーダルIT」というのが出てきた。情報システム界隈で、ガートナーという方が提唱されたもので「2つの流儀のIT」と言うそう。 ITと入ってくるので、たけてつさんの広義なバイモーダルから少し反れてしまうかもしれないが、今回情報システムのお話しではないので、概要部分だけ掻い摘む。 さらっとバイモーダルITについて・・・ “ガートナーは「バイモーダルIT（2つの流

最近，チームを自己組織化させるためにどうするかみたいなことをよく話したり考えたりするのだけれど，チームの自己組織化を考えるうえで，特に組織の「境界」をどこに引くかはとても重要なんじゃないかなあと思うので，今の考えをまとめておく． 基本的にはどのような組織にも当てはまる話ではあるが，主にソフトウェアシステム開発の現場での経験が元になっていることをご理解いただきたい． 自己組織化とは何か いろんな定義があると思うのだけど，自分は Scrum Alliance の認定スクラムマスター研修にて日本人唯一 *1 の認定スクラムトレーナーである江端一将さんが仰っていた定義がわかりやすいと思う． 1. チームのゴールが明確であること 2. チームの仕事や裁量の境界が明確であること 3. チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること また，最近同僚と話していた中で出

この記事は何 昨日， Engineering Manager Advent Calendar 2018 にて 今，個人的に重視しているエンジニアリング組織のためのセオリーをまとめる - TechとPoemeの間 という記事を公開しました．その記事の続編かつ実践編として，本記事では， FOLIO が2017年から2018年にかけてどのようにエンジニア組織を形成し，課題を抱え，その解決のためにどのようなアプローチを取ってきて，更にその後どのような課題に取り組もうとしているかを紹介しようと思います．自分が FOLIO に入社するよりも前の頃の話も多く含まれていますので，その点はご留意ください． この記事は, FOLIO Advent Calendar 2018 14日目の記事です． adventar.org この記事は何 βリリースまで: 職能組織 プロジェクト体制 組織組成においてプロジェクト

個人的な考えをまとめるために作ったもので特に対外的な発表資料ではないです。 ”見積もり”の話が中心なので”計画”の話は外しています。Read less

今年の2月より、FOLIO という会社で働いています。本業はバックエンドシステム開発とかエンジニアリングマネージメントなのですが、それとは別に、「社長による社内向けの音声コンテンツ」の企画及びインタビュアーをやっているので、その話をしようかな、と思います。 この記事は、そんな FOLIO のアドベントカレンダー 2日目 の記事です。昨日は id:ken5scal による 『踏み台環境でテレポートする』でした。 adventar.org 組織の「100人の壁」 自分が入社したときの FOLIO は50人から60人という会社でしたが、私の加入後にも続々とメンバーが参画し、今では100人に迫ろうとしています。 一般に、組織には「100人の壁」と呼ばれる、会社規模が大きくなることで発現する組織課題があると言われています。実際に FOLIO でも、今年の初めには1フロアだけだったオフィスも3フロアま

株式会社FOLIO にてエンジニアリングマネージャーをやっています．FOLIO では この1年間，プロダクト開発を円滑に進めるための組織を目指し，様々な試行錯誤をしてきました．その中でも，適切なチーム・グループの境界設定やミッションに基づいた組織の構造化は現在進行系で大きなトピックの一つです． Engineering Manager は Engineer のマネジメントではなく Engineering のマネジメントだ，という指摘が今回の Advent Calendar でもありましたが，エンジニアリング組織の持てるポテンシャルを十二分に引き出せるかどうかを左右する変数のひとつが「組織のカタチ」だと思います。 本稿は，10月のあるタイミングで社内に向けた啓蒙活動の際に書き出した『組織づくりを考える上で知っておく必要のある概念たち』という wiki の内容を素にしています．私が今の仕事のコン

はじめに クラスメソッド株式会社 AWS事業部長の佐々木です。 私は前職で創業メンバーの1人としてビジネスを立ち上げた後、エンジニアとして実業務に携わりながら、統括マネージャーとして50人規模のエンジニア組織を構築しました。 また2014年にAWSエンジニアとしてクラスメソッドに入社し、2015年7月よりAWS事業部の部長に就任。事業は順調に拡大しており、2015年と比較して組織も2倍以上に大きくなりました。これは優秀な仲間に恵まれたのはもちろんのこと、組織設計と構築プランが功を奏したことも一因だと感じています。 そこで、私がこれまでに培ってきた経験から得たエンジニア組織の構築の仕方をお伝えしたいと思います。 エンジニア組織構築マニュアル 骨子を定義する これはエンジニア組織に限りませんが、組織には3つの骨子が必要です。 ポリシー ビジョン ターゲット ポリシーは、その組織が最もこだわる一

元エンジニアリングマネージャで、今は人事をやっています。 この記事は、Engineering Manager vol.2 Advent Calendar 2018 の19日目です。 もはや関係ないのに未だにエンジニアの1on1を何人かの人とやっているのですが、そこで、同じことを何人かの人に説明することが続いたので、きっと同じようなことで詰まってるんだろうなと思い、久しぶりに書いてみることにしました。*1 前提 僕が1on1をやっている人は、チームのリーダーもしくはリーダー的な動きを期待されている人 それぞれのチームは古い人もいれば、新しい人も入ってきて、割とカオス。 それぞれのリーダーは、なんとかチームを良くしたいと思ってがんばっている。 1on1での話 とあるAさんの1on1から チームのみんなが技術的に向上したいって思ってくれない という悩み。聞いてみるとチームとしては業務はそれなりに

＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう

インターネットテレビ局 AbemaTVは開局から2年2ヶ月で3,100万DL突破、毎月1,000万を超えるユーザーが利用する動画サービスに成長しました。今年の基調講演ではこれまでの技術戦略、組織戦略を振り返ると共に、今後の展望についてご紹介します。Read less

サーバーサイドレンダリング、Isomorphic、Universal JavaScriptなどの言葉をよく見かけます。なるほどね、良さそうだね、外部公開するサービスを書くことがあったら挑戦してみたいね、Mithrilにもisomorphic-mithrilってのをがんばっている人がいるし、みたいなことを漠然と思っていたのですが、最近ASCII.jpのシステムコールプログラミングの連載を書いていて、あらためてHTTPの仕様を見返してみて、逆にサーバーサイドレンダリングをしない方がいいのではないか、と思い始めました。 追記(23:30): サーバーサイドレンダリングと書いていますがUniversal JavaScriptみたいな凝ったビューの更新の意味です。 サーバーサイドレンダリングの欠点 サーバーサイドレンダリングのメリットとしてあげられるのは次の2点です。 検索エンジンのクローラー向け

あけましておめでとうございます。エンジニアリンググループの松原@ma2geです。 私はこちらの記事にもあるマルデバチームのチームリーダーをしていますが、採用チームとしても働いております。 今回は採用チームで取り組んでいるエンジニアの成長や OSS 活動を推進する仕組みの一部として、 チラッとこのブログにも出てきた「エンジニア実績システム」を導入してみた話です。 エンジニア実績システムとは エムスリーの実績システム 2015 年くらいにはてなさんやペパボさんで導入されたことが話題になったのでご存知の方も多いと思います。 以下のようなエンジニア各人の社外的な取り組みに対して、達成したかどうかを実績として記録できるようなシステムです。 GitHub リポジトリへのスター数(10, 50, 100, 1000) 月間記事エントリ数(5, 10, 20) 詳しくははてなさん、ペパボさんの以下の記事を

こんな感じ。 cat で連続して nowファイルの内容を表示している。ファイルを変更しているわけではないが、 表示するたびに内容が変わる。 # cat now 2018-12-27 00:21:20 # cat now 2018-12-27 00:21:21 # cat now 2018-12-27 00:21:23 Fuse-BindEx どういう仕掛けかというと、今回作成した bindex ファイルシステムを経由して、 上記ファイルにアクセスしているため。この bindex というファイルシステムは、 「実行ファイルが read されたら、そのファイルを execute した際の出力を内容として返す」 という動作をする。上記nowファイルの本当の内容はこちら。 #!/bin/bash date "+%F %T" 今回の場合、bindex 経由で cat (read) するたびに、dat

2018年は公私ともに忙しい年でした。このエントリを書いている時点でもう年が明けてしまいましたが、1年のふりかえりとして、またある種のポートフォリオとして、1年間のアウトプットをまとめたいと思います。 手元のスケジュールを確認したところ、講演/ワークショップを53回、インタビュー/対談/Podcast出演を5回、社内読書会ゲスト参加を3回、執筆、増刷作業を6回、主要OSSプロダクトのリリースを3回行っていました（小さなモジュールはカウント外）。これらが2018年のアウトプットです。 新作登壇（6回） 私は再演が多い講演者で、登壇依頼のほとんどは既存の講演/ワークショップの再演です。それでも2018年に新しいテーマの講演をいくつか行いましたので、それら「新作」がアウトプットの筆頭となるのではないかと思います。 技術選定の審美眼（2月15日） 2月15日に「技術の進化の歴史は振り子ではなく螺旋

TikTokは良い動画が一瞬でバズりやすい。それは例え、あなたの最初に投稿した動画だったとしても。これはYouTubeと対極的である。YouTubeでは無名の人がどんなに面白い動画を投稿しても、そもそも誰にも見てもらえない。YouTubeで毎日毎日面白い動画を投稿し、たまたま見てくれた人が読者登録してくれたりして、数ヶ月、半年と努力を継続しなければならない。 一言で表せば、YouTubeは「信用経済」「評価経済」時代のプラットフォームなのである。 たくさんの登録者数を持つYouTuberが強い。少ない登録者数しか持たないYouTuberは弱い。弱いYouTuberは、たくさん登録者数をゲットするまで、修行する。そういう世界だ。 一旦インフルエンサー級まで自分の信用や評価を蓄積することができれば、後は自由自在に動きやすい。他のYouTuberともコラボしやすいし、企業案件もどんどん舞い込んで