やはりSEは「コミュ障」では慣れないと思った話。
SEほど「ことば」を使い分けなければいけない仕事はない。
…タイトルも見出し文も煽りみたいな文章になってしまった。
別にわたしは他の職種を経験しているわけでもなく、SE歴もたったの1年程度（しかもコードを書いているのは合計でも2か月程度）なので、新卒新米SEのぼやき程度だと思って読み飛ばしてほしい。
…最近、やっと、企業向けのシステム構築=システムインテグレーション（SI)というものが何たるかということを経験ベースでわかるようになってきたと思う。就活時代には、SIの伝統的なサイクル（要件定義、基本設計、詳細設計、開発、テスト、運用・保守）というものを用語としては理解していたものの、それを自分の働き方に置き換えてリアリティあるものとして考えることはできていないなかった。
システムインテグレーションってなんだ
私のざっくりとした理解だが、SIは次のようなフェイズで進んでいく。
要件定義
まずはお客さんの潜在的なお困りごと・ニーズを引き出し、整理し、その解決策の一つとしてのシステムの全体像を決めるのが要件定義フェイズ。
基本設計・詳細設計・開発
その次に、システム全体像から、個別具体の機能に落として考えるのが基本設計フェイズ。この設計書が、開発者と技術者の懸け橋になって、それを詳細設計・開発フェイズで実際の機能開発に落としていく。
テスト
機能開発が終わったら、テストフェイズが待っている。お客さんがシステムを実際に触るうえで正常に動くシステムか、使っていてストレスを感じないシステムになるかetc…を厳しくチェックしていく。
保守・運用
テストが終わるとシステムを実際にお客さんに使ってもらう。この保守・運用フェイズでは、日々使っていくうえでよりお客さんにとって使い勝手の良いシステムに改善するために追加で開発を行ったり、システムで不具合があった際の障害対応などを行う。
以上がわたしの知る限りのざっくりとしたシステム開発の流れである。このSIの過程において、作る機能が巨大化・複雑化すると、基本的には、その分開発する人数も増えていって、その分コミュニケーションにかかるコストも増える。
開発におけるコミュニケーションってなんだ
コミュニケーションというと、お客さんとの折衝・社内での報連相など言葉を介した、対人コミュニケーションが真っ先に思い浮かぶが、わたしは設計書・プログラミングすらも一種のコミュニケーション手段だなと最近思う。
というのも、大規模開発であればあるほど、同じ機能でも設計者・開発者・テストシナリオ作成者・テスターが違う場合があり、自分とは文脈を共有していない人とのコミュニケーション手段にもなりえるというのが理由だ。
自分が書いた設計書・プログラミング・テストシナリオが自分の意図せぬところで読まれ、それをもとに開発・別のプロジェクトで再利用されることがある。たとえ、自分が設計・開発・テストまで全部やったとしても、その過程で生まれた設計書なりプログラミングコードが、自分のあずかり知らぬところで読まれていることがある、ということを肝に銘じておかないと、社内から突然問い合わせが殺到する、という事態になりかねない。
こうしたリスクを回避するためにも「誰にとってもわかりやすい設計書・コード」を書こうという心がけが必要だと最近しみじみ思う。
ともすると、プログラミングは独りよがりな作業になりがちだと思う。
書いている人の「わからない/わかる」の境界線が、読む人の「わかる/わからない」とか限らない。その前提を無視して動くものを作ればよい、という意識で書いていると間違いなく失敗する。これは文章もそうだと思う。
この文章を読む人は誰か、読む人はどんな知識・背景を持っているのか、どんなシチュエーションでこの文章を読むか、というところまで想像を膨らませて書かないと、独りよがりな文章になってしまう。（もしかしたら、すでにこのエントリーも、何言ってんだこいつ？？？状態になっているかもしれない。先に謝っておく）
会社のボランティア活動からの学び
ちょっと余談になるが、最近、ボランティアで高校生や社会人の方向けに、生意気にもプログラミングやマーケティングについて説明する機会があり、そうした場でもやっぱり相手への思いやりを持ったコミュニケーションの重要性を身に染みて感じる。
ただ、インプットすべき事柄を1から10までを懇切丁寧に網羅的に説明すればよいというものでもなく、相手の頭の中を想像して、何が一番その人にとって記憶に残っているのか、何がその人の好奇心を刺激するフックになるのかを考えて、臨機応変に説明の仕方を変えていかなければならない。これがうまくいけば、1から10まで説明しなくても、その人自身がもっと自分で調べてみよう、と勝手に10、100とキャッチアップしてくれたりする。逆説的ではあるのだけれど、1-3くらいの知識で、相手の興味をそそる伝え方をしたほうが、一度に10伝える以上に効果的なのではないかとすら思う。
こうした教える・伝えるスキルというのはもともとの「地頭の良さ」というより、「経験」がものをいうのだろうな、と個人的には思う。むしろ地頭が良い人ほど「相手がなぜわからないのかわからない、何をわからないのかわからない」という壁にぶち当たるではないかとすら思う。
そういう人こそ、そこからさらに思考を進めて、「自分が言っていることは10％くらいしか伝わらないかもしれない」というネガティブな見方に立って、とにかくあの手この手を使って、相手が腹落ちしてくれる方法を探る中でしか、こうした教える・伝えるスキルは磨かれないのではないかと思っている。
「わたしさえよければいい」「わかる人だけわかればいい」では絶対回らない。
…話をシステム開発に戻すと、システム開発においても、誰向けに、どんなやり方で、何を伝えるのか、という視点は必要不可欠だと思う。小さなアプリ開発であれば自分ひとりで完結できるのかもしれないけれど、システム開発は多くの場合で団体戦だ。
自分のことだけでなく、どうしたらチームの回りがよくなるか、どうしたら自分以外の人の負担を減らしてあげられるか、という全体最適の視点に立って、チームメンバーとのコミュニケーションをしていきたい。
もちろん自分の目の前のことに手いっぱいで、他人のことを考えている余裕はない、というときもある、というか、今はそっちの方が多いかもしれない。
でも、だからこそ、自分が後輩に対して何か伝える・教えるときには、その後輩の気持ちに立ってコミュニケーションを取りたい。自分がやったことのないこと、知らないこと、得意でないことに直面した時に焦る気持ち、自分を責めたくなる気持ちが痛いほどわかるし、そういうときの上司の「なんでこんなこともわからないの」という態度を感じた時には消えてしまいたくなる。
でも、少し見方を変えれば、相手の伝え方がよくない可能性だってある。理解力は人それぞれだし、その人がその時に出せる100％を出しているなら、「なんでこんなこともわからないの？」という詰め方をするのは、無意味なプレッシャーを与えるだけで決してパフォーマンスが上がるやり方ではないと思う。（ドMな人に厳しい言い方をして、より成果を引き出すというやり方もあるが、そのアプローチが通用するのは本当に極意一部な気がする）
…そして間違っても「わかる人にだけわかればいい」「わからない人は知らない、才能・センスがない、あの人は向いてない」と、すぐに決めつけて、その人と向き合わずに簡単に切り捨ててしまうような人にはなりたくない。
そのプロジェクトに入る人全員が、必ずしも要件定義・設計・開発・テストそれぞれのフェイズで得意なことをやっているわけではないのだから、やっぱりそこも加味して、その人がそのときの100％を出せるようなコミュニケーションをしたい。
今はまだ自分のことで精いっぱいではあるのだけれど、ここまで書いてきたような態度で仕事に臨まないといつかそういう上司になるんだろうなという恐れもありつつ、戒めもかねて、書いてみた。
書きたい事が無限に出てきて、タイトルと最終的な着地点が全く一致しなくなってしまったOTL
プログラミングもコミュニケーション手段の一つ。
コミュニケーションするときは相手の立場に立って、臨機応変に伝え方を変える必要があること。
システム開発は団体戦で、自分ひとりの作業でも全体最適の視点で仕事をすることが大事だということ。
いろいろと考えた夜でした。おやすみなさい。
