サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。Storiesの季節です。Stories2で書いた内容をほぼ原文で公開します。はじめに皆さんは「アジャイル」のどういうところが好きですか?「そもそもアジャイルとは何か?」という議論も色々ありますが、ここでは「アジャイルソフトウェア開発宣言」を理解して実践しようとしていることとします。私が「アジャイル」に感じた好きなところは以下のようなものです。(a)顧客により価値の高いものを提供することができる(b)自分達の成功体験を短いスパンで感じることができる(c)携わったプロダクトやサービスに誇りを持つことができる(d)またこのチームで仕事をしたいと思うことができる以降、それぞれについて書いていきます。顧客により価値の高いものを提供することができるアジャイルでは顧客に実際に動くものを見てもらい、フィードバックを得ます。そのフィードバックを次のスプリントの開発に活かすことで、本当に顧客が欲しかったものを提供できる可能性が高くなります。スクラムだと、各スプリントで行う「スプリントレビュー」でデモなどを行い顧客に確認してもらいます。私が過去に経験していたやり方のいくつかでは、システムテストまで顧客が実物を見て触る機会がなかったこともありました。実際に使うユーザにいたっては、リリースするまでその機会がなかったこともありました。常にユーザに見てもらえる状態を維持するのは、それほど簡単なことではありませんが、それにチャレンジする価値はあります。要件定義や基本設計の工程の成果物を変更したりできず、またより良い方法をマネージャなどに提案しても力ない笑みや苦笑と共に...「もう決まったことだから」「お客様はそれで良いと言ってるから」という返答を聞いたことありませんか?社内定義のQCDは充足していたとしても、発注者だけでなく、実際に使うユーザも含んだ顧客の満足度をもっとトレースしたいと思っています。プロジェクト終盤によく聞く「自分達が欲しかったのとは少し違うなぁ...」という声よりも、プロジェクトの途中に何度も「こういうことをしたかったんだよ。自分達の成功体験を短いスパンで感じることができる「スプリント・レトロスペクティブ」(ふりかえり)が大事な理由の1つとして、チームの良い点をより強化して、改善し、顧客への価値の提供のスピード、質を上げるというのがあると思います。それと同じほど大事な理由に「自分達チームのことを知って、成功体験を得る」があると思います。私が過去に経験していたやり方のいくつかでは、「ふりかえり」はプロジェクト終了時...それこそカットオーバー後...に行うことが多くありました。いくつかは詳細設計などの工程の終わりで実施していたこともありました。途中でプロジェクトから抜けたり、あまりに大きなプロジェクトの場合、ひょっとすると「ふりかえり」の場すら無いかもしれません。いずれにせよ、そこで得た改善や成功体験を活かすまで、長いスパンが必要になります。これでは何度もあるレベルアップのチャンスを逃しているようなものです。経験が浅いエンジニアほど「自分達のチームがどの程度イケてるのか?」に敏感な傾向があり、「ふりかえり」によって成功体験を得ることで一段と伸びていきます。チームメンバー同士でフィードバックをし合うことで、個人の成功体験を得て、自信を持つことができ、レベルアップにつながります。相互理解も深まりチーム全体のレベルアップにもつながります。携わったプロダクトやサービスに誇りを持つことができるある尊敬できるエンジニアが「コードのAuthorに自分の名前を入れたくないようなコードを書くな」と言っていました。これはプロダクトやサービスでも同じようなものだと思います。自分達チームがリリースしたプロダクトやサービスを街中やインターネットで見かけた時に胸を張って「自分達が作ったもの」と言えますか?前述した「顧客により価値の高いものを提供することができる」内容にも関係しますが、私が過去に経験していたやり方のいくつかでは、不本意なコード、ユーザインターフェース、機能群を持ったシステムを提供せざるを得ないことがありました。アジャイルでは徐々に顧客と一緒にシステムを作り上げていくので、顧客はもちろん自分達チームにとっても「誇り」と思えるものになる可能性が高いと思います。このチームで仕事をしたいと思うことができる私自身はアジャイルで一番好きなのはこれです。これは「アジャイルな開発をしたから思った」「アジャイルな開発でないから思わなかった」わけではありませんが、感覚としてアジャイルなチームで開発をすれば、ほぼ間違いなくこの感情を持ちました。私が過去に経験していたやり方のいくつかは「二度と〇〇の顔を見たくない」ということも残念ながらありました。顧客から「これが欲しかったんだ」という声をもらい、成功体験を積み重ねて、プロダクトに誇りを持っているチームだとそうはならないと思います。最後に私は「これまで書いたようなことをできる/したいからアジャイルをやろうとした」わけではありません。当時は色々悩んでいました。「どうしたらお客様もハッピーになってチームも楽しく良い価値を提供できるんだろう?」を日々考えて、動いて、フィードバックを得て、改善してまた動いて...を繰返していく中でたどり着いた「こういう状態で働きたい」という形が自分なりのアジャイルなプラクティスや姿勢に近かったという感じだと思っています。「アジャイルをやりたいんです」とたまにを聞きますが、その前に自分達とチームがしたいことが何なのか?を考えてみるってことも大事かと思います。※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。旧館よりできるだけ文字を打たないことでミスを少なくする文章やプログラムを書く時に効率性や質の向上の為に自分なりのルールや注意していることがあります。1つは前に書いた文章の揺らぎです。1つは低レベルな話ですが「出来るだけ文字を打たない」ことです。「37シグナルズ」の理念を書き記しています。打合せ前に少しだけ調べておくとある社内での打合せの席で思ったことです。「相手の方を少しだけ知っておくと、それだけど打合せがスムーズに進む(進みやすい)」と。その打合せは部門も違い、お互い初対面でした。事前に「○○さんと△△さんが出席する」ことは分かっていま...ソフトウェア開発プロジェクトの種々なこと「プロジェクト」を、前職ではPMO(プロジェクトマネジメントオフィス)的に外から、そして現職で逆に一員として内から見て...と異なる視点を経験しました。その中で感じたことをつらつらと書いてみます。コメントをキャンセルコメントを投稿するにはログインしてください。サウスポーなエンジニアの独り言.ホーム検索トップサイドバータイトルとURLをコピーしました。