カテゴリー別アーカイブ: 受託開発

受託開発という名前の弊害

受託開発という分野を作っているのは、実は開発を行っている側が自分たちは受託開発だと思い込んでいるだけで、世の中に受託開発っていうのは、本当はなくって、お客さんは、自分のビジネスをいい方向に一緒に考えてくれる人に発注した(orしたい)と思っている。
それは、お客さんの会社の大きさ(大きな企業とか小さな会社や個人事業主)には関係ない。

作る側のビジネス・モデルの都合で、「考える事」と「つくること」を分けて作業し始めたから、お客さんも手を動かしている開発者も不幸な結果になってしまうことが起こっているんだなと自分の足で立って、営業から開発までやってみて今更ながら実感。

大企業のお客さんと仕事をしていた時に、大企業の中でも情報システム部門(or100%小会社)に属していない、本当の発注者の顔や声に直接触れられた時に会社なんてどうでもいいから、この人が喜ぶために、全力で考えて、社内だろうが社外だろうが全力で泥臭い調整業務を行って、開発チームに対しても自分に対しても「それは、お客さんが喜ぶかな?」と言うことを常に問い続けた。

結果、終わった時にお客さんに笑顔で言われた「お願いして良かったです」という言葉がすごく嬉しかった。

という2年前のポエムを忘れないようにメモっておく。

INVESTだけでいんですと?

@posauneさんのINVとESとTのポストを読んで、京アジャのレフトウイング(どっちがどっち担当だったっけ?)として勝手思ったことを書いてみる。

実際のプロダクトオーナー(PO)にINVESTとはですねーといっても必ずしも技術畑でもなければ、暇でもない(POが暇だって?!)POになかなか意識して書くことを要求するのは酷だったりする。
(書き方を気にするあまり、追加するのをためらわれたら本末転倒)

けれど、POはプロダクトへのアイデアはあふれんばかりに持っている(はずだ!)から、アイデアを思いついた時にプロダクトバックログですぐにでも関係者に共有したい。

こんなときどうすんの?

プロダクトバックログにはゾーン(Zone)という考え方がある。

気にしないゾーン

プロダクトオーナーは、アイデアレベルのプロダクトバックログアイテムを、まずは気にしないゾーンに入れておく(INVESTですらないかも)。

気にしないゾーン

気にしないゾーン

荒目ゾーン

次のスプリントではないけど、近々行いたいプロダクトバックログアイテムを荒目ゾーンに移動する。
この荒目ゾーンで、INVが満たされているものがきていれば、POとTeamや関係者とのコミュニケーションが進んで、中期的にどんなことをやろうとしているのかが共有出来て、コミュニケーションがはかどる。

荒目ゾーン

荒目ゾーン

詳細ゾーン

詳細ゾーンは、市場の状況が変わらなければ次のスプリントで着手するプロダクトバックログアイテムが入っているはずなので、可能ならINVESTであることが望ましい。なぜかというと、スプリントプランニングにコストをかけ過ぎたくないので。
当然、アクセプタンス・クライテリアを詳細に書かないとTestableにはならないし、スプリントプランニングでコミュニケーションコストをかけ過ぎてしまう。

詳細ゾーン

詳細ゾーン

とうことで、POに優しいプロダクトバックログを作るためにはINVESTに合わせてZoneも意識してみてはいかがでしょうか?

「DevLOVE関西×泥臭い受託開発を語り合う」で発表してきました

今回発表させていただいたのには理由がありました。

訳あって7年勤めた会社を退職しました。
その際一緒に仕事をしていた人への引き継ぎを行っていたのですが、丁度DevLOVE関西で「泥臭い受託開発を語り合う」勉強会が開催されるということで、ここに引き継ぐ人に参加してもらって、ここで引き継ぎを完了させようと勝手にたくらんでいました。

ところが主催者側の都合で開催時期が2ヶ月伸びてしまったのと、引き継ぐ予定の人に開催日を伝えるのを忘れたため、結局ただの発表となってしまったという経緯がありました。無念。

すごくコンテキストを絞った発表だったため、お役に立てるかかなり心配だったのですが終わった後素敵なフィードバックを複数頂きました。
参加された皆様、資料をご覧になってフィードバックをくれた皆様有難うございます。

7年間勤めた会社で得た自分なりの経験を引き継ぐ人に少しでも伝わればという思いで作成した資料だったのですが、同じ境遇の方に何かを感じ取って頂けたため無駄にはならなかったというだけでもすごく嬉しい日となりました。
また、退職した実感が湧いていなかったため自分にとっても卒業式的なイベントとなり、お陰様で無事卒業出来ました。

普段は京都アジャイル勉強会で素振りを行っています。発表資料の内容やアジャイルに興味をお持ちの方は是非お立ち寄り下さい。

スクラムによる受託開発#2

〜スクラムを学び始めた自分へ、今伝えられるなら何を伝えたいか〜

7年前にスクラムを学び始めた自分に、今の自分がスクラムを伝えるなら何を伝えているだろうか。

契約について

スクラムで受託開発をする場合の契約は、どうすれば良いのだろうか?

NobMouse via flickr

Contracts

最近では、IPAが非ウォーターフォール型開発時の契約書を公開している
http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html

他にも、@kdmsnrさんが翻訳してくださっている「次のアジャイルソフトウェアプロジェクトに使える10の契約」もすごく参考になる。
http://capsctrl.que.jp/kdmsnr/wiki/transl/?10-agile-contracts

ただ、実際のところ受託開発で下請け側の意向で契約形態の変更は、かなりハードルが高い。
大抵は、会社全体で同じ契約書を使用しており、それをプロジェクトに依存する箇所(※1)のみ変更して契約している場合が多いと思う。

では、契約方法が変更できないからスクラムでの開発は出来ないのかというと、案外そうでもない。プロジェクトのコンテキスト(※2)に依存するところは多分にあると思うけれど、
「契約が変えられない=スクラムを導入できない」
では、思考停止してしまう(実際そう思っていた時もあって、プラクティスに走ったりもしたけれど。。。)
では、どうすれば良いのだろうか?

何も変えないという方法

実際のプロジェクトで契約しているのは、納品日と金額と納品する成果物だけであって、どのストーリーを実現するかを契約書に記載しているわけではない(あくまで自分の場合はだけれど)。

ということは、決められた金額、納期、成果物を満たしつつ、よりユーザーにとって価値のあるストーリーからプロダクトを作り、その都度フィードバックをもらい、大きな変更については他のストーリーとの優先順位をつけてもらい、今回の開発から外して、次回の改定に回してもらうなどの交渉を行いながらやっていく。

実際ユーザーもプロジェクトのかなり早い段階で、プロダクトに触れる事ができるため、真剣にプロダクトを触りながら、優先順位やフィードバックを出してくれる。
(見慣れないExcelファイルに書かれた図と小さい文字をみて内容に承認を求められ、その結果、数カ月後に作りましたと初めて見せられた時には既に修正するには手遅れなどという状況にはなりにくい)

実行するにはいくつか注意点も

Warning breakdancers!

受託開発をスクラムで行うには、READYになっておく必要があり、これらもそのための準備だと言える。

  • ”要件定義”から参加するプロジェクトであること

要件定義の段階から、ユーザー、発注側とスクラム開発に向けた準備を進める必要がある(あくまで、スクラムの準備だと考えているのは開発チームだけ)。
主に、インセプションデッキ(※3)を使用してその準備を行っている。
ただし、インセプションデッキは、要件定義〜基本設計の間に作成してこそ本来のパワーを発揮するツールだと思う。
詳細設計からスクラム開発を行うと、かなりの部分で交渉の余地がなくなっているため、その段階でインセプションデッキを作成しても、現状の把握には利用できるが、交渉の余地があまり残っていない分、その効果も低い。

  • 発注側に、開発途中のプロダクトをユーザーに見せて確認する旨を伝え、了承を得ていること

事前に発注側に
「今回のプロジェクトは不確定要素が多いため、リスクヘッジを兼ねてプロジェクトの早い段階からユーザーに単体テストが完了しているプロダクトをお見せしてフィードバックをもらいたい」(※4)
と正直にお伝えすること。
決して、スクラムを使用して開発しますなんていう必要はない(言うことで、逆に抵抗にあうことだってありうる)。
リスクヘッジについて考えてくれているということで、好意的に取られる可能性もある。

契約も標準もリスクを管理(or回避)するための手段だと思う。
それを考えた人たちには、すごく意味のあるものだけれど、その恩恵を受けるところからしか関わったことのない人たち(自分も含め)には、なぜ契約と標準があるのかもセットで伝承しないと、その有り難みも弊害も理解できない。

スクラムを使った開発を行うということがきっかけで、この辺りに疑問が持てるようになったことも、すごく学びにつながった。

次は、インセプションデッキかな。

※1契約名、金額、納期、納品物など
※2業務系のWebシステム開発で要件定義〜基本設計;準委任契約、詳細設計〜システムテスト:請負契約となることが多い
※3インセプションデッキ自体は、スクラムのツールではないけれど、全てではないにしろ必要な物は、必ず作成したほうが良いと思う。
※4全く不確定要素のないプロジェクトなんてないとも思うけれど

スクラムによる受託開発#1

〜スクラムを学び始めた自分へ、今伝えらるなら何を伝えたいか〜

7年前にスクラムを学び始めた自分に、今の自分が伝えるなら何を伝えているだろうか。

どこから手を付けたらいいのか?

7年前の自分は、スクラムを自分が参画するプロジェクトに適用しようと考えた時に、どうやって、どこから適用しようか色々と試行錯誤した結果、失敗に終わった(※1)。

今、あの時の自分に教えるなら、まず何から始めることを教えるかな。

スクラムは開発ツールの一つ

ツールとして使用できるようになるまでには、それなりの準備が必要。

いきなり使って、すぐに上手には使えなくて当然で、まずは、次のステップをふんでチーム作りから進めたい。

 

Step1.

組織内で1人は、サラリーのためだけに仕事をしているのではなく、より良い物をユーザーに届けたいという思いがあるメンバーを見つけ、チームに入れること

最初のフォロワーは、自分で見つけるということ。
(有名なこの動画の様に最初のフォロワーが見つかればよいが、見つからなかったら見つけるしかない)

何がユーザーにとって本当に必要な価値であるかを話し合えるメンバーがいて、開発中に2人でそのことについて話していると、次第に他のメンバーも巻き込まれていく。
つまり、2人でどれだけちっぽけでも良いので、まずは同じ目的地に向かうバス(※2)を作ることが、重要だと思う。何も、いきなり全員バスに載せる必要はない(そういえば、いきなり全員バスに乗せようとして失敗したことも。。。)

他のメンバーが仕様書を実装するあまり、ユーザーの価値を考えて開発できなくなっているメンバーだった場合(悪い人では決してないのだけれど)、1人でどれだけ熱く語ったところで改宗してもらうための努力は、徒労に終わることが多い(手を動かすオペレーターという役割が長すぎて、そもそも価値って何?となっている人も少なくない)。
相手にとって興味が無い事へ興味を向けさせることほど、大変なことはないと思う。すくなくとも自分の場合そうだった

まさに北風と太陽で、バスに乗ってほしいのであれば、矯正するのではなくて、バスに乗って楽しそうにしているところを見せれば良い。

 

Step2.

1人見つけたら、一緒に社外のスクラムイベントに参加して、スクラムを最初から最後まで通して学べるワークショップに参加すること

image via “Scrum Simulation with LEGO”

スクラムの開発プロセスは、1枚の図でよく表されていることが多い。
それだけ、プロセスについての表面的な理解はそんなに難しいことではない。
でも実際にやると、

  • プロセスをなぞってはいるものの、チームのやる気が今までと何も変わらない(やらされている感)
  • 本当にユーザーに価値を提供できているのか(ただのスクラムごっこ(※3)の成果物となってはいないか)?
  • チームは、リズムにのって開発を行っているか?
  • 日々改善する努力を行えているか(ふりかえりで出た、改善策は出しただけになっていないか)?
  • など、ただ、スクラムのプロセスにそっているといったことにはなっていないだろうか。

    スクラムを実践する前によく考えていたのは、「1度でいいからスクラムで開発しているチームに参加することができれば、自分でも出来る気がする。」という思い。

    そんな時は、社外のスクラム勉強会にぜひ同じチームのメンバーと参加してほしい。
    そして、できれば1日でスクラム体験が出来るワークショップが良い。

  • 実際に、スプリントを回していくとはどういうことなのか?
  • プロダクトオーナーにデモするプロダクトがないときのバツの悪さ
  • 荒ぶるプロダクトオーナーにどう対処するのか?
  • スプリントを重ねるごとに、その日即席で出来たチームがすすんでお互いを助け合いタスクをこなしていく感覚
  • ベロシティを上げたいと思う気持ち
  • など、たった1日だけのワークショップだけど学びは1プロジェクトを終えたぐらいの学びがある。
    素振りと呼ぶには、十分な体験が得られる。

     

    Step3.

    そのワークショップで、スクラム開発での経験を持っている人たちと知り合い、悩みがあればいつでも相談出来る場を見つけること

    jonevans94 via flickr

    Thinking

    スクラムはスポーツと同じで熟練度によって楽しみも辛さも学びも異なると思う。

    だから、スクラムは学び続ける必要があるし、仮に1つのプロジェクトで上手く行ったからといって、次のプロジェクトでも上手くいくという保証はない(上手くいかなかったのならなおさら)。
    要は、いかにしてチームで早く基礎になる部分を体得して、そこからさらに楽しめるようになるか。
    一度楽しめるようになったらどんどん価値を生み出すことが出来て、どんどん楽しくなっていくと思う。

     

     躓いてしまった自分へ

    この先長く続くプロジェクトを一人で生き残るのは結構きついと思う(納品後のプレッシャーとかは、実際きつかった)。

    でも、

  • 同じチーム(もしくは組織)の人がより良い物をユーザーに届けたいという思いが感じられない
  • イベントに誘ってみても、いまいち興味を抱いてもらえなかった
  • などということももちろん、あると思う。

    そんな時は、思い切って社外の勉強会に参加している人を、自分のチームに参加してもらうことも考えてみてはどうだろうか。
    権限がないかもしれないけれど、上司だって優秀な人材を探しているし、SIerの場合、大抵職務経歴書をみただけで、雇うかどうか決めなければいけないわけだから、自分の部下が積極的に優秀な人を連れてきてくれることは、上司にとっても嬉しいことではないだろうか。

    また、上司に頼んで派遣の方の面接に一緒に参加させてもらい、自分で直接チームに加わる派遣の方を採用するという方法はどうだろう。
    スクラムはチームの文化をすごく重要視していると思う。
    技術は教えられたとしても、考え方や感じ方が異なる人とチームを組むことはすごく難しい。

    であれば、面接に一緒に参加させてもらい、自らチームのメンバーとなる同じ文化の人を採用してみるのも手段の一つだと思う。

    これで、7年前の自分が一歩踏み出せるかは、甚だ疑問だけれど。

    ※1 ここでの失敗は、スクラムのプロセスにのっとった開発すらできなかった
    ※2 アジャイルサムライの第3章「みんなをバスに乗せる」に因んで
    ※3 チームが自発的に改善に取り組んでおらず、”時間が来たから”、”支持されたから”スクラムを行っている状態をスクラムごっこと言ってみました。