「あるもので工夫しろ！」とは、手持ちの武器の使い方を変えるということなんだよ

on

プロジェクトでは、何をするにもバジェットが必要で、そのバジェットで様々なリソースを調達してチームを編成し、資材を揃えて加工し、顧客にdeliverableを届けるんですよね。


プロジェクトをはじめると様々な課題や課題を放置していたら問題にクラスチェンジしてたりしてて(汗;;;;)、なんてことを経験しているエンジニアも少なくないだろうと想像しますが、少なくとも課題を読み違えて問題にクラスチェンジさせてしまったことは、勿論、あるに決まっているじゃないですか(開き直り)。


よくあるチームの中での不満
どんなチームでも、たとえ順調にプロジェクトが進捗していても、多かれ少なかれ人が集まる以上、人に伝える、人から聞き出すことが人それぞれでプロトコルが違うのでギャップが生じ、結果、意思疎通が自分が思っているように取れない、と言うことになるんです。


そうしたギャップによる意思疎通の較差を感じ、それをチームの中で言ってくれればまだいい方で、そうした意思疎通のギャップが実は重大な日常の運営の壁になっていることが明るみに出るのはプロジェクトの規模でトラブルと言う事象になってから、と言うことが多いものです。そして、トラブルになっているのでその根っこの原因の意思疎通はおざなりで減少として表面にあらわれている方に宙諒くしてしまう、と。


まだ、不満がトラブルの煙くらいなうちに出てくれば勿怪の幸いのようなもので、早期に出てきたらそれを解消できるような取り組みをすればいいのだけれど、「じゃあどうやって意思疎通したい？」なんて聞いても「コレで！」なんて言わないし、言ったとしても意思疎通を取りたいという総論賛成、でも「オレそのツール使ったことないからヤダ。」とか「ソレならコッチがいい。」と各論反対と言う宗教戦争が勃発したりしちゃう。ヤレヤレ。


とは言え、意思疎通のギャップの放置は将来の事故の元だから、放っておくこともできない。さて、どうするか。


無いものでは解決しない
ここでよくある間違いが、ない予算を回してツールを新たに導入しても、結果、使われずに意思疎通のギャップは解消されず終いにはトラブルを起こしてしまうbad ルートに突入するパターンかと。


もともと、意思疎通と言う曖昧なふるまいに対する対処なのなら、今あるもので実は運用で対処できることが少なくないものです。


ただ、エンジニアの集まりのプロジェクトでなぜチームのメンバがそれに気づかないかを疑問に思うかもしれないけれど、それは単純なことで、そうした訓練をしていないから。


先の、総論賛成、各論反対じゃないけれど、今あるもので工夫できないなら、新しいものを持ってきても使わないし、使えない。だってね、今あるものをどう使ったらいいだろと考え抜くことさえしていないなら、新しいもの新しいツールを選ぶための解決したい課題を正しく理解できないままでツールを選定することになるから別の選ぶ人の感情だけで選ぶことになるわけで。そんな選定で選んだものを課題を解消するように使いきれるわけがないもの。


それは、技術を覚え、習熟度を向上していくエンジニアリングの領域ではなくて、課題で解決していく原因の裏に隠れている真因の追及とそれを解消するためのしくみが何を適用すればいいのか、ということを発想できるアーティスティックな感性を正に磨く訓練をしているかどうかに依存していると思うのです。


あるもので解決するとはソリューションの考え方と同じなのである
解決したい課題、ここでは「意思疎通のギャップを解消したい」とするならば、それを解消するなら今手持ちのあるもので解消することを考えなければならないわけで。それはこんな風に例えるとわかる人もいるかもしれない。


「今あるものは器で、そこに解決したい課題を盛るんだけれど、どの器を選ぶのか、課題をどう味付けして、不満を言うエンジニアに美味しく食べてもらうかは、料理人次第。」


「分散拠点で同時並行の作業をするときの双方で何をやっているか知りたいけれどメールじゃ後で共有の情報として残しておけないし。」でも、「メッセンジャーツールがあるわけでもないし。」という意思疎通の課題がある場合、何が手元にあるツールで、

  • リアルタイムで書き込める。
  • 書いたものをメンバなら見られる。


であるもので考える……

  • メールはプロジェクト情報として後で閲覧しにくい。
  • ファイル共有は手間が煩雑。

　：


もう一つ、あるでしょ、と。チケットが。チケットなら、

    • ブラウザで同時に閲覧できる。
    • F5でほぼリアルタイムで「知る」ことができる。
    • (設定に依るけど)他からの書き込みを気にしなくていい。


ね。チケットを、チケットシステムをバグ管理ばかりで使う必要はないわけで。TiDDばかりで使う必要はないわけで。ある意味、作業の進行状況の共有はTiDDでチケットを切る対象のタスクの一環と言えば一環だけれどね。


手持ちのツールを改めて眺めてみよう。
私たちのチームの課題になっている真因はなんだろうか。
運用で今ある手持ちのツールを使って見たらどうなるんだろう。
実際、自分だけでもそれをやってみたらどう感じるだろう。


無いものでは何も作れないんだよ。余所から持ってきても解決しない。なら、あるもので解決できるかを考え試してみよう。