TISが実践する、価値創造に向けたチームの作り方──ドキュメント化とリーダーシップの醸成で自走する組織へ

【Session6】サービス開発チームがビジネス価値作りに向かい自走するようになった経緯と取り組み

話すだけでは伝わらない？ ドキュメント化の文化で形成する組織の共通認識

　ここまでは、2023年2月のデブサミでも発表された内容だが、そこで取り上げられなかったこと、そして、それ以降に実施された取り組みについて紹介された。

　まず1つめに、髙谷氏は「言語化と情報のストック化の徹底」をあげた。以前は、コミュニケーションにおいて口頭でのコミュニケーションの比率が非常に高かったため、実際に各自の開発・実装作業をした後に認識が合っていないということがあった。特にビジネスの要求やシステム要件での認識がずれると、大きく手戻りすることになりダメージが大きい。

　また、コミュニケーションでのやりとりや結果をストックする文化が根付いていなかったため、後から参画したエンジニアへの情報提供や、新領域の開発に関する情報共有がうまくできていなかった。そこで、改善に向けてさまざまな本やドキュメントを読み返す中で、髙谷氏は「アジャイルソフトウェア開発宣言（Manifesto for Agile Software Development）」の中の「ドキュメントを作成しなくてもいいというのは誤解」という記述に気づき、言語化の徹底を決意したという。

「アジャイルソフトウェア開発宣言」に対する誤解と真意

　「話せば伝わるという幻想を捨て、言語化と情報のストックを徹底しよう。アジャイルであっても残すべきドキュメントは残そう。そういい続け、これをチームのコアな文化として掲げ、実践し続けてきた。その結果、明確に共通理解を築けるというメリットが確実に得られた」と髙谷氏は語る。

　もちろん文字で書かれている場合でも認識齟齬は発生するが、同じ文言を読み返し咀嚼することができるため、曖昧な表現に気づいて確認したり、認識齟齬を減らしたりする効果が高く、後から確認する時間は大きく削減された。また、コードレビューの際にも実装に至った背景情報がすぐに参照できるため、時短につながった。髙谷氏は、「文字をタイピングする時間はかかっても、間違いなくメリットが大きい」と語る。

　実際のドキュメント作成にはwikiを活用した。プロダクトバックログアイテムにまつわる情報やユーザーストーリー、受け入れ条件、さらに、ユーザーストーリーの上位になるエピックもしっかり文字情報で記述している。また、システム機能の概要についても、複雑な処理が行われる場合に処理概要を言語化したり、図に起こしたりして残すことを徹底している。

言語化と情報のストックで取り組んだこと

　髙谷氏は、「コードを読む認知負荷が高そうな場所は、とにかく言語で表現することを徹底した。言語で表現できないことは実装できないとして、まず言語で表現できる処理なのかを確認する意味合いもあった。最後に認証やトランザクションといった考慮が必要不可欠な処理についても一旦書き出しておき、チェックリスト的に活用していた」と説明した。

　また、必ずしも全てをドキュメント化するわけではなく、議論や意見交換などはむしろ口頭の方が早い場合も多い。そこで得られた結論やそこに至るまでの経緯などは記録が望ましい。そして、内容的にも、たとえばビジネスの目的や希望、夢などはテキストコミュニケーションよりも、顔を突き合わせて話すことが向いているといえるだろう。