ソフトウェアエンジニア#仕事雑談
システム開発(特にsaas業界やアジャイルでのシステム開発において)における生産性と品質の両立って、永遠のテーマだなと思っています。
そこで、皆さんの会社で実践している取り組みやここに対する考え方をお聞きしたいなと思います。
自分としては、生産性というのを目先のものととらえず、中長期的なものととらえ、変更容易性の高い設計をしていくことが品質と生産性の両立につながるのかなと考えています！
(編集済み)
5
コメント一覧
有名なt_wadaさんの講演、「質とスピード」が正にその両立をテーマにしていますね。
両立は難しいのではなく、むしろ、どちらかを犠牲にしても、決してもう一方が高まる事はない。
スピードを出すためにクソコードを書くエンジニアはスピードを落としてもクソコードしか書けないし、クソコードは負債として確実に利息を積み重ね、近い未来でのスピードに対する重しになると言われています。
近頃では、Googleの一機関となったDORA（DevOpsResearchAndAssessment）と言う組織の研究結果が「LeanとDevOpsの科学」と言う本で紹介されていて、そこで提唱されているFourKeysと言われる4つの指標が、開発生産性を表す信頼できる指標として支持を集めています。
開発生産性の指標は、ビジネスの成果と正の相関があるとされています。
指標の内容は割愛しますが、ここでもやはり、質とスピードを両立出来なければ、この指標を高めていく事はできないとしています。
で、私自身は自分のチームの生産性を高めるためには、自動テストを徹底し、人間のポカミスによる失敗を防ぐ事を取り組みとしています。
自動単体テストを作りやすくするためには、責務を一つに絞った単機能の部品を組み合わせる様な実装にならざるを得ません。
そうすると、プルリクエストのサイズを小さく出来ます。
プルリクエストのサイズが小さい事はかなり重要で、それによりレビュー負担の軽減や気づきによる学習のプロセスを早められます。
テスト容易性の獲得に伴い、自然と変更容易性、理解容易性が担保されます。
テストの書きやすい実装方法や効果的な自動テストの書き方をメンバーに周知するため、ペアプロやモブプロを積極的に実施する様にしています。
(編集済み)
補足で、生産性と品質の定義についても色んな見方がありますね。
アジャイルの世界での品質とは、アウトプットではなくアウトカム、つまり、完成したシステムの質ではなく、システムがもたらす価値によって得られる成果だと言う見方があります。
その為には、細かく細かく機能をリリースし、その反応を持って次のアクションの方向性を見定めて、何が価値を生み出すのかの試行錯誤を重ねていく事になります。
SIの世界観に基づくプロジェクトと、事業会社目線とでは、生産性と品質の定義が異なってしまう部分があると感じています。
ビジネスモデル的な面で仕方ない部分はどうしてもあると思っているのですが、SIのプロジェクトでは、顧客の要求を満たすためのプロジェクト計画の遂行に必要な生産性と品質の定義になっている事が多い様に感じます。
もちろん、事業側の見方でプロジェクトを進めて下さるコンサルタントやSEの方も多くいらっしゃいますが、逆に事業会社でのマネージャーやプロダクトオーナーの中にも、SIプロジェクト的な方針を優先される方もいらっしゃいます。
投稿主様が考える生産性と品質の位置付けについて一度整理されてみると良いかもしれません。
差し出がましいコメントになっていたとしたらすいません🙇
(編集済み)
コメントいただきありがとうございます！！
書かれている内容は非常に学びが多く参考になります。。
生産性と品質の位置付けを今一度整理してみるというところ、まさにその通りだと思いました！
ここを再度確認して、納得できる答えを見つけていこうと思います！
もう一つ、私が普段の業務の中で実践している事があります。
それは、チームのメンバーに、実装の時間は常に自分やチームのメンバーが、会社やプロジェクトが変わったとしても使い続けられる部品を作り貯めるための時間と考えて欲しいと言い続けています。
それにより、新しい機能を作る際に、信頼できる部品を再利用したり、新しい実装が、高凝集、疎結合な部品の組み合わせで、メンテナンスしやすい実装構成に近づきます。
こちらはあくまでチームリーダーとしての私の取り組みの一環ですが、参考になりましたら幸いです。
私も、むしろ質とスピードは両立しないと共倒れになるという体験を何度もしています。他の業界を見ても、車で故障が1番少ないのは出荷台数世界一のトヨタ、家の内装工事は自分でDIYよりも職人、と言った感じで、ボリュームのある方々がより質を上げる機会を得ているということですね。
私は過去に2週間で終わると見積もられた仕事を2日で終わらせたことがあります。その時は、残りの1週間半を予定していなかった機能実装や普段はできないようなリファクタリングをすることで、質と量を両立できました。
