開発現場のコミュニケーションを改善する、ちょっとした工夫
grasysの開発の流れは、プランとフィードバックを繰り返すいわゆるアジャイル開発だ。アジャイル開発においては、仕様書が薄い分だけ、開発フローを早く回せる一方、開発の幅が出て、携わるエンジニアによって品質に差が出ることもある。
「こういった課題を感じている企業は多いのではないか」と西野氏は指摘したうえで、自身が最も苦労してきた「コミュニケーション」と「開発」についての課題をひも解いていった。
まず、コミュニケーションの課題。ここで言うコミュニケーションとは「コミュ力」といったものではなく、開発にあたって発生する報告・連絡・相談を指す。
西野氏は、3つのポイントでコミュニケーションにおける自身の失敗と改善を説明した。
課題と進捗の管理
まず、マネジメント側が課題を管理する際のコミュニケーションで起こりがちなのが、催促を重ねてメンバーを焦らせてしまうことだ。
西野氏自身、現場の管理を任されて進捗が悪いと感じたとき、メンバーに聞いたり「あとで報告してね」と課題管理表にコメントしたり、それでも返事がない場合に全体チャットで催促したりと、せっかちな行動をとりがちだったというのだ。
「あとでメンバーに聞いてみたら、プレッシャーを感じて、ちょっとしんどかったといった声があったんです」
そこでいくつかの教訓を得た西野氏。まずは、事前に、進捗・報告のタイミングと粒度を決めておくというもの。進捗がいいときは報告して、進捗が悪いときは報告しないという人がいるので、ばらつきが出ないように、タイミングを決めて報告できるようにしておくのが良いと考えたという。
また、進捗を把握したいから報告してもらうのであって「良いか悪いかの判断はその次の話」ということも、きちんと伝えておくことが重要だと指摘する。
もうひとつ重要なこととして「各人がプロジェクトの目的にどのくらい共感を持っているか理解しておくこと」も挙げた。プロジェクトの目的に共感できている人は、最初はつまずいても結果を出すことに信念を持っているはずだからだ。
責任の考え方
2番目のポイントは、責任の所在。「僕も経験がありますが、何かをやらかしたとき、とりあえず嘘をつく、しれっとパッチを当てる、失敗した人を非難する……といった場合がありますよね」と西野氏。
人間は完ぺきではないので仕方ないこともあるが、自分の身を守るために行動してしまうと、周りに迷惑をかけてしまうこともあるだろう。ただ、そこで「失敗を個人の責任にしてしまうのは、プロジェクトのリスク管理不足」だと西野氏は指摘する。
そこで重要になるのが、失敗があるという前提で、その場合の手順を決め、チーム内で合意をとっておくなどの「心理的安全性」を確保することだという。
リーダーシップ
3番目のポイントは、リーダーシップの考え方だという。
マネジメントやプロジェクトリーダーの立場にいる人が、「オレにまかせろとリーダーシップを発揮して、『この技術を使えばうまくいく』『この作業よろしく！』と意気揚々とした雰囲気を作ることは、最初のうちは良いのですが、ちょっと状況がシビアになったときに努力だけで何とか解決するというのは難しい」と西野氏。
そこで大事なのが、プロジェクトを成功させるためのオーナーシップ持ったうえで、そのオーナーシップを部下に継承していく取り組みだ。
リーダーシップを持つ人は、プロジェクトの背景などを知っていて、いかに意義があるかを理解し高い熱量でプロジェクトに向き合える。一方、背景などを知らない他のメンバーは「なんか仕事が下りてきた」という感覚になってしまうことが少ないないという。
「メンバーにも情報を共有して、自分の仕事がプロジェクトにどのような影響を与えるのかを理解する機会を設けることが必要。そうすることで、どの機能をどこまでやりこむのかといった『力の入れ加減』もつかめるようになるので重要です」
開発現場の改善がうまくいかないときにどうするか
2つ目の課題は、開発現場でのプロセス改善の取り組みについて。モダンでトレンドの技術を採用して、よりよい現場にしていこうと取り組んでも、なかなかうまくいかない。そういったときにどうアプローチすれば良いか、自身の経験から学んだ教訓について3つのポイントに分けて説明した。
スコープクリープ
「まず起きがちな問題は、『スコープクリープ』です。要件がふくらんでしまって、仕様を追加することを指しています」
こういった状態に陥るときの特徴として挙げたのは、ユーザーが何を求めているのかといったプロジェクトの目的を見失っていること。そして、過度の楽観性によって周囲の開発作業が目に入らなくなっていたり、機能の洗い出しに漏れがあったりというケースを挙げた。
「そこで得た教訓は、プロジェクトの目的のために行動するということです。何のためにやるのか目的を理解すれば、おのずと不要なことはやらなくなります。そして、設計からずれていないか実装を日々確認していきます」
また、要件があまり固まっていない状況で実装を進めるのは、ほどほどにすることも重要だ。
西野氏は「アジャイル開発のおかげで、設計書が不要になって実装は楽になりましたが、それに甘えすぎると、ユーザーが求めていないものを提供してしまって悲しいことになる場合も少なくありません」と誤ったアジャイルに進まないよう警鐘を鳴らした。
都合の良いソースコード
続いて2番目のポイントは、「都合の良いソースコード」。
「これも僕の経験ですが、ソースコードが読みづらいから『リーダブルコード』を読んで実践しなさいと言われたんですね。でも、実際にやってみても、まだ読みづらいと言われたんです」
この経験を踏まえて西野氏は、「リーダブルコードの前にやるべきことがあるのでは」と言う。コードがなんとなく動けばいいと思っているだけで、目的がないと元も子もない。
「まずは、きちんと目的と情報を整理すること。そうすると、実装するソースコード上からも無駄なことが省かれて、読みやすくなるんじゃないか」と西野氏。
また、情報を整理するのが難しい場合も、テストコードとテスト結果を共有しておく。実装した人が、用途のわかるテストコードを書いておけば、どのように使われて、どのような結果が出てくるかエビデンスが残るため、他の人がそのファンクションを使う際にも誤解が少なくなるという。
それから「曖昧な確信はバグの温床になりがち」と自身の経験から指摘。「僕の経験では、ちょっと心配だなと思ったとき、8～9割はバグになっていた」という。「まあいけるだろう」といった曖昧な確信は避けるように提言した。
「良いものを生み出す」には今の問題を明確に
3番目のポイントは、「良いもの作りたいという気持ちが、良いものを生み出すとは限らない」ということ。
「僕自身、良いもの作りたいという気持ちがあります。そのために、学習した内容と照らし合わせて実装し、バグを作らないよう慎重に作業を進めていくと、高い期待感が得られます。このような状況はとても楽しいものですが、結果を残せるとは限りません」
また、新しい技術を採用しても、実装スピードは以前と変わらないことが多いという。当たり前だが、従来の技術に対する熟練度と比べると、新しい技術に対する熟練度の方が低いため、新しい技術ならではのうまみを享受するには一定時間がかかるからだ。
もちろん、新しい技術に投資し続けることで、最終的にはコストやスピードも改善されていくが「今の問題を正確にしたうえで適用してほしい」と西野氏。今の技術がレガシーだからといって切り捨てては、今までのリソースを生かせず開発の幅が狭まってしまうかもしれない。
「単に技術を入れ替えただけでは、新しい文法・技法だけが良さとなって残り、開発工数やスピードといったビジネスに与える貢献が薄くなってしまう可能性がある。レガシーな状態と新しい技術でできることのジレンマをどう乗り越えていくか。こういったノウハウを身につけていくことが重要だと思う」
最後に西野氏は、開発現場の改善に欠かせないのは、物腰を柔軟にすることだと述べた。シチュエーションに応じて、素早く機敏に柔軟に動いていく必要があるというのだ。
そして、お客さまに価値を届けるエンジニアとして、重要なポイントを以下のように語り、セッションを締めくくった。
「まずは、オーナーシップです。先にお客さまの目的とやりたいことがあり、その目的を達成するために技術がある。また、自制心と規律から生み出される誠実さも重要です。自分のことばかりだと、プロジェクトメンバーなど周りに悪影響を及ぼしてしまうからです。それから、エンジニアとして良い考えを生み出すためには休養も必要。よりよいものを作るためにも、何より大切なのは自身の健康だと思います」
Google Cloud INSIDE Games & Apps 登壇情報
4月13日に開催されるオンラインイベント「Google Cloud INSIDE Games & Apps」に、grasysのエンジニアが登壇します。
