mtx2s

ソフトウェアエンジニアリングを対象領域とするマネージャー。競争力あるプロダクト開発組織を作り上げるにはどうすれば良いか、日々模索しています。はてなブログ https://mtx2s.hatenablog.com/ | ツイッター https://twitter.com/mtx2s

mtx2s

ソフトウェアエンジニアリングを対象領域とするマネージャー。競争力あるプロダクト開発組織を作り上げるにはどうすれば良いか、日々模索しています。はてなブログ https://mtx2s.hatenablog.com/ | ツイッター https://twitter.com/mtx2s

最近の記事

そのプロセスが開発チームのパフォーマンス発揮を阻害する

ソフトウェアプロダクトに対する新たなアイデアや改善要望は、日々、途切れることなく生まれ続けます。このペースに開発チームのパフォーマンスが追いついていない状況は、プロダクトマネージャーにとってもどかしいものです。一見すると、このような状況はエンジニアの人手不足に原因があるかのように思えますが、実はバリューストリーム上のプロセスに問題があるのかもしれません。 問題を生じさせるプロセスはどこか一般的なバリューストリームは次のようなものだと思います(参考:『リーンエンタープライズ』

    • 生産性向上vs.優先順位付けというプロダクトマネジメント

      生産性向上なる課題は、それがエンジニアリング組織の外からの要求であるならば、その解決率はかなり低くなると感じます。そのようなケースの多くは、問題の所在がエンジニアリング組織の外にあるからです。根本的な問題は、やることに「優先順位を付けない」ことではないでしょうか。 私自身の経験から察するに、生産性向上というこの曖昧な課題に秘められた要求は2つです。ひとつは「大きなものを短期間でリリースする」こと。もうひとつは「多くのものを同時にリリースする」こと。 激しい競争の渦中にある

      スキ
      1
      • プログラマは「コードを読む」ことに労力を割いている

        「手を動かす」という表現は、プログラミングに対する誤ったイメージを絶妙に反映した言葉選びだと、そう思えてなりません。目に浮かぶのは、キーボードに向かってカチャカチャと一心不乱にコードを打ち込むプログラマの姿でしょうか。映画に描かれるハッカーもカチャカチャカチャカチャッと、高速タイピングを駆使し、鬼気迫る攻防を繰り広げます。優秀なプログラマというのはとにかく「手」が早い。キーボードにもこだわりを見せる。「手を動かす」という言葉の通り、プログラミングとは「コードを書く」こと。これ

        スキ
        18
        • 遅延よさらば。バッファ活用によるプロジェクトマネジメント

          プロジェクトっていうのは、進捗に遅れが出始めると、挽回するのがとても難しいと感じます。数多くのソフトウェア開発プロジェクトに関わってきましたが、遅延プロジェクトがオンスケに戻ったケースは記憶に多くありません。むしろ、時間が経つにつれ、じわりじわりと遅延が拡大していくケースが多いように思います。遅延が明らかになった時には既に、それを取り戻す術はほとんど無いのかもしれません。 ステークホルダーとの遅延影響の調整は、誰だって精神的に参ります。不満を表情に滲ませて詰め寄ってくる人だ

          スキ
          1
          • 頭数だけ揃えても開発キャパは思うようにスケールしない

            頭数だけ揃えたって、開発キャパシティは思うようにスケールしないよ。どうしてって?だって、ソフトウェア開発は、チームプレーだから。 ミッドフィルダーばかり11人いても、サッカーの試合で勝つのは難しいよね。それぞれのポジションが揃って、巧みに連携してこそ勝利を導くわけでしょう? ソフトウェア開発もチームプレーなんだよ。それぞれが受け持つポジションがあって、互いに連携するわけ。 スポーツチームとの違いは、控え選手がいないことかな。それってリスクだよね。そうそう、急な欠員に対し

            スキ
            3
            • 無計画なコミュニケーションにいつまで振り回されるの?

              社内ミーティングに追われ、自身の担当タスクを処理する時間が取れないという話を耳にすることがあります。 複数の人が集まり、組織として共通目的を持って協働するためには、コミュニケーションが欠かせません。しかし一方で、社内コミュニケーションにかかる負担は、組織のパフォーマンスを減衰させるコストにもなり得ます。 必要なコミュニケーションを取りながらも、考えること、手を動かすことに集中する時間も確保する。それには、コミュニケーションコストを積極的にコントロールする必要があります。一

              スキ
              4
              • DX白書2021が指し示すVUCAな現代とアジャイルな未来

                『DX白書2021』で明らかにされた日米ギャップの大きさは、テック企業でソフトウェアプロダクト開発に身を投じる私にとっても、深いため息の出る、決して他人事ではない厳しい現実でした。これほどまでに日本の現状は遅れ、時代の変化から取り残されているのか、と。それを最も感じたのは、p.45「図表23−9 アジャイルの原則とアプローチ」でした。 このグラフは、「アジャイルの原則とアプローチを組織のガバナンスに取り入れているか」に対する回答を部門単位で集計した結果です。 ご覧の通り米

                スキ
                4
                • 「いかに作らないか」が考え抜かれた機能開発を。

                  機能要件を網羅しようとする機能開発は効率が良くないなあと、つくづく感じています。 ソフトウェアプロダクトの機能開発では、作り上げた機能がリリースされてユーザーに使われ始めるまでは、そのユーザー価値を正しく評価することができません。つまり、開発中は正しいゴールの場所がわからない。おおよそゴールだと信じる場所に向い、リリースするその日まで、ただひたすらに真っ直ぐ突き進んでいるようなものです。 はじめに目星を付けた方角に正しいゴールがあれば良いのですが、そうでなかった場合、その

                  スキ
                  2
                  • アジリティに欠けるプロダクト開発は人手不足に陥りやすい

                    自社ソフトウェアプロダクト開発が慢性的な人的リソース不足に陥りやすい背景は、いたってシンプルです。「アジリティ(agility)」がないこと。ほんと、これに尽きる。プロダクトマネジメントの問題であって、採用では解決しません。 私自身の経験や、観測可能な範囲からではありますが、アジリティのないプロダクト開発に共通する特徴として、次の三つが挙げられます。 ・ロードマップに個々の開発案件をプロットしている ・数か月規模で開発する案件を抱えている ・人的リソースが分散している

                    スキ
                    14
                    • ソフトウェアプロダクトの機能追加・機能改善をプロジェクト体制で進めるのはもうやめよう

                      ソフトウェアプロダクトをビジネスの中心に据える企業にとって、プロダクトの競争力を高めることは、一番の関心事です。だからこそ、プロダクトをより顧客価値の高いものに磨き上げようと、アップデートを繰り返すことに腐心する。 しかし、残念なことに、魅力的なプロダクトというものは、すぐに競合他社に真似されてしまいます。一度獲得した優位性を、長期間持続することは難しい。むしろ、競争優位性など一時的であることが普通だと考えた方が良い気さえします。 だからこそ、「プロダクトの競争力を高める

                      スキ
                      10
                      • 『ユニコーン企業のひみつ』という組織論

                        私は昔から、いわゆる「ヒーローもの」が好きで、それを題材とした映画やドラマをよく観ます。ヒーローは、我々のような普通の人間では太刀打ちできない強大な敵と戦い、打ち勝っていく。多くの物語で彼らは孤高であり、孤軍奮闘する存在として描かれますが、それは、特別な能力を持つヒーローが、それ故に希少な存在だからでしょう。つまり、「スケール」できないのです。 企業というものもそう。数少ない「優秀な社員」に頼る方法で組織をスケールさせることには、そもそも無理がある。書籍『ユニコーン企業のひ

                        スキ
                        7