せいせいせーいっ！
どうもクラウドアーキテクチャチームの齋藤です。

今日は思い出話をしようと思います。

もう数年前になるのですが、以前にある開発イベントに参加したことがあります。
それは、いくつかのチーム（5-6人）が３か月間かけてアプリの企画・実装・発表までを行い、順位を競い合うというものでした。

開発2年目くらいでなんもわからなかったけど、サービスを１から作る経験しとけば役に立つやろみたいなあれで参加したことを覚えています。

明らかにやべー重いイベントなだけあって、これ普通は参加企業内でチームを組んでから参加するんですよ。
でも弊社からは自分しか参加者がいなかったので、その場で混成チームを組んで参加したんですね。
全員その場で初顔合わせ、というか全部オンラインだったので顔もあわせてないです。

その結果、チームメンバー6人中開発未経験者４人という状況でスクラム開発をするということになりました。

で、その６人で作った成果物が2/3タイトルで優勝、僕個人も表彰を受けるという圧倒的に最強の結果をたたき出しました。

映画かな？

どんなもんつくったの？

旅行アプリですね。
Googleから観光スポットの口コミとかをとってきて表示、ポチポチするだけでいろんなスポットの情報が見れるので、気になった場所をあつめて観光プランを作り、自宅の最寄り駅から移動経路とか全部表示して観光ガイド作成。

観光中はガイドに記載されたミッションを達成することで、ただ行くだけじゃなくてどう過ごすかの体験も含めてサポート。
最後にはその観光結果を日記の１ページとして残し、公開したりできるWEBアプリでした。

うーん、自分のチームの成果物ながら、今見ても面白いなぁ。

これ、うちのチームでデザイン担当たてて、マスコットキャラとかサイトのデザインと化してもらってたんですけど、すごいそれっぽくしあがってて好き。

サービスの基本構成

機械学習でユーザーに最適なレコメンドをする機能搭載

運用監視

サーバレスのアーキテクチャでいい感じ。
まるで開発未経験者集団が作ったとは思えない出来栄えだと思います。
でもGoogleAPIの利用料金がやばすぎてサービスとしては残せなかったのが心残りですね。

じゃあこのいい感じのアプリを作るまで、我々がどんな壁にぶつかり、どう対応していったかをほにゃほにゃ語っていこうかと思います。
あらかじめ言っておきますが、とても大変でしたし、理想的とは程遠いと思います。
でも、次には活かせるはずです。

※注意
今回の内容は宣伝用ではなく反省のためのもので、チームの課題や良い結果が得られなかったという部分も書き出しています。
これらによって当時のメンバーや運営を非難するつもりは一切ありません。（みんないい人でした）
また、本内容は組織人としてではなく齋藤個人の意見とさせてください。

チームの抱えた課題

思考プロセス、評価軸の違いを補うための施策

アクション：思考プロセスや評価軸のすり合わせ

全メンバーが違う企業から集まっている以上、考え方や文化には大きな違いがあり、これに共通認識を持っていない場合議論が崩壊します。

最初にプロジェクトの企画をやるのですが、このあたりを一切触らずに「アイディア考えてきてください」と宿題をだし、後日投票制でアイディア決めを行ったのですが、いきなりおお揉めしたのを覚えています。

具体的にどうこうという例をあげるのもアレなので控えますが、自社の文化や考え方が当然の常識という幻想を持ってはならないと理解しました。
そしてこれは、文化とかだけじゃないんですよね。
IT知識とか、前提条件とか優先順位とか、「当然知っているだろう・こう考えているだろう」というバイアスで会話してしまうことが自分にも多々ありました。
コミュニケーションをとるうえで、共通認識をベースに会話をすすめるということの重要性をよく学びました。

そこで、議論を進めていくうえで重要なポイントを共通認識としてもとうと会話する機会を設けてみました。

要は思考プロセスから違っていて、何を重要視するか、良い意見を出すためにどうすればいいかが皆ちがっていることが問題だと思ったため、
まずはそのような思考法や、会議を進めていくうえでの重要なポイントについて共通認識をとろうと考えました。
これで共感を得ることができれば、以後根拠のない意見や、結果ありきの議論などを減らせると考えました。

その結果は

どちゃくそ失敗しました。
そもそも関係性とか構築できてない相手にこんな話しても共感や納得なんて得られないですよね。
むしろ反感買ってチーム不和を生む原因になりました。

最初はまず何はともあれ仲良くなること、お互いの価値観や実力を把握し、関係性を構築すること、これが大事だと頭ではわかっていましたが、初めて理解しました。

プロジェクト企画でもめて、チームの仲悪くなって、そんな状態だから表立ってリードする立場に立つこともできなくなって、出だしは最悪でした。

アクション：意思決定者を用意する

さて、前段のやらかしで自分はチームをリードすることができなくなりました。
また、議論を進めるうえでの価値観の共有にも失敗しました。
この状況下で、なんとかスムーズかつできるだけ有効に議論を進められる方法を検討する必要がありました。

関係性のないメンバーの集合＋価値観の共有ができていない状況は、会議の進行を止めます。
なぜかというと、お互いの立場に上下関係がない場合その意見を平等に扱わないといけないので、強い発言権を持つことが難しく意思決定がかならず多数決になってしまうことに加え、共有された価値観をもとにより会議体全体の方針を統一・決定するのが難しくなるからです。
ちなみに、この状況でまた会議を動かそうと発言を繰り返すと、さらにヘイトを買ってより難しくなっていきます。（経験者は語る）

なので、メンバーのなかでも比較的ロジックで判断でき、かつ話し合いの上で発言が少ない方を判断して、意思決定者として設定しました。

これでによって、議論が硬直した場合「じゃあ意思決定者に決めてもらいましょう」ということで強制的に議論を執着させることができるうえ、意思決定者がロジックで判断できるのであればノイズは自動的にはじかれるので、スピードを維持したまま次の議論に進んでいけるわけです。

意思決定者がアイディアを出すと公平性をそこなってしまって反感を買うことにつながるので、それを避けるために会議内ではなるべく発言の少ない方から選ぶのが適任と考えました。

これによって、対立関係者が存在する会議体でもスピードを落とさず正しい結論を出していけると考えました。

その結果は

大成功でした。
これについては完全に想定通り、うまく施策がはまったと感じています。

実際ちゃんとノイズとなる意見ははじかれていきますし、僕自身の独りよがりなものにせず、まともな意見を拾い上げてくれるよいバランサーが生まれたので、これはかなり良い施策でした。

また、上司の大切さを学びました。
実際上下関係のない集団をコントロールするのは難しいですね。
発言権が平等であるがゆえに、どんな意見も大事にしなきゃいけない空気ができるわけですが、この状態で会議体に正しく意思決定を行ってもらうことというのは想像以上に難易度が高いと感じました。
こんな時、ちゃんと俯瞰で判断を下してくれる上司がいるというのは、非常に大事なことなんだと実感しました。
ちなみに、この施策以外にもスクラムのルールで存在するレトロスペクティブなども効果を発揮したと思いますが、
私が考えて実行したものではなくスクラムという手法の話なので、割愛します。

スクラムとは

技術力不足を補うための施策

アクション：専門分野をつくる分業体制

未経験者を３か月という短い期間でどう開発できるようにするのか、これは大きな課題でした。
全員が全体を見れるというのは理想ですが、gitとは何かくらいから始める人が大半なので、そうもいきません。

アダムスミスの国富論でも説かれているように、生産過程において役割を決めて作業者をその作業だけに特化させることは、生産効率を上げます。
特に、開発経験のない人間をあつめて一つのサービスを作っていこうというのですから、極力一人当たりのキャッチアップ範囲はすくなくなるべきです。
というわけで分業体制をつくり、その分野について責任を持つ人間を振り分けていきました。
これにより、一人一人が専門領域を持つようになり、アプリケーションの開発スピードが上がると思いました。

その結果は

たしかに各種専門領域ができること自体は多くのメンバーの開発速度を上げる結果につながったと思います。
実際タスクを振る際も、基本的にタスクごとに誰をアサインするかでもめる必要もなく、タスク過多なら開発経験者がサポートに入るということで、運営自体はスムーズに回りました。

反面、各種専門領域ができたことで、タスク終盤に手の空いた作業者を他の領域に回すことができなくなりました。
基本的に、LambdaはpythonとGMAPAPI、アプリケーションはvue.js、DBアクセスはgraphqlやDynamoDB、リソース連携はamplify・AWS全体というように必要とされる知識が全然違かったため、いきなりアサインされてもすぐに開発に着手できるという状態ではなく、その分野で開発をしている人に教育コストをはらってもらうこともできなかったためです。

また、僕の労働が非常にブラック化しました。
つまり、専門領域を作ったは良いものの、メンバーの能力自体は当然ながら未経験者であるため、開発経験者は全領域見なければならなかったということ。
そして、専門領域以外のすべての必要な作業は僕がサイレントに巻き取る必要があっということです。
また、僕自身にも専門領域は割り当てられている状態だったため、まぁかなりひどい状態になりました。

ただ、多分分業していなかったらもっとひどいことになっていたと思います。
なので、身もふたもない話ですが、最終的な高い成果を求めるという意味で多くの領域を巻き取ってしまったということ自体は間違っていなかったと思います。

ただ、このプロジェクトが3か月より長い期間続くということを前提とした場合、この方法は間違っているように思いました。
今回は運よく開発期間と方針がかみ合ったということですね。

アクション：開発環境を整理する

さて、つぎは開発環境の共通化、復旧の容易化についてです。
今回の参加メンバーは開発経験が無いものが過半数を占めていたこともあり、
個別のローカル環境での開発は環境問題のトラブルシュートに時間をとられると考えていました。

そこで、開発環境をAWS Cloud9というサービスを使って、AWS上に構築するようにしました。
これにより、環境の複製やメンバーの開発環境に直接アクセスできるようになったため、トラブルシュートの速度を上げることに成功しました。

これは企画→実装へとフェーズ移行する中間で一人で一気に進めました。
というのも、このレベルのことを相談して進めてたら絶対終わらないからです。

内容は以下のようにしました。

実装チームが大きくLambda・フロントで別かれたので、CodeCommitでソースを分けて管理しつつ、フロント側のCICDをAmplifyで自動化しました。
DynamoDBの定義もコードで管理し、データの中身はAWS Data Pipelineでバックアップを定期的に取得するようにしていました。

なるべくIaCといえるような状態にすることを心掛けていたと思います。

実際この初動が結構大事で、当然ながら開発中の環境はしょっちゅうぶっ壊れたり環境全部削除されちゃったりしたのですが、無事コードから楽々復旧出来て助かったりしました。

コーディング環境をCloud9に固定することで、メンバーが環境構築で詰まったりバグが解消できないというケースでも、それと全く同じ環境で動作確認したりペアプログラミングすることも容易にしました。
おかげでチーム単位での連携はかなり強化され、僕も横断的に開発に参加することができました。

アカウント保護についてはいろいろやりました。
以下以外にもたくさんあったと思います。

MFAの強要
 AWS 環境における脅威検知と対応
 AWS Config ベストプラクティス
 おすすめConfig Rule
セキュリティグループのSSH全開放をAWS Configで自動修復
 GuardDutyの設定
 メーリングリスト作成マニュアル
 OWASP Top 10
AmplifyにIP制限を設ける
 AWS WAFとマネージドルールの違い
 Macie
SecurityHub

その結果は

大成功でした。
そもそもこの内容は開発作業を楽にするための物だったわけですが、イベントではアーキテクチャも評価対象になったため、これも成果物の一つに含めることができたので、評価ポイントになりました。

また実際3か月の間に環境破壊は4,5回おこっていて、こちらについてはすべて2時間以内で復旧を完了しています。
くわえて、開発環境のトラブルも当然ながら幾度かおこったわけですが、どれも他の人の開発環境を複製したり、僕が直接アクセスするなどして迅速な解消に成功しました。

他のチームでも同じようなことに挑戦しようとしたという話を聞いていますが、実際にプロジェクトが動き始めてから改善するのと、まっさらな状態からここを視野に入れているのとではタスクの進めやすさが全然違ったと思います。

初期から明確に先をイメージしてタスクに当たれるかどうか、その重要性を理解しました。
また、開発体験を向上することで、明らかに開発の効率は向上するということを理解できました。

アクション：ペアプログラミングによる教育

技術不足対策最後の施策はペアプログラミングです。
今回、コロナの影響で全行程をネット上で行ってきたわけですが、その結果ペアプログラミングを行うのも少し工夫が必要になりました。

今回は前述の開発環境構築にて、開発環境をAWS上に構築することでコードの複数人同時編集を可能にし、ペアプログラミングを実現しました。

その結果は

結果としては大失敗でした。

実際ペアプログラミングをしてよかったという意見もありましたし、それがちゃんと成果に反映される人もいます。

ただ、結局最終日までに対応された開発チケットが0件のメンバーもいました。
別に相手もやる気が無かったというわけではなく、お互いの人間関係も悪くもなく、単純に習得にかかる時間が足りないか適性が低かったか、僕の教える能力が低かったかというケースだったと思います。
正直、自身の力不足にかなり落ち込みました。
また、数十時間の教育コストと達成されなかった実装タスクの巻取りでめちゃくちゃブラック労働が加速しました。

できないものはできないものとして開発以外のタスクに割り振るしかないのですが、このイベント目的には本人の成長という面もあります。
そのため、最終発表１週間前までずっと教育を続けてしまいました。
普通の企業であれば適正に合わせた異動とかあるとおもうんですが、そういう対応が縛られていたことで最後までどうしてよいか結論は出ませんでした。
これによって僕個人への負担もあり得ないぐらい引きあがりまして、個人的には最大の失策だったと思っています。

教育というのは、効果がでるとはかぎりません。
短期プロジェクトであればなおさらです。
人材の適性の見極めと適切な人員配置の重要性を理解することになりました。

まなびのまとめ

マジでいろいろありましたし失敗も多い時間でしたが、ちゃんとした結果もだせて学びもあってとても良い時間を過ごせたと思っています。
特にマネジメントの観点で得たものが大きかったように思います。

もう当時のメンバーとは一切連絡を取ってないですが、みんながこの時間を糧に今につなげられてたらいいなぁと思ってます。

あっ、そういえば４月からコアアーキテクチャチームのリーダーになりました。
やっとこの学びを活かせますね。

Fin.