社内SEを目指している方や、情シスで働き始めたばかりの方の中には「プログラミングがそこまで得意じゃないけど大丈夫だろうか」「技術力で評価されないと居場所がなくなるんじゃないか」と不安を抱えている人もいると思います。私も社内SEになりたての頃は、まさにそう思い込んでいた一人でした。この記事では、社内SEとして約3年働いた今だからこそ感じている「本当に大事なスキル」について、現場でのリアルな出来事を交えながら書いていきます。
社内SEに必要なのは技術力だと思っていた頃の自分
社内SEになる前、訓練校でプログラミングを学び直していた時期がありました。当時、私の頭の中は「とにかくコードが書けるようにならないと現場で通用しない」でいっぱいでした。社内SEという職種を知ったときも、まず気になったのは「どのくらいの技術レベルが求められるんだろう」という点だったんです。
正直、未経験から飛び込む立場だったので、技術力で評価されないなら自分の居場所はないと思い込んでいました。同じように考えている方は少なくないんじゃないかと思います。
ところが実際に社内SEとして働き始めてみると、「あれ、思っていたのと違うぞ」という感覚が日に日に強くなっていきました。3年働いた今、一番強く感じるのは、技術力よりも優先度の高いスキルがあることでした。それがコミュニケーション能力です。
私も最初は「技術がすべて」だと思い込んでいました。
実際に働き始めて、その認識はけっこう揺らぎました。
訓練校で実際にどんなことを学んだのかは、職業訓練校のプログラミングは意味ないのか正直に書いた記事にまとめています。
情シスの仕事は「人と話す時間」が想像以上に長い
社内SEと聞くと、一日中パソコンに向かってコードを書いたり、サーバーをいじったりしているイメージを持つ方もいるかもしれません。私も入社前はそういう想像をしていました。
実際の一日はというと、他部署からの問い合わせ対応、ベンダーとの打ち合わせ、チーム内の進捗共有、ユーザーからのトラブル相談。気づくと人と話している時間がかなりの割合を占めています。純粋に手を動かして開発している時間は、思っていたよりずっと短いというのが正直な感覚です。
職場や担当領域によって差はあると思いますが、少なくとも私の現場では「コードを書く時間」より「人と情報をやり取りする時間」のほうが長いです。そしてこのやり取りの質が、そのまま仕事の成果に直結している実感があります。だからこそ、技術力よりもコミュニケーション能力のほうが効いてくる場面が多いんだと思うようになりました。
情シス・社内SEに必要なスキルを痛感した3つの場面
実際に「コミュニケーション能力がなかったら詰んでいたな」と感じた場面が、特に印象に残っているものだけで3つあります。
他部署からの要件ヒアリング ―「前のあの感じで」問題
社内SEをやっていると、他部署から「前に作ってもらったあの感じで、ちょっと別のやつ作れない?」みたいな依頼が普通に飛んできます。最初の頃は「あの感じってどの感じだ……」と頭を抱えていました。
依頼してくる側は悪気があるわけではなく、自分の頭の中でやりたいことのイメージはあるんです。ただ、それを言語化して伝えるのが難しい。システムの細かい挙動まで理解している人ばかりではないので、当然といえば当然なんですよね。
ここで「了解しました」と引き取ってしまうと、後から大変なことになります。出来上がったものを見せた瞬間に「いや、こういうことじゃなくて……」と言われ、最悪の場合は作り直しになります。だからこそ、最初に「どんな場面で使いたいのか」「どこまでが必須でどこが希望なのか」を、こちらから丁寧に質問していく必要があります。
そして引き出した内容を、今度は相手にもわかる言葉で返してあげることもセットで大事です。「つまりこういう動きをするものでよいですか?」と、専門用語を抜いて確認する。この一往復があるかないかで、後工程の手戻りがまったく違ってきます。
「あの感じで」と言われたら、こちらが具体化するしかないんです。
聞き返すのは失礼じゃなくて、むしろ親切なんだと今は思います。
トラブル対応 ―「なんかおかしい」から原因にたどり着くまで
トラブル対応の現場でも、コミュニケーション力の差がそのまま解決スピードに出ます。印象に残っている一件があるので紹介させてください。
ある日、「いつも使っている処理を動かしたら、出力された帳票にデータが入っていない」という連絡が来ました。最初に話を聞いたときは正直「えっ、最近そのプログラムは触ってないのに、なんでそんなことが起きるんだ?」と疑問でいっぱいでした。
そこで現場に行って、画面を見ながら順を追って状況を聞いていきました。すると、その日の処理ではなく前日のオペレーションに違和感がある話が出てきたんです。さらに掘り下げていくと、前日のデータ取り込みで手順をミスしていたことがわかりました。リカバリーの過程で、誤って取り込みを2回走らせてしまった可能性が見えてきたんです。それでデータがおかしくなっていたわけです。
正直なところ、ミスがあった時点で連絡してほしい気持ちはあります。ただ、ユーザー側はその操作がシステム全体にどこまで影響するのかまではわからないので、本人にとっては「もう解決した話」だったんですよね。だからこちらが「他に何か思い当たることはありませんか」「最近いつもと違う操作をしませんでしたか」と広めに聞いていく必要があります。
トラブルが起きるとどうしても解決を急ぎたくなるんですが、そういうときほど落ち着いて話を引き出すほうが、結果的に早く原因にたどり着けます。当時は気づいていなかったんですが、振り返るとあの一件は私にとってけっこう大きな学びでした。
「最近触ってないのに不具合が出る」ときは、たいていシステム以外のところに原因があります。
聞き出す力がないと、永遠にコードを疑い続けることになります。
ベンダーとのやり取り ―「拠点ごとに違う」を伝えきる難しさ
ベンダーに開発してもらったシステムを複数の拠点に展開するときの話です。一見すると同じシステムをコピーして配るだけに見えます。ところが実際には、拠点ごとに業務の処理タイミングや細かい運用ルールが微妙に違うので、そのままでは動きません。
この「微妙な違い」を自分の中で整理して、ベンダーに過不足なく伝えるのが、想像以上に骨の折れる作業でした。一つでも伝え漏れがあると、後から「この拠点ではこのタイミングで動かない」といった問題が出てきて、追加対応が発生してしまいます。
事前に各拠点の担当者から情報を集めて、表にまとめて、共通点と差分を切り分けて、それを資料化してベンダーに渡す。事前準備の段階だけで結構な時間がかかりましたが、ここを丁寧にやっておくと、ベンダー側も抜け漏れのない開発がしやすくなります。
伝える側の整理力が、そのまま成果物の品質に直結するんだと痛感した経験です。「自分が知っていること」と「相手に渡すべき情報」は別物だと意識するようになったのは、この案件がきっかけでした。
「聞く力」と「伝える力」、両方が要るけど特に効くのは聞く力
3つとも、起点は「相手から正しく情報を引き出せるかどうか」でした。要件ヒアリングも、トラブル対応も、ベンダーへの説明も、まず自分が状況を正しく把握できていないと、その先の伝える作業も全部ズレていきます。
伝える力ももちろん大事です。ただ、伝える内容そのものが間違っていたら、どんなに上手に話しても結果は出ません。だから順番としては、聞く力が先で、伝える力がその後にくる、というのが私の今の感覚です。
私はもともと心理学を専攻していたこともあって、人の話を聞くこと自体にはあまり抵抗がないほうでした。学生時代の知識が直接仕事に活きているとまでは言えませんが、「相手の言っていることをそのまま受け取らずに、その背景にあるものを想像する」という姿勢は、けっこう役に立っているのかもしれません。
これから社内SEを目指す人に伝えたいこと
ここまで読んでくださった方の中には、「じゃあ技術力はいらないのか」と思った方もいるかもしれません。そういう話ではなくて、技術力は前提として持っておくものだと思っています。コードがまったく読めない、システムの仕組みがまったくわからない状態だと、そもそもヒアリングも噛み砕いた説明もできません。
ただ、「技術力さえあればなんとかなる」という発想で社内SEに飛び込むと、現場でけっこうしんどい思いをするんじゃないかなと思います。少なくとも私の現場では、技術一本で勝負するよりも、人の話を丁寧に聞ける人のほうが信頼されている印象があります。
人と話すのが得意じゃないという方も、悲観しなくて大丈夫だと思います。「上手に話す」ことより「丁寧に聞こうとする姿勢」のほうがずっと大事で、これは後からでも身につきます。私自身も最初は手探りで、今でも正解がわかっているわけではありません。それでもなんとかやれているので、同じような不安を抱えている方の参考になれば嬉しいです。
口下手でも大丈夫。「ちゃんと聞こう」という気持ちさえあれば、現場はちゃんと見ていてくれます。
未経験から社内SEに転職して3年経って感じたリアルは、別の記事にまとめているので良ければ読んでください。
