現職でこれまでの経験を振り返る機会があり、自分がこれまで何をしてきたのかを整理しなければならなくなった。
ただ、正直に言うと、かなり苦しい。
何をやってきたのかを思い出すこと自体が、少ししんどい。なぜなら、入社してからの時間には、自分にとって忘れたいこと、なかったことにしたいこと、思い出すと気持ちが重くなることが多いからだ。
もちろん、客観的に見れば、担当してきた仕事はある。要求仕様を書いた。ベンダーと調整した。設計レビューをした。評価をした。監査対応をした。AWSやIoT、エネルギーマネジメント、デマンド制御、データ分析、閉域網、セキュリティ、プライバシーなど、技術的にも幅広い領域に触れてきた。
しかし、自分の内側に残っている感覚は、達成感よりも、違和感と消耗の方が大きい。
「自分はここで何をしていたのだろう」
「これは本当に自分のやりたい仕事だったのだろうか」
「この苦労は、職能として語れるものなのだろうか」
そう思わずにはいられない。
この記事は、きれいな実績整理ではない。
会社の場でそのまま話すための文章でもない。
まずは、自分の中にあるドロドロした違和感を、できるだけごまかさずに言葉にするための振り返りである。
最初のギャップは、「システム開発」という言葉の意味が違ったことだった
入社してから最初に苦しかったのは、自分が想像していたシステム開発と、実際に組織で行われていたシステム開発の意味が違ったことだった。
自分は、システム開発という言葉に対して、要件を考え、設計し、作り、動かし、運用し、改善していくようなものをイメージしていた。
もちろん、すべてを一人で実装するという意味ではない。
ただ、自分たちの中に技術判断があり、設計思想があり、運用で得た学びがあり、それを次の改善につなげていく。そういうループの中にいることを期待していた。
しかし、実際には、外部委託を前提とした仕事が多かった。
要求仕様を作る。
ベンダーに依頼する。
出てきた設計をレビューする。
評価する。
受け入れる。
監査に対応する。
関係者と調整する。
これは、たしかにシステム開発の一部である。
しかも、大企業の製品開発としては合理的でもある。品質、責任分界、コスト、リソース、スケジュールを考えれば、外部委託は自然な選択肢である。
でも、自分の中ではずっと引っかかっていた。
これを続けた先に、自分は何者になるのだろうか。
作れる人になるのか。
運用できる人になるのか。
障害や改善から学べる人になるのか。
それとも、仕様を書き、調整し、レビューし、受け入れる人になるのか。
その問いがずっと消えなかった。
想定していたシステム開発と、実際のシステム開発の射程が違いすぎた
もう一つ大きかったのは、自分が想定していた「システム開発」と、実際にこの組織で扱う「システム開発」の射程が大きく違っていたことだった。
自分が想定していたのは、どちらかといえばクラウド中心で、業務に近いシステムだった。
ユーザーの業務があり、課題があり、それをクラウド、Web、データ、API、認証、監視、運用改善の仕組みで支えていく。作った後も、利用状況や運用上の課題を見ながら、継続的に改善していく。
そういうシステム開発をイメージしていた。
しかし、実際にこの組織で扱うシステムはもっと広かった。
クラウドだけではない。
サーバがあり、装置があり、通信があり、現地機器があり、組込みがあり、製造があり、評価があり、品質保証があり、外部委託先があり、顧客ごとの導入条件がある。
それ自体が悪いわけではない。
むしろ、エネルギーやモビリティ、IoTに関わるシステムとしては当然なのだと思う。
ただ、自分にとっておかしいと感じたのは、その広さに対して、自社側で技術判断し、設計し、運用し、改善していく社員の厚みがあまりにも足りないことだった。
扱っている範囲は広い。
責任も重い。
関係者も多い。
しかし、自分たちの中で実際に手を動かし、深く理解し、運用で学び、次の設計に返していく人は少ない。
その状態で、本当に自分が理想とするようなシステム開発に辿り着けるのか。
正直、かなり早い段階で難しいと感じていた。
クラウド中心の業務システムに近い世界で、作る・動かす・観察する・直すループを回したかった自分にとって、ここで求められる役割はかなり違っていた。
広いシステムを扱っているのに、自社側の技術的な厚みは薄く、開発の根幹は外部に依存し、社員は要求、調整、レビュー、評価、品質対応に寄っていく。
この構造の中で、自分がエンジニアとして強くなっていく未来が見えなかった。
今振り返ると、かなり厳しいが、これは自分にとって明確な選択ミスだったと思う。
会社や組織が悪いというより、自分が伸ばしたい方向と、この組織で求められる役割が違いすぎた。
自分は、クラウド、業務、運用、改善に近い場所で技術を深めたかった。
しかし実際には、装置、外部委託、品質、調整、広すぎる責任範囲の中で、技術の中核から距離を置く役割に近かった。
そのギャップに気づいたとき、エンジニアとしてのキャリアが止まっていくような恐怖があった。
このままここにいると、自分は何者にもなれないのではないか。
クラウドエンジニアにも、SREにも、プロダクトを改善できるエンジニアにもなれないのではないか。
そういう危機感がずっとあった。
「自社でやらなくてもよい」は正しい。でも、それを聞くたびに冷めていった
組織や上司の考え方も、理解できないわけではない。
技術は手段である。
自社で作ること自体が目的ではない。
外部委託でも、要求仕様を決め、設計をレビューし、品質を担保すれば、知見は蓄積される。
これは正しい。
たぶん、事業責任や品質責任を持つ立場から見れば、かなりまっとうな考え方だと思う。
しかし、自分の中では、その正しさを聞くたびに、どこか冷めていく感覚があった。
なぜなら、自分が欲しかったのは、発注者としての知見だけではなかったからだ。
自分が欲しかったのは、作ったからこそ分かること、動かしたからこそ分かること、壊れたからこそ分かること、運用して初めて見えることだった。
たとえば、クラウドの構成を考えるにしても、単にベンダーの設計書をレビューするだけでは足りない感覚があった。
なぜその構成なのか。
どこが壊れやすいのか。
監視はどこを見るのか。
障害時に誰が何をするのか。
データ量が増えたらどうなるのか。
運用負荷はどこに出るのか。
IaCで再現できるのか。
改善するときに自分たちで触れるのか。
こういう問いは、外から成果物だけを受け取る立場では、どうしても弱くなる。
もちろん、要求仕様やレビューでも知見は残る。
しかし、それは主に、発注、調整、品質確認、ベンダーコントロールの知見である。
自分が伸ばしたかったのは、そこではなかった。
だから、「自社でやらなくてもよい」という正論を聞くたびに、自分の中では「それは分かる。でも、それではつまらない」と感じていた。
これは、単なるわがままではないと思う。
自分にとって仕事の面白さは、作る・動かす・観察する・直すというループの中で、自分も組織も強くなっていくことだった。
そのループから遠ざかるほど、仕事が自分のものではなくなっていく感覚があった。
スマートホーム向けIoTシステムの延長線と、サービス開発への違和感
組織には、過去にスマートホーム向けのIoTシステムを扱ってきた歴史があった。
宅内で動作するハブのような機器を提供し、住宅メーカーなどに向けて展開する。機器があり、システムがあり、連携先があり、外部のメーカー系SIerや製造委託先と一緒に進める。
その経験自体には価値がある。
しかし、自分から見ると、その延長線上で語られるシステム開発と、自分が考えるサービス開発には大きなギャップがあった。
システムを作ることと、サービスを継続的に改善することは違う。
機器を提供することと、利用者の業務や運用に入り込み、価値を出し続けることも違う。
OEMや委託を組み合わせて成立させることと、自分たちの中にプロダクトの判断軸や改善能力を持つことも違う。
ここが、元々その組織で長くやってきた人たちと、どうしても話が噛み合わない部分だったのだと思う。
相手が間違っているわけではない。
むしろ、過去の文脈ではそれが正しかったのだと思う。
ただ、自分はその文脈にうまく乗れなかった。
「システムを提供している」と言われても、それが本当にユーザーの利用シナリオや運用改善に結びついているのかが気になった。
「サービス」と言われても、サービスとして誰が使い、どの業務を変え、どう継続改善するのかが見えないと、言葉だけに聞こえた。
「ユーザー起点」と言われても、実際の設計や運用に落ちていなければ、スローガンに見えた。
ここに、自分の強い違和感があった。
一番しんどかったのは、話が通じない感覚だった
仕事の中で一番しんどかったのは、単に忙しかったことではない。
話が通じない感覚だった。
もちろん、言葉が通じないわけではない。相手は頭がいい。むしろ、頭がいいからこそ、こちらの言葉は整理され、別の正論で返ってくる。
「技術は手段でしょ」
「自社で全部やる必要はないでしょ」
「要求仕様として落とし込めばよいでしょ」
「ベンダーからの設計をレビューすれば知見は残るでしょ」
その通りだと思う。
その通りなのだが、自分が言いたかったことは、そこではなかった。
自分が言いたかったのは、手段としての技術を否定しないからこそ、どの判断を自社に残すのかを明確にしたい、ということだった。
外部委託を否定しないからこそ、何を自分たちで理解し、どこまでを設計判断として握るのかを決めたい、ということだった。
ユーザー起点を掲げるなら、誰が何を見て、何を判断し、何を操作するのかまで落としたい、ということだった。
しかし、そこまで行く前に、言葉の表面で整理されてしまう感覚があった。
そのたびに、自分の中で何かが削られていった。
自分が細かいことを言っているだけなのか。
自分が技術にこだわりすぎているだけなのか。
自分がわがままなだけなのか。
自分がこの組織に合っていないだけなのか。
そう考える時間が増えた。
それでもやったことは、違和感を仕様と評価に変換することだった
そんな中でも、自分は何もしていなかったわけではない。
むしろ、自分の違和感を、そのまま愚痴で終わらせないようにしてきた。
違和感を、仕様に変えた。
違和感を、評価観点に変えた。
違和感を、運用シナリオに変えた。
違和感を、リスクとして言語化した。
違和感を、設計レビューの指摘に変えた。
エネルギーマネジメント系のIoTサービスや充電制御を含むエネルギーマネジメント系システムでは、システム要求仕様、ベンダー調整、設計レビュー、評価、監査対応、セキュリティ、プライバシー、閉域網、AWS設計、IoT連携、データ確認などに関わった。
デマンド制御では、「ピークを抑える」という抽象的な目的を、30分時限、時限開始直後の安定化、超過予測、抑制、解除、優先度、出力制御、ON/OFF、異常時停止、再起動時の扱い、UI表示、履歴の見え方にまで分解した。
データ分析では、1分値、30分平均、建屋負荷、充電負荷、買電、売電、待機電力、欠測、0W異常、平日休日、気温や湿度との関係などを見ながら、システムが本当に動いているか、運用上どこに問題が出そうかを確認した。
AWSやIoTの領域では、Cognito、API Gateway、Lambda、DynamoDB、S3、IoT Core、IoT Jobs、Kinesis、SQS、WAF、Route 53、ECS、CloudFormation、CDK、Terraformなどの技術要素に触れながら、認証、通信、データ保存、ジョブ配信、バッチ処理、Shadow、MQTT、監視、閉域接続、セキュリティを整理した。
これらは、派手な成果ではないかもしれない。
しかし、曖昧なままでは進められないものを、進められる形にしたという意味では、確かに職能だった。
私が工夫していたこと
私が工夫していたのは、与えられた仕事をただ処理することではなかった。
まず、抽象的な言葉を具体化した。
「ユーザー起点」と言われたら、誰がユーザーなのか、いつ使うのか、何を判断するのか、何に困るのかに分解した。
「デマンド制御」と言われたら、どの時限で、どの計測値を見て、どのタイミングで、どの機器を、どの順番で、どの程度抑制し、いつ解除するのかに分解した。
「外部委託」と言われたら、何を委託し、何を自社で判断し、どのレビュー観点を持ち、どの受入条件で確認するのかに分解した。
「サービス」と言われたら、導入前、利用中、異常時、保守時、改善時の流れに分解した。
次に、技術と運用をつなげた。
AWSの構成やIoTの仕組みを、単なる技術要素としてではなく、運用、保守、障害対応、データ活用、セキュリティと結びつけて考えた。
さらに、ベンダー任せにしないための観点を持ち込んだ。
設計書があるかどうかではなく、その設計で何が成立し、何が成立しないのかを見るようにした。
評価項目があるかどうかではなく、その評価で本当に運用上のリスクが見えるのかを考えた。
仕様に書いてあるかどうかではなく、その仕様で利用者や保守担当が困らないかを考えた。
これが、自分なりの工夫だった。
組織に還元したこと
組織に還元したことは、たぶん、単なる作業成果ではない。
一番大きいのは、クラウド・IoT・サービス型システムに必要な観点を持ち込んだことだと思う。
従来の機器中心、委託中心、品質プロセス中心の見方だけでは抜けやすい観点がある。
認証はどうするのか。
データはどう蓄積するのか。
監視は何を見るのか。
異常をどう検知するのか。
ジョブ配信はどう管理するのか。
端末とクラウドの状態差分をどう扱うのか。
閉域網とインターネット接続の責任範囲をどう分けるのか。
セキュリティやプライバシーを後付けにしないために、どこで考えるのか。
こうした観点を、仕様や設計レビューや評価や監査対応の中に持ち込んだ。
また、充電制御を含むエネルギーマネジメント系システムのような新しい領域では、単に機能を作るだけではなく、実際に導入し、データを見て、制御が期待通り動いているか、異常がないか、運用できるかを確認する必要がある。
そのための見方を増やしたことも、組織への還元だったと思う。
もう一つは、曖昧な議論をそのままにせず、議論可能な形にしたことだ。
何が決まっていて、何が決まっていないのか。
技術制約なのか、運用制約なのか、事業判断なのか。
自社で判断すべきことなのか、委託先に任せられることなのか。
標準化すべきことなのか、個別対応せざるを得ないことなのか。
こうした切り分けをしようとしてきた。
それは、目立たない。
しかし、組織が新しい種類のシステムやサービスに向き合ううえでは、必要な仕事だったと思う。
これは普遍的なことなのか
この経験は、普遍的なことなのだろうか。
私は、普遍的だと思う。
ただし、普遍的というのは、どの組織でも同じように評価されるという意味ではない。
普遍的なのは、曖昧なものを構造化し、成立条件に変換する力である。
事業の言葉を、要求に変える。
要求を、設計や評価に変える。
技術制約を、運用や責任分界に変える。
違和感を、リスクや判断材料に変える。
外部委託を、丸投げではなく、レビュー可能で受入可能な形に変える。
これは、どの会社でも必要になる。
特に、IoT、クラウド、エネルギー、モビリティ、SaaS、VPPのように、機器、クラウド、ユーザー、保守、事業、外部連携が絡む領域では重要になる。
一方で、この力は、持っている本人にとってはかなりしんどい。
なぜなら、違和感に気づいてしまうからだ。
曖昧なものを曖昧なまま進めることに耐えづらくなるからだ。
きれいな言葉に対して、「それは具体的に何ですか」と聞きたくなってしまうからだ。
そして、それは時に、面倒な人、細かい人、理屈っぽい人に見える。
でも、そのしんどさの中に、自分が発揮してきた職能があったのだと思う。
もう二度とやりたくないこと
もう二度とやりたくないことは、はっきりしている。
自分たちが何を判断すべきか曖昧なまま、外部委託だけが進む仕事。
作る・動かす・観察する・直すというループから切り離され、調整と管理だけが残る仕事。
「ユーザー起点」や「サービス」という言葉だけがあり、利用シナリオや運用シナリオに落ちていない仕事。
使われるかどうか、売れるかどうか、運用できるかどうかを直視せず、機能追加や実証で前に進んでいるように見せる仕事。
手段と目的を気にしているようで、実際には外部委託、品質プロセス、組織都合、過去のやり方が目的化している仕事。
頭のいい人たちの正論により、自分の違和感が言葉の表面で処理されていく仕事。
これは、もう二度とやりたくない。
かなり強い言い方だと思う。
しかし、ここをごまかすと、自分が何を大切にしたいのかまで曖昧になる。
会社の場で話すなら、どう言い換えるか
この文章を、そのまま現職でこれまでの経験を振り返る機会で話すことはできない。
そのまま話せば、組織批判や愚痴に聞こえる可能性が高い。
ただし、職能発揮として言い換えることはできる。
私は、入社以降、外部委託を活用したシステム開発、スマートホーム向けIoTシステム、エネルギーマネジメント系のIoTサービス、AWS・IoTを含むクラウドシステム開発において、要求仕様、設計レビュー、評価、監査対応、ベンダー調整、運用観点の整理を担当してきた。
特に苦労したのは、技術、運用、事業、委託先との責任分界が曖昧な中で、システムとして成立させる条件を具体化することだった。
その中で、単に与えられた業務を処理するのではなく、ユーザー、導入先業務、異常時対応、保守、データ活用、セキュリティ、クラウド運用まで含めて、要求・仕様・評価観点に落とし込むことを意識してきた。
また、クラウド・IoT・データ・運用改善の観点を組織に持ち込み、従来の機器中心・委託中心の開発では抜けやすい観点を補ってきた。
その結果、量産開発、複数拠点導入、監査対応、特許につながる制御ロジック整理、データに基づく運用確認などに貢献した。
今後は、これまで培った「曖昧なものを構造化し、技術・運用・事業をつなげる力」を活かしながら、より作る・動かす・改善するサイクルに近い形で、組織に継続的な価値を還元していきたい。
結局、自分は何に苦労したのか
結局、自分が苦労したのは、仕事量そのものではなかった。
自分が信じている仕事観と、組織の仕事観のギャップに苦しんだ。
自分は、作り、動かし、観察し、直すことで、人も組織も強くなると考えている。
一方で、組織では、外部委託、品質プロセス、要求仕様、レビュー、調整によって成立させる仕事が中心だった。
どちらが完全に正しい、という話ではない。
ただ、自分にとっては、そのギャップが本当にしんどかった。
それでも、何も残らなかったわけではない。
違和感を、仕様に変えた。
違和感を、評価観点に変えた。
違和感を、運用シナリオに変えた。
違和感を、リスクとして言語化した。
違和感を、組織が議論できる材料に変えた。
それが、自分がやってきたことだった。
そしてそれは、たぶん、どこに行っても使える職能である。
ただし、もう一度同じ環境で同じ苦しみを味わいたいかと言われれば、答えは明確に違う。
私は、作り、動かし、観察し、直すループの中で仕事をしたい。
自分たちの中に、判断力と改善力が残る仕事をしたい。
そのことを確認するためにも、この苦しかった時間を、ただ忘れるのではなく、職能として言葉にしておきたい。
この記事は役に立ちましたか？
フィードバックはブログの改善に活用させていただきます