本記事の背景
IT企業にとってエンジニア社員の育成機会拡充は非常に重要なテーマです。特に私が所属するARIにおいては、社として掲げる「BXdesigner」というコンセプトの実現に向け、技術的な知識や実践力を磨き続けるのは当然のこととして、そんな技術力を活かすための「ソフトスキル・コンセプチュアルスキルの向上」も非常に重要な課題と捉えています。
そこで過去社内外において実施してきた登壇素材を元に、cacumo様のご協力を得てより消化してもらやすい形での言語化を試み社内に研修素材（動画＋記事）として整備するプロジェクトを開始しました。この記事はその第一弾です。
cacumo藤木さんのファシリテーションのおかげで、伝えたいことを十二分に引き出していただくことができました。社外の方にも参考になるのではないかという示唆もいただき、こちらで公開させていただくこととしました。システム開発ビジネスの現場で奮闘されている多くの皆様の、何か少しでも気づきや学びになれば幸いです。
なぜ、お作法を伝えたいのか
[中野]
本日から数回に分けて『クライアントワークのお作法』についてお話します。というのも、システム構築をいろいろやってきた中で、すごく上手くいったプロジェクトもあれば、上手くいかなかったプロジェクトもあります。その要因は必ずしもシステムの難易度とか、使っている技術の難しさに比例していませんでした。システム開発＝テクノロジーだ、と思う人もいるかもしれないけれど、実は技術とは全く違うところで勝敗が決してしまうことを知ってもらいたいです。
あと、クライアントワークでは、依頼してくれるクライアントさんが満足するように仕事をしなければなりません。我々が作りたいシステムを作ることが仕事にならないように、「何を望んでいるのか」「どういった背景で仕事を頼もうとしてくれているのか」とかを理解しておかないと、一生懸命に頑張ったとしても高い評価には繋がらなかったり、マイナスになってしまいます。それを避けるためにも、クライアントワークのお作法を伝えたいなと思いました。
クライアントワークは難しい
[中野]
システム開発に限らず、web制作やそれ以外のコンサルティングなども同じだと思うんですけど、クライアントワークって非常に難しい仕事だと思います。なぜなら 「作るべきシステム」とか「解決すべき課題」という本質的なものを取り扱う前に、綺麗にしなきゃいけないことが結構あるからです。
例えば、そもそもお客様はどういう会社か、どういう背景で今回のご依頼に至ったのか、その方が普段どういった仕事をしているのかとか、ちゃんと理解できずにいて、それによって言葉がかみ合わなくて上手くいかないこともあります。 お客様側のいろんな立場や立ち位置の人がプロジェクトに関わっていて、それぞれ望んでいることが違うこともあります。
若いときにありがちですが、お客様は社内で合意が取れてから、僕らに頼んでくれていると思ってしまいます。しかし、我々が一枚岩になることが難しいのと同じように、お客様だって一枚岩になるのはすごく大変なわけです。
[藤木]
関係者が多いと難しそうですね。
[中野]
そうですよね。僕らが難しいことは、お客様も難しいということですよね。あとは、契約という行為を前提に仕事するので、法律の特別な知識も一部必要になります。ビジネスの慣習として、予算の考え方や契約をどういう単位で区切るのかとかも事前に知っておけるといいですね。僕らがそういう法律やビジネス慣習を知っている前提でお客様が会話していることもあるので その辺は押さえておきたいです。
どんなプログラム言語とか、どんなアーキテクチャとか、どんな業務に変えるのかみたいな話に行く前の外堀が大切なんです。
難しさの原因：多様なステークホルダーの存在
[中野]
なぜこういうことが起こりやすいのかというと、特にシステム開発の案件はステークホルダー（利害関係者）が沢山いるからです。業務でシステムを使う人、システム屋さん、システム屋さんの中でもデザイナーさんやフロントのエンジニア、バックエンドのエンジニア、インフラのエンジニア、そのアプリケーションの面倒を見る情シス担当者など。いろんな人たちがいて、それぞれが得たい成果と担当している領域が違いますよね。最終的に目指しているものは一緒で、システムのカットオーバーであり、その効果を最大化することなんだけど、それぞれ役割が違うから手に入れたいことも違う。
「どう移行するんですか？」みたいな作った後のことを考えたい業務担当者もいれば、「プログラミング言語を早く決めてください」という人もいれば、「インフラを早く作らなきゃいけない」って焦っている人もいる。それぞれ自分の優先順位で動きたがります。
あとは、他の職種の人と交わることに強い関心を持ってない人たちも一部います。分業する中で、お互いの専門性をリスペクトすることはいいことですが、必要なことや関心事が違うということを知らないフリをしているとか。関心を広げると面倒くさいから、耳をふさぎがちなことがあります。他の職種の人と関心事が違うから「困ったな」ではなくて、「どうすればうまくいくか？」って考えることをデフォルトにしたい ということが今回の提案です。
解決のポイント：相手の関心にも関心を払う
[中野]
『関心の輪』という言葉を『7つの習慣』という書籍から引用しています。関心を寄せている輪が広ければ広いほど、相手の方は「自分のことを理解してくれている」という気持ちになります。そうすると、何か言葉を投げかけたときに、受け取ってくれる確率が高くなります。その人の目的を果たすための言葉より、2人の目的を達成するための解決に向けた言葉だと捉えてもらえた方が届きやすいじゃないですか。だから、関心の輪を広げるようにしたいです。
なぜ、プロジェクトマネジメントをメンバー全員が学ぶべきなのか？
[中野]
プロマネのスキル・経験・知識をプロジェクトメンバーも知っておくべきだと思っています。なぜかというと、プロジェクトをまとめるには、どういう大変さがあるのかを知っているのと知らないのとでは、プロジェクトの中での振る舞いが変わってくるから です。例えば幹事をやったことがない人たちの集まった飲み会に比べて、幹事経験豊富な人たちが集まった飲み会のはっちゃけ具合って簡単に想像できるじゃないですか。
[藤木]
幹事経験者が多いと安定しますね。
[中野]
そうなんです。全員が幹事をやる必要はないんだけれども、僕の理想ではみんな1回は幹事をやって、幹事の大変さが分かっている人たちの飲み会であってほしいですよね。
本資料の背景と、受講者への期待
[中野]
以上のようなことで、特にシステム開発は、異なる価値観、経験値、業務の範囲を持っている人たちの複合作業という特性があります。特にエンジニアではないお客様の価値観や特性を、エンジニアである我々が知っておく必要があります。 幹事の仕事を知っている状態で飲み会に参加する状態を、システム構築でも出来るんじゃないかなという事で今回こういう企画をしました。
[中野]
これからお話しすることを聞いてもらって、お客様や自分以外のロールの関心ごとにも関心を寄せてもらえるようになってくれたら最高だなと思います。
1.企業のシステム開発にかかわる人達を知ろう
[中野]
大きく3つのパートがありますが、本日は1番の「企業のシステム開発にかかわる人達を知ろう」についてお話しします。
企業システムに関わる取引構造
[中野]
まず、どういう方々がシステムの開発に関わっているのかを見ていきます。特に我々の場合だと、個人開発というよりは、企業の中で商用システムを作ることが中心になるので、その場合を例に挙げています。
企業が情報システムを取り扱うときの組織構成は、企業によって異なります。ユーザーは大きく分けると、お客様の会社の社員のみなさんの場合もあれば、BtoCのサービスを運営している事業者さんの場合は一般ユーザーさんですし、BtoBの場合であればクライアントさんのクライアントさんになります。
なので、最終的な利用者も、社外の方だったり、お客様の社員の方です。お客様の社員であっても、本社にいる人と支店・支社の方がいる場合は全然違うよね。本社の方と話しているんだけど、実は本社と支社の間に「踊る大捜査線」のような軋轢があるみたいな（笑）
[藤木]
なるほど（笑）、それはだいぶ温度が違いますね。
[中野]
全然違うから、その辺をちゃんと意識しておかないと「なぜ所轄に血が流れ出るんだ？」って言われてしまう。
僕らとユーザー部門の間に情シスの方々がいることがよくあるパターンですね。情シスも実は会社によって組織の大きさや役割が違います。一定規模の会社になると、システム子会社のような形で外の法人に出されているケースもよくありますね。
[藤木]
会社が違うと複雑になりますね。
[中野]
そうなんですよね。会社が変わると、上下関係が出たり、文脈が難しくなっちゃうので要注意ですね。情シスやシステム子会社の下に、我々のようなベンダーがいます。当然、ベンダーだけで体制を作るのは難しいことが多いので、ほとんどのケースは協力会社さんと言われているパートナーさんにも依頼します。パートナーさんの中には、オフショアの海外の会社さんだったり、最近だとフリーランスに近いような方が参画されているケースもあります。パートナーさんに見えるんだけど、個人事業主の方とお付き合いしているケースもあるので、登場人物の階層はかなり深いです。
まずは、お客様側にフォーカスして、どういう登場人物が、どういう形でいるのかはめちゃくちゃ重要ですね。なぜなら、システム開発は意思決定のマネジメントゲームだからです。最終的に「要件や仕様をどう合意するか」というコミュニケーションゲームに近いところがあって、そこをミスらなければ、大きな技術的課題が無い限り、ほとんどのケースで勝率が上がっていくはずなんです。
コミュニケーションの計画を考える上で、そもそもこのプロジェクトに登場する方々の関係性や会社間の序列、役割をちゃんと知っておかないと、トンチンカンなコミュニケーション計画を立ててしまう可能性があります。
[藤木]
なるほど。コミュニケーションが重要なゲームだから、まず相手を知ることが必要というわけですね。
[中野]
「踊る大捜査線」で例えると、所轄が使っているから「所轄の方々と仕様を詰めておけば間違いないですよね」って進めていくと、直前で本庁の室井さんが出てきて「そんな話聞いてないぞ！」みたいなことも普通にあり得る。本庁がOKを出したもの以外は所轄では使っちゃいけないこともあるかもしれない。本庁の方々と仕様を詰めて、所轄に使ってもらおうとしたときに、現場から反発を受けちゃうこともあり得ます。なので、誰と話すべきなのかは非常に重要ですよね。
[藤木]
初めてプロマネをやる方からすると、この登場人物やそれぞれの関係性を解像度高く理解するのはなかなか難しそうだなと思いました。
[中野]
そうですね。それと、自分たちの上位にプライム（元請け）がいるプロジェクトでは、どうしてもプライムより先のお客様側の登場人物とかコミュニケーションが見えづらかったりします。なので、過去のプロジェクトの経験値によっては、そこに触れる機会が実はあんまりなかったっていう方もいるかもしれないですね。
[藤木]
自分たちの上位にプライムがいるプロジェクトの場合でも、こういった考え方は必要ですか？
[中野]
自分たちがプライムではないときでも重要です。プライムにはプライムの苦労があります。今後、自分たちもプライムになる機会が増えるわけで、プライムになってからそれを知ろうとしても間に合いません。今からプライムに協力することで学べますし、そのプロジェクトの成功確率も上げることができます。
基本的には、どこのポジションにいようとも「このシステムを誰が使うか」「誰が仕様を確認するか」「誰がOKと言うのか」のような、全体に関心を持つことが重要です。
「自分の作る機能のために、この人に承認もらえればいい」という閉じ方もあるかもしれないんだけど、それって部分最適になる可能性があるので、できればプロジェクト全体の体制を全員が理解できている状態で、自分の役割を頑張ってほしいですね。
関係者が多い分、コミュニケーションも複雑に
[中野]
登場人物とそれぞれの立場が多くなればなるほど、当然コミュニケーションの量は増えるし、複雑になります。コミュニケーションとは、会議体やドキュメントの承認フロー、メール、チャットなどです。内容によっては1人だけでなくて、いろんな関係者と会話しなきゃいけない可能性がありますよね。
全員が理解すべきか意見は分かれるけれども、どういう人たちが会話をすれば今回使うプロジェクトの技術や要件が完結できるのかを、プロジェクトを立ち上げる計画のタイミングで把握しておくべきだと思うし、コミュニケーションの範囲が曖昧になってしまうと、その分リスクが増えると思っていいんじゃないでしょうか。
体制図に「誰だろう？」がいない状態
[藤木]
中野さんがプロジェクトに関わるときにも、こういった関係者の顔ぶれや人を理解するところに時間を使うんですか？
[中野]
それがめちゃくちゃ重要で、体制図上では出てきているけど「この人は、一体誰なんだろう」という人がいます。プロジェクトによっては意図的に範囲を閉じた方がいいことももちろんあります。だけど、本当の意味で全体をマネージして成功させなきゃいけないときは、「誰だろう」という人は作らないようにします。 1回は会話をするとか、どういう役割なのかを知っている人に聞くとか、把握のために会議に出させてもらうとか。何かあったときに電話ができる状態を作ることは、プロマネをやるときにはとても重要だと思う。
少なくとも最低限の何かあったときに連絡ができる状態は作っておいた方がいいですね。キックオフで1回は顔を合わせておくとか、普段のご挨拶ができていないと、トラブルがあったときだけ急に連絡しても、相手は話を聞いてくれませんから。そういう意味で1回はノックして、関係をつくっておくのは必要ですね。
なぜ、「提案書」「議事録」が重要なのか？
[中野]
ここからはプロマネの会話になりますが、議事録をちゃんと取りましょう。なぜドキュメントが重要かというと、コミュニケーションの渦の中で、いろんな情報共有とお客様の社内的な承認行為がなされているからです。 お客様のコミュニケーション能力に依存しすぎると、我々としてリスクが大きいわけです。
[藤木]
なるほど。自分たちが出られないお客様の社内会議もあるからですね？
[中野]
おっしゃる通りで、出られない会議の方が多いし、そこで「中野さんが何でもやるって言ってましたよ」なんて言われたものなら「待ってくれ」ってなるじゃないですか。
目の前のAさんを納得させるためじゃなく、Aさんが自分の上司のBさんや、隣の部署のCさんに承認取ってもらうことを前提に書いてほしい。 担当者の説明力に期待しないっていうことです。馬鹿にするとかそういう話では一切なくて、担当者が話したいことと、担当者がどうでもいいと思っていることの説明には濃淡がつきます。ベンダーが話してほしいことが、担当者が話したいこととは限らない。必ずそこにギャップがある前提 で、ベンダーとして言っておいてほしいことは赤字にするとか、フォントサイズを40pxとか大きく書いて、第三者にも誤解なく伝わるようにします。
[藤木]
なるほど。関心事が違うから、お客様の担当者が我々と同じように説明してくれるわけじゃないという意味で「期待しない」ってことですね。
[中野]
そうなんですよ。お客様への提案書をレビューしていると「お客様とは話したので大丈夫です」って言われることがあります。話したそのお客様は分かってくれているかもしれないです。だけど、お客様が社内で上司に上げる際、我々とその資料で合意したという前提で、我々にとってはマイナスの交渉をしてしまう可能性があります。だから、話した相手だけが分かるようなドキュメントじゃ駄目ですっていう話です。
[藤木]
わかりました。大事な心構えですね。
成果物を元に合意・承認・指示がPJの基本
[中野]
これは、敢えて言うまでもないんですが、僕らの仕事で一番恥ずかしいのは『言った、言わない』です。こういう商売をやっている以上、お客様と『言った、言わない』という話になったらこちら側の負けですよね。 もちろんお互い様みたいなところもあるんだけど、こういう話に持っていかれそうになった瞬間「プロとして恥ずかしいな」って思うぐらいが丁度いいんじゃないかと思います。つまり、どんなことも資料やチケット、チャット、メールなどでしっかり記録を残しながら合意形成を重ねることを当たり前にしておきたいです。やっているときもある、というのはナシ。やってないことが1件でもあったら恥ずかしい。なかなか難しいですよね。僕自身も、1回見つめ直さないといけないぐらい恥ずかしい思いもあるんだけど、自分のことを棚に上げてでも言いたいです。
なぜ、「ステコミ」が重要なのか？
[中野]
ステアリングコミッティ（通称：ステコミ）という会議体があります。普段のプロジェクト担当者じゃないお客様の偉い人と、ベンダー側の偉い人が顔を合わせる会議をステコミと言います。大きなプロジェクトでは、月に1回とか3ヶ月に1回ぐらいの頻度で開催することがあります。
お客様はプロジェクトの状況を社内で共有していることが多いです。なので「ステコミをやりましょう」と言うとたまに嫌な顔をされるんですよね。担当の人から社内で上司に報告しているから、「あえて時間作ってもらうのもアレなので」みたいな。上司の方は大体忙しいから会議の調整とか面倒くさいわけですよ。それでもステコミは必要ですね。なぜなら、お客様の担当者の情報共有能力とか、説明力に期待しすぎるということは、我々のクライアントワーク商売においては致命的なリスクだからです。
ステコミは上手くいくプロジェクトにおいては、8-9割は無駄な会議になるんですよ。「上手くいってるから、メールだけでいいじゃん」みたいな感じになるんですけど、上手くいかなくなったときの、みんなの当事者意識を高める上でとても必要なプロセス なんですよね。上手くいかなくなってから急に呼び出されても、被害者意識丸出しで来るから解決できないわけですよ。だから、問題が起こる前から会議に呼んでおきます。「トラブルがないなら呼ぶなよ」となりがちだけど、上手くいっているときから偉い人を呼んでおくことを、面倒くさがらずに是非やってほしいなと思いますね。
[藤木]
8-9割は、「上手くいってます」と報告する会になるんですかね。
[中野]
大抵は上手くいってないことが1つ2つはあるから、いちいち言わなきゃいけない面倒くささがあるけど、この面倒くささは将来起こるトラブルの保険料だと思って払っておいた方がいいですね。
[藤木]
顔を合わせておくことと、小さい問題でもみんなで考えておくと当事者意識が高まりそうですね。
[中野]
基本的に管理職の人たちは、一定の経験を持っていたり人柄良い人が多いから、ちゃんと問題解決に貢献しようとする人がほとんどなんですよね。そういう人たちを巻き込むべきだなと思います。 ただリスクに敏感で気軽に巻き込もうとしてもすごくガードが固い人もいる。だから出世しているという部分もありますしね。変な空気になってから巻き込もうとしても「いや、俺は聞いてないから」ってなっちゃいます。
既存ベンダーの置き換えとして僕らが入るケースだと、既存ベンダーの人たちがなかなか協力してくれないことがよくあります。結局そこもコミュニケーションでしかなくて「お前ら全然駄目だったらしいな、俺たちが代わりにやってやるよ」みたいな感じでイキってきたら、そんなの協力する気にならないですよね。「皆さんも大変だったんですね」「皆さんの責任にされてますけど、お客様の責任も半分以上あるんじゃないですか」とか、そこで「いや、そうなんだよね」ってなれば儲けもんだし。それでも心を閉ざされたらしょうがないんだけど、何がしか共感してくれるところは絶対あるはずだから、コミュニケーションを取らなきゃいけない人とコミュニケーションをサボらずに取りに行くっていうことですよね。
ここまでが、本日の範囲となります。
[藤木]
ありがとうございました。
―後編に続く。