「技術経営」でより強い組織とビジネスへ!~技術の管理方法を試行錯誤中~



こんにちは、風間です。

知財経営(「知財経営」でより強い組織とビジネスへ!)を意識するようになり、最近は技術管理のやり方を試行錯誤しており、技術者と管理者の最適なコミュニケーション方法を模索しています。

試行錯誤の日記ですので、具体的な答えはありませんが、同様の悩みを抱えていたり、何らかのやり方で本問題を克服された方がいましたら、是非話をさせてください。

顧客の要望Xを満たすためにAに着手する場合

たとえば、Xをしたいという顧客の要望のもとに、Aという機能を技術者が作ることになったとします。このときに、技術者と管理者はどうすれば良いかを考えていきます。

Aを作る中で、Xを満たすには、Aの機能を作るだけでは不親切なので、Bという説明資料も同時に作らないといけないということが見えてきたとします。しかし、技術者はAを作るだけでも相当にハードであり、Bにまで手が回らなかったとします。あるいは、Bを作る必要性に気がつかなったとします。

管理者は、Xが実現できるものを作って欲しいというお願いをしている訳で、そういった状況であれば、AとBの製作が当然必要だと判断します。むしろ、Aだけを作っても、操作ミスを誘発するので、Aだけをリリースすることは「悪」となる可能性もあり、「結局何もしない方が良かった」という状況になり、Aの開発費用と時間が無駄になることもあります。加えて、Aの機能がお金に関わるものの場合、Bの説明資料がないことで、お金に関わるミスリードをAの機能で誘発してしまったら、それは大問題になり、経営上の重大なリスクとなります。

一方、上記は「Xを満たすために、AとBが必要」という分かりやすい例ですが、実際には納期に追われると「Aで本当にXを満たせるのか?」という基本に立ち返る瞬間もあまりなく、「Aに加えてBが必要である」という議論もされないことも良くあります。特に、技術的な話が深くなればなるほど、非技術者が現状を把握することは困難になります。こうなってしまうと、管理者はBを作る必要性を知らないまま、かつ、本当にXを満たすかどうかも分からない状態のAが作られたかどうかだけで判断をすることになってしまいます。これは非常に怖いことです。

Bを管理するのは誰か?

これらは、かなり話を単純化したものです。もちろん、ものを作る前にしっかりと要件定義をしたり、管理者が進捗を細かく確認することは大切ですが、ことが動き出すと、なかなかその通りにいきません。また、技術が深くなればなるほど、技術的な工程管理をするのも難しくなります。

本件を技術者の目線に立つと、「XはAで満たされる」というところまでを詰めて技術者に依頼をしてくれないと、AもBもという五月雨式の要望を満たすことは困難であると、主張するかも知れません。また、A自体の実装がハードな場合はBにまで目がいかない、あるいは、Bが必要となりそうであれば、AとBを作成するようなオーダーを最初からするのが管理者の仕事だと主張するかも知れません。

一方、非技術者である管理者からすると、技術者はAの製作を任されているのだから「AでXが満たせるかどうか」は常に自問し続けるべきであり、自問し続けていれば、製作過程の中でBの必要性に自ずと気がつくはずであり、そこは早急に共有すべきであると考えます。

どちらの主張も、正しくもあり、改善の余地があると言えますが、1つ言えることは、Bの製作がまさに担当者があいまいなポテンヒット状態になっているということです。

技術の話が深くなったり、技術者と非技術者とのコミュニケーションにおいては、担当者が曖昧なポテンヒットが生まれやすくなるだけでなく、技術というベールがかかり、ポテンヒットの位置にボールが置かれているかすらも分からない状況が起こりえるのだと痛感しました。

では、どうするか?

結論から言うと、管理者も技術者もBのような存在が発生しても、掌握できる仕組みとマインドを持つということです。技術経営をうたうのであれば、管理者は「非技術者だから」という逃げ道を捨てて、当然Bを把握するべきです。一方、技術者もビジネス寄りの話になったとしてもお客様に評価されての技術のため、Bに対処するマインドをもつべきです。

「Xを満たすためにはAが必要か?」→「Xを満たすためにはAだけでなく他に何か必要なものはあるか?」→「Xを満たすためには、AとBで本当に大丈夫か?」という議論ができる流れを作らないといけません。加えて、「Xを満たすためには、実はCを作れば解決できるのではないか?」というさらに前のめりに、解決策を模索する仕組みがあればさらに良いです。

では、その流れをどう実現するかの大枠を考えてみました。まずは、下記2つを実行するための具体的なTODOを社内展開し始めましたので、どのように変わっていくかが楽しみです。

①管理者に、技術の知識を習得させ、「技術者-管理者」間での技術的な知識のギャップを小さくし、管理者が技術現場の作業の様子を正しく判断できるようにする

②技術者に「AでXが満たせるかどうか」というように、製作物と要望との関係性を常に意識をして頂き、「AだけでXは満たせない、あるいは、Aではない方法でXは満たせそうだ」ということを感じたら早急に管理者に報告をするようにする

技術は深くなればなるほど武器になりますが、管理が大変になってくることを肌で感じています。しかし、ここを乗り越えるかどうかで、技術を強みにした企業経営に近づくので、1歩1歩仕組みを作るしかありません。

非常にやりがいのある仕事です。