開発効率とモチベーション
TLで流れてきて、なんとなくリンクをクリックしてサッと読んでみるとやっぱり何か引っかかりを覚えるので、もう一度、読んでみる。ううん。そうかなぁ、と。
プロジェクトでワタシがチームにできることは、チームの活動の障害を避ける道を選んだり、取り除いたりすることなんですよね。その回避したり、取り除く障害にはいろいろあるけれど、逆説的ではあるけれど障害を作らないというのもあるんですね。
それがプロジェクトの活動としての業務プロセスを作ることです。別に毎回新しく想像するようなことはないけれど、チームの成熟度、紐解けば、メンバ一人ひとりの基礎スキルや技術スキルとそれらのレベルを知ることで、チームの業務プロセスのルールを調整することを目的とするので、そういった意味では作ることではなくて調整作業なのですが。
業務プロセスの設計は、チームのメンバが全員従うルールですからその業務プロセスに無駄や無理があれば、それは業務プロセスを作るワタシ自身が品質要求を欠損させる原因のひとつを作ることになります。ワタシがみんなの手足を縛って自らも溺れるようなものです。
まあ、そうならないように業務プロセスを調整するのですし、実際使ってみたら見立てたよりメンバの基礎スキルや技術スキルのレベルで低い人がいることがわかるとその下限にチームが引っ張られるので調整が必要になりますし、期待以上であれば更に良くなる点があるかをみんなで話し合いながら変えていくことになります。
業務プロセスの上に開発のツールやテクニックがのりますが、そこはワタシより長けたメンバに、多くはアーキテクトやリーダが担いますが、お任せしています。餅は餅屋です。
こうした業務プロセスや開発ツールて、開発効率を暗黙に考えて組み立てると思うのですよ。なので、開発効率は、業務プロセスと開発ツールや開発支援のためのテクニックを選定する時点で決まってしまうわけです。
イメージにするとこんな感じです。選択する業務プロセスと開発ツールが持つスペックありきで、それを使うチームの習熟度により上ぶれすることもあるし、未達の時もあるよ、と。
業務プロセスや開発ツールが元々持っている効率性の上限
↑
業務プロセスや開発ツールの採用で想定する開発効率
↓
業務プロセスや開発ツールが元々持っている効率性の下限
これをもっと向上させたいなら、業務プロセスもしくは開発ツールや開発支援のテクニックを別のより効率の高いものに置き換えないと良くはならないです。
それを「開発効率はモチベーションで決まる」ような書き方をされると違和感を覚えざるを得ないのです。それ、元々の業務プロセスや開発ツールは狙いの開発効率を得られていたのかな、と。
モチベーションって、結局精神論に近しい話じゃないですか。よし、これを頑張ろう、とか、そういったレベルのものですよね。続くわけがない。ベースはエンジニアリングなんじゃないですか。システム開発って。でも、メンバが同じものを作らない、同じプログラムはないわけです。ちょっとずつ似て非なるプログラムを作るわけです。その、似て非なるところがシステムエンジニアの楽しみの技術力や創造性を発揮するところだと思うんですよ。
上のイメージは、プロジェクトで得ることを必要とする開発効率であって、これを得られなければ、対策が必要になります。この中心のラインが基準点な訳です。
でもそこにモチベーションを持ち出すと話がおかしくなる。例えば、イメージの中心にモチベーションが良い状態を当てはめるとモチベーションで開発効率が上下することになります。これ、受けれ入られますか。プロジェクトマネージャじゃなくても、いちメンバとしても「なんだかな」と思いませんか。
だって、モチベーションが維持できなければプロジェクトとして得たい開発効率が得られないってことですよ。もっと頑張れるようなモチベーションを保ち続けないとプロジェクトの目標に到達できない…そんなのおかしいじゃないですか。
開発効率ってモチベーションのニュートラルなポジションというか影響を受けないところで設定しないと開発自体がギャンプルになっちゃうんですよ。だから、違和感を感じるんです。
といはいえ、期待する開発効率が一発で確保できるなんて思うほどお花畑でもないのですけれど。だからスプリントゼロに相当する作業を一度して、メンバの力量を把握しなきゃ、というんですね。
モチベーションを言い出すメンバがいたら、業務プロセスか開発ツールの何にストレスを感じているのか聞くと良いです。どこかにストレスを感じているので。それをみんなにも聞いてみる。別のやり方で同じ開発効率が得られるなら、そっちにピボットすればいいので。
