会社内の責任と権利の構造 | F's Garage
いろいろ事業やら取り組みやらをやりたい時に、会社の中でどうハックするかの基本構造をダラダラと書いてみる。あまり他人に理解してもらおうと思った文章になっていなくて、自分の頭の整理のために書いているので、それについては先に謝っておきます。こういうアウトプットは、そのうちquoraの回答等で質問に対する回答形式で再利用することになりますので、わからなかったらquoraで質問などしていただけますと。 ーーーーーーーーーーー 「責任を負う」とは、何かの目的に対する達成に対する責任を持つことである。 つまり、そこで起きた問題は、すべて自分のせいであるとし、問題解決や目標達成に全力を尽くすことを約束すること。 責任を負う約束をするからこそ、その目標を達成するために必要なリソースをその人に委ねることができる。 それがヒト・モノ・カネと呼ばれるもの まず、会社の中のマネージャの仕事、いわゆるマネジメントに関
エンジニアの思考を停止させる不安係数∞の罠 | F's Garage
エンジニアの職能の一つに「重箱の隅のような問題に気がつくスキル」というのがあります。このスキルのおかげで、見積もり精度はあがり、将来に起きうるリスクを防ぐことができるというメリットがある反面、不確実性のあることへの恐怖、100%の確信がないことから自分の発言に自信が持てない、決断できないなどのデメリットをもたらすことがあります。 これを総称して「不安係数∞」という言葉を、はるか昔から使っていましたが、それに言及した自分の昔のブログの記事でいいものが見つからなくなってしまったので、もう一度書いておきたいと思います。 我々は日常、たくさんのリスク要素に気が付きます。Webサービスならセキュリティホール、ネットワーク設定の不備、技術的負債に基づくスケーラビリティ問題などなどが代表例ですし、受託ならお客様の対応が信じられない、納期がころころ変わる恐怖、仕様が難しすぎて実現できないのでは？などなど。
技術視点の時間軸を鑑みたCTOの役割定義 | F's Garage
最近、ずっと考えてることとして、CTOの役割定義は大切かなと。 IVS CTO Night & day 2018のイベント中で「CTOという肩書はラベルか？」という示唆的な話が出てきていました。 この指摘がイベント中になされたのは、なんどもこのイベントに参加している僕が知ってる限り初めてで、会社のステージの変化に対して、CTOという役割認識においてもフェーズが変化してきたのを感じています。これは言葉を返すと「ラベルだけの存在になるとCTOはいらないかもしれない」という指摘で、組織構造がどんどん変わっていく上で、どういう裁量、責任を持ち続けるのか？を設計しておくことが重要であると考えます。 CTOのイグジットマネジメントや、急に組織が拡大した時に歪を及ぼさない形で組織をスケールさせたい時、はたまたCTOの肩書に流動性をもたせるにあたっても、この辺の考え方をしっかり持っておくのは必要かなと。
日本の美意識がイノベーションを阻害する | F's Garage
日本は信用レベルが高い社会なんだと思う。何故なら大体みんな世界レベルでは裕福な人が多いから。 ただ、それに依存しすぎると期待と現実の間に齟齬が生まれていくどころか、それが当たり前だと思って変化することをこばんでいくと世界から置いていかれるかもしれない。 中小企業だと廃業の危機!? 大阪の模型製作会社が予約キャンセル大量発生を訴える 「予約だけして音信不通キャンセル」が発生して困っているという話なのだが、クレジットカードでオーソリだけ取っておけば、発送時に確定すればとりっぱぐれないので、そういう決済方式に移動したほうがいいんじゃないかと思うわけです。 BASEで決済を利用すればクレカは最大60日までオーソリを延長できますから、その間に発送できる商品であれば、ちゃんとお客さんとコミュニケーションさえとってあれば、事実上の予約だって可能だと思うわけです。 （ちなみに、もっと待たせたらドタキャンは
昔いた会社のこと | F's Garage
いくつか会社を経験してきたけど、ここ最近、一番思い出すのは、何社か前の受託を生業にしていた会社のこと。 多分、会社の規模や、抱えている状況が類似しているからなんだと思う。 当時、僕もマネジメントについては初めてで付き合い方に、すごく悩んだことがある。どうやって同じ方向、望む方向に向いてくれるだろうか、とか考えていた。そういう時は、休日はプールに行って泳ぐんですよね。プールに潜ってる時は極端なことを言えば生死に関する状態なので、生存を維持するために、何も考えなくて、ただそのことに没頭できる。 一方、土曜の夜とかに埼玉くんだりから、六本木のABCとかツタヤに行って、マネージメントの本だとか、当時、光り輝いていたライブドアの堀江さんの本を読んだり、またソフトウエア開発プロセス関連では、トム・デマルコの本を代表とする、マネジメントや開発プロセスをどうやったらうまく進められるか？について読んだりして
誰と働いているかという視野のエンジニア評価軸について | F's Garage
うだうだ記事を書く。あんまりブロガーさんのように、懇切丁寧に説明する意識はない。うざかったら途中で離脱推奨です。 とある理由で、本番のデータを修正することになった。休日だったので僕が対応したのだが、その部分のデータ修正の経験がなかったので、ソースコードから調べて依存関係を解決するSQLを書き、Slackを通じてコードレビューをお願いして、無事修正タスクは完了した。 所要時間は、作業開始から40分。 日常的にソースコードをいじっていて、データ構造を熟知しているメンバーなら、５分もかからないで終わる作業だろう。もしそうならば、８倍の速度差が生まれている。 その８倍の速度差が顧客満足度に影響をおよぼすのであれば、その人は、僕よりも8倍速で得られる顧客満足度の分だけ、仕事ができると評価ができる。 その人材がいれば5分、いなければ40分。この差はとても大きい。その差が大きいと思うのであれば、そういう
リーダーはどのようにして作られるのか？ | F's Garage
大学の頃、高校時代の友達とドライブに行った時に、コンビニの脇に車を止めてたら、近くにいた原チャリが転んだのが目に入ってきた。彼は素早く見つけて、いち早く車を降りて助けに行った。その瞬発力は天性のものだと思っていたが、大学を出たら警察官になった。 警察官は、彼にとって天職だと思った。今も元気にしてるだろうか。 同じくリーダーシップも天性のものだと思うことがある。友人のその行為に、「にじみ出る警察官臭」があったとするならば、リーダーになる人は、リーダー職にいなくても「にじみ出るリーダシップ臭」がある。 以前WebSigモデレータの和田さんと話をしていて、新卒から定年までの人材育成ロードマップができあがっている歴史ある企業は、ところてん形式で、人を枠にはめる人事モデルを持っているのがすごい、という話が面白かった。 大卒で入社し、３０歳になれば主任になって、３５歳で管理職になって、４０歳で云々。そ
モバツイサービス終了について | F's Garage
モバツイのサービス終了が発表されました。 Twitterクライアント「モバツイ」がサービス終了へ 12月14日まで jig.jp、「モバツイ」と全関連サービスの提供を12月14日に終了 「モバツイ」と関連する全サービスが12月14日に提供終了となることが決定 あと半年とちょっとで１０周年なんですよね。 １０周年までは持ってほしかったけど、昨今のTwitterの売却騒動も含めて、雲行き大丈夫かなと思っていたところ、この発表のちょっと前にサービス終了の連絡をいただいていました。 サービス譲渡後の現場を知らないので、何が困難だったのかを感じ取れてないのですが、外野から見えるサービス譲渡後に起きたこととして、大きな問題は、 ・Twitterの利用規約変更によるサードパーティクライアントの締め付け ・SSLのセキュリティ問題による、Twitter本家の証明書強度のバージョンアップからのログイン画面に
上司は期待はするが、結果というファクトなしに部下を無条件で信頼するわけではない。 | F's Garage
自分は「評価されていない」「信頼されてない」と思ってしまうケースにおいて、いくつか、「社会人として、うまく生きるためのテクニック」がある。 僕も、過去、この言葉に思いなやなんでいた経験はあるし、今でも人格要素として持っているので、この感覚にある「どうしたら良いか分からない感」は非常によくわかる。 なお、これは誰かからのヒントを元に、別のケースにおいて該当するかもと思ったので、誰に対して言いたいという他意はないので、というエクスキューズを前に置いておきますね。 この記事のきっかけは以下の記事でした。 「知力」は生まれつき備わったものなのか？自信過剰になることで人は成長を止めてしまうことが判明 これの記事に対するGroove X林さんのノートが全公開だったので、大切な部分を参考にさせてもらうと、 ＞「他人との比較」→「劣等感」→「思い込み」→「保守的」 ＞このループに入ると、成長が止まって、時
与えられたバッターボックスは一期一会 | F's Garage
BASE社は少し決算期がずれているので、今月がQ（クオーター）の変わりです。 今年からOKRという目標設定手法をやっていて、今回で４クオーター目になります。未だに慣れていないところはありますが、エンジニア流のタスク設定の部分は徐々に慣れてきました。エンジニアの仕事は不確実性が高く、当初立てた目標と結果としてやった仕事が全く変わっていることも不思議ではありません。少なくとも、過去数社でやってきた目標設定は「静的な目標設定」だったため、半年後の予測などできずに評価の前提も全く変わっているということが常でした。それ故に、目標設定による評価の難しさというのを常々考えていたというのが昔からのマネジメントの悩みでした。 今回のOKRについては、その徹は踏まないようにと、「動的な目標設定」を行うことにしました。 方法は、まず、KRの高い順位に「絶対にやるタスク」を設定します。これを「S級チケット」と呼び
ちゃんとしてないようで、ちゃんとすること | F's Garage
滅茶苦茶なことを書いてるのでスルー推奨です。 企業が大きくなっていくと、おのずと社会から、その会社は「ちゃんとすること」を求められます。 それまで、全然ちゃんとしていなかったのに、突如ちゃんとすることを求められると、困惑します。 スタートアップも、 「ちゃんとしていないフェーズ」で活躍していた人、 「ちゃんとすることで、会社がつまらなくなってしまった人」 「ちゃんとしている方が力を発揮する人」 「ちゃんとする方向にシフトできずに苦労している人」 など、さまざまな軋轢が起きます。 「ちゃんとする」とは何でしょうか。 先日、鹿児島のさくらじまハウスという、さくらじまで開催されたエンジニア向けイベントで、さくらインターネットの田中社長が、こういう一言を仰っていました。 「メリットを求めると、熱量が下がる」 この言葉、すごく刺さりました。 「メリット」というのは、企画を立てた時のやる理由の説明責任
東大佐藤ママに見られるスモールチームを成功につなげる３つの法則 | F's Garage
朝、家の出がけに朝のテレビ番組、ノンストップ！に、息子３人を東大にいれた佐藤ママが登場していた。二度目の出演だそうだが、以前、書籍を読んでみて、お母さんの姿や発言に興味があったので、家に帰ってきてから改めてガラポンで見返した。そこには案の定、想像した通りの豪腕女性社長のような風格を持った頭の切れるお母さんの姿があった。 この本に対する話題は、実に微妙だった。妬みや親子関係という主観に依存するために、実に感情論が多い。我々も、お母さんでも使えるサービスを作りなさい、という開発理念が浸透しているが、誰にとっても最強の主観的な存在が「ママ」であり、誰もが個別の関係性を持っていて、にもかかわらず多くの人が共通する何かをイメージしやすいので、そこから外れるものは非難の対象になりやすい。 それ故に画面に流れていたツイッターコメントについても、このママの教育支援方針について過保護だとネガティブなコメント
CTOという役割について 〜 IVS CTO Night & Day 2015 Winter powered by AWSに行ってきた。 | F's Garage
CTOという役割について 〜 IVS CTO Night & Day 2015 Winter powered by AWSに行ってきた。 IVS CTO Night & Day 2015 Winter powered by AWSに行ってきました。 過去３回、全部参加してるんですが、個人的には一番良かった。 イベントクオリティも高かったけど、個人的に壁にぶつかっていたということなのかもしれない。自分の中での疑問や仮説を持った中での他のCTO職、管理職の人たちの意見はビシバシ心に刺さる。そんな３日間でした。 イベントの中でアンカンファレンスというコーナーがあって、そこではいくつかのアジェンダについて数人で議論するのですが、「経営者としてCTOがすべきこと」という議論が非常に面白かった。そもそも「経営チームにおけるCTOの存在意義って何？」という、そもそも論の部分が整理されたのが大きいw 事業
何のために頭を使うのか？手を動かすか？という美意識 | F's Garage
最近、ジジイになってきてワガママになってきただけかもしれないけど、手を動かして何かをする以上は、それが自分にとってポジティブであることはすごく重要だよな、と思う。 何かのプログラムを書く時に、それが本当に必要だと思っていればこそ頭が回ると思うけど、でも、そうじゃなくて、いわゆる仕事として必ずしも目的も見いだせてない時にコードを書いたりする場合（ぶっちゃけ社長しか本当のビジョンが見えてない時とかね）、そこで必要なのは、 ・それが本当に必要だと思ってくれている人がいる とか、 ・これを出したら喜んでくれるんじゃないか ということが期待できて、その期待に応えたいと思えるようなことって、エンジニアにとって、すごく大事じゃないかな。要するに、この人が欲しいって言ったから信じて作ってみる、というのがあって、それができる人が優れたプロダクト開発のリーダーになるのではないかと。 なんかそれ、どうなるかよく
労働時間と、仕事のやりがいの関係性に関しての独り言 | F's Garage
すっげー微妙な話書きます。 労働時間の話です。 ブラック論が取り沙汰された時に、２つの話が出てきました。 一つは、労働時間が長くて、本当辛くて自殺してしまった人が出るぐらいの話 もう一つは、労働時間が長くてブラックと言われてる会社で、ポジティブにやって出世までしている人の話。 えと、労働時間が長いといえば、一番代表的なのは経営者です。経営者が過労で病気になるという話は聞いたことはあるけど、経営者が働き過ぎて気持ちを病んでしまうというケースは聞いたことがありません。そもそも彼らは24時間仕事のことを考えています。 それに対して、そこまでの重圧は持っていないにも関わらず、社員で気持ちを病んでしまう人の話というのは聞きます。 その２者が人間的に違うかというと、そんなに違わないと思います。少なくとも同じ人間です。 あ、この話、決して経営者目線云々という話をしたいんじゃないですよ。この文章をうっかり
Web制作Web開発で、10年後なくなる仕事の議論 | F's Garage
こないだWebSigモデレータのmtgで和田さんとかとしていた議論を噛み締めながら、頭の中を整理するメモ AWSでサーバ開発周りで起きていることを考える。 AWSが出たことで、サーバのハードウエア障害からおさらばになっただけでなく、構築業務はボタン一つで終わるようになった。撤去も契約も構築もいらない。さらにオートスケールや自動デプロイの手段で、その管理も自動化することができる。 まさに自動化だ。 じゃぁ、すべてのエンジニアは、どうなったのだろうか。 サーバのオペレーションという作業からは開放されたことで起きたことは、フルスタックに近いエンジニアへの要望である。 ・サーバをいじるだけ ・アプリケーションを書くだけ ではなく、AWSを活用し、サーバもセットアップできるし、アプリケーションも書けるし、間を繋ぐデプロイメントやテストも適切に構築できるエンジニアではないだろうか。何故かと言うとこの作
Web系エンジニア経営者の選択肢 | F's Garage
ふと思いついたので日記として書きます。 以前、モバツイを運営するマインドスコープを経営していたが、会社を手放して改めて再出発しようとして、改めてマインドスコープ時代の総括ができるようになって、ようやく気がついた反省点というのがある。 それは、マインドとして、エースエンジニアの座を社員に譲れなかったこと。 自分自身の問題として、というか１クリエイターとして自分が許せない、というか、正確には、自分が一番、怖がっていたこととして、目の前のお客さんが困っている状態を、絶対に自分たち要因では作りたくない、ということに強いコダワリがあったことだと思う。 モバツイというサービスを育てる時に、一番大切にしてきたのは、Twitterというリアルタイムサービスの仲介業として、即座に問題を解決すること。繋がり続けることにコミットすること。そのために自分の時間を捧げていたと言っても過言ではない。 311の時にも、
スマホでUSENが神アプリすぎて参った | F's Garage
もうサービス開始後、一周年を超えてるらしいんですが、ふと居酒屋の有線が気になって、検索してみたら見つけました。 月490円でUSENのだいたいのチャンネルは聞けるっぽい。 てっきり１０ちゃんねるぐらいのサブセットかと思ったら全然そんなことなくて、90年代J-POPとかボサノバチャンネルとか聞けます。マジで神です。ラブホテルとかであるやつのと同じのが聞けます。 音楽聴き放題アプリ スマホでUSEN 昔、マンションを買ったことがあるんですが、その時にUSEN入れようか迷ったんですよね。でも高くてJCOM（ケーブルTV&ISP）と二つはキツイなと見送ったことがあったので、こんな安くなって嬉しすぎます。 開発作業をする時に、無音は苦手なのでこれを流すと捗ります。huluを目の前のモニタに流してBGV化するってのもあるんですが、huluだとどうしてもコンテンツが気になっちゃってね。 まったく何も考え
2014年のふりかえり（KPT） | F's Garage
他の人の振り返りを見ていて、自分のも書きたくなったので、今年の振り返りをしておく。 ７月中旬までの時間の使い方 日常の時間の使い方としては、 ・ShopCard.meの開発 平日２日、土日休日 ・モイ 平日３日という時間の使い方でした。 ・BASEは顧問として週１参加。 でした。 ■よかったこと、続けたいこと（Keep）： ・モイでは若手のマネジメントみたいなこともやってました。年齢差があるからこそ、若手を育てるのは楽しい、と思えるようになった。 ・研究的に、機械学習の勉強ができた。 ■うまくいかなかったこと（Problem）： ・２つのサービスに本気でコミットするのは難しかった。 リスクを分散するために複数の仕事をするのがよいという話がありますが、僕がやってみた結論としては、「言われたことをやるだけ」とか、「ちょっとお手伝いする程度」ならできるけど、責任を持とうと思ったら、２つのワラジは
クソコードを片付ける心構え | F's Garage
クソコード問題には、いくつかの「不安」が隠れていると見た。そこを解決しないと感情的な問題点は解決しない。 1.現状、クソコードを量産する人がいる場合 2.現状、クソコードを改善できない組織である場合 3.クソコードをリファクタリングする時に壊す恐怖 この３つに対して、どうにかしたい / どうにかなれよ、と思っているのがクソコードに対する不満につながっているのではないだろうか？と思った。 人の批判は堂々としにくいから、如何にクソコードは駄目なのか？という不満だけで「誰か」を変えたい、という代理戦争的言説がネットにはびこることになるのではないだろうか。 そういう状況に対して、 4.引き継いだクソコードを書いた人が社内にいない場合 は、終わった話なので意気揚々と片付けよう、という結論でしかない。知恵を絞って、がんばろう。 例えソレがそうであってもソレを口にするとネガティブが蔓延する。思ってもイイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
