ギークでスマートな人達が活躍する組織を支える3つのポイント - エムスリーテックブログ
長女と2人で水族館に行ったときの写真。帰路のバスで「2人でまた来たいねえ」と言われて泣きました。例のごとく本文とは全く関係がありません。 はじめに こんにちは。最近、ダンダダンのアニメ化が発表され、嬉しい気持ちのエムスリー エンジニアリンググループ VPoE 河合(@vaaaaaanquish)です。 皆さんは『Hit Refresh』という書籍をご存知でしょうか。 現Microsoft CEOであるサティア・ナデラの自伝であり、OpenAIやGitHubと現在"Hit"を続けているMicrosoftに成る過程において、会社を"Refresh"してきた物語が書かれています*1。 その中にあるサティア・ナデラのテクノロジー文化をリスペクトした一節が、私は大好きです。 テクノロジーは魅力的だが、 それ以上に魅力的なのがそれを設計した人達の深いこだわりだ。 実際にサティア・ナデラがMicroso
CTOとはいったいなんだったのか - 肉とビールとパンケーキ by @sotarok
こんにちは。元クロコスCTOの sotarok です。 元というのは、「クロコス」という会社が吸収合併にされてなくなったからですね。 「CTOとはどういう人だ」という話は、ここ1−2年ホットで、定期的に話題になります。自分の元上司であるグリーふじもとさんやnaoyaさんをはじめ、立派な諸先輩方が語ってくれているところではあります。 よりまとまった話をわかりやすく聞くには彼らの話を聞いてみるというのが良いかもしれませんね。GREEのエンジニアブログとか、wadapのブログとか、WEB+DBとか。 で、まあとはいえ、CTOというのをやってみた身として、自分なりに思っていることを、自分の言葉でまとめておくことをやってみようかな、と思っていたのでせっかくなのでブログに書いてみようと思います。 ただし、はじめに言っておきますがCTOとはこうでなければいけないとか言うつもりはありません。自分が意識して
アーキテクチャ変更を決断するときCTOは何を考えているか？ 技術的意思決定を経営陣に説明する実践的Tips - Fast DOCTOR Technologies TECH BLOG
記事を書く背景 ばんくしさんの「エンジニアとビジネスの距離感の難しさ」というブログを読みました。 経営とエンジニアリングをつなぐ立場であるCTOとしては永遠のテーマだと思います。 申し遅れましたが、私はファストドクター株式会社CTOの宮田 芳郎です。昨年、ファストドクターの開発組織は、大きな技術的意思決定を経営陣とともに実施できました。具体的には次の2点です。 アプリのFlutter化（意思決定は2022年5月） 新規のバックエンド開発時の言語をRubyからTypeScriptへ切り替え（意思決定は2022年6月末） いずれも一度の経営会議で、上記の方針について経営陣との合意を取っています。 5秒でわかる記事の結論 経営陣への提案資料は下記の5点をポイントとして記述すると良い 実施の意義（≒ 解決したい課題） 必要リソース（人・モノ・金 + 時間） 実現コンセプト リスク 手続きの妥当性
【一休】CEO榊淳×CTO伊藤直也が語る「社内の壁」の壊し方
赤裸々な対談で、とても面白かった。最後の榊さんの一言がカッコいい。 対談でも語られているけど「まずやってみる」とか「まず先に目標を立てて、それを実現するためにはどうすれば良いか頭を振り絞る」みたいな考え方は、エンジニアの思考とは少し違う部分があるので、自分で飛び込んでみないとなかなか身につかない感覚な気がする。一方、この思考に慣れすぎると今度はエンジニアの気持ちに寄り添えなくなることもあったりするので、両者を繋ぐことが CTO やエンジニアリングマネージャの一つの役割なのかなーと思うことがあります。ビジネスの成果とエンジニアの満足、これを両立させるのが難しいからこそ組織づくりが重要なんだろうなと。 エンジニアの理想郷を作るのが CTO の仕事ではないので、エンジニアに対して甘すぎてもいけないし、ビジネスには妥協なくコミットしていかないといけない。ここの塩梅をしっかり取っていこうと思ったとき
共同創業者は仲の良い友達1人がいいかも
共同創業者は何かというと、一緒に会社を起こしてくれる人です。で、どんなにイケている社長でも、1人ではできることは限られるわけで、やはりいいチームにしていく必要がある、というのはスタートアップ業界ではよく言われることです。 創業時に社長が立ち上げて、だんだんとメンバーを集めていく、というケースも普通ですが、最初1人なのと、最初から2人なのでは、やはり2人でやりはじめたほうがはるかに創業者の負担は少ないと思います。 そして、決まりはないですが、共同創業者は、取締役になるケースが多いと思います。執行役員だったり、一メンバーだったりするケースも珍しくはないですが、それはどちらかというと、「創業者が、だんだんと人を集めている」ケースに近いので、共同創業とは呼ばないのが一般的かもです。 となると、「じゃあ共同創業者ってどうやって見つければいいの？」というところが問題になります。 そもそも、共同創業者に
成長事業の代償「技術的負債」を解消する！既存ラクスルの「解体」が生んだ新たな価値 | SELECK [セレック]
変化の激しい現代におけるシステム開発では、できるだけ早くプロダクトを世の中に出してフィードバックをもらい、またプロダクトを磨く…というリーンな開発サイクルを高速で回すことが重要だ。 しかし、このトレードオフとして生まれるのが、システム開発における「技術的負債」だ。 ラクスル株式会社では、2017年に「Raksul Platform Project」を立ち上げ。「触れば誰でも怪我をする」PHP40万行、JavaScript10万行という規模の巨大なアプリケーションが抱えた技術的負債の返済に着手した。 その目的は、既存ラクスルの解体。一枚岩のシステムを機能ごとに小分けすることで、それぞれ独立したチームがアジャイル（俊敏）に顧客へと価値を届けられる状態を目指した。 結果として、技術的負債を大きく返済することに成功。創業当初から描いてきた「印刷産業を変えるプラットフォームになる」ための事業の多角化
![成長事業の代償「技術的負債」を解消する！既存ラクスルの「解体」が生んだ新たな価値 | SELECK [セレック]](https://cdn-ak-scissors.b.st-hatena.com/image/square/34fac6d04d3d2fc04278660aeae588332eece96b/height=288;version=1;width=512/https%3A%2F%2Fdpd29bjwmgbr8.cloudfront.net%2Fwp-content%2Fuploads%2F2021%2F05%2F11122652%2F97019519de0b032589501f0a6693213e.jpg)
18-E-5_Uzabase_高山温_デブサミ登壇資料
Babylon.jsと色々なものを組み合わせる：ブラウザのAPIやガジェットや2D描画ライブラリなど / Babylon.js 勉強会 vol.3
大きなプロダクトの育て方
Developer Experience Day 2021での発表資料です https://dxd2021.cto-a.org/developer-experience-day-2021
メドピアCTOが明かす、技術的負債を乗り越えるためにやったこと
2019年6月20日、TECH PLAY SHIBUYAにて「CTOが考える、チームで向き合う技術的負債との付き合い方」が開催されました。メドピア・SansanのCTOが、自社における技術的負債といかにして向き合ってきたか、その経緯と取り組みを語りました。（※当初登壇予定だったアイスタイルCTO竹澤氏は体調不良により欠席）。プレゼンテーション「ぼくらはこうして乗り越えてきた！」に登壇したのは、メドピア株式会社執行役員CTOの福村彰展氏。講演資料はこちら 医師専用のコミュニティサイトを運営するメドピア 福村彰展氏（以下、福村）：始めさせていただきます。今日のタイトルは「チームで向き合う技術的負債との付き合い方」ということで。私からは「ぼくらはこうして乗り越えてきた！」というテーマで、みなさんに有用な情報をお伝えできればと思いますので、よろしくお願いします。 まず、私の自己紹介からですね。 メ
DX Criteriaとは - DX Criteria v201912- 「２つのDX」とデジタル経営のガイドライン
DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会の個人会員様と議論をおこないながら、適宜アップデートをしていくものです。 https://dxcriteria.cto-a.org
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
なぜレッドオーシャン化する前にサービスを グロースできなかったのか？ - フリマアプリ編 - @yutadayo
Council Post: Should The CTO Code? 16 Tech Leaders Weigh In