imarizazen0i9a7332_tp_v-2

システム開発会社は、重要な意思決定を行うとき社内会議を行います(個人でビジネスをやっている場合を除きます)。出席者全員が顔を合わせて行う会議は、お互いの意思を確認し建設的な意見を交換する場として意味があります。

しかしシステム開発会社によっては、ずいぶんと長い社内会議を続けるところもあります。例えば、稼働中のソフトウェアの動作を確認するためにシステム開発会社の開発担当者に電話をしてもいつも社内会議中でつながらないのです。

開発担当者の手が空いていなければ、所属する組織の上司や他のわかる人が対応してくれても良いのにと思います。しかしながら、そのように取り次いではくれません。実際のところ、会議ばかりやっているシステム開発会社はなぜそのような長時間に渡って会議をやらなければならないのでしょうか。

ここでは、「社内会議ばかりやっているシステム会社は頼りにならない」ということについてお話ししていきます。ここで述べる内容を理解しておくことで、お客さまを大切にするシステム会社の見極めに役立てることができます。

会議を何時間やってもシステム開発は進まない

システム開発会社の本業は、良いシステムをどんどん設計開発してお客さまのところに納め最終的に対価を得ることです。しかし、社員全員がお客さまのところに出払っているようですと社員の統率が取れません。やがて、各自が勝手なことを始めるようになるでしょう。したがって、社員が定期的に集まり会議で意思の疎通を行うことが必要です。

会議の本来の目的は、複数の立場の人が一同に会して情報を共有することです。また、重要な意思決定をするのに一部の人が偏った判断をしないように意見をとりまとめることも会議の目的に含まれます。そこは、システム開発会社であっても同じです。

ところがシステム開発が他業種と異なるのは、現場がたいへん忙しくてエンジニアが昼夜問わず働いていたりトラブル対応で突発的に多くの仕事が発生したりすることです。そのような現場の状況は、上司含め他の人がまず追従できるものではありません。

そのため、会社の中で会議をやっている人たちは必然的に全く現場を知らないか、または遠い昔に現場を引退してしまった人ばかりになってしまいます。つまり、実際にプロジェクトが火を吹いていたり、トラブルを起こして大変な状況になっている現場を知らない人が集まって会議をしているのです。

そのような人たちが集まる会議は、現場の臨場感がありません。そして会議は、形式的かつ無意味なものになりがちです。会議の本来の目的を離れ、単に「会議を行う目的で行う会議」になってしまうのです。

システム開発は、そのような会議を何時間やっても決して進みません。システム開発が遅れ、かつトラブルが増える中それの対策にまた無意味な会議を繰り返すことになります。「長い会議は、悪循環する」のです。これが、典型的なシステム開発会社によくありがちな実情です。

単にソフトの障害対応版をリリースするのに、多くの会議を行う意味があるか

例えば、ソフト開発部署がすでにリリースしたパッケージソフトウェアの障害修正版をリリースするとしましょう。修正箇所は限定的で、ソフトの他の機能に影響することはありません。そのソフトウェアは、複数の現場にリリースされているパッケージソフトです。現場からは、障害を直したいのですぐにリリースしてほしいと迫られています。

そのような障害修正は、開発担当者が早急に対応して即リリースした方が良いに決まっています。しかし、会社によっては、ソフトのリリース前に多くの人を集めて会議を行わなければならないというルールがあります。

この例の場合ソフトの障害修正であり修正による影響範囲が限定されていて、現場から迅速な対応が求められている状況です。そのような中、リリース前の会議を行うのはとても時間と労力がかかります。

出席者が、開発者と受け入れ先のプロジェクト担当者ぐらいであれば会議を行う意味があります。しかしそうではなくて、出席者が「開発部長」「品質保証部長」「生産管理部長」「エンジニアリング部長」「システムサービス部長」「現場担当者の上司」…などになったら悲惨です。

たかが障害修正版ソフトのリリースを行うのに、現場から遠く離れた会社の上役が大人数集まって会議をやることになるのです。それどころか、会議は一つとは限りません。

リリース前会議の他、「パッケージソフトリリースのプロジェクト計画審査」、「ソフト設計審査」、「結合テスト審査」、「内部検証審査」、、、などいくつもの会議を義務付けている会社もあります。そのような会社は、きっと「多くの会議を開くことが、ソフトウェアの品質を維持するために必要だ」と信じ切っているのでしょう

しかし結局のところ、このような多くの会議は形骸化して無意味です。会議の出席者が、現場に通じていて修正版ソフトのリリースにあたってのリスク、開発プロセスの正当性・妥当性、品質管理ができる人ならば良いのです。しかし先ほど述べたように、会議に出る人は実際に現場を知りません。会議で審査ができる人たちではないのです。

そのため、開発者が会議で重要なパッケージソフトの情報を共有しても会議の中で共有されるだけで終わってしまいます。それでも出席者は、会議の場で何か発言しなければとどうでも良い話やツッコミを入れて存在感を出そうとします。そして会議はどんどん長引きます。

したがって、このような中で行われる会議に意味はないと考えられるのです。

会議をする目的は一人で責任をかぶりたくないだけ

参加者にとって、会議のメリットは本来の目的と違うところにあります。それは、会議で意思決定を行っておけば後で何か問題が起きたときでも他の参加者との共同責任にできることです。権限や責任が分散されて、問題の所在がうやむやになるのです。

一方、意思決定を一人で行った場合にそれが失敗したら大変です。要は、一人で責任をかぶりたくないのです。システム開発は現場の働きで大方の開発能力が決まります。会社で会議ばかりやっている人は、たいてい実際の開発作業に携わらず中身も把握していないのです。

そのような出席者が集まってソフトのリリース会議やら、設計審査やらをやったとしても「意味のある審査」になりません。会議に集まった人が仕事をした気になるだけです。会議に参加することで、自己満足感を満たしているだけだと言えるでしょう。

現場の仕事をしない人は、会議で有意義な発言ができない

忙しい現場の状況を知らない人たちが集まる会議は、有意義な発言が出ません。例えば、ソフトリリース前の会議であれば「そのソフトをリリースすることで、現場にどのような影響が想定されるか」などリスクを察知してその対策が打たれているかを確認する「リスクマネジメントの観点が必要です。

今のソフトをリリースしたとして、「どのようなトラブルが想定されるか」「そのリスクは回避可能なのか」「リスクを回避できるならば何をしたら良いか」など会議でさまざまな思考を巡らすことができる人が必要なのです。しかし、そのようなことができる人はたいてい現場から引っ張りだこになります。そのため、社内会議には出られません。

代わりに参加するのはやはり上司などになりますが、その人たちでは現場で発生するリスクがわからず会議で議論する材料を持ちあわせていません。これらの事情から、多くの会議が無意味になるのです。

このように、会議ばかりやっているシステム会社はお客の頼りにならないと考えられます。システム開発会社は、お客さまに良いシステムを提供しシステム構築後も改善をしていくために、社内の内向きの会議ではなく現場のシステムに力を注いでいかなければなりません。

会議ばかりやっているシステム会社は、社内に多くの問題を抱えていてお客さまへのサービス改善に手が回っていない会社ではないかと疑うくらいでちょうど良いでしょう。