プロトタイピングチーム作ります

AWS にプロトタイピングチームというプロトタイピング活動を支援してくれるチームがあり、WHI でもいくつかのプロジェクトでお世話になっていたのですが……

偉い人「社内にもこういうチーム欲しい」

というわけで、今年、私の Group が Training & Prototyping Group へと改組され、ありがたいことに AWS から直接、AWS のプロトタイピング手法を伝承していただけることになりました。
AWS でも他社のプロトタイピングチーム立ち上げを支援するのは初、というお話だったので、この半年間、グループマネージャーとして考えてきたことややってきたことをまとめて公開したいと思います。

準備

グループがやることの整理

プロトタイピングチームは AWS の標準的なチームを参考にまずは 1 チームだけで始めることにし、チームのミッションを整理、明確化し、今期の目標を設定、それをメンバーの役割に落とし込んで説明しました。

上位のミッションとの関係の整理

なぜプロトタイピングを推進するのか？　それは会社、あるいは上位組織のどのミッションと関係しているのかを意識して COMPANYの機能開発時の技術課題を素早く解消する 手法として推進していくものとしました。

今期の目標の設定

AWS にプロトタイピングチームの立ち上げを手伝っていただけることになっていたので、今期は AWS の手法を取り入れることと、差異や違和感を洗い出し、課題を明らかにすることに置きました。

どうやって AWS からプロトタイピング手法を継承していくか

まずマネをする

幸いにも最初のプロトタイピングプロジェクトは明らかに「できそう」であったため、AWS の手法を全面的に参考にしながら進めることにしました。

社内のプロセス・手法と融合させる

また、その時に社内の開発ツールやプロセスとうまく融合できるかチェックすることにしました。

次に失敗する

次のプロトタイピングプロジェクトは明らかに「難しそう」であったため、失敗を視野に、スコープの縮小や最小限の成果の設定といった手順、基準の洗い出しを目標に置くことにしました。

実践 1：最初のプロトタイピング

プロトタイピングはプロトタイピングなのか？

一件目を実践してみてこのプロトタイピングは（達人プログラマーで語られる）プロトタイピングとは若干違うな、という感覚を持ちました。

	スコープ	例外系	対象データ	成果物	言語・ツール
達人プログラマー	最小化する	非対応	ダミー可	棄てる	自由
AWS	最小化する	非対応	ダミー可	利用する	再利用先に合わせる

どちらも検証範囲にスコープを限定しますし、データのチェックや例外処理を割愛します。また、それが検証対象でなければ少量のデータやダミーデータを活用して検証の完了を急ぎます。
違いは成果物の再利用、あるいはそれをベースにした拡張開発を視野に入れているか否かです。
そのまま利用することを想定しているため、開発言語やそのバージョン、プロジェクト管理などが制約を受けます。

社内プロトタイピングチームではどうするか？

各開発チームがどちらの「プロトタイピング」を行うべきかの判断は

その課題に対応できるチームになることに、どれだけ価値があるか？

を軸にして考えるべきでしょう。
価値が高ければ自分たちのチームで 「プロトタイピングの真の目的は学びにある」 達人プログラマー式のプロトタイピングを実践するべきでしょうし、価値が低ければ技術課題の素早い解消を狙ってプロトタイピングチームの助力を求めるべきでしょう。

そのため、私たちのチームは

各チームが主体的に取り組むプロトタイピングのヘルプ
多くのチームが利用している言語、フレームワークの新機能のプロトタイピングへの参加と、情報の横展開
製品開発者が必ずしも知っておく必要の無い、ニッチな技術、深い技術の主体的なプロトタイピング実施

というように、ノウハウを持つべきところに応じて主体性を預ける、あるいは預かる調整を意識していこうと思います。

成果

社内の開発プロセスとの融合

WHI はパッケージ製品とサービスを自社開発し、リリースしている会社であるため、開発サイクルが一定です。
このため、この開発期間と同じ期間を、標準的なプロトタイピングの期間として設定することにしました。
また、たまたまその期間が AWS のプロトタイピング支援の標準的な期間と同じであったため、適切な規模感をそのまま共有できたのは幸いでした。

社内管理項目の整理

成果物をそのまま活用、発展させていくので、開発リポジトリや開発環境、予算などは原則として依頼元チームに用意してもらうことにしました。
これは、GitHub Enterprise や AWS の認証認可の管理が整備されていた点も大きく、基本的には Prototyping team のグループを作って、グループ単位で権限を管理できるようにしました。

活動成果のとりまとめ

プロトタイピングがどういう場面で役に立つのかを知ってもらいもっとプロトタイピングという手法を活用してもらうためと、各開発チームではなく Training & Prototyping Grp. がメインで取り組んだものの調査結果を社内へ展開する目的で、活動成果の蓄積と、一部公開もはじめました。

課題

あいまいな要件

1 つ目のケースは、課題がそれほど明確でない状態で始まりました。
プロトタイピングでは目的を明確にすることが大事で、この目的を中心に、主体となる開発チームとプロトタイピングチームとの間でゴール設定を行ってから実作業に入ります。
ですが、社内の別チームへの依頼となると、この部分をあいまいのまま進めざるを得なくなるようです。

これは

改めて資料や要件を整理しない
後から気楽にゴールを動かせる

という、社内チームだと気軽に依頼できる メリットとのトレードオフでもあり、厳格にしすぎるとメリットが小さくなってしまいます。
そのため チケットをベースに依頼を受ける という運用方針で様子をみることとしました。

実践 2：2 つ目のプロトタイピング

2 つ目の案件はある技術 V に対応できるかどうかの調査でした。
（当初、技術 V について、どういう問題が起きたのかを詳述しようとしていたのですが、ちょっと、関連する術語や概念が多すぎ記事のボリュームがとんでもないことになったので、詳細を落としてチーム立ち上げに焦点を絞りました）
難航が予想されたので、実践 2 の目標は

難しいプロトタイピングを実践する（難しい案件にチームとして取り組む経験を積む）
難しい案件をコントロール（スコープの縮小・目標の再設定）する
コントロールするために予見ポイントを見つける

としました。

成果

難易度の高い課題と向き合う

技術 V は W3C 勧告がまだ出ていない中、いくつかのグループ、フレームワーク、ライブラリが先行している草創期のもので、ただでさえ少ない情報が新旧・ベンダー・ライブラリが入り乱れている状態にありました。
メンバー別々に情報を整理してもらい、それを突き合わせていくことでキャッチアップを早めることを狙いました。
また、このようなものは概念だけでの理解が難しいので、ライブラリのデモコードを読み、サンプルを動かして理解を深める時間を取りました。

失敗のコントロール

工期がどんどん伸びていったのですが、途中 2 回、スコープの縮小と目標の再設定を行うことができました。
AWS のプロトタイピングチームの方のアドバイス通り、最初に 「何を検証したいのか」 をはっきりさせておいたことが、再設定時にたいへん役に立ちました。

また、再設定時に目標を細分化、優先順位付けを行いましたが、開発期間が短いものであっても、最初からやっておくべきことでした。

Python

チームメンバーは Python に馴染みがなかったそうですが、必要に迫られて読んでいました。
最近は、Python でアイデアやサンプルを示されることも多く、個人的には実装で使わなくても習得しておく価値の高い言語だと思うので、良い機会になったかなと思います。

課題

スコープを狭めきれない

検証スコープは最後は必達目標だけに絞ったのですが、技術 V は、その小さな必達目標を達成するための前提となる技術的ハードルが多く、作業量はそれほど圧縮できませんでした。
今回のようにまだ情報が錯綜している段階の技術では、ふたを開けてみないと分からない部分も多いため難しいですが、技術課題の細分化も最初に行った方がよさそうです。

予見は難しい

そのため早期発見の仕組が必要です。
とはいえ開発期間が短いため、発見のためのミーティングを持つのは重いので、メンバー間の実装相談や連携確認などの場に混ぜてもらうなど、観察の機会を増やして発見できないか試行しようと思います。

工期をきちんと切る

難しい課題では 終わり が見えていることも大事です。
ゴールの再設定などで作業の 終わり はコントロールできましたが、工期は伸びてしまいました。
今後は、期日の 終わり もしっかりとコントロールしていきたいと思います。

Fail fast を意識する

また、この 3 つの問題が起きたのはプロトタイピングを Fail fast、つまり、この技術を製品に組み込むのは、もう少し待ったほうが良さそうだ と終わらせなかったせいでもあります。
もちろん、それで完全に終わりにはならないでしょう。
「じゃあ、いつ、あるいは何が解消したら進められるのか？」という調査が必要で、それをチームで継続して調査するということにはなったかと思います。
ですが、プロトタイピングを一度 「早期に問題が発見できてよかったね」 と成功裏に終わらせて、調査としてゴールを決めて仕切り直しすべきでした。

主体となる開発チームがない

2 つ目のケースでは、検証したい技術的な課題は明確な一方で、実際の製品の開発を進めている開発者のチームが存在しないという問題がありました。
これも社内ならではの状況で、企画あるいは製品アイデアのみというかなり早期の段階でプロトタイピングを行って欲しいというものでした。
成果物として課題に取り組んだデモの実装とレポートをまとめ、企画担当者に引き継ぐ形で終わりにしましたが、今後は開発チームのビルドアップと共にプロトタイピングを行うようにする方が良いと感じました。

メンバーの手ごたえ

リサーチ力が上がった

特に 2 つ目のケースでは、調査中に情報が新しくなっていくような中、開発者たちの Discord コミュニティや OSS の issue、プルリクエストなどを読み解きながら状況を把握するといった、情報収集の手段が広がったそうです。

先輩の役に立ててうれしかった

普段の製品開発だと、先輩の方が圧倒的に詳しい場合が多かったけれども、今回、プロトタイピングでは新しい技術を調査して使っていくということで、後輩が調査した項目が先輩の役に立つという局面も出てきました。
後輩メンバーがそのことを「ちょっと恩返しができたようでうれしかった」と言っていたのも良かったのですが、後輩メンバーにとっても、自分自身の成長を実感する機会となったので、それも良かったところです。

ノウハウがチームに貯まる

プロトタイピングを個人に任せず、チームで行うと、ノウハウがそのチームに貯まっていって、詳しい人が複数できるので良かったという感想もありました。
新規開発や技術調査だと、一人で突き進み、結果、スーパーマンがひとりできるといったケースが多かったので、チームにノウハウが残るのはプロトタイピングの強みだと思いました。

主体となるチームとタッグを組みたい

ノウハウがチームに残るということは、プロトタイピングチームだけでプロトタイプをやるよりも、引き渡し先のチームと一緒にやるほうが良さそうです。
来年以降のプロトタイピングではその点もしっかりと意識していきたいと思います。

来年以降にむけて

標準の試行と改善

今期整備したプロトタイピング標準を活用したプロトタイピング支援を計画しています。
プロトタイピングによる Fail fast の効果が高そうな技術課題であればベストですが、プロトタイピングの普及のためにも広く構えていきたいと思っています。

また、標準を活用することで問題点を洗い出し、さらなる改善を加えていく予定です。

予算の確保と活用

予算を依頼元に用意しておいてもらう前提にはしていますが、それとは別にプロトタイピングチームが使える予算を申請しました。
2 つ目のプロトタイピングでは、多数あった技術的ハードルは検証のための前提条件にすぎないので、外部のインフラ、サービス、ネットワークなどを利用しても構わないはずのところでした。
このような場面で活用していきたいと考えています。
とはいえ、短い開発期間のうちの数日を稟議に取られるのは厳しいので、技術課題の細分化を早期に行うことは必須となりそうです。

チームの拡充

当面は様子見となりますが、メンバーが難しい技術課題のプロトタイピングに連続で取り組むような状況を避けたいと考えています。
これはゴールの見えない、はっきりしない仕事を連続させないためで、社内の月次の健康チェック（ストレスチェック）でも確認されている項目です。
幸いにして今のメンバーたちはそれほど苦にしていないようですが、社内体制としてチェックされている項目を、仕組みとして回避できない状態はあまりよくないので、軌道に乗り、忙しくなってきたら 2 チーム体制に拡充して、難しい課題を連続させない仕組みを整えたいな、と考えています。

宣伝

となると、人員が必要になりますが、WHI はただいま絶賛エンジニア募集中です。
プロトタイピングチームに直接でなくても、社内のエンジニアが増えれば異動できるメンバーが増えるので、よろしくお願いします。

リンク

AWS Prototyping チームの blog
AWS Summit Tokyo 2023 のセッション動画
 上記セッションの資料

社内プロトタイピングチームの立ち上げ