並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 160 件 / 161件

新着順 人気順

management-memoの検索結果121 - 160 件 / 161件

  • 不確実性に立ち向かう一つのTips〜リスク管理に取り組んだ話〜 - BASEプロダクトチームブログ

    こんにちはエンジニアリングマネージャーをしております植田です。4月18日にグロースプランの提供が開始されました。今回この開発プロジェクトにて「リスク管理」に取り組んでみたのでそのお話をします。 Index リスク管理に取り組んだ背景 そもそもリスク管理とは 具体的なリスク管理の進め方 リスク管理はどのようなプロジェクトで実行すべきか 実際にどのように取り組んだか 取り組んで良かったことと、今後発展させたいこと リスク管理に取り組んだ背景 まず今回なぜリスク管理に取り組んだかをお話します。BASEでは現在大小様々な開発プロジェクトが同時進行していますが、日に日にその複雑性は増しています。年月を追うごとに積み重なる仕様、日に日に拡大していくリポジトリ(ソースコード群)…と、複雑性・難易度は増す一方です。その中で、開発プロジェクトもいわゆる「不確実性が高い」と言われることが当たり前の状況になって

      不確実性に立ち向かう一つのTips〜リスク管理に取り組んだ話〜 - BASEプロダクトチームブログ
    • ソフトウェア開発サイクルの改善を行う際に認識すべきボトルネックの種類 - stefafafan の fa は3つです

      去年認定スクラムマスターになって、実際に自分の開発チームにScrumを導入したり、最近ではチーム内でテックリード交代して開発プロセスの高速化についてより考えるようになってきた。 Agile, Lean, XP, DevOps, Four Keys, Team Topologies など様々なフレーズを見かけたり本を読んだりしたところ大体皆同じ場所を目指していると感じるけど、イマイチ自分の脳内インデックスが貼れていない気がしたのでこのエントリで軽く考えを整理してみようと思う。 とにかく改善のサイクルが回っていない (ソフトウェア開発に限らない) 開発速度が上がらない (ソフトウェア開発者側) Extreme Programmingのプラクティス DevOpsのプラクティス チーム内での連携が上手くいっていない チームの構成がイマイチ・他チームとの連携が上手く取れていない まとめ とにかく改善

        ソフトウェア開発サイクルの改善を行う際に認識すべきボトルネックの種類 - stefafafan の fa は3つです
      • 生産性指標をFour Keysから変更した話 - Sansan Tech Blog

        技術本部 Mobile Applicationグループの山本です。名刺アプリEightの開発を行っています。 今回はMobile ApplicationグループのEight開発チームの生産性指標をFour Keysからベロシティを含む別の値に変更した話をします。 一般的にはベロシティは生産性指標にすべきではない、Four Keysは生産性指標として適切であるという評価だと思います。もちろんそれは理解した上でこの選択をしています。その理由について説明します。 なお組織全体がこのように考えているわけではないということに御注意ください。例えば同じMobile ApplicationグループでもSansan開発チームはFour Keysを生産性指標にしています。 生産量2倍計画 現在技術本部では中期的な課題として1年で単月の生産量を2倍にするという目標を掲げています。 ポイントとして、技術本部のレ

          生産性指標をFour Keysから変更した話 - Sansan Tech Blog
        • 3つの⽴場で考える技術的負債への組織的アプローチ

          ■イベント 技術的負債に向き合う Online Conference https://findy.connpass.com/event/297813/ ■登壇概要 タイトル:3つの⽴場で考える技術的負債への組織的アプローチ 登壇者:VPoE / VPoP 西場 正浩 ■Sansan技術本部 採用情報 https://media.sansan-engineering.com/

            3つの⽴場で考える技術的負債への組織的アプローチ
          • 開発マネージャがメンバーに知って欲しい事 ※随時更新 - Qiita

            はじめに 開発マネージャーがメンバーに知って欲しい事を纏めた記事です。随時、更新します。 前提 新人向け Webアプリケーション開発 Learning 開発は常に学び続ける事になるので、「どう学ぶか」を考える。 メタ認知 自分を客観的に認知する。 Self Management 自己管理を行う。 守破離 学びのプロセスを理解する。 継続力 継続する手法を理解する。 Thinking 開発では考える事が多いので、その為の基本を学ぶ。 Logical Thinking 論理的な思考方法の基本を理解する。 参考書: Thinking Framework 思考を整理する際に利用するフレームワークを知る。 Thinking Backwards 逆から考えると言う思考法を習慣づける。 参考書: Document Business Document ビジネス文書の書き方の基本を理解する。 文章は長くなり

              開発マネージャがメンバーに知って欲しい事 ※随時更新 - Qiita
            • IT人材 2021年まとめと2022年トレンド予測:難航し続ける採用と定着|久松剛/IT百物語の蒐集家

              年始ということもあり、去年に倣って2022年版も書いてみたいと思います。主に人の流れの観点から採用と定着にフォーカスしながらお話をしていきます。 スタートアップの光と影先立ってキャリアの地図2021が公開されました。企業名をクリックするとどこから人が入ってきて、更にどこへ行くのかが記載されています。規模感が分かりにくいところではありますが、日本の大企業の人材輩出感(インがなく、アウトだけある)、外資コンサルとスタートアップの吸引力が目立ちます。

                IT人材 2021年まとめと2022年トレンド予測:難航し続ける採用と定着|久松剛/IT百物語の蒐集家
              • 開発生産性カンファレンス 2024を堪能してきました - $shibayu36->blog;

                dev-productivity-con.findy-code.io 自分の所属しているクラスター社に相談したところお金を出してもらって参加できることになったので、開発生産性カンファレンス2024に行ってきました。自分が開発生産性に非常に興味が強いため各セッションすべて興味深く、またこれまで名前は知っているけど話したことのなかった人と色々と会話ができて、非常に堪能できました。 運営のファインディ株式会社のみなさん、ありがとうございました。 興味深かったセッション 顧客価値向上による開発生産性向上 顧客価値を高めるという観点にフォーカスした発表でした。 顧客価値を高める領域かは狩野モデルを使って考えるという話。狩野モデルはよく聞くが、ちゃんと使ったことないので試してみたい 当たり前品質は、品質を高めすぎても、顧客価値に繋がらない = アクセルブレーキなどの基本操作 一元的品質は、高めれば高め

                  開発生産性カンファレンス 2024を堪能してきました - $shibayu36->blog;
                • マネーフォワードCTOが考えていること(2021年9月) - Money Forward Developers Blog

                  こんにちは。 マネーフォワード CTOの中出(なかで)です。 CTOの私が、普段「なにを感じて、どんなことを考えているか」について、四半期に一回社内へ共有している内容を一部編集し、エンジニアブログに公開したいと思います。 前回はこちら:マネーフォワードCTOが考えていること(2021年6月) 目次 エンジニア組織の英語化 VPoEがベトナム拠点に赴任 AI領域のエンジニアの採用拡大 名古屋拠点の設立準備 エンジニア組織の英語化 マネーフォワードはグローバル企業を目指します。 今後、より積極的に世界中から優秀なエンジニアの方の採用を進めていく目的で、2024年度中を目処に、社内エンジニア組織における仕事上のコミュニケーション言語を英語にすることを決定しました。 ※ 全社のコミュニケーション言語はこれまで通り日本語となります。 今後の実施イメージ: 英語話者が配属されるチームから順次開始(20

                    マネーフォワードCTOが考えていること(2021年9月) - Money Forward Developers Blog
                  • 事業開発におけるBSとPLの考え方 - SaaSベンチャーで働くエンタープライズ部長のブログ

                    事業開発は、企業が長期的な成功を収めるために必要です。事業開発においては、PL(損益計算書)型とBS(貸借対照表)型の二つの異なる考え方があると考えています。PL型は売上や利益の追求に焦点を当て、BS型は将来のPLを見越して資産を積み上げることに重点を置いています。この記事では、私の経験から、これら二つのアプローチの特徴、利点、そして潜在的な落とし穴について詳しく記します。 売上や利益を追求するPL型の事業開発 PL型事業開発の落とし穴 短期的な成長を追ってしまう 製品・組織が発展しない場合がある BS型の事業開発 BS型の事業開発とは BS型の事業開発は長期的に有益になる まとめ 売上や利益を追求するPL型の事業開発 PL型の事業開発は、短期的な成果に注目し、売上や利益の最大化を目指します。このアプローチは市場での迅速な対応や競争上の優位性を確保する上で有効です。一方で、短期的な目標に集

                      事業開発におけるBSとPLの考え方 - SaaSベンチャーで働くエンタープライズ部長のブログ
                    • 【SaaS】スタートアップ200社と話して分かったSaaS立ち上げの「Don’t」 | 岩澤 脩 | UB Ventures

                      UB Venturesでは2018年のファンド立ち上げ以来、延べ200社以上のSaaS起業家と面談の機会を得ることができました。 ビジネスにおける成功の要因は各企業それぞれであり、時には思いもかけない成長を目の当たりにすることもあります。 一方で「SaaS立ち上げで陥りやすい罠」にはいくつかの共通点が見られます。 私自身がユーザベースでのプロダクト立ち上げ時にした失敗と同じように、様々な起業家においても同様の問題に悩んでいる姿を目の当たりにし、このタイミングで言語化したいと思うように至りました。 ここではSaaSスタートアップの「Don’t – 事業立ち上げ編」と題し、ビジネス立ち上げで気を付けるべき点をまとめていきます。 ① SaaS KPIの全方位的トラッキング 数年前と比べ、SaaS KPIの概念が一般化し、MRR(Monthly Recurring Revenue)、Churn、N

                        【SaaS】スタートアップ200社と話して分かったSaaS立ち上げの「Don’t」 | 岩澤 脩 | UB Ventures
                      • エンジニア組織の開発生産性を いかに定量化し、改善する?〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜

                        エンジニア組織の開発生産性を いかに定量化し、改善する?〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜 近年、メガベンチャーや大規模調達を果たしたスタートアップでは、エンジニア組織は拡大し、開発環境やプロセスも複雑化しています。それに伴い、採用や人事、組織づくりを担うエンジニアリングマネージャー、技術領域の課題解決を推進するテックリードの重要性も高まっています。 2022年2月24日に開催した『EMとテックリードに聞くエンジニア組織づくり最前線vol.4』では、株式会社マネーフォワードと株式会社アンドパッドでエンジニアリングマネージャーやテックリードとして事業や組織の成長を率いるお二人に、現場のリアルな課題や取り組みを語っていただきました。 登壇者 柴﨑 優季さん/株式会社アンドパッド[@shiba_yu36] 2021年10月に株式会社アンドパッドに入社。アカウント基

                          エンジニア組織の開発生産性を いかに定量化し、改善する?〜マネーフォワードとアンドパッドの EM・テックリードによる実践〜
                        • エンジニアの“自立”には2種類ある ソウゾウとSmartHRの取締役が語る、成長と育成

                          エンジニアtypeとメルカリが共同開催したテックカンファレンス『Tech Update 2022』で実施された、今注目のスタートアップ2社の事例からひもとく「成長&自立を後押しするカルチャーのつくり方」のセッション。ここに株式会社ソウゾウの名村氏、株式会社SmartHRの芹澤氏が登壇。まずはそれぞれの企業がエンジニアの自立を意識したきっかけについて。 登壇者・モデレーターの自己紹介 司会者:本日の登壇者のみなさまの紹介に移りたいと思います。では、モデレーターの広木さんから名村さん、芹澤さんの順番で一言ずつ自己紹介と、ぜひ本日の意気込みを教えてもらいたいと思います。 広木大地氏(以下、広木):どうも広木です。チャットに反応を書いてもらえるとすごくやる気が出るので、「こんにちは」でもなんでもいいので、コメントもらえるとうれしいです。今日は、お二人からいろいろな話が聞ければいいなと思って引き出し

                            エンジニアの“自立”には2種類ある ソウゾウとSmartHRの取締役が語る、成長と育成
                          • EMのトレンド?もしくはその兆し (2022年)

                            2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人(や組織)のマネジメントに専念させるパターンが出てきている、ということです。 もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。 プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容(開発者であれば技術的なこと、デザイナーであればデザイン的なこと)と、人(と組織)に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果と

                              EMのトレンド?もしくはその兆し (2022年)
                            • プロダクト開発チームの分断に立ち向かう - yigarashiのブログ

                              先日のRSGT2023で以下の発表がありました。「自分がそれほどプロダクト開発に興味がないことに気づく」は自分自身にも心当たりがありますし、プロダクト開発チームのリアルを言語化した発表だと思いました。この発表では、そうした言語化を受けてどうするのかについては深く触れられておらず、回答は聴衆に委ねられていることから、さらに議論を広げてみようと思います。 実際問題、真に興味を持つのは大変 現代のプロダクトマネジメントは、ひとつの深遠な専門領域になっていると思います。「本が1冊書ける」なんてレベルではありません。何百冊、何千冊と書ける世界です。そうした専門知識を組み合わせ、市場とユーザーとプロダクトを徹底的に分析し、データに基づいて仮説検証を繰り返し、それを自分のプロダクトに接続する方法を捻り出して、ようやく少し尤もらしい方向に近づきます。とても過酷な領域です。 ここにエンジニアが越境して興味を

                                プロダクト開発チームの分断に立ち向かう - yigarashiのブログ
                              • 組織の遠心力への立ち向かい方 - NTT Communications Engineers' Blog

                                この記事は NTTコミュニケーションズ Advent Calendar 2023 の5日目の記事です。 こんにちは、イノベーションセンター所属の岩瀬(@iwashi86)です。普段は生成AIチームのエンジニアリングマネジメントをしています。 この記事では「組織の遠心力」をテーマに組織を強くする方法について書いていきます。本記事を読むことで、組織改善策の一案が得られることを狙っています。 なお、本記事は一人のエンジニアリングマネージャーである @iwashi86 の主観を多く含みます。NTT Com内には多くの考え方があり、その1つとして受け取っていただければ幸いです。 組織の遠心力って何だろう? 同じ組織の @mizuman_ が社内講演した「最強のチームが最高のプロダクトを作る」というスライドがあります。 詳細は上記スライドをぜひご覧いただければと思いますが、チームが良ければ良いほど、プ

                                  組織の遠心力への立ち向かい方 - NTT Communications Engineers' Blog
                                • アジャイル開発の「人的側面」の課題を解決する「システムコーチング」

                                  はじめに アジャイル開発では、技術やビジネスといった側面だけでなく、開発を担う人々の「人的側面」への取り組みが欠かせません。この記事では、その「人的側面」を強化する効果的なアプローチとして、「システムコーチング®」を紹介します。 特に「アジャイル・フルーエンシーモデル(アジャイルのプラクティスを包括的にまとめるモデル)」とシステムコーチングとの相互補完性に焦点をあて、ログラスの事例を交えて具体的な効果を探ります。システムコーチングを導入することで、チームや組織にどのようなインパクトがあるのか、そのポイントをお伝えします。 アジャイル開発とは アジャイル開発は、顧客の要求に迅速に対応するためのソフトウェア開発手法の総称です。短期間のイテレーションを通じて、開発チームは頻繁に製品のリリースを行い、顧客のフィードバックをすばやく取り入れることができます。 このアプローチはその柔軟性と迅速性により

                                    アジャイル開発の「人的側面」の課題を解決する「システムコーチング」 
                                  • エンジニアの採用情報をまとめた GitHub Repository を公開しました #GameWith #TechWith - GameWith Developer Blog

                                    ごぶさたしています。@serima です。 このたび GameWith では採用情報をまとめた GitHub Repository を公開しました。 github.com 採用に関する情報の分散化問題 GameWith ではエンジニアを積極採用中ですが、いざ採用候補者の立場にたってみると情報が各所に分散しており、せっかくの情報発信が十分に届いていないのではないかと感じていました。 たとえば年単位で運用している技術ブログの記事のなかで、どれが現在の会社の雰囲気や開発スタイルを適切に伝えているものなのかは外からでは分かりません。 さらに昨今は、採用にまつわる情報があらゆる媒体に分散して掲載される傾向があり、候補者視点では情報の収集も一苦労です。 特に、なかの人のインタビュー記事は自社運用の Wantedly や外部の求人媒体などそれぞれで掲載されたりする傾向が強いように思います。 さまざまな媒

                                      エンジニアの採用情報をまとめた GitHub Repository を公開しました #GameWith #TechWith - GameWith Developer Blog
                                    • EM見習いとして1on1と採用計画見直しを実施して感じたこと - Commune Engineer Blog

                                      自己紹介/経歴 コミューン株式会社でcommmuneチームのEM(Engineering Manager)見習いをやっている いちろー と言います。 今迄20年間位、ほとんどのキャリアを開発につぎ込んで決ましたが、2022/02のコミューンへの転職を機にEM的な仕事を行なうようになりました。 27歳位まで、とあるSIerの下請け会社の技術サイドのトップをやっており、技術的なマネージャ、アーキテクト、技術チームの評価、メンタリングなどをやっていました。 でも、その会社を辞めた後は、一環してアーキテクト、プログラマーとして物作りを行なっており、それがプライドでありアイデンティティでありました。 というわけで、現在のWeb系でモダンなマネージメント手法に関しては情報をあまり持っておらず、素人の気持ちで職務に当ってます。 このentryで伝えたい事 EMの仕事って意外とフワフワしている部分があるか

                                        EM見習いとして1on1と採用計画見直しを実施して感じたこと - Commune Engineer Blog
                                      • 【新刊】エンジニアリングマネージャーのしごと - ナイスビア珍道記

                                        8月に出る新刊のお知らせです! 企業でよくある人事制度では、技術職の上位職としてテクニカルスペシャリスト職とマネジメント職が用意されている、というのをよく見ます。 わたしも前職でまさにそういう人事制度のもと、管理職として本を読んだり研修を受けたり相談したり、いろいろやってた記憶があります。 いざ管理職になるといっても、用意されている研修プログラムは薄らボンヤリした一般的な内容で(そりゃそうですよね、マネジメントって人が相手なのにその実装を抜いた話はボンヤリするに決まってる)、結局マネジメントのしかたなんて誰も教えてくれないし、上司やデキる人の真似をするぐらい。個人が体得していく専門性なんて怪しいもので、センスのある人はいいマネージャーになるけど、センスがない人は全然ダメ。センスのないマネジメントの部下になんてなったら最悪。そもそもセンスってなんだ! いいマネージャーかどうかって何をもって評

                                          【新刊】エンジニアリングマネージャーのしごと - ナイスビア珍道記
                                        • 1000人の会社で部門横断プロジェクトを最短で立ち上げるコツ - SmartHR Tech Blog

                                          みなさんこんにちは!SmartHRのプロダクトマネージャー@ryopenguinです。 この記事は「SmartHRのプロダクトマネージャー全員でブログ書く2024」への参加記事です。25人が持ち回りで毎週記事を投稿します。ぜひご覧ください! 今回は「1000人の会社で部門横断プロジェクトを最短で立ち上げるコツ」を取り上げます。 プロダクトマネージャーをしていると、さまざまな社内プロジェクトに関わることがあると思います。他部署とのコミュニケーション、要望管理などなど、プロダクト間で落穂になっている課題のプロジェクトを立ち上げ、解決を目指す…そんなイメージです。 会社の人数が少ないうちは「まずはやってみる」でいいかもしれませんが、役割や人数が増えるとプロジェクトを軌道に乗せる難易度が上がります。プロジェクトをうまく進行できないとリソースが無駄になるだけでなく、社内のステークホルダーからの信頼を

                                            1000人の会社で部門横断プロジェクトを最短で立ち上げるコツ - SmartHR Tech Blog
                                          • エンジニアリングマネージャのしごとを読んだ, Ruby 開発者会議 11 月 - HsbtDiary(2022-11-17)

                                            ■ エンジニアリングマネージャのしごとを読んだ https://www.oreilly.co.jp/books/9784873119946/ 目次を眺めて発売日直後に買ったものの、無限に読む本が積んであるので後回しとしていたけど、ITエンジニア本大賞2023 が告知されているのをみて、読んでもいない本を推薦するのはいかんなと思いうりゃっと読んでしまった。感想としては大変素晴らしい本なので、シニア以上のエンジニアにはぜひ読んでもらいたい、という内容だった。 エンジニアリングマネージャの本はちょうど英語で出版されたものの翻訳のムーブが日本に来ているような気がしていて、あらゆるレイヤの本がオライリーを中心に出版されているけど、エンジニアリングマネージャのしごと、の本は抽象的かつ個人の経験談になりがちなマネジメントの話題について、多数の文献や論文を引用しながら、事象とそれに対する対策、何をすればい

                                            • UXリサーチを活用して、仮説検証プロセスを改善した話(前編)|Mercari Analytics Blog

                                              はじめまして。メルカリ Analytics チームでアナリスト兼リサーチャーをしている@tsugutoと申します。 今回のブログでは、私が分析を担当しているSeller Experience チームで取り組んでいる「UXリサーチを活用して、仮説検証プロセスを改善した話」について、2回に分けて紹介します。1回目は、取り組みの全体像について、2回目で具体的な事例を記載できればと思います。少し長いですが、お読みいただけると嬉しいです。 Seller Experience チームについて メルカリでは、PdM / Designer / Engineer / Analystでチームを組み、日々プロダクト(メルカリアプリ)の改善に取り組んでいます。私が担当している Seller Experience チームでも、全員でコミュニケーションを取りながら、機能の開発・改善に取り組んでいます。Seller E

                                                UXリサーチを活用して、仮説検証プロセスを改善した話(前編)|Mercari Analytics Blog
                                              • LIFULLにおけるエンジニアリングマネージャーとは何かを考えてみた|長沢翼

                                                先日、とあるマネージャーと話していて、LIFULLにおけるエンジニアリングマネージャーってどのようなものか。という話になりました。 LIFULLエンジニア全体では目指す姿として前回の記事でも紹介した LIFULLエンジニア像 というものがあります。 しかし、エンジニアリングマネージャーには、エンジニア像のような言葉がありませんでした。良い機会だと思いましたので、過去に社外向けの登壇でエンジニアマネジメントに関して話したものも利用して(一部修正)、この内容にも触れながら、改めて整理してみました。 (以下スライドの7-13ページ) なお、エンジニアリングマネージャーの仕事はLIFULL内でも多岐にわたるのですが、その中でもどんな階層であろうとエンジニアリングマネージャーであれば、各人の領域でやってほしいことを組織全体の観点から書いています。なお、本記事ではエンジニアリングマネージャーに必要なス

                                                  LIFULLにおけるエンジニアリングマネージャーとは何かを考えてみた|長沢翼
                                                • 管理職の仕事の7割をAIが代替、Gartnerが2024年を予測

                                                  Gartnerは2020年1月23日(米国時間)、仮想パーソナルアシスタントやチャットbotのような人工知能(AI)や新興技術が2024年までに、管理職の日常作業のほぼ69%を代替するようになるとの見通しを示した。 Gartnerのリサーチバイスプレジデントを務めるヘレン・ポイトビン氏は、こう説明する。 「管理職の役割は、今後4年間で一新されるだろう。管理職は現在、フォームの記入や情報の更新、ワークフローの承認に時間を費やしている場合が多い。AIを使ってこうした作業を自動化すれば、トランザクション管理に費やす時間を減らし、その代わりに学習や業績管理、目標設定により多くの時間をかけることができる」 AIや新興技術が管理職の役割を変えるのは必至だ。加えて、従業員はこれらの技術によって、管理作業を引き受けることなく、責任や影響力の範囲を拡大できると、Gartnerは述べている。イノベーションとA

                                                    管理職の仕事の7割をAIが代替、Gartnerが2024年を予測
                                                  • DX Criteriaとは - DX Criteria v201912- 「2つのDX」とデジタル経営のガイドライン

                                                    DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 本基準は、デジタル技術を企業が活用するために必要な要素を多角的かつ具体的に体系化したものです。ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。 また、本基準は絶対ではありません。極めて実践的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会の個人会員様と議論をおこないながら、適宜アップデートをしていくものです。 https://dxcriteria.cto-a.org

                                                    • 最適化ではなく最大化�生産性と生産量を上げるためにどう考えるか?

                                                      ■イベント 最適化ではなく最大化を - Sansan西場さんが考える開発生産性を学ぶ https://developer-productivity-engineering.connpass.com/event/309513/ ■登壇概要 タイトル:最適化ではなく最大化�生産性と生産量を上げるためにどう考えるか? 登壇者:執行役員/VPoE 西場 正浩 ■技術本部 採用情報 https://media.sansan-engineering.com/

                                                        最適化ではなく最大化�生産性と生産量を上げるためにどう考えるか?
                                                      • “大規模アジャイル”とは何か? ソフトウェアテストの課題へのアプローチを語る

                                                        スピーディにテストケースを再利用するノウハウや技術、そしてテストの「実行」ではなく「設計」の自動化に着目したアプローチ法について考える「品質か?開発スピードか?大規模アジャイル時代の品質確保」。ここで株式会社ベリサーブの朱峰氏が登壇。まずは本セッションの概要について話します。 開発ベンダー、株式会社ベリサーブ 朱峰錦司氏(以下、朱峰):あらためまして、株式会社ベリサーブの朱峰と申します。3連休明けの平日の夜遅くに100名以上の方に参加いただき、本当にありがとうございます。 私はテスト絡みでいろいろな場所で話してはいますが、ふだんどういう環境でしゃべっているかというと、自分で買ったそこそこいいWebカメラとそこそこいいマイクで、自宅でリラックスしてしゃべっています。 (しかし)本日はTECH PLAYさまの全面協力ということで、今みなさんにお見せできないのが大変残念ですが、私の前にはカメラが

                                                          “大規模アジャイル”とは何か? ソフトウェアテストの課題へのアプローチを語る
                                                        • DX Criteria ver.201912を使ってVOYAGE GROUPとfluctを自己診断してみました。 - CARTA TECH BLOG

                                                          どうも、ajitofm 準レギュラーの @makoga です。この記事は ajitofm ep.56 とのコラボ企画です。 ajitofm ep.56ではVOYAGE GROUPとfluctの自己診断結果などについて 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) | Twitter さんと楽しく語っていますので、ぜひ聴いてみてください。 この記事では、各社のCTOそれぞれが実施したDX Criteria ver.201912の診断結果を公開したいと思います。 DX Criteria ver.201912 とは DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 デジタル技術を企業が活用・コントロールするために必要な要素を多面的・具体的に言語化し、ソフトウェアエンジニアリン

                                                            DX Criteria ver.201912を使ってVOYAGE GROUPとfluctを自己診断してみました。 - CARTA TECH BLOG
                                                          • 「良いコーチ」ではなく「良いマネージャー」を。ヤフー人事が語る、事業ミッションを達成するマネージャーの3つの共通点とは。|ハイマネージャー / HiManager

                                                            「良いコーチ」ではなく「良いマネージャー」を。ヤフー人事が語る、事業ミッションを達成するマネージャーの3つの共通点とは。 「1on1はコーチングを強く打ち出しすぎると危険です」 ヤフー社内での1on1浸透を指揮していた小向さんは、そう振り返ります。 そして、コーチングは手段であり、事業ミッションの達成をすることがマネージャーの役割だと強調します。 日本における1on1の先駆的な取り組みを引っ張った、ヤフーの人事である小向さんが考える、理想のマネージャー像とは? ハイマネージャー主催「OKR/1on1/CFR勉強会#4」のレポートをお届けします。 小向 洋誌 さん ヤフー株式会社コーポレートグループ ピープル・デベロップメント統括本部 カンパニーPD本部 PD企画部 地元仙台にて起業と廃業を経験後、2005年ヤフー株式会社に入社。ショッピング、オークションの企画・営業業務を経て2012 年よ

                                                              「良いコーチ」ではなく「良いマネージャー」を。ヤフー人事が語る、事業ミッションを達成するマネージャーの3つの共通点とは。|ハイマネージャー / HiManager
                                                            • 日本では少ないが、海外では多い「スタッフエンジニア」の募集 求められる“チームへのかけ算”という役割と、そのキャリアを進むメリット

                                                              「【t_wada & masuidrive CARTA探訪】スタッフエンジニアというキャリア」は、書籍『スタッフエンジニア マネジメントを超えるリーダーシップ』の監修・解説を担当した増田氏を招き、スタッフエンジニアという役職について学ぶイベントです。基調講演には増井氏が登壇。続いて、海外におけるスタッフエンジニアの募集状況と、そのキャリアに進むメリットについて紹介します。 海外でスタッフエンジニアの募集はかなり多い スタッフエンジニアという仕事自体が日本であるか調べたんですが、僕が調べた感じでは今のところは募集している会社はなかったです。海外では多いかというと、海外ではかなり多いです。 (スライドを示して)これはスタッフエンジニアという定義の1つです。マスターの定義ではないので、どこかの会社に入って3年目の人をスタッフエンジニアと呼ぶこともあります。 「Indeed」で募集を見てみると、実

                                                                日本では少ないが、海外では多い「スタッフエンジニア」の募集 求められる“チームへのかけ算”という役割と、そのキャリアを進むメリット
                                                              • KPI経営、設定はシンプルに 組織への落とし込みも有効

                                                                東京大学大学院工学系研究科修了。大学時代の専攻はコンピューターサイエンス、機械学習。2012年大学院在学中にGunosy(グノシー)を創業。15年、東証マザーズ上場。後に東証1部に市場変更。18年にLayerXの代表取締役CEO(最高経営責任者)に就任した。(写真:的野 弘路) 奇抜なKPIは不要、シンプルさが重要 福島さんは「ソフトウエアによるKPI経営」を指針として掲げ、実行されています。連続起業家としても、多くのベンチャー企業の経営者から相談を受けるそうですね。 福島良典氏(以下、福島氏):よく「どんなKPIを設定すればいいですか」と質問をされます。KPIはベーシックなものを設定します。「どんなKPIを設定するか」よりも「どれくらいの深さ・細かさでKPIをコントロールしているか」が大事かなと思っています。 世の中のビジネスは、基本的には最終的に売り上げとコストで決まります。大体の企業

                                                                  KPI経営、設定はシンプルに 組織への落とし込みも有効
                                                                • プレゼンテーション時に「パワポ」禁止としている企業がAmazon等、徐々に増えていると聞きますが、そのような企業はなぜ「パワポ」を禁止するのでしょうか(個人的にはパワポでプレするの大好きなのですが)?

                                                                  回答 (35件中の1件目) パワポ禁止が重要じゃないんです。 ミッションとレポートラインがしっかり整備されている(大企業)かが大事なんです。 やることが明確で報告相手が明確ならAmazon流の簡潔にA4に纏めた文書が最強ですよ。作成も読むのも時間を取らず事が済みます。 テック企業でもそういった形式を好む企業が増えてるのは成熟した企業が増えたと言うことです。 でもね。 世の中綺麗に整備されたミッションばかりじゃないんですよ。ゴミを積層した非テック企業のIT環境を整備していくとか、ビジネスモデルをガラッと変える必要性がある時とか、やっぱり絵を描いて説明する以外の方法はありません。 ...

                                                                    プレゼンテーション時に「パワポ」禁止としている企業がAmazon等、徐々に増えていると聞きますが、そのような企業はなぜ「パワポ」を禁止するのでしょうか(個人的にはパワポでプレするの大好きなのですが)?
                                                                  • 「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?

                                                                    2024/2/26 「開発組織から経営層までが開発生産性を考える時代へ - DMMが伝えたい組織づくり」登壇資料 https://developer-productivity-engineering.connpass.com/event/310155/

                                                                      「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
                                                                    • 顧客満足度やNPSだけでは改善策につながらない!具体案のための心理ロイヤルティマーケティング

                                                                      『MarkeZine』が主催するマーケティング・イベント『MarkeZine Day』『MarkeZine Academy』『MarkeZine プレミアムセミナー』の 最新情報をはじめ、様々なイベント情報をまとめてご紹介します。 MarkeZine Day

                                                                        顧客満足度やNPSだけでは改善策につながらない!具体案のための心理ロイヤルティマーケティング
                                                                      • 『[イラスト解説]ティール組織』を読んだ - 別にしんどくないブログ

                                                                        ティール組織はサイボウズが目指す組織の形なので以前から存在は知っていました。しかし、ティール組織の本は500ページを超える本でなかなかハードルが高いと感じていました。 私が所属するチームで「チーム間の情報の共有がうまくいっていないのではないか」という課題が出ました。「 情報が共有されるのを待っているのではなく、各メンバーが自分から情報を取りに行く意識を持つ必要があるのではないか。これは青野さん(社長)がティール組織の話をするときに自立したチームに必要だと言っていた気がする。」という意見が挙がりました。 そこでティール組織について学ぶことでヒントが得られるのではないか」という意見がでました。最初はイラスト版がオススメという意見もあり、会社の本棚にあった本書を借りて読んでみました。 以下、読書メモです。 従来の組織の形とティール組織型 ティール型の組織を知る前に従来の組織の形について説明がされ

                                                                          『[イラスト解説]ティール組織』を読んだ - 別にしんどくないブログ
                                                                        • 「とりあえず集まって話そう!」が残念な理由

                                                                          Coach's VIEW Coach's VIEW は、コーチ・エィのエグゼクティブコーチによるビジネスコラムです。最新のコーチング情報やコーチングに関するリサーチ結果、海外文献や書籍等の紹介を通じて、組織開発やリーダー開発など、グローバルビジネスを加速するヒントを提供しています。 「たくさんの人に会議で発言してもらう」 「クチコミを見比べてレストランを選ぶ」 一見、異なる2つの行動ですが、背景には共通して「集合知の価値」があると考えられます。 「集合知」とは、個人から情報を多数集めて組み合わせ、より高度な次元となった知性や情報のことを言います。 価値ある「集合知」を多く生み出せる組織は、高いパフォーマンスを発揮するでしょう。 しかし、ただ意見が多く集まれば集合知が生まれるか、というとそうでもありません。大人数が集まった会議でも良いアウトプットが生まれないことがあります。 それでは、「価値

                                                                            「とりあえず集まって話そう!」が残念な理由
                                                                          • 24. 開発組織から部長がいなくなるまでの経緯 w/ teppeis | fukabori.fm

                                                                            話したネタ サイボウズはどのようなプロダクトを開発しているのか? kintoneの競合って? サイボウズって外注しているの?オフショアは? 組織変更したら部長がいなくなりました 部長がいなくなる組織変更する前はどのような組織だったのか? マトリクス組織、上長って複数名? マトリクス組織において、どのような問題があったのか? 職能定義に固定的に考えてしまう どのように組織変更を進めていったのか? 60組以上に今考えている課題について、ヒアリング実施 左右の壁と、上下の壁 プロダクトチームはどういうメンバ構成なのか? 組織変更は、だれが、どのぐらいの人数で、どのぐらいかけて考えていったのか? ヒアリング結果は常にオープンに 「あれ、俺の役職なくなるんじゃね?」という懸念はあったのか? 旧部長の多くは、組織運営チームにJoinした マネージャは孤独な仕事であるが、チームを組んで考えるようになった

                                                                              24. 開発組織から部長がいなくなるまでの経緯 w/ teppeis | fukabori.fm
                                                                            • [社説]ソニー復活が示すビジョンの大切さ - 日本経済新聞

                                                                              長らく低迷が続いた日本の電機大手の中で、ソニーグループの復調ぶりが鮮明だ。2021年3月期決算では初めて純利益が1兆円を超えた。ライバルのパナソニックをはじめ他の電機大手との勢いの差は歴然といえる。ここまでのソニーGの復活から日本企業が学ぶべき点は多い。最大の教えはビジョンを示した経営構造改革の重要性だろう。26日に開いた経営方針説明会。4月に社名を「ソニー」から変更して初めて吉田憲一郎会長

                                                                                [社説]ソニー復活が示すビジョンの大切さ - 日本経済新聞
                                                                              • ペアプロと建設的相互作用 - いつもあさって

                                                                                概要 教育心理学概論 の6章2節に建設的相互作用というものが出てきます。建設的相互作用を踏まえてペアプロを行なった方がペアプロの効果を高めるためられるかもという内容です。 本の内容 6章 建設的相互作用論 ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。 ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。 折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことは

                                                                                  ペアプロと建設的相互作用 - いつもあさって
                                                                                • リモートワークでのチーム開発、はいくるチームの場合【はいくる通信 第7話】 - RAKUS Developers Blog | ラクス エンジニアブログ

                                                                                  id:radiocat です。多くの企業がリモートワークに移行して試行錯誤されていることと思います。緊急事態宣言が延長されて、もうしばらくこの状況が続きそうということもあり、今回はリモートワークへの移行によって試行錯誤している私たちのチーム開発の事例をお伝えします。 組織的な取り組みやルール 朝はニコニコカレンダーを更新してチェックイン 終業時はひとこと感想でチェックアウト 連絡事項は履歴を残す リモートワークのノウハウやトラブルを記録する チーム開発の現場 タスクはなるべく小さく分解する Web会議は常時つないでおく 1対1の相談は電話感覚でWeb会議をコールする マインドマップでふりかえり さいごに 組織的な取り組みやルール 私たちの所属する配配メール開発課はメンバー10人で構成されるチームです。まずはその全員に関係する組織的な取り組みやルールを紹介します。 朝はニコニコカレンダーを更

                                                                                    リモートワークでのチーム開発、はいくるチームの場合【はいくる通信 第7話】 - RAKUS Developers Blog | ラクス エンジニアブログ

                                                                                  新着記事