mtx2s

ソフトウェアエンジニアリングを対象領域とするマネージャー。競争力あるプロダクト開発組織…

mtx2s

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

詰め込み型のソフトウェアプロダクト開発は誰も得しない

チームのキャパシティを超える要求を抱えたプロジェクトが、なんの問題もなく完了するはずがありません。なんとか作り上げられた機能は、表面上は要求通りでも、どこかぎこちなさを感じます。ユーザー体験が悪く、それがユーザー価値を押し下げ、ビジネス価値を削り取ります。触るたびに新しい欠陥も見つかるかもしれません。内部品質も最低です。それが今後の追加開発の足を引っ張ることにもなるでしょう。そして、ただ消費するような働き方によって、チームは成長も達成感も感じられず、疲弊します。 詰め込み型

mtx2s

    • 兼務による体制構築はプロジェクトの効率を損なわせる

      ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。 しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されているように感じます。 たとえば、兼務者本人にとってプロジェクトの掛け持ちは、仕事

      mtx2s

      • 「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号

        リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することは

        mtx2s

        • ユーザー体験を高めるためのエンジニアリングと効率性を高めるためのエンジニアリング、その両方の視点を持つ

          エンジニアたちの時間を機能開発にばかり割いていると、彼らの生産性や業務効率が落ちてしまいます。これが、自社ソフトウェアプロダクト開発の難しいところです。 ところが、プロダクト開発に関わっていても、それに気付いていない関係者が意外と多いように感じます。その背景には、エンジニアリング業務に対しての不理解があるのではないでしょうか。 ユーザー体験の向上と効率性の向上。エンジニアリング業務は、この2つの目的に分けられます。前者ばかりに気を取られていると、徐々に効率性が落ちていきま

          mtx2s

        詰め込み型のソフトウェアプロダクト開発は誰も得しない

        mtx2s

        • 兼務による体制構築はプロジェクトの効率を損なわせる

          mtx2s

        • 「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号

          mtx2s

        • ユーザー体験を高めるためのエンジニアリングと効率性を高めるためのエンジニアリング、その両方の視点を持つ

          mtx2s

          チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する

          依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。 機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手で、様々なタスクが実行されます。その全てを1つのチームで完結することは、プロダク

          mtx2s

          チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する

          mtx2s

          ビジネスインパクトのない新機能に費やす時間とコストを低減する

          リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。 このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。 失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。それが繰り返されると、組織全体の士気が落ち、学習性無力感に支配されていきます。ソフ

          mtx2s

          ビジネスインパクトのない新機能に費やす時間とコストを低減する

          mtx2s

          ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する

          自社ソフトウェアプロダクトを内製する組織であっても、開発チームがそれをどうやって作り上げているか、開発者ら以外にとってはブラックボックスであり、不可視です。それだけに、開発チームのパフォーマンスや内部状況の良し悪しは、各々の主観や興味によって、不統一な認識を持ってしまうことも多いでしょう。そしてそのような認識のばらつきは、開発する当人たちにとっても実は同じです。 しかし、例えブラックボックスであっても、自動車のダッシュボードのように様々な指標によってその内部が数値化され、可

          mtx2s

          ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する

          mtx2s

          エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく

          組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。 自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソフトウェアに変えられるのは、開発者だけです。より多く、できる限り早く、アイデアを

          mtx2s

          エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく

          mtx2s

          ソフトウェア間での機能単位の実装コピーは簡単じゃない

          「当社の旗艦プロダクトに搭載されている○○機能を、我々のプロダクトにも追加したい。簡単だろう？既にある実装をコピーして持ってくるだけなんだから」 ソフトウェアプロダクトの開発チームに対し、顧客やプロダクトオーナー、その他のステークホルダーが、このように話す場面に何度か遭遇したことがあります。それを聞いたソフトウェアエンジニアたちは、苦笑いしていたり、「またか」とうんざりしたため息を付いていたり。いずれにしても一様に、良い反応を返しません。 それは、異なるソフトウェア間での

          mtx2s

          ソフトウェア間での機能単位の実装コピーは簡単じゃない

          mtx2s

          ソフトウェアプロダクトにはもう1つの品質がある

          ソフトウェアに対して変更を加える行為は、下手をすると、いわゆる「諸刃の剣」になりかねません。ここで言う「変更」とは、機能追加や機能改善、不具合修正など、ユーザーの価値を高めるために行われる開発全般を指します。片側の刃でこのようなユーザー価値を高めようとする行為が、反対側の刃でソフトウェアそのものを斬りつけてしまう行為となり、その寿命を縮める結果になり得るということです。 これが何を意味するのかを理解するためには、ソフトウェアの品質には2つのタイプが存在することを知っておく必

          mtx2s

          ソフトウェアプロダクトにはもう1つの品質がある

          mtx2s

          ソフトウェア見積りを大きいと感じさせる4つの要因を理解する

          ソフトウェアエンジニアが作成する見積りはいつも大きすぎる。そういった声を聞くことが度々あります。これは、受託開発での顧客の声ではありません。社内でのやり取りです。ここでは自社ソフトウェアプロダクト開発の現場の話という前提で進めます。 この発言はもちろん、ソフトウェアエンジニア以外の人によるものです。ソフトウェアプロダクト開発には、エンジニア以外にも様々な職種の人々が関わります。ビジネス・企画、マーケティング、デザインなど。エンジニアの間では、これらの職種で働く人たちをまとめ

          mtx2s

          ソフトウェア見積りを大きいと感じさせる4つの要因を理解する

          mtx2s

          タスク集中型のエンジニア職とミーティング駆動型のビジネス職

          ソフトウェアエンジニアの仕事の進め方は、ビジネス職のそれとは根本的に違います。まったくの別ものだと言っていいぐらいに。それらを名付けるなら、前者の仕事の進め方は「タスク集中型」で、後者は「ミーティング駆動型」といったところでしょうか。 もし、職種ごとに仕事が完全に分離して接点を一切持たないとしたら、この違いはおそらく問題にならないでしょう。が、もちろんそんなことがある訳もなく、互いにコミュニケーションを取らなければ組織として機能しません。そのため、仕事の進め方の違いは、人と

          mtx2s

          タスク集中型のエンジニア職とミーティング駆動型のビジネス職

          mtx2s

          開発チームの時間を無駄にしない。それはプロダクト開発における重要課題である

          もっとやれる。開発チームのポテンシャルを十分に引き出しきれていない。むしろ、彼らのキャパシティを浪費させるようなことばかりを日常的に強いてしまっている――これは、ソフトウェアプロダクトの開発チームに関して私が常に感じている問題意識です。 開発チームのキャパシティは有限です。そのキャパシティは、プロダクトが提供する価値の総量を維持・拡大するためにこそ割り当てられるべきで、無駄に浪費されるべきではありません。開発チームやそのメンバーが、価値あるソフトウェア開発に費やせる時間、集

          mtx2s

          開発チームの時間を無駄にしない。それはプロダクト開発における重要課題である

          mtx2s

          アジリティが基礎力：プロダクト開発のチーターとイノシシ

          走ることにかけて「世界最速の哺乳類」と呼ばれているチーターは、その圧倒的なスピードよりも、優れたアジリティによって狩りの成功率を高めているそうです。その調査結果をまとめた論文は、2013年6月にニューヨーク・タイムズでも、"Cheetahs’ Secret Weapon: A Tight Turning Radius" という見出しで紹介されました。 日本語では「敏捷性（びんしょうせい）」と訳されることの多いアジリティ（agility）ですが、ここでは、「横に跳び、急に方向

          mtx2s

          アジリティが基礎力：プロダクト開発のチーターとイノシシ

          mtx2s

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

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

          mtx2s

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

          mtx2s

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

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

          mtx2s

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

          mtx2s