開発の品質を最後に決めるのは有機的な取り組みと言う終着点

皆さん、こんにちは。ハンマーFMのハマケンです。
第2回目ではありますが、今回からこのブログ名にHammer-FMの名前を冠していこうかなと思います。

元々は社内Slack内でラジオのチャンネルを運営していて、そのチャンネル名ではあるのですが、そこから派生してYoutubeチャンネルでも使ったりしたりと、個人的にスゴク気に入っている冠名なので、noteでも引き続き使用していきます。

それでは、今回は「開発の品質を最終的に決めるのは有機的な取り組み」と言う話をしていきます。

物事をいつもややこしくしているのは、いつも情報が共有されていなかったり、情報の理解度の違い、目的、背景の認識違いなど様々な言葉でつづられたりしますが、恐らくかなりの確率でその要因を因数分解していくと、結局コミュニケーションの壁が原因と言う事になるのではないかと思います。

とかく開発やマネージメントなどのチームスキルが問われる種類について解決の糸口を説明する世のコンテンツは、そう言ったコミュニケーションのすれ違いを無くす為に「仕組み」を説明し、裏付けるエビデンスを並べ、あたかも「これは画期的な仕組みである」と伝えがちだなと思います。

これに対し残念な事に、コミュニケーションに悩んでいる人（悩んでいることに気づいていない人も）達は、きっとそれが成功への糸口だと信じ、早速実践に移行するが、上手く行かない。上手く行かないどころか、悪化さえあり得ます。

何故そうなるのかと言うと、コミュニケーションをそもそも理解していない事に尽きるのかなと思います。

このnoteでは、「コミュニケーションとは、こう言う定義でこうあるべきだ」と言った、鳥肌が立つ様などうでも良い話はしたくもないのですが、開発をより成功に導く為にまず1つ必要なのは、このコミュニケーションに長けている人間であることが条件なので、少し述べておこうかなと。

• 「誰とでも話せる、しゃべるのが好き、根明、友人が多い」これはコミュニケーション能力が長けているとは別問題であり、条件では全くない。

• コミュニケーションの本質は言葉だけでなく、目線、しぐさ、声の変化を機微にキャッチし、「相手が話しやすい環境を作る事」であり、自分が多くを語る必要は多くはない。

• コミュニケーションに長けていると言うのは、「状況や内容を相手に伝わる言葉に翻訳する事ができる」事であり、端的に述べるとは、また別である。

• コミュニケーションに長けている人は「無機質な仕組み」での対応を考えはするが、優先度は低めにしている。

あなたが話しやすい、相談しやすい人はベラベラと話す人でしょうか？
少なからず、あなたの話を聞いてくれるし、こちらに気づきすら与えてくれる様な話をしてくれたりしませんか?
前述の通り、コミュニケーションに長けた人は相手が話しやすい環境を作れるプロであり、また相互に意思疎通ができる状態に仕上げてくれる人であると思います。

また、実はコミュニケーションと言うのはプライベートなモノから、プロジェクトの要求や要件に至るまで実は全て同じレイヤーで存在をしていて、どちらが高度な技術と言う事も無く、全く本質は同じであると言う事です。

つまり非常に有機的なモノを取り扱っていると言う認識を持たなくてはならないです。プライベートの悩みなどは人に伝えにくいですよね。それは非常に生々しいモノでもあるからですよね。

※ここで言う有機的と言うのは、「血が通っている、感情が入っている」と解釈してください。

良くある風景の事例

開発で良くある話を一つ。
実装開始後に追加になる要件が発生したとする。
追加された要件は、例えば機能レベルではなく、LPなどのページに記載する文言の修正だったとしましょう。

例えばスクラムであったとしたら、日々追加の要件は吸収ができ、修正が可能だ。これはスクラムと言う「仕組み」で解決がされています。

さて、このありがちな光景において、スクラムの特徴によってカバーができているから良いよね、やそれだけの修正は全然OKと言ってしまう事は非常に簡単だなと思います。

確かにその通りではあるし、チームとしてはそれを許容していく環境は必要だし、修正は歓迎をすべきではあると言う事は事実です。

だが、それをそこまで作ってくれたデザイナーは人であるし、その気持ちを置き去りにしていないか？と思ったりしています。

現場側の修正依頼者は、修正を依頼しなくてはならないので、言う事は正義であるし、またデザイナーも修正をしなくてはならない。それもまた事実ではあります。

ですが意外にこう言った小さすぎる出来事は案外よく起こり、時には大きな問題となって噴出する事があります。

プロダクトオーナーはそう言った小さな出来事であったとしても、依頼者をつるし上げる事も無く、進め方をレクチャーしたり、デザイナーに敬意を示していく事も必要で、非常に有機的な動きが必要なのです。

当然こう言ったズレを無くしていく為に、プロダクトつくりでは仕組みを用意していく事も必要。例えば実装前に要件確認MTGを入れるなど。
個人的にはそれはそれで良いと思います。

ですが、何度も言いますがコミュニケーションは非常に生々しいものであり、仕組みを用意したとしても、それでは解決できない事は多々あります。

例えばこの様な小さな棘が連続した時に、デザイナーが「この担当者とは話しても無駄である」と思ってしまっていたら？「とりあえず言われたものを作っておけば良い」と思ってしまったら？逆にそれでもより良いモノを目指すが、再び反故にされたら?

そう言った素直ではない感情で作られたモノに本当の価値は宿るのだろうかといつも思ってしまいます？良いモノと言えるのでしょうか？

作るのは感情がある人。
人によっては、その仕組みによって助かる人も多く居ると思います。
ですが、その仕組みに色々悩み、相談すらできない人も居るとも思います。

私はプロダクトオーナーとして、せめて関わっている現場側、デザイン側、技術側の人間が最高のパフォーマンスを発揮できる場所を用意しているつもりです。
これを証明できる話はいくつかありますが、それはまた、あまり話すべき内容ではありませんが、このnoteを書き続けていく中でどこかで書ければと思います。

前述した様な非常に小さな棘の累積した堆積物こそ、プロダクトの全容であり、何かしらのサービスになっていきます。

良いサービスを作る為に必要なのは、流行っている技術でも開発手法でもありません。人が作る以上、有機的な流れを有機的な動きを持ってコミュニケーションを全力で再構築していくそう言ったモノが必ず必要であり、それが理解できないと永遠に「何か違う感」から抜け出すことはできません。

まとめ

さて、いかがだったでしょうか？
今回は自分の周りで起きている、個人的には大きな勘違いとも言える問題を少し切り取ってみました。

個人的に意味がない仕組みを押し付け、そこに露出しなかった問題は問題を提起しない人が悪い、私たちは十分な仕組みを提供していると発言している様なパフォーマンス施策が大嫌いです。時間もコストも無駄だからです。

Hammer-FMはハマケンがプロダクトオーナーをしていて気づいた、全員が同じゴールに向けて全力で走れる方法を今までの経験談も含め、綴っていきます。
更新は不定期ですが、是非フォロー、コメントなどお待ちしております。

それでは！