いわゆる問題解決の基本動作の一つに論点（イシュー）を明確化することが挙げられる。論点とは文字通り、何を論じるべきかを明確にしたステートメント（一文）である。議論をする際には必ず論点が明確になっている必要がある。しかし現実にはこの論点に沿って物事を議論することは難しい。論点思考ができるには結局のところは慣れではあるが、いくらかのコツは存在するので本エントリでは自分なりのコツを述べていきたい。 一つ目は論点には必ず「べき (Should)」を入れる必要がある。理由は「べき」が入ってると判断を含む行動に結びつくためである。物事を議論する目的は詰まるところ結論、すなわちアクションを明確化することにある。そのため、原則としてどのような論点でも、強引にでも必ず「べき」を入れる習慣を身に付けるべきである。強引にと述べたのは、陥りがちな傾向として論点を分解したサブ論点で「べき」が消えることが多いためである

自分は元々とにかく技術志向のエンジニアであり研究者であった。とにかくコードを書いたり論文を書いたりすることが生き甲斐であった。 そんな自分が数年前に色々考えた結果、マネージャーや経営者の道を志すようになったのだが、その際によく聞かれることがある。「技術を中心にやれなくなる不安や葛藤はなかったんですか？」と。 その答えとしては「その不安や葛藤はない」である。なぜかというと、マネージャーや経営者に強烈な専門性を感じているからだ。勉強すればするほど、あれ、これはエンジニアや研究者の時にやっていた学び方とほとんど変わらないのではないか、と思えているからである。 おそらく僕自身も、かつてはマネージャーや経営者に専門性を見出せておらず、エンジニアからそうなることは考えてもいなかった。むしろ、技術者としての諦めのような風に捉えていたかもしれない。しかし、自分がそこに身を置くにつれて、全くもって雰囲気で適

って話をPHPカンファレンス2018でしてきます（1時間後に過去形になります って話をPHPカンファレンス2018でしてきました。 2018/12/16時点で動画とFAQの内容を追記しています。 phpcon.php.gr.jp 当日の登壇資料はこちら。 当日の動画です www.youtube.com ※ 5:41:20 くらいからが僕の動画です。 ※3ヶ月以内を目処にセッション毎に割ってくれるみたいです 内容補足 Webサービスは成長と共に変化していくので、つまりは変化に強いチームというのは重要になります。 では変化に強いチームとはどうやってつくるのか？って話が今回のテーマです。 チームビルディングってとても重要なのは周知の事実だけど、じゃあどうやって？って言うHow toは意外と語られません。 それは「答えが無い」ってのもありますが、プレイヤー目線とマネージャ目線（経営者も含む）で大き

「ソフトウェアと経営」マガジン始めました 幾つかのスタートアップからGunosyのCTOや新規事業担当を経て、現在はDMMのテックカンパニーへの改革を進めています。その中でソフトウェアを経営に活用する・企業のデジタル化を支える自分なりのフレームワークが見えてきました。これまで部分ごとに都度発信してきたのですが、ソフトウェアからマネジメント、会計など様々な領域にまたがる知識を整理して発信したいと思い、これらをまとまった形式でnoteのマガジ もっとみる

何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている

経産省の「未来人材ビジョン」はとてもよく書けていて、日本の現状を突きつけるものだった。 https://www.meti.go.jp/press/2022/05/20220531001/20220531001-1.pdf 残念だけど、日本はすでに詰んでいて、今後も停滞が続くと個人的には思っている。僕がその見識を信頼する人たちも、大声では言わないけれども同じような意見だ。 なぜ詰んだといえるのか。いろいろな理由はあるけれども、一番深刻なのは高齢化と硬直的な人事制度だと思う。 社会に高齢層が増えることの一番の問題は「人は年をとると昔の自分より頑迷になる」という一般的事実に基づいている。これは高齢者攻撃の話ではなく、人間の脳は年齢とともに劣化するという事実の話だ。そして、人間はよほど自覚的でないと自分の脳の劣化には気づかない。より多くの頑迷な人が投票権を持っているので、政治は基本的にその人たちを

はじめにこれは何？ 数カ月間マーケット調査、商談をして見えてきた日本とグローバルでSaaSプロダクトに求められることの違いを紹介する 誰向けの記事？ グローバルで利用されるプロダクト開発に興味のあるPdM, エンジニアの方 まとめると？ 競合がエグい。日本はプロ野球で、グローバルはメジャーリーグみたいなイメージ。プロダクトは広く浅く→狭く深くに要件が変わる。 エコシステム、SaaS市場の成熟度の違いから、インテグレーションファーストになる 時差や人件費の違いがプロダクトに影響を与え、セルフサービス前提の設計になる 伝えたいこと グローバルで使われるSaaSプロダクトづくり（＝メジャーで野球する）、そしてそこで勝つためのプロダクト・開発組織づくりに経営者として本気で取り組みます。 メジャーで勝利するために、優秀なメンバーが集まり、切磋琢磨し、成長できる環境。勝ち筋も見えています。他ではできな

OCHaCafe Season4 #4の資料です． デモのソースコード等はこちらをご参照ください．

自分が複数のシステムの開発を経験して得た確信として、「認証と認可と課金とコアドメインの分離がめちゃくちゃ重要である」というものがあるので、コレを整理してアウトプットしていく 分離するモチベーションとは Microservice文脈でいうと、デプロイ独立性だったり、リソースの最適配分だったり、障害の局所化だったり、開発組織とのマッピングだったりがメリットとして語られることが多い。 だが、ここで取り上げたいのは戦術的DDD的観点でのコンテキスト分離の有用性である。 ※ちなみにコンテキスト分離のみであればモジュラモノリスだけで実現可能。 戦術的DDD的観点での関心事の分離によるメリットとは コンテキストが分離されていることによって、境界をまたぐ際に「このI/Fは正しいのか？」を都度考えることを強制することができる。 境界がなければ意図しない密結合を生みやすくなってしまう。 もちろん、境界を超える

NLP2024 参加報告LT ~RAGの生成評価と懇親戦略~ / nlp2024_attendee_presentation_LT_masuda

田島 篤（以下、田島）　及川さんはエンジニアとして著名ですけれども、近年はITを有効活用するための企業支援もされていますね。早速ですが、どんな本を読まれてきたのでしょう。 及川卓也（以下、及川）　これまでに読んできた本をまとめてきたので、それに基づいてお話ししますね。「学生時代に読んだ本」「ITに関する本」「プロダクト開発に関する本」というように、年齢や仕事の内容に応じて、多くの本を読んできました。 ●高橋三千綱 『シスコで語ろう』（角川文庫） 『九月の空』（角川文庫） 『対岸の祝日』（角川文庫） 『天使を誘惑』（新潮文庫） ●三田誠広 『僕って何』（角川文庫） 『赤ん坊の生まれない日』（河出文庫） 『Mの世界』（河出文庫） 『考えるウォークマン』（角川書店） ●村上龍 『限りなく透明に近いブルー』（講談社文庫） 『海の向こうで戦争が始まる』（講談社文庫） 『コインロッカー・ベイビーズ（上

リモートワークにおけるファシリテーションの方法論 ーミーティング・プロジェクト・組織ー 2020.05.18

CTOとしてプロダクトマネジメントに軸足を置いてから半年ほど経過し、エンジニアリングマネジメントの観点で新しい気付きがうまれてきたので、記事にしてみる。 この記事で述べることこの記事では、back checkでプロダクトマネジメントをする上で試行錯誤してきた内容を踏まえ、プロダクトマネジメントを遂行する上で必要な人のアサインとキャリアについて言及していこうと思う。 まずは「back checkがプロダクトマネジメントの観点でどういう課題に直面したか」を述べた上で、「組成した新規チームのミッションとアサイン」を述べ、そこから学んだことを述べる。 その上で、一個抽象化し、「プロダクト運営上発生する不確実性」を述べた上で、「適性をもとにしたエンジニアリングマネジメントのセオリー」を考えていく。 プロダクトマネジメントでやってきたこと自分がback checkのPMとしてジョインしはじめたのは20

今年も書きます。 kths.hatenablog.com kths.hatenablog.com 能力主義のパラドックス 自分が客観的で公正な人だと信じてしまうことで、偏向した行動をとってしまう現象を「能力主義のパラドックス」というそうです。 韓国で16万部超のベストセラーとなった『差別はたいてい悪意のない人がする』では、全員に同一の基準を適用することが、だれかを不利にさせてしまう間接差別の例について紹介されています。 だれに対しても同じ基準を適用することのほうが公正だと思われるかもしれないが、実際は、結果的に差別になる。司法書士試験で、問題用紙・答案用紙と試験時間をすべての人に同一に設定すれば、視覚障害者には不利になる。製菓・製パンの実技試験において、すべての参加者に同じように手話通訳を提供しない場合、聴覚障害者に不利である。公務員試験の筆記試験で、他の受験生と同様、代筆を許可しない場合

カミナシでEM(エンジニアリングマネージャー)をしている宮本と申します。 カミナシには現在CTOがいません。 ただ、採用活動は進めておりますので、近い内に採用活動が花開くことを切に願っております。 本記事では、将来のCTOを迎えるにあたり、EMである私が直近半年で何を考え、どんな対応をしてきたかについてまとめました。 カミナシが求めるCTOとはCTOを採用したいという話が挙がった際、カミナシは具体的にどういった方をCTOとして迎えたいのか議論になった事があります。 ここでよく議論の分かれ目になるのが、実務者のTOPとしてのCTOか、経営者としてのCTOか、という2つの観点です。 当然、両方の性質を備えているのが望ましいのですが、究極的にどちらの要素しか満たさざるを得ない場合、どちらを選択すべきか関係者の認識を揃えておく必要があると思います。 結論、カミナシでは経営者としてのCTOを優先した

こんにちは、PMをしているmacyamazakiです。 今回は自分自身でPMを経験してきて、そしてPMの採用プロセスにも参画した経験から、スタートアップでのPMの採用難易度がめちゃくちゃ高いことに気づきました… そして副業PMでどう価値を出すのか友人からの相談が多いです。自分自身も一時期同じ問題で悩んだことがありました。 副業スタートからでもOKというPM求人もよく目にしますが、実際PMの仕事って週10時間じゃコアなところまで関われない・結果にコミットできないしそれって本当に幸せなのかな？と疑問に感じます 🤔 サンプル数は少ないものの、現在お手伝いさせていただいているスタートアップで、 『ジュニアPMとペアになってタスク分配すると、上手くいって成果が出せた』 のでノウハウの共有です！！ ☝🏻注意☝🏻 : 実体験のサンプル数1なのでもっとブラッシュしていきたいです。 副業でPMをされて

いつでもどこでもモノがトドク、世界的な物流ネットワークを創りたい、207株式会社のイナバです。 207の1on1、めっちゃ良いんです！！ 先日の忘年会で業務委託の方に「207に所属していて良いところは何か？」とお聞きして「1on1、めっちゃ科学されていて良いですよね」という話題に上がるくらいには良いです！ 私自身、業務委託で色んな会社を見ているのですが、たしかに207の1on1は凝っていると思います。 という事で、本記事では「どんな質問を」「どんな意図で」しているのかを代表にインタビューしてきたのでまとめていきます。 1on1をやる目的 そもそも1on1を実施してよかった点ですが、たくさんのメリットの中でも特に、 - 認識のズレをなくす - 信頼関係を構築する - アラートの早期検出 みたいな効果を享受できています。それぞれ、どういう意味かをご説明していきます。 認識のズレをなくす 業務上

コロナ禍において、多くの企業がテクノロジーを活用し、自社のビジネスを再定義するケースが多く見られました。また、ソフトウェア業界自体も成熟化が進んでいますが、そのような状況でも企業はさらなる成長を求められています。 その際に、成長手段の1つとしてM&Aが考えられます。そして、CTOは異なる文化の開発組織を融合し、ビジネスインパクトを生み出すことを求められます。しかし、異なる文化の組織を融合させることは容易ではありません。 今回は、前ZOZOテクノロジーズ執行役員CTOで、現BuySell Technologies 取締役CTO 今村さん(@kyuns)に「異なる文化の開発組織を融合させるためのCTOの役割」というテーマでお話を伺いました。 開発組織のPMI（組織統合） M&Aを行うと、次にPMI（Post Merger Integration）と呼ばれる、統合プロセスが発生します。その際、C

これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必