CTOの頭の中：技術と組織と牽制関係｜Shin Takeuchi
うちの会社には技術的なCXOとして、CTO、CIO、CISOの3パートがあります。何が違うねん、という話なのですが、ここにはのっぴきならない事情と仕組み化の流れがあって、3つのロールに分けました。このあたりの話を今日はつらつら書いてみたいと思います。 CTOの責任昔はCTOこそ全てのバランスを有し、社長よりも俯瞰したロールであれ、的な思想を持っていました。というのもマーケットを理解し、P/L、B/Sも理解しながら先日書いたG/Pを最大化しろ、また負債をいつどのようにどうやって減らしていくのかを考え、説明責任を果たし（その間機能開発力が落ちるかもしれないし）、実行しなければならない。これらは、短期的な収益と中長期的な投資をバランス良く、柔軟に判断しなければならない、という意味で、できりゃいいのですが簡単ではありません。特に簡単ではないのが、結局社長なり、トップの視点、視野にこの広大さと深さが
CTOの頭の中：技術を財務で表現する｜Shin Takeuchi｜note
会社の体制が大きく変わり、カオスの中に少しの静寂（暇）ができました。特に日々執行に勤しんでいる方々は皆そうだと思いますが、色んなこと考えているのにそのプロセスをアウトプットする機会があまりなく、結果や結論、最終的な決断のみが共有されるため、サクセッションプランに対する有効な情報を残すことも出来ていないことと思います。僕もその一人。 この時間を有効に活用するため、頭の中にあるイメージと考え方をここに、時間の許す限り吐き出していこうと思います。時折、言葉が足りないところも前提条件やバイアスの記述が足りないところもあるかと思いますが、混沌とした頭の中を曝け出すプロセスにはつきものですので、大目に見ながら読んでいただけると幸いです。 財務諸表と同じように見える化する会社は財務諸表によって経営されるものなので、経営者たるもの財務諸表を見ながら戦略を立てるべきであると僕は考えています。数字以外信じない
1on1.md
1on1.md これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。 概要 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。 グループ/チームでのミーティングを補完するためのものです。 みんなの前では話しづらい、込み入った内容を話します。 チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿ってい
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 本記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで
プロジェクトをリードする前に読みたかった本 - motokieeの日記
この1年ほど、プロジェクトのリードを任せてもらえるようになりました。2017年の夏くらいから「プロジェクト推進役」→「PJO」→「Tech Lead」, 「Project Lead」など、正式ではないものの「肩書」のようなものがついていますが、実際にやっていることは「プロダクトの成功に向かってプロジェクトを行動で引っ張っていくこと」で統一されています。 これは別に偉くなったとかではなくて、そういう責任を持ってPJに関わる役割だと思って臨んでいますし、実際マネージャーからもそのように言われています。 自分なりに試行錯誤をして時には成功し、時には失敗しながらなんとかかんとかやってきていているのですが、「あー、この本に救われた」とか「ちょっと前にこの本読んでおけばよかった...」という本があったので何冊か紹介したいと思います。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリフ
Redmine まだ使ってるの？ Trello 試してみるといいよ。【動画付き】 - Kawaz広報ブログ
こんにちは、ぎぎねっとさんとTetuさんと共に『コミュアゲ』というゲームを作っておりますハワイ長万部です。 さてさて、チーム開発と言えばオンラインレポジトリやタスク管理、円滑なコミュニケーションのとれるチャットツールが不可欠ですね。 『コミュアゲ』ではそれぞれ、GitHubと時々Dropbox（非エンジニア向け）、Trelloと時々GitHub Issue、Slackを活用しています。 さて、その中で今回取り上げるのは Trello 。( https://trello.com/ ) 『コミュアゲ』は自分にとって久々のゲーム開発ということもあって、 「 Slack の使い勝手を試してみたい」 「タスク管理ツールの Trello ってやつを試してみたい」という希望がありました。 Slack は順番前後して、結局 Kawaz全体での Hipchat からの移行が先になりましたが、 Trelloに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
