ID:59255さん

新規事業開発プロジェクト。社内チーム6名、プロパー10名

本質的な社会課題を解決に導くシステムにすること。また、それを滞りなく開発・提供すること。実際のユーザーの使い方を想定した企画設計とUX改善。

法人向けシステムだったので、ユーザーとひとくくりにしても「複数人、複数ロール」を想定する必要があった。 運用テスト中、たとえばユーザーの一斉退職・異動・部署ごとなくなるなど、レアであってもシステムとしては考慮すべき点（不具合を起こしてはならない点）が存在していたが、設計には盛り込まれていないことが発覚した。 改修案として、様々な組織のスケールや使い方のケースを加味したユーザー体験をゼロベースで洗い出し、それらを差し込んだ修正を行った。

金融系スマートフォンアプリサービスとその開発チーム・業務チーム

チームメンバーが互いに連携し、助け合い、各々の責務に正しくコミットできる状態。 また、業務チームと開発が対等に話し合い、双方納得のできる形で、社会にとってより良いプロダクトをユーザーに提供すること。

【状況について】 下請け企業から引き取って内製化するプロジェクトだったので、誰かがしっかりと現状を把握する必要があった。下請け企業に完全にお任せしていたところが多く、先方のやりやすさや”好み”のような主観的な設計が混在しており、続行か作り直すかも含めての判断を求められた。 【行ったこと】 まずは課題をつまびらかにしていく所からコミュニケーションをスタートし、特に「現時点で決まっていないこと、何も手をつけていないこと」などの言いにくい部分を可視化する作業に注力。 やる・やらないの判断、トリアージの議論は目的の部分から意識的に行い、「なんとなく引き取って続きをやるだけ」にならないよう注意すると共に、新規参入メンバーが「なぜこれをやるのか」を理解できるような情報の整備とタスク管理のルール付を並行で行った。 【チームビルディングについて】 リモートワークということもあり、相互理解を深めるため「ジョハリの窓」を用いたキックオフなど、互いに相談しやすい雰囲気作りを初手で行った。 開発はアジャイルでタスク管理を行い、みんなが一人ひとりの短期目標を積み重ねてゴールに進んでいるという実感が持てるようにした。 【ピープルマネジメント】 関係性という面では、特に当方のようなマネジメントクラスと作業者とでは立ち位置の違いが大きく、遠慮されてしまうこともあるため、心理的安全性の担保に全力を尽くした。 語弊を恐れずに言うと「話のわかる上司」や「関わると気持ちが上向く相手」であることを日頃から意識し、何でも言いやすい人と認識してもらうよう努めている。 誰もが完璧ではない -> だから全員で助け合おう という意識に持っていくまでの1手法として、リーダーである自分が率先して、失敗や愚かさ・それを反省し改善するまでの姿を隠さないようにした。 実際に後輩に技術面で頼ることもあれば、議論を交わす中で間違いに気付くこともある。 結果、指示待ちの部下や同僚はいなくなり、スクラムの効果も発揮され、自立したメンバーの育成ができたと思う。

スマートフォンアプリ開発チーム(正社員4名, 業務委託1名)

組織文化としては、共助の意識が醸成されたチーム。 役割としては、複数案件への対応（設計、新規開発、保守運用、アドバイザー）が必須である中で、各メンバーがスマートフォンアプリ開発の知識を互いに活かし、スピードと品質のバランスを取りながら、ステークホルダーにも納得感のある成果を出すこと。

【状況について】 旧来のマルチプラットフォーム言語で書かれた既存システムの改修であったり、新規サービスの開発、全く新しい事業の企画〜開発など、非常に多くの案件に自チームのニーズがある中で、チームメンバーのスキルには偏りがあった。 特に、言語仕様を理解できていないマルチプラットフォーム言語は改修の難易度も高く、メンバーも「選り好み」をしてしまっており、タスクの対応時にモチベーションが低く、暗い雰囲気で「仕方なくやる」結果効率が悪く、発注側との関係性もどことなくギスギスしてしまっていた。 【行ったこと】 - 各自にヒアリングを行い、運用保守に対する心理的な拒否感があることにたどり着いた - そこから課題を掘り下げ、「製作者不明のプロダクトを保守しなければならないことへの不満」「設計書が存在せず解読が難しいソースコードの実態」「うまくできなかったらどうしようという不安」の3点に絞った - チャレンジングだが何とか任せたい、という組織側の期待を噛み砕いてコミュニケート - ステークホルダーに対し、失敗してもチームのせいではない、その時は別の方法を考えるという確約の取り付け - 会社と交渉し、外部の専任アドバイザーをエンジニアに横付けすることで、挑戦しやすい環境を整えた - その後、たまたまマルチプラットフォーム言語に精通した方が入社してくれたため、本人とも相談し、ソースコードの解析やそこから設計書を起こすといった作業を行った。 【チームビルディングについて】 リモートワークということもあり、互いに一人で籠もりやすい環境になりがちだが、話し好きで穏やかなメンバーが多いため、毎朝の朝礼から昼休みまでを「オープンワーク」時間とし、通話を繋ぎっぱなしにして、常に相談しやすい環境を設けた。 （ミュートOK、どうしても一人で集中したかったり1分1秒でも惜しい場合は朝礼後退出可能というルール） 困ったら誰かが（例え自分のスキル外のことだとしても）駆けつける、相互に助け合う習慣作りを行い、全員でスプリントゴールに向かうことを目的とした。 心理的安全性を仕組みとして担保することは難しいが、何を言っても受け止めてもらえる、何を言われても受け止める、という相互意識は会話の中で意識的に醸成し、前提となる知識のキャッチアップや意見交換もスムーズに行えた。 結果、互いへの信頼と協調性をもって、スピード感のある案件進行ができた。 【ピープルマネジメント】 オープンワーク時間での雑談を含め、定期的な1on1を組み合わせて、日々の状況や心理状態の変化に素早く気づき、フォローに回れるよう関係構築を行った。