はじめに
こんにちは。元ガチプログラマーのプレイングマネージャです。
できれば、プログラムをカタカタ打ってPC画面に向かって「いい感じのコードを書いちゃったなぁー」と独り言だけを言っていたい人間だったのですが、それだと仕事にならないなあと。
ということで最小限のコミュニケーションで仕事をする方法について考えたことをまとめておきたいと思います。
最小コミュニケーション術
『プロジェクトのゴールに対する』自分や相手の課題を解決できるようにコミュニケーションをとることが、コミュニケーションを最小にする方法と考えます。
相手の課題を解決するために自分となんらかの調整が必要なケースでは、相手の課題が解決するまではコミュニケーションが継続されますし、自分の課題についてもまたしかりです。
相手の質問の裏には、相手のプロジェクト上の課題が必ず存在します。相手の質問にそのまま答えても相手の課題が解決しなければ、さらなる質問をされ、最悪不毛なやり取りに発展することもありますよね？
『プロジェクトのゴールに対する』自分や相手の課題 を把握して、それを解決するためにどういった確認や相談や提案を行えばいいかを考えて実行することで、コミュニケーションの量を最小にすることができるかと思います。
以下に少々長い考察を続けます。
エンジニアの仕事
給料が比較的よさそうに見えるからとなんとなくIT業界に就職した方が最初に知っておいた方がいいことは、「プログラムを書く仕事」 ではなくて 「まだ世の中にないモノを形にする仕事」 だから給料が比較的よい、ということかと思います。
『こんなモノを作ったら世の中がよくなるとか便利になるとか儲かるとかを考えているお金を持っている人や企業』 が世の中には存在していて、そんな方々から依頼を頂いてモノを作ることで対価をいただく仕事です。
売れるモノを作れれば、たくさんお金が儲かるから給料もたくさんもらえるという話ですね。1
※SESの場合は時給で労働力を提供しているだけなのでどんなに売れても直接給料には反映されなそうです。
ゴールとコミュニケーション
「まだ世の中にないモノ」 というのは存在していないモノなので、発注側が作って欲しい内容を具体的に指示することはとても難しいです。
一般的に発注側は業務知識を持っており、受注側は開発知識を持っていると思いますが、それぞれ自分が「普通」と思っていることは伝えないことが多いです。単純に量が膨大であることと、無意識で実行している事をわざわざ言語化して伝えるのがとても難しいことが理由として考えられます。
そのような理由もあってか、知識の範囲が違う人からの指示や依頼には理解できない点が含まれることも多いです。全員が同じ知識を持っていたり、一人で要件定義から開発までできたりすればよいのかもしれませんが、そういうケースはあまり見かけません。多くのケースでは知識の範囲が違う人達が「こんなモノを作ってほしい」「そんなモノを作ればよいのですね」と 相互理解を深めて合意をした内容をバケツリレーして ようやくモノが完成します。
学生のアルバイトであれば、意味が分からない時には相手の指示が悪いと突っ返せるかもしれませんが、エンジニアの仕事は 「まだ世の中にないモノを形にすることがゴール」 なので突っ返したり、思い込みで作っていてはゴールに近づかず仕事になりません。ゴールに近づくために 確認や相談といったコミュニケーション を取る必要があります。
いちいち確認や相談をするのは面倒と感じるかもしれませんが、プロジェクトのゴールから見るといちいち確認するのが一番面倒くさくないです。2
確認を行わなかったり、思い込みで作った結果、依頼側の期待と異なるモノが出来ていた時の手戻りが最高に面倒くさいです。
確認や相談をしないと何が起きるの？
意図せずに時限爆弾を仕掛けることになる可能性があります。
その場ではなく、プロジェクト後半で爆発したりします。
もっとひどいケースでは、リリース後に爆発したりします。
発覚が遅れれば遅れる程爆発による被害は大きくなります。
また、事態を収拾するチームを編成するのも難しくなります。
確認や相談をすれば予定通り進むの？
システム開発について、以下の様な調査結果が出ています。
- 工期が予定通り完了する割合は 14% ~ 34%
- 予算が予定通り完了する割合は 17% ~ 37%
規模が大きいプロジェクト程予定通り進まないようです。
出典 : 企業IT動向調査報告書 2022(図表 7-3-5 業種（製造業／非製造業）×売上高別 システム開発の工期遵守状況)
出典 : 企業IT動向調査報告書 2022(図表 7-3-6 業種（製造業／非製造業）×売上高別 システム開発の予算遵守状況)
今年は、こんなことをやって、このくらいの費用を投じて、このくらいのお金を儲けよう（またはこのくらいのコストを削減しよう）という計画が最初にあるため、プロジェクトに対するおよそのテーマ、リリース時期および予算がまず決定されると思います。
ただ、テーマが決定されただけの 「まだ世の中にないモノ」 を作るプロジェクトの計画を立てるのは、エスパーか預言者ではない限りは難しいかと思います。3類似のテーマのプロジェクト経験があれば可能かもしれませんが、それは「既に世の中にあるモノ」であるため大きくお金が儲かることはないかもしれません。4
ここで 「予定通り」 という言葉に着目してみましょう。
「工期」と「予算」については予定通り完了したかは定量的に評価ができますが、「まだ世の中にないモノ」に対して、「思った通りできたのか？」を定量的に評価することはできません。 近い指標として「品質」がありますがちょっと違いますし、「売上」には広告宣伝やマーケティングなど営業的な要因も入ってきてしまうため評価には使えなそうです。
とした場合、 プロジェクトのゴールから外れない範囲で 「工期」と「予算」を守れるように確認や相談を行うことで 「予定通り」 進められる可能性を上げられないでしょうか？唯一の変数である 「まだ世の中にないモノ」 をどのような形にするかを走りながら決めるアジャイルという考え方もありますよね？
最小コミュニケーション術：確認や相談のしかた
大前提として、プロジェクトのゴールを関係者全員が理解していること、それに向かって仕事を行うことが必要です。
その上で、関係者に対して等しく敬意を持って接することが大事です。
- 開発者が案件ごとにすべての業務知識を持つことは難しい
- 発注側がすべての開発知識を持つことも難しい
- 業務知識を持っていることも開発知識を持っていることも等しく価値がある
それぞれの人の立場を理解して、確認や相談を行う時に以下のようなことを考えるとよさそうです。
- この確認や相談を行うと、相手からどのような回答が得られるのか？それによって自分や相手がゴールに近づくのか？
- 相手の質問に回答すると、相手はゴールに近づくのか？近づかない場合はどのような回答をすればいいのか？
最小コミュニケーション術：文書化
人は忘れる生き物です。
相互理解を深めて合意をした内容をバケツリレー した結果を記録として残す文書が必要です。
また、プロジェクトメンバーが増えれば増える程、同じ話を伝えなければいけない相手が増えるのに対して毎回同じ話をするのも効率が悪いので、 『分かりやすい文章を一度書く』 というのはコミュニケーションの量を減らすためにはかなり効率的な手段と言えます。たとえ一度しか使わなかったとしても。
おわりに
プロジェクトのコミュニケーションは『プロジェクトのゴールに向けてどのように振る舞うか』という点に集約されると思います。
この考え方はエンジニアとして仕事をしている間はずっと使えるかと思います。
いわゆるコミュニケーションと考えられている会話の仕方については、相手によって全く異なったり、相手がいないと練習できなかったりと別の巨大な課題に突き当たりますが、これはいろいろな人と接して経験値を積んで少しずつ改善していくしかないのかなぁと思っています。
お客様と話す機会や後輩の面倒を見る機会など、人と接する機会が与えられそうであれば積極的に取りに行くのがよいと思います。
おまけ０
おまけ１（新卒エンジニア向け手紙）
おまけ２（新卒エンジニア向け記事）
おまけ３（パイセン向け記事）
おまけ４（...は難しいシリーズ）
おまけ５（営業A短編シリーズ）
おまけ６（エンジニアのためのお仕事問題集）
2030年にIT人材が最大79万人不足するとのことで、学習用の資料をgitで無料公開してます(不定期更新)。
よろしければどうぞ。