記事一覧
兼務による体制構築はプロジェクトの効率を損なわせる
ソフトウェア開発プロジェクトは、「兼務」を用いるチーム編成が多用されやすい対象ではないでしょうか。エンジニアであれば誰もが経験したことがあるでしょう。1人で複数のプロジェクトやチームを掛け持ちするあれです。マネージャーであれば、組織の人的リソース配置を考える時の手段の1つとして用いたことが何度かあるはずです。
しかし、兼務が引き起こす様々な弊害や問題については、あまり意識されないまま多用されてい
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。
このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもし
ユーザー体験を高めるためのエンジニアリングと効率性を高めるためのエンジニアリング、その両方の視点を持つ
エンジニアたちの時間を機能開発にばかり割いていると、彼らの生産性や業務効率が落ちてしまいます。これが、自社ソフトウェアプロダクト開発の難しいところです。
ところが、プロダクト開発に関わっていても、それに気付いていない関係者が意外と多いように感じます。その背景には、エンジニアリング業務に対しての不理解があるのではないでしょうか。
ユーザー体験の向上と効率性の向上。エンジニアリング業務は、この2つ
チーム・組織デザインの良し悪しはプロダクト開発フローの効率を左右する
依頼、調整、合意、承認、etc. こういったコミュニケーションがチーム境界を越えて頻発すると、ソフトウェアプロダクト開発のフローは遅々として進まなくなります。いずれも、機能追加や機能改善を進める上でのクリティカルパスを引き伸ばす要因を生み出すからです。
機能追加や機能改善といったひとつひとつの開発は、アイデアを生み出し、それを価値に変えるまでのフローです。フローが進む過程で、組織内の様々な人の手
ビジネスインパクトのない新機能に費やす時間とコストを低減する
リリースした新機能がビジネス指標に何の影響も与えていない。ユーザーからの評判も芳しくない。いや、そもそも反応すらない無風状態。我々が費やした努力と時間はなんだったのか。
このような失敗は、ソフトウェアプロダクト開発に携わっていると何度でも経験します。むしろ、期待通りの成果を得られることの方が少ないでしょう。
失敗から得られる知見もありますが、それと引き換えに費やしたコストと時間は戻せません。そ
ブラックボックスになりがちな開発チームの内部状況を指標を用いて可視化する
自社ソフトウェアプロダクトを内製する組織であっても、開発チームがそれをどうやって作り上げているか、開発者ら以外にとってはブラックボックスであり、不可視です。それだけに、開発チームのパフォーマンスや内部状況の良し悪しは、各々の主観や興味によって、不統一な認識を持ってしまうことも多いでしょう。そしてそのような認識のばらつきは、開発する当人たちにとっても実は同じです。
しかし、例えブラックボックスであ
エンジニアの稼働率を上げれば上げるほど機能リリースが遅くなっていく
組織内のメンバーを「リソース」として見始めると、それを100%使い切ることにばかり注力してしまいます。リソースの稼働率を下げることは、すなわち、生産性を下げること。マネージャーは、まるで強迫観念に取り憑かれたように、そのような考えに囚われます。
自社でのソフトウェアプロダクト開発において、その対象は特に、開発者に強く向けられます。その理由は明らかでしょう。バックログに積み上がり続けるアイデアをソ
ソフトウェア間での機能単位の実装コピーは簡単じゃない
「当社の旗艦プロダクトに搭載されている○○機能を、我々のプロダクトにも追加したい。簡単だろう?既にある実装をコピーして持ってくるだけなんだから」
ソフトウェアプロダクトの開発チームに対し、顧客やプロダクトオーナー、その他のステークホルダーが、このように話す場面に何度か遭遇したことがあります。それを聞いたソフトウェアエンジニアたちは、苦笑いしていたり、「またか」とうんざりしたため息を付いていたり。
ソフトウェアプロダクトにはもう1つの品質がある
ソフトウェアに対して変更を加える行為は、下手をすると、いわゆる「諸刃の剣」になりかねません。ここで言う「変更」とは、機能追加や機能改善、不具合修正など、ユーザーの価値を高めるために行われる開発全般を指します。片側の刃でこのようなユーザー価値を高めようとする行為が、反対側の刃でソフトウェアそのものを斬りつけてしまう行為となり、その寿命を縮める結果になり得るということです。
これが何を意味するのかを
ソフトウェア見積りを大きいと感じさせる4つの要因を理解する
ソフトウェアエンジニアが作成する見積りはいつも大きすぎる。そういった声を聞くことが度々あります。これは、受託開発での顧客の声ではありません。社内でのやり取りです。ここでは自社ソフトウェアプロダクト開発の現場の話という前提で進めます。
この発言はもちろん、ソフトウェアエンジニア以外の人によるものです。ソフトウェアプロダクト開発には、エンジニア以外にも様々な職種の人々が関わります。ビジネス・企画、マ
タスク集中型のエンジニア職とミーティング駆動型のビジネス職
ソフトウェアエンジニアの仕事の進め方は、ビジネス職のそれとは根本的に違います。まったくの別ものだと言っていいぐらいに。それらを名付けるなら、前者の仕事の進め方は「タスク集中型」で、後者は「ミーティング駆動型」といったところでしょうか。
もし、職種ごとに仕事が完全に分離して接点を一切持たないとしたら、この違いはおそらく問題にならないでしょう。が、もちろんそんなことがある訳もなく、互いにコミュニケー
開発チームの時間を無駄にしない。それはプロダクト開発における重要課題である
もっとやれる。開発チームのポテンシャルを十分に引き出しきれていない。むしろ、彼らのキャパシティを浪費させるようなことばかりを日常的に強いてしまっている――これは、ソフトウェアプロダクトの開発チームに関して私が常に感じている問題意識です。
開発チームのキャパシティは有限です。そのキャパシティは、プロダクトが提供する価値の総量を維持・拡大するためにこそ割り当てられるべきで、無駄に浪費されるべきではあ
アジリティが基礎力:プロダクト開発のチーターとイノシシ
走ることにかけて「世界最速の哺乳類」と呼ばれているチーターは、その圧倒的なスピードよりも、優れたアジリティによって狩りの成功率を高めているそうです。その調査結果をまとめた論文は、2013年6月にニューヨーク・タイムズでも、"Cheetahs’ Secret Weapon: A Tight Turning Radius" という見出しで紹介されました。
日本語では「敏捷性(びんしょうせい)」と訳さ
そのプロセスが開発チームのパフォーマンス発揮を阻害する
ソフトウェアプロダクトに対する新たなアイデアや改善要望は、日々、途切れることなく生まれ続けます。このペースに開発チームのパフォーマンスが追いついていない状況は、プロダクトマネージャーにとってもどかしいものです。一見すると、このような状況はエンジニアの人手不足に原因があるかのように思えますが、実はバリューストリーム上のプロセスに問題があるのかもしれません。
問題を生じさせるプロセスはどこか一般的な
生産性向上vs.優先順位付けというプロダクトマネジメント
生産性向上なる課題は、それがエンジニアリング組織の外からの要求であるならば、その解決率はかなり低くなると感じます。そのようなケースの多くは、問題の所在がエンジニアリング組織の外にあるからです。根本的な問題は、やることに「優先順位を付けない」ことではないでしょうか。
私自身の経験から察するに、生産性向上というこの曖昧な課題に秘められた要求は2つです。ひとつは「大きなものを短期間でリリースする」こと
プログラマは「コードを読む」ことに労力を割いている
「手を動かす」という表現は、プログラミングに対する誤ったイメージを絶妙に反映した言葉選びだと、そう思えてなりません。目に浮かぶのは、キーボードに向かってカチャカチャと一心不乱にコードを打ち込むプログラマの姿でしょうか。映画に描かれるハッカーもカチャカチャカチャカチャッと、高速タイピングを駆使し、鬼気迫る攻防を繰り広げます。優秀なプログラマというのはとにかく「手」が早い。キーボードにもこだわりを見せ
もっとみる