自分で気が付くことの難しさに気が付く ~ アスカン2019でお話したこと

少し前の話になりますが、4月24日の「明日の開発カンファレンス2019」で、POやったときの失敗と教訓についてお話をさせていただきました。売り上げは本当に35,400円でした。ROIについては、、スライドに書いてありますので興味ある方は見てみてください。

 

www.slideshare.net

内容に関しては、なんでこうなっちゃんだろう?ってことを、事実ベースで掘り下げ(追求)してます。自分の記憶ではなく、証拠となる資料を探しました。

プロジェクトだったり事業の区切れだったり、何かあると当然ふりかえりはするんですが、深層心理に気が付かないというか、見てみぬふりをしてしまうことがあるな、ということを直視する必要がありますね。四半世紀も同じ会社で働いているとなおさらです。

 プレゼンのスタイルに関しては、「法廷劇」を目指しました。本当は二人でやりたかったんですが、都合よく相方が見つかるわけもなく、今回は初演ということもあり一人芝居です。いつか本来の形でやりたいなぁ、と思ってます。

最後になりますが、アスカンスタッフの皆様、ありがとうございました。

締めのパネルディスカッションにも参加させていただき、有意義で楽しかったです。こだわりのある老舗のお弁当も、成功談の直後に失敗談となるセトリもおいしかったです!

 

アジャイル時代のリーダーシップ ~ DevLOVE関西

私が受託開発プロジェクトで現場リーダーをしていたころには、アジャイル開発は日本のプロジェクト現場・コミュニティに着実に根付き始めていました。

当時の私は、朝会・かんばん・ふりかえりなど、アジャイル開発の一部のプラクティス(「プロジェクトファシリテーション」と呼ばれます)を実際にプロジェクトに導入し、チームのために有用であると実感していました。

ただ、プロジェクトを成功させるには現場リーダーのリーダーシップと行動がとても大切だと思っていて、会議やトラブル対応などの現実的なシチュエーションで使える、心構えやテクニックをまとめた本を書きました(「プロジェクトを成功させる現場リーダーの技術」絶版)。

あれから十数年経ち、アジャイル開発も当時とは比較にならないほど普通になり、私も「アジャイル」と名のつく開発組織のディレクターになりました。それまでの間、Scrumを中心にアジャイル開発を基礎から学び、様々な実践者の方々の話を聞くにつれ、リーダーシップとチームの在り方について、現場リーダーのころとは違うマインドセットを持てたことを感じています。

5月17日に、10年ぶりに、DevLOVE関西でお話をさせていただくことになりました。当日は、この「アジャイル時代のチームやリーダーシップ」について、いろいろと議論できればと思います(オープン・スペース・テクノロジー形式での対話ありなんです)。 devlove-kansai.doorkeeper.jp

 

おまけ。2009年の発表スライドです。DevLOVEだけに「愛」をテーマにしてて、何やら重いw。当時、私は開発者や現場リーダーではなくマネージャをしてて、いろいろなギャップに思い悩んでいた記憶があります。

www.slideshare.net

総売り上げは35,400円。POとして失敗から学んだこと~「明日の開発カンファレンス2019」

私はScrum研修のトレイナーとして、POについてお話をすることもあるのですが、だからといって自分がPOとして成功するとは限りません。

実際、POとして2017年の夏にローンチしたサービスは、ビジネス的に振るわず、2年足らずのうちにクローズしています。

原因はいろいろと求めることができます。私はこのサービスのPOであると同時に、受託含めた事業全般の責任者でもありました。そのコンフリクト・利益相反があったかもしれません。

また、アジャイルチームの育成の仕方や、そもそものゴール設定に問題があったかもしれません。チームを成長させることは、いつだって簡単ではありません。

ただ事実として残るのは、このサービスの総売上が35,400円であったことです。

ふりかえるのは辛いぐらいの経験なのですが、この貴重な失敗で得た学びを、4月24日(水)に、大田区産業プラザPIO コンベンションホールで開催される「明日の開発カンファレンス2019」で、生生しくお話をさせてもらいます(夕方からのパネルディスカッションにも参加させていただきます)。

 

「総売り上げ:35,400円 ~ 受託エンジニアが自社サービスのPOをやって学んだこと。」

永和システムマネジメントはソフトウェアの受託開発を生業にしていて、私もその最前線で20年以上やってきました。そんな私が企画し、プロダクトオーナーとして関わった自社Webサービスが、先日ひっそりと終了しました。「ニーズがなかったね」の一言で済ますのではなく、一体何が悪くて、そこから何を学ぶのか?受託から共創にシフトする時代に求められるエンジニアのスキルとマインド、そして組織の形とは?といったことを、プロダクトオーナー・エンジニア双方の視点でお話させていただきます。

 

↓ ただいま事前登録中です。よろしければお申込みください。

asucon.alleyoop.jp

 

一枚の付箋で肩こりを和らげる

f:id:HappymanOkajima:20190404114102j:plain

勤務先のディスプレイ

ずっとずっと、肩こりや首筋の強烈なハリに悩まされていたのですが、この度改善が見られたのでご報告です。やったことは、付箋に「歯」と書いて仕事中一番目に付くところに貼っただけ。

2週間ぐらいたちますが、徐々に首筋のハリが緩和され、肩こりも楽になりました。ひどい時は、大好きなブレスオブワイルドも遊べないぐらいだったんですが、この付箋のおかげで、ついにポーチの全開放を実現しました!

種明かしというか、実際は、自分が「TCH(Tooth Contact Habit)」を持っているかもしれないという気づきがスタートです。文字通り、歯(の上下)をずっと接触させている癖ですね。癖なのでなかなか気が付けないのですが、たまたま見た以下のサイトのおかげです(実際、知覚過敏にも悩んでました)。

www.hhk.jp

私は、特にPCで作業しているとき、気合を入れるつもりなのかわかんないのですが、口を「ぐっ」と、閉じ続ける癖がありました。 その際当然ながら、上下の歯が触れ、顎の筋肉に余計な力がかかっているんです。もしかすると、ゲームしてるときもそうだったかもしれません。

なので、付箋に「歯」と書いて、それを見たときにに意識的に口元を「ふわっと」緩める癖付けをしました。PCの前じゃないときも、(口は閉じたままで)歯の上下が触らないよう気を付けます。

加えて、顎やこめかみの筋肉の簡単なマッサージ(指の腹でぐりぐり)をたまにやっているうちに、気が付いたらハリや肩こりが緩和されていました。

すべての肩こりの原因がHCTだとは思えませんが、自分もそうかも?という方は、一度試してみてください!

 

 

 

 

今時の議事録事情

4月1日、永和システムマネジメントにも7名の新入社員が入社しました。みんなフレッシュで良い刺激になりますね。

うちの場合、これからマナーなど共通的な教育があり、その後、配属先に分かれての教育に切り替わっていくわけなんですが、議事録の書き方を教える機会はないようなので、今時の事情を踏まえつつ、大事な点について、あらためて書いてみたくなりました。

ソフトウェアの現場で昔ながらの議事録を書く機会は減っている?

対面コミュニケーションを重視するアジャイル開発が増えているのが理由なのかどうかわかりませんが、少なくともこの5年間、私は「昔ながらの」議事録を書いていませんし、書かせたこともありません。

「昔ながらの議事録」は概ね以下の内容で、昔はWordとかで書いて参加者にメールで回覧してました。内容的には、単なるメモではなく、目的と結論が大切です。

  1. 日時
  2. 場所
  3. 出席者
  4. 目的
  5. 結論
  6. アクション
  7. 議論の内容
  8. 次回予定
今はみんなで議事録を書きながらのミーティングが主流?

じゃあ今はどうしてるのと聞かれると、Google Docs などのコラボレーションツールを活用することで共同編集し、打ち合わせが終わった段階では書き終えているスタイルでしょうか。専用のサービスも増えていますね。

私も、(ツールを使ったコラボレーションに慣れている)社内の仕事ではよく使います。複数の部署が絡んでいて主導権が固まってなかったり、要望がふわふわの状態だけどキックオフが始まっちゃうことって、実は結構あるんですけど、そんな場合は次のようなステップで進めています。

  1. Googleスライドで最低限のアジェンダを3分で書いて即参加者に共有する
  2. 集まった目的とかゴールをアジェンダを見ながらレビューというか意識合わせし
  3. 事実関係をヒアリングしながら最新状況として皆でメモしつつ
  4. 最低限、「今の課題は何で、次までに何をアクションすべきか」までを皆で認識する
  5. 打ち合わせ終了予定の5分から10分程度前から、口に出して、「皆さん、次のアクション見えましたか?」「今日のゴールに満足ですか?」など、締めに向けたまとめに入っていく。

こうやって、皆の意識を議事にフォーカスしてもらい、目的達成に向けた課題や手順をクリアにしていきます。コラボツールを使ってみんなで編集することで効率化することでタイムボックス守りつつ、「結論出なかったので次回持ち越しね」を断じて避けるのがポイントです。

コラボで効率よくタイムボックス云々って難しくないです?

ここまで読んだ新入社員の人が「理屈はわかったけど、スピード感もった意識合わせとか課題出しとか、難しくないですか?」といいたくなる気持ちはわかります。うん、多分、難しい。それは、議事録とか打ち合わせ以前に、仕事そのものに対する慣れが必要になるからです。

社会人になると、作業ではなく仕事を期待されます。自分の頭で目的を考えたり課題を発見する必要があるし、もちろん、具体的な行動と成果が期待される。

私は、会議という場には、仕事の要素が濃縮されていると思います。なので、まずは「昔ながら議事録」を身に着けて、仕事のスキルアップの一助にしてみてください。質の高い議事録スキルは仕事をするうえで、とても価値があります。

今でも議事録を書く機会はあります。チャンスがあれば議事録係に手を挙げてください。以下の記事が役に立つと思います。 

happyman.hatenablog.jp

 

 

 

 

 

 

 

一括の受託開発でアジャイル

スクラムのコーチとしてトレーニングに参加したりすると、必ず契約の話題になります。(質疑応答で100%でてきます)

  • 「うちは一括でしか契約できないのですが、スクラムではどうしますか?」
  • 「リリース日を約束しないとなると、契約上の納期に遅れそうな場合どうしますか?」
  • 見積もりした結果に利益加算して契約するかと思うのですがスクラムでの契約はどうするんですか?」

などなど。よく言われているように日本のエンジニアは受託開発に従事されている方が多いので、そりゃ質問したくもなるだろうなぁ、とは思います。ただ、身もふたもない言い方をしてしまえば、今のところ答えは「準委任契約ですね」となってしまいます。

もちろん、契約モデルについては様々な試行錯誤がされています。価値創造契約も一つの形ですね。ものすごく細かく(それこそスプリント単位で)請負契約を分割するやり方も実践されています。

ただ、従来のウォーターフォールで慣れ親しんだレガシーな企業の契約形態はそうやすやすと変わることはありません。たとえお客様担当者に理解があったとしても、法務や調達部門の壁を壊すのは、なかなかムズイ。

そこで今日は、私の知る限りで、「一括請負でアジャイルやれているケース」について説明してみます。

ベロシティ実測してリスク取る

まず、ウォーターフォールでもよくある形なのですが、要件定義を準委任でやって、基本設計以降を一括で、というパターンの応用です。

要件定義フェーズで要件定義を行う(要件定義書を書く)のではなく、実際にスプリントを回すことでベロシティを計測し、残りのバックログの開発に関しては、このベロシティを前提とした費用(必要な期間と人数をはじき出す)見積もりを行い、一括での契約を行います(もしくは、プロトタイプ開発を準委任契約範囲で行い、本開発を一括で行います)。

なので、「アジャイル開発に理解はあるが、諸々の事情で一括契約しかできないお客様」にしか使えませんし、当然、開発会社のリスクはなくなりません。一括契約なので事前に要件を洗い出す必要があるため(じゃないと検収できない)、やりたいこと(バックログ)が、安定している必要はあります。

持久戦に持ち込み徐々にアジャイルトランスフォーム

次は、比較的大規模なシステム構築をアジャイル化していくパターンで、いわゆるハイブリッドなアジャイルを経由し、元々ウォーターフォールな開発を、時間をかけてアジャイル化していくことになります。相当根気が必要ですが、実はこれが最も現実的な取り組みです。

当社でこの取り組みをうまく続けているチームを観察すると、いくつかのポイントを見つけることができます。

1.しっかりウォーターフォールを成功させチームを安定化させる

 顧客との信頼関係を築くのはもちろん、安定したチームを作るためにも、ウォーターフォール開発を成功させます。この成功体験を持ったメンバーで、徐々にアジャイル化をしていくことになります。正しくウォーターフォールすることでドキュメントも揃うため、業務知識の形式知化も進みます。

2.リリースを3か月から6か月程度にステップ分けする

大規模なシステムの場合、ファーストリリースされた後に追加開発が行われることは多いでしょう。もしくは、最初から「機能ごとに、段階的にリリースしていきましょう」などという提案を行います。それぞれのリリースはすべて一括契約で行うため、これにノーを出すお客様は少ないかと思われます。

もちろん、一括の範囲を狭くすることでリスクを下げることが狙いですが、リリース期間を短く繰り返すことで、アジャイル開発のリズムに慣れてもらうという効果もあります。

3.プロジェクトファシリテーションからスタートし改善の癖付けする

ここから徐々にハイブリッド化させていきます。取り組むプラクティスはふりかえりと朝会からがやりやすく、スクラムマスター候補にファシリテーターを任せたり、スクラムのトレーニングを受けてもらったり、アジャイル開発をしている別プロジェクトのメンバーとの交流も開始します。

ただしこの時点ではウォーターフォール前提のため、タスクはサインアップではなくリーダーによるアサインであったり、報告のためにガントチャートを作成しています。

自己組織化と機能横断的チームについては、次で説明する育成とワンセットで時間をかけて取り組みます。

4.育成には時間をかける

アジャイル化に向けた大きな課題はいわゆるT字型人材の確保・育成です。ウォーターフォール組織の場合、設計とプログラミングで担当が分かれてしまうことになりますが、アジャイルチームでは全員が設計とプログラミング両方できる必要があります。

これを実現するには、エンジニア本人がそうなりたいと思えないと本当にダメで、チームのサポートだけでなく、部署・会社組織としての取り組みが必要です。年間を通じた個人面談や各種勉強会の開催、資格取得に対する支援など、組織としてやれることは多いです。

5.ウォーターフォールの中に本物のアジャイルチーム

メンバーの意識とスキルが整い、お客様の信頼も高めた状態になってから、プランニングやサインアップ、バーンダウンチャートなど、その他のプラクティスを導入していくことで、ウォーターフォールの中に本当のアジャイルチームを作り出すことが可能です。

ちなみに、今回引き合いに出したプロジェクトは、ここにいたるまでに約2年かけています(ただし、「バーンダウンからガントチャートへの変換」は継続中ですが、必要コストとみているようです)。

6.要件定義という名のバックログリファインメント

今でも要件定義は実施しており、要件定義書もしっかり作成します。ただし、今では要件定義作成と開発期間をオーバーラップさせることで、すぐに次のステップの開発に入れるようになってきています。スクラムにおけるバックログのリファインメントとは意味合いは違いますが、そのステップに盛り込みたいストーリーすべてを「Readyの定義Done」にしておくイメージです。

7.お客様にアジャイルの良さをアピールし続ける

こうして時間をかけて実績を積み重ねながら、お客様にはアジャイル開発の意義をご提案というか啓蒙し続けます。 そして実は、時間をかけることのもう一つのメリットは、「世の中が追い付いて偉い人の耳にもアジャイルが届くようになってくる」こと、かもですね。

本当に大事なものは何?

現在はプロセスとしてはハイブリッド状態であり、完全なアジャイル化にはまだ時間がかかると考えています。ただ、安定し、自己組織化されたチームが実現できたことは、何事にも変えられない成果だと考えますし、ゆくゆくは、契約を一括から準委任に切り替えていくことも可能だと思えます。

ずいぶん長くなってしまいました。。いろいろ他にも書きたいことはありますが、もしよろしければ、続きは是非現場に見学に来て、実際のチームにいろいろ質問してください!ということで、宣伝しつつ締めたいと思います。(以下ページに見学申し込みフォームがあります)

www.asf.esm.co.jp

 

 

企画や講演なんかのネタ作り用テンプレート

企画を手早くまとめたいときや、講演で発表するネタを考えたり整理するときのテンプレートです。スライド1枚に収まります。まずはこのレベルで上司にネゴったり、主催者に確認したり、誰かに意見求めると良いと思います。別段私が思いついたものではありませんが、若いころ企画のプロジェクトをしていたときに沁みついたもので、今でも使えるんじゃないかなと思います。

  • 外部要因(経済環境、技術トレンド、競合状況など)
  • 内部要因(当社・自分の強みや相手の困りごとなど)
  • Why?(外部内部要因をふまえた、相手の嬉しさとか自分のモチベーションをシ一言で)
  • What?(内容をシンプルに。展示会なら何を展示するのか)
  • How?(どのように伝えるか。講演ならスライド使う/使わないなどのスタイルや演出方法)
  • キャッチコピー(企画ならテーマ、講演ならタイトル案)
  • 目標(獲得したい具体的なもの。営業の企画ならリード数など)

まとめると、、

今はこんな時代背景で〇〇に困っている人が多く、一方当社にはこんな強みがある。そこで私たちこそが〇〇のために〇〇すべきだ!なので、こんなものを、こんな方法で作りたいのです。キャッチコピーは〇〇!この企画通してくれたら、〇〇を得ることができますよ」

といった感じでしょうか。

一通り書き終えたら、セルフチェックをしてみましょう。

  1. かけがえのなさはあるか?自社(自分)以外に置き換えられるようでは刺さりません。
  2. 時代性はあるか?今この時代・時期・このイベントだからこそ企画したり語りたい内容になっているか。
  3. エレベータピッチできるか?「要は〇〇ですね」と偉い人に5~10秒程度に圧縮して話せるか。

チェックにパスしたら、周りにいる有識者に意見求めて洗練させていきましょう!