ENGINEER THEORYソフトウェア開発エンジニア座談会

今は二つの案件を担当しています。
一つ目は、医療関係器具の開発を行っています。メンバがー二人いて、その二人の管理が中心です。
案件内容としては、特殊なOSを使って、その上に様々な機能を載せていく、ということをしています。
OSをどのように構成していくか、みたいなところも考える必要があり・・・
なかなか難易度が高いですが、自分のできる範囲でメンバーのサポートを行っています。

二つ目は、私1人で担当している案件で、これも若干特殊なのですが・・・
組み込みLinuxをビルドするためのフレームワークがあって、それをもとにお客様の要望にあったOSを作成するということを行っています。
お客様の要望をヒアリングし、機能を追加したりするのですが、問題が発生した際にどのように構成すれば課題を解決できるか話し合いながら進めています。

はい、そうです。

私は自動車の自動運転機能における、白線認識機能の開発を行っています。
開発の本流というよりは、シミュレーションや試験の結果を元に、解析を行うのが主な作業です。
T.Nさんみたいな難しい案件ではないんですけど（笑）

いやいや（笑）

エンドユーザーから細かな粒度で案件を振り分けられ、ひとつひとつこなしていく感じの状況です。

私はお客様先に常駐で、GNSS受信機のソフトウェア設計・開発を行っています。
GNSSとはあまりなじみのない言葉だと思うんですけど、位置情報を正確に把握できるサービス全般を指していて、例えばGPSとかはその中の1つなんです。
私自身未経験の分野だったのですが、テストから始め、新しい機能の設計開発も行っています。

私は社会インフラ関連の測定機器の開発を行っています。
実装作業や、機能を追加する際の設計書作成などを担当しています。
言語はC言語なので、入社時の研修で学んだことを活用できています。

工業高校出身で、前職は発電所勤務だったので馴染みがなく・・・　IT業界は偏屈な人が多いんだろうな・・・と（笑）

入ってみたらそれは偏見だったとわかって、みなさん気さくにしゃべってくれて安心しました。

私は「数学が出来る人の集まり」というイメージでした（笑）
英語で謎の言語を扱っている人たちがいるみたいなイメージでした。

はい。元々文系なので、私も馴染みがありませんでした。

私は、新卒で入った会社で最初からエンジニアでした。
最初の担当が組み込みソフトウェア開発だったので、今の案件は馴染みがあり、とっつきやすいです。

学生時代は、技術力が大事なイメージを抱いていて、今もそれは変わっていないんですけど、
実際に働き始めてわかったのは、プログラミングや設計以外の仕事も本当にたくさんあるんだな、 というのがエンジニアとして働き始めてすぐに実感したことですね。
会社のスタイルによりますが、打ち合わせや書類作成などにかける時間も多いし、大切なんだなと。

元々IT業界出身ではあるんですが、最初は自分自身はエンジニアではなくて、エンジニアを管理する側の仕事をしていました。
だから、仕事内容はざっくり知っていて、だんだんと「自分もあんな風になりたいな」と思うようになりました。
憧れに思う気持ちが強かったですね。

T.Nさんの言う通り、プログラミング以外の仕事も多いので、プログラミングにかける時間はどんどん短くしていくべき、という意識があります。
今入っている案件も、解析は自動化ツールに頼ることで作業時間をどんどん短くしていく。
それよりも設計書や手順書を読む時間や、コミュニケーションのためにチャットツールでのやり取りや、会議での話し合いをする時間とかが、とにかくコミュニケーションをとる時間が大事なんだなと思うようになりました。

本当にそうですね。そう思います、やっぱり。
お客様とだけでなく、チームメンバーとのコミュニケーションの時間とかも大切にしています。

近い観点だなと思うのは、ソフトの話をするときに事実ベースで話すのが大事だなと。
○○だと思う、という曖昧な言い方ではなく、△△により□□というデータが出ている、というようにしっかり事実を確認したうえで、状況の共有を始めるようにしています。
事実を報告しなければいけない場面で、「多分」という不確定な要素があると、後々トラブルを生む可能性があるというのは、実感としてあります。

誤解を与えないように、という点は本当にその通りだと思います。
言葉だけで伝えにくい時は、フローチャートなど、資料で補足して自分が伝えたいことと、相手が受けた内容に乖離がないよう、こまめに確認しながら話を進めることを意識しています。

未経験研修を終えて、最初に配属された現場で感じたことなのですが、研修で学んだC言語ではなくC++だったんです。
C++はC言語と比べて結構言語としての思想が違うので、そもそもプログラムのソースコードが読めないという状況から始まって…。
現時点で自分が持っている知識と、実際に現場で求められる知識とのギャップを埋めるのがとても大変でした。
基礎知識が身につけば応用が利くので、時間をかければ解決できる話ではあるのですが、まず「ソースコードが読める」というラインに立つまでがなかなか苦労しました。

研修では、基本設計があって詳細設計があって・・・という感じで順を追ってしっかりとしたテンプレートが用意されていたけど、実際の現場ではそうもいかない。
まず自分が携わっている案件についての理解をするのが難しくて、ひとりで悩んだ時間も多く苦難でした。

ひたすら聞きました（笑）
ひとりで考えてもわからないので、周囲の人に頼って、最終的には解決できました。
ついつい1時間、2時間と悩んでしまうこともあったので、時間を無駄にしないためにも、15分考えてわからなければ聞くとか、悩む時間は自分の中で基準を決めた方がいいということを痛感しています（笑）

私も案件の理解が一番大変でした。
Y.Sさんの言う通り、丁寧な仕様書が用意されているとは限らないので、読み解くのに時間が必要だったり、資料が散らばっていたりもすることもあるので、情報の収集や取捨選択に苦労しました。
不足している知識については、本やネットで調べたり、人に聞きました。
わからないことは自分から聞く・調べるをしないと、理解するのは難しいですね。

レベルアップをするのが楽しいです。
案件の理解の前にある、作業の各工程に対する考え方などのベースとなる知識が次の段階を理解するのに役立ったりするので、知識のレベルアップをすることで、目に見える成長があるので楽しいし、やりがいになります。
こんなこと知ってるんだよ、と同級生とかに自慢したくなる（笑）

私は社会人になってからずっと、仕事へのモチベーションが「課題解決」で、その軸をブラさずに生きてきました。
だから、エンジニアは天職だと思っています。
案件に入りたての時は知らないことだらけだけど、自分の知識を武器として装備して臨んで、ぶち当たっている壁を超えてく、という試行錯誤の末に、お客様に感謝してもらえた時にやりがいを感じます。
Y.Sさんと似ていて、レベルアップして、強い敵を倒していくイメージ（笑）

わかります。職業病ですよね（笑）

私は直近の仕事で言うと、バグ（不具合）を直しているときに楽しいなと感じました。
バグが発生するタイミングによって、早い段階で問題に気づけるので良い時もあるし、スケジュールを考えると、今バグが出るのはまずいという時もありますが・・・
課題解決というか、問題を解くような感覚があって、「さあ何がバグの原因なのか調べちゃうぞ」という気持ちになって、面白さはあります（笑）

だから、設計やテストよりも不具合の対応をしている時の方が、モチベーションが上がっていることに最近気づきました。
そして、それが思い通りに解決できたときに達成感がありますね。

あとは、お客様から頼られるとすごく嬉しいです。
今の現場はお客様側のメンバーも若い方が多いので、自分がフォローすることも多いんです。
周囲の方との関係性が築けて、質問されたり頼ってもらえたりするとやりがいになりますね。

まだ今は「頼る側」なので、K.Tさんのように「頼られる側」になりたいですね。
そのために、どんどん知識を取り入れたいです。
かつ、定時内で仕事を終わらせて、ワークライフバランスも大事にしていきたいです。

今までC、C#、Pythonと3種類の言語を使って仕事をしてきたので、そこから何かひとつを突き詰めるというよりは、いろんな業務に挑戦して、何でもある程度はわかる、広く対応できるような人になりたいと思っています。

自分もM.Kさんと似ていて、知らない分野にもどんどん頭を突っ込んで、自分の知識の範囲を広げていきたいです。
その結果として「頼られる側」になれるのかなと思うので、「この案件ならT.Nさんだな」と仕事を振ってもらえるような、事業部から頼られる存在になりたいです。

「頼られる側」と言っておいてなんですが・・・（笑）
自分も知識は常に課題だと思っていて、現状はLinuxや前職でやっていたアプリのUIに関する経験値があるのですが、今の現場でも扱う分野なので、どんどん深めていきたいと思っています。
経験があっても、いざやってみると知らないこともまだたくさんありますし、知識の幹を太くしていきたいですね。