「処理を速くしてほしい」
そう相談され、私は最初、システムの速度を改善する方法を考えていました。ところが実際の作業を見ると、本当に負担になっていたのは、毎日30分以上も続く同じ内容の入力でした。
言われた要望をそのまま直していたら、技術的には改善できても、担当者の仕事はほとんど楽にならなかったかもしれません。
『はじめの一歩』第1話を見て、私はエンジニアにとっての「強さ」を改めて考えました。難しい技術を知っていることより、相手もまだ言葉にできていない問題を見つけることのほうが、現場では重要な場合があります。
この記事では、30年以上の仕事で経験した業務改善や現場観察をもとに、問題解決ができるエンジニアが何を見ているのかを振り返ります。
「速くして」の裏に別の問題があった
40代の頃、ある業務システムの改善を任されました。最初に聞いた要望は、とても単純です。
「処理を速くしてほしい」
こう言われれば、多くのエンジニアは処理時間を測り、遅い箇所を探すと思います。私もそうでした。データベースを見直すのか、プログラムの無駄を削るのか。頭の中では、すでにいくつかの技術的な方法を考え始めていました。
ところが、担当者に詳しく話を聞いてみると、少し様子が違います。
どの操作に時間がかかるのか。何件くらい処理するのか。1日の中で、いつその作業をしているのか。話だけでは分からなかったため、実際の操作を見せてもらいました。
そこで目に入ったのが、同じ内容を何度も入力している姿です。一度入力した情報を、別の画面でもう一度入れる。少し項目を変えて、また入力する。システムの処理を待っている時間より、人が手を動かしている時間のほうが長かったのです。
私はその場で、「これは速度の問題ではないかもしれない」と思いました。
処理を数秒短くしても、毎日30分以上かかる入力作業はほとんど変わりません。そこで処理速度の改善より先に、入力そのものを自動化する方法を提案しました。
結果として、担当者が行っていた作業はほぼ不要になり、「こんなに楽になるとは思わなかった」と言ってもらえました。
こちらとしては嬉しい反応です。ただ同時に、少し怖くもなりました。最初に言われたことだけを、そのまま直していたらどうなっていたのか。技術的には改善したのに、現場ではほとんど楽にならなかったかもしれません。
要望と本当の困りごとは違う
利用者が、自分の困りごとを正確に説明できるとは限りません。これは相手の説明が悪いという話ではありません。
毎日行っている作業ほど、どこに無駄があるのか本人には見えにくくなります。「昔からこうしている」「このシステムはこういうものだ」と思い込み、負担そのものを当たり前として受け入れている場合もあります。
だから、エンジニアが聞くべきなのは「何を作ればよいですか」だけではないのでしょう。私は今、業務改善の相談を受けたとき、次のような点を確認します。
- その作業はいつ、何回行うのか
- 作業の前後で何をしているのか
- 一番面倒だと思う瞬間はどこか
- ミスが起きたとき、どうやって気づくのか
要望の言葉だけを聞くのではなく、その人が仕事をしている流れを見る。そうすると、「速くしてほしい」「画面を増やしてほしい」「ボタンを付けてほしい」という言葉の奥に、別の問題が見えてくることがあります。
私にとってエンジニアの強さとは、難しい技術を使うことより、まず解くべき問題を間違えないことです。どれだけ高度な仕組みを作っても、問題の場所が違えば役には立ちません。
技術的に正しくても現場で使えない
別のプロジェクトでは、システム担当と現場担当の意見が真っ向からぶつかりました。
システム担当が考えた設計は、技術的には筋が通っています。データの整合性も保ちやすく、管理もしやすい。一方、現場の担当者は「その流れでは仕事が回らない」と強く反対しました。
会議では、両者が自分の正しさを説明します。システム側は、なぜその設計が必要なのかを話す。現場側は、そんな操作をしている時間はないと言う。
どちらの話も間違っているようには聞こえませんでした。ただ、このまま会議を続けても、同じ主張を繰り返すだけだろうなとも思いました。
そこで私は、実際の作業現場へ数日通うことにしました。
作業の横に立って初めて見えたこと
現場では、担当者の横に立ち、いつ入力し、何を確認し、どこで作業が止まるのかを見ました。
そこで分かったのは、システムが想定していた入力順と、実際の作業順が違うことでした。設計上は、必要な情報をすべて入力してから次の工程へ進みます。
しかし現場では、情報が一度にそろうわけではありません。届いた情報から少しずつ入力し、別の作業を挟み、あとから不足分を追加していました。
システムの順番に合わせようとすると、担当者は何度も前の画面へ戻らなければなりません。確認のために紙を見る。別の端末を開く。また画面へ戻る。
後ろから見ていると、たしかにこれは面倒だなと思いました。
そこで、入力項目の順番を実際の作業手順に合わせ、途中保存の方法も見直しました。大きな機能を追加したわけではありません。
それでも画面を行き来する回数が減り、入力ミスも起きにくくなりました。
このとき改めて分かったのは、会議で聞く説明と、現場で見る動きは同じではないということです。相手がうまく説明できない部分もあります。本人が意識せずに行っている細かな判断もある。そこは、実際に見なければ分かりません。
コミュニケーションは会話だけではない
エンジニアに必要なコミュニケーション能力というと、話が上手なことや、説明が分かりやすいことを想像しがちです。もちろん、それも大切です。
ただ、私が現場で助けられてきたのは、むしろ聞くことと見ることでした。
相手が話し終わるまで待つ。言葉に詰まったところを急いで補わない。作業の横に立ち、本人が何気なく行っている動きを観察する。
少し地味です。会議で立派な意見を言うより時間もかかります。それでも、問題解決という点では、この地味な作業が一番効くことがあります。
一歩が家業の釣り船屋で重い荷物を運び、不安定な船の上で踏ん張る力を身につけていたように、エンジニアも過去の環境から意外な力を得ています。
人の話を聞く機会が多かったこと。違う立場の人の間に入ったこと。言葉では伝わらず、何度も説明し直したこと。そうした経験が、技術とは別の場所で自分を支えてくれます。
学生時代に驚いた友人の視点
視点の違いを初めて強く意識したのは、学生時代でした。
当時、私には「この人たちにはかなわないな」と思う友人が二人いました。勉強ばかりしているようには見えません。しかし、先生との受け答えや、問題の見方が周囲とは明らかに違っていました。
ある数学の授業で、先生が難しい問題を出したことがあります。多くの生徒は、どの公式を使えばよいのか考えていました。私も頭の中で、習った公式を順番に探していたと思います。
すると、その友人の一人が「図にすると分かりやすい」と言い、黒板へ図を書き始めました。複雑に見えた問題が、図にした途端、単純な関係として見えてきます。
私は答えよりも、その考え方に驚きました。
「公式を探すのではなく、問題の見え方を変えるのか」
その発想は、当時の私にはありませんでした。
「水も資源では」という一言
さらにさかのぼると、中学生の頃にも忘れられない発言があります。
社会の授業で、日本は資源が少ないという話になったとき、友人の一人が「でも、水はあるのでは」と言いました。
私は一瞬、何を言っているのか分かりませんでした。「水って資源なのか？」と。
当時の私は、資源といえば石油や石炭、鉄鉱石のようなものを想像していました。先生が話した枠の中でしか考えていなかったのです。
その友人は、言葉の定義を少し広げて考えていました。正しいか間違っているかより、なぜ自分にはその見方ができなかったのかが気になりました。
この二つの経験は、今の仕事にも残っています。
問題が難しいとき、知識を増やすだけでなく、見方を変えられないか考える。利用者の言葉を別の角度から捉える。処理を速くするのではなく、処理そのものをなくせないか考えてみる。
学生時代の友人たちが、私にとって最初の「視点を変える先生」だったのかもしれません。
自分から難しい場所へ入れるか
『はじめの一歩』第1話で印象に残るのは、一歩が誰かに強制されてボクシングを始めたわけではないことです。
不安もある。自信もない。それでも「強いとは何か知りたい」と思い、自分から足を踏み入れます。
仕事では、逃げられない状況で頑張ることがあります。担当になったからやる。期限があるから進める。ほかにできる人がいないので引き受ける。私も、そういう仕事を何度も経験してきました。
ただ、自分から新しい場所へ入るのは少し違います。
誰にも頼まれていない技術を学ぶ。これまで避けていた仕事へ手を挙げる。分からない状態のまま、小さく試してみる。失敗したら、誰のせいにもできません。
だから怖い。
最近、AIの勉強を始めたときも同じでした。知らない言葉が次々と出てきて、最初は何を質問すればよいのかすら分かりません。
「今さら、ここまで覚える必要があるのか」
そう思うこともありました。それでも毎日少しずつ触っていると、昨日分からなかったことが、今日は少しだけ分かる。その変化が面白くなってきました。
52歳になって分かった続け方
若い頃は、短期間で覚えられる人を見て、自分も同じようにやらなければと思っていました。
今は、そこまで一気に吸収できません。新しい用語を覚えても、数日たつと忘れる。前に調べた内容を、また検索している。「いや、これは前にも読んだな」と苦笑いすることもあります。
それでも、続けていると少しずつ残ります。
ブログも最初は、1記事を書くのに丸一日かかることがありました。何から書けばよいか分からず、冒頭だけで何度も止まる。見出しを作っては消し、話が途中でずれて書き直す。
今でも迷いますが、以前よりは「まず体験を書き、そのあとで気づきを整理する」という自分なりの流れが見えてきました。
AIも同じです。毎日少し触るうちに、質問の仕方で答えが変わること、曖昧な依頼をすると曖昧な結果が返ってくることが分かってきました。
年齢を重ねると、速さでは若い人にかなわない場面もあります。ただ、無理のない続け方を見つける力は、むしろ強くなった気がします。
一気に覚えようとしない。昨日より少し分かればよしとする。分からないままでも触ってみる。
派手ではありませんが、今の私にはこの方法が合っています。
問題解決ができる人の3つの見方
30年以上働いてきて、問題解決が上手な人には、共通する見方があると思うようになりました。
言われた要望をそのまま答えにしない
「速くしてほしい」と言われても、本当に必要なのが速度とは限りません。なぜそう思ったのか、どの場面で困っているのかを確認します。
会議だけで分からなければ現場を見る
説明を聞いて理解したつもりになっても、実際の作業を見ると違うことがあります。手順、待ち時間、確認方法、画面の移動。小さな動きの中に問題が隠れています。
分からないときは見方を変える
知識が足りないと考える前に、図にできないか、順番を変えられないか、そもそも作業をなくせないかを考えます。正面から解けない問題でも、角度を変えると単純になることがあります。
まとめ｜強さは正しい問題を見つける力
技術力は、エンジニアにとって欠かせません。知識がなければ、考えた仕組みを形にはできませんし、安全性や保守性を判断するためにも学び続ける必要があります。
ただ、技術力だけでは解決できない問題もあります。
処理を速くしてほしいと言われたとき、本当に困っていたのは繰り返し入力でした。技術的に正しい設計を示したとき、現場では作業の順番が合っていませんでした。難しい問題を前に公式を探していたとき、友人は図を書いて見方を変えました。
どれも、答えを出す前に「何を問題として見るか」が重要だった経験です。
『はじめの一歩』第1話で、一歩は自分がすでに持っていた力に気づいていませんでした。エンジニアも同じかもしれません。
技術以外の経験、人の話を聞いた時間、現場で戸惑ったこと、違う考え方に驚いた記憶。そうしたものが、あとになって問題解決の土台になります。
52歳になった今、私が思うエンジニアの強さは、何でも一人で解決できることではありません。分からないときに立ち止まり、相手の仕事を見て、問題の場所を考え直せること。そして、必要な技術を少しずつ学び続けることです。
コードを書く前に、そもそも何を解決するのかを確認する。
地味ですが、その一歩を省かないことが、現場で長く役立つ強さなのだと思います。
コメント