当社が現在開発中のRBO-Field（ロボフィールド）は、インフラ構築、設定作業、
障害復旧の自動化およびAIによる予兆検知をスマートに行えるソリューションです。
製品名の由来は、RunBook(運用手順書)のRBとDevOps(開発者と運用者)から
Dev(開発者)を抜いたOpsを付けた造語です。RBO-Fieldがあれば、運用手順書と運用者が開発者がいなくても自動化出来ると言う意図を込めて命名されました。
2021年7月にサービス開始を予定している本製品の開発責任者である宮坂賢一に、
どのように開発が始まったのか？製品開発の楽しさや、苦労についてシリーズで
インタビューしていきます。
■開発者の宮坂さんてどんな人？
製品開発についてお話していただく前に、宮坂さんについて
少し教えてください。宮坂さんは入社して何年になりますか？
宮坂：
2012年入社で、9年目(8年6ヵ月)になります。現在、別の製品開発を担当して
いる堀さんと、ほぼ同時期に中途で入社しました。入社した頃の社員数は70～80名位
で今の5分の1くらいのメンバー数でした。
東京生まれの横浜育ちで、趣味はサッカーです。昨年シニアリーグに参加したのですが、
コロナで思うように蹴る機会がなくて悶々としています。
好きな色はメタリックレッドです。仮面ライダーカブトのボティの色が気に入ってい
ます。ちなみに仮面ライダーも好きです。
宮坂さんは入社してから、どのようなお仕事をしているんですか？
宮坂：
入社してからほとんどクライアント先に常駐して、さまざまな開発業務に携わって
います。クライアントは、名だたる大手のSIerさんばかりなので、いつも良い経験をさせ
ていただいています。社内での勉強会などの開催も好きで、「Pythonの試験必勝塾」の
ようなメンバーの育成にも積極的に参加してきました。
■役員から突然の呼び出し・・・
ほとんどクライアント先に常駐されていたんですね。
そんな宮坂さんが、RBO-Fieldを開発することになったきっかけは？
宮坂：
2020年に役員に呼ばれて、「現場で培ってきた経験を基にして何か新サービスを作れ
ないか？」という話をされました。
その時に3年以上携わっていたのが自動化ツールの開発だったので、自動化のニーズや
得られた知見などの話をしたところ「そのフレームワークをベースにGUIをプラスして
製品にしたら良いんじゃない？」となり、トントン拍子に話は進みました。
これがRBO-Fieldのベースになっています。
これからも使いそうだから、フレームワーク化しておこう！
という話はよくあるんですか？
宮坂：
多くのプロジェクトでは、既存のフレームワークを使うことが多いと思います。
そもそも自動化ツールの開発なら、既存製品を選択することもあると思います。
今回、なぜ独自(フルスクラッチ)で作ろうとしたと言うと、明確な理由があります。
まず、私達がネットワーク機器やインフラ周りの知見が多くはなかったので、既存製品
や既存のフレームワークを利用した際に、ピッタリした製品が見つからず、帯に短し襷
に長しという状況になったり、ベンダーロック（開発ベンダーの独自技術に大きく依存
した製品やサービスを採用した時に、他のベンダーが提供する同種の製品やサービスへ
の乗り換えができなかったり、手間が増大すること）に見舞われる可能性がありました。
業務効率化のために、自動化開発の需要は今後も増加することは明らかなので、クライア
ントごとのニーズに合わせるには、既存のフレームワークを使った開発をすることに、
リスクがあると判断しました。プログラミング言語によるスクラッチ開発は大変ではあり
ますが、言語開発にしておけば、最悪力技でなんとかなる笑ということで、スクラッチ
での開発を決めました。現在もですが、当社はPythonの利用を推奨していて、当時はスキ
ルチェンジを推進していたので、Pythonの利用を促進したいという思いもありました。
■これからますます増加する「自動化」って？
なるほど！ところで自動化について詳しく教えてください。
宮坂：
自動化というのは、文字通り、人の手を動かさずに、自動でさまざまなタスクを
行えることです。私が開発しているRBO-Fieldは、インフラ構築、設定作業、障害復旧
を簡単な初期設定で、自動化できる製品です。また、障害を検知して、その障害に紐づけ
た復旧処理を自動実行する機能やサイレント障害を検知するためにAIを利用した予兆検知
も用意しています。
自動化によって、24時間、365日の監視負担軽減、運用コスト削減、作業時間短縮、作業
品質向上が見込めます。実はITの世界で、ヒューマンエラーというのは結構大きなコスト
であり、リスクなので、この部分を削減するための努力は各企業で積極的に取り組んでい
るんですよ。
RBO-Fieldはクライアント企業の内製化支援としてノンプログラミングツールとして設計
しているので、導入時の教育コストを抑えることも出来ると考えています。また、自動化
したい要件があるたびに開発を外部に発注しなくて済むことで、コスト軽減に繋がると思
います。
なるほど〜！自動でインフラ構築や設定作業ができるんですか？
宮坂：
はいそうです。もちろん、最初に各社の業務に合わせるためのワークフローを作成
することは必要ですが、運用手順書に記載されているコマンド、APIを基に、検証に必要
なマッチング方法を選択することでプログラミングが不要で自動化ツールが作成できま
す。人の手を動かすことを最小限に抑え、ミスを減らし、時間の短縮が可能になります。
宮坂：
RBO-Fieldは、上記のようにスタート時のワークフロー設定の操作が簡単なことも特徴の一つです。運用担当者の方は、日々運用手順書を元に作業をしていると思うので、運用担当者様がイメージしやすいよう、運用手順書に記載されている章立てや手順(=コマンド)を記載していくことで自動化ツールが作成できるんです。
なるほど、スタート時点の操作が簡単なのはとてもよいですね！
それなら今後、ITのさまざまな分野で自動化されていきそうですね。
それを見越して、現場でフレームワーク化しておこうという話が
あったのですね？
宮坂：
そうですね。当時一緒に設計していたメンバーと、「これ製品として売れるよねー！」なんて話をしていました。
ただ、当時はすっかりSES脳だったため、これで実際に製品(サービス)を作ろうなんて思考にはならなかったですね。
■SES脳と人月単価の限界
SES脳？！ってどんな脳、考え方なんですか？
宮坂：
SES（システムエンジニアリングサービス）の技術者として、長く現場に出て開発を
行いつづけて、いわゆる労働集約型の働き方が沁みついてしまった思考状態のことで
すね。
客先に出て、求められているものを開発するというスタイルに
脳が慣れてしまい過ぎて、現場で培ってきた技術から派生する
アイディアをサービス化するという発想がなくなっていました。
なので「なんで製品化しないの？」と言われて、「なんでだろう・・・」と思ったのが
正直なところでした。。
また、製品開発には投資が伴うので、勝手に「駄目だろう」という思考になっていたところもありました。
なるほど〜！SES脳、よくわかりました。もしかしたら当社には、
SES脳のせいで眠っている原石がたくさんあるのかもしれませんね！
ところで、役員は、なぜ新サービスを作りたいといっていたのでしょうか？
宮坂：
当社は、企業のサポートをするにあたって、今までは人月単価という考え方で、売上を
計上していましたが、このようなビジネスモデルだと、社員一人当たりの売上はある程度
決まってしまい、継続的に一人当たりの利益額をアップさせていくことが難しくなるんで
す。これから当社が事業を拡大していくためには、社員のスキルアップに伴った単価にし
ていくことはもちろんですが、向上した技術力を使って、製品をつくることで、人が働い
て稼ぐだけではなく、製品が稼ぐ事業も手がけることで、利益率をアップしていくことが
できるので、自社製品を開発したいと考えていたそうです。
自社製品の開発には投資が必要になりますが、長期的にみると技術力の向上や、お客様目
線でのサービス設計の仕方を身につけることができるので、製品という結果だけでなく、
その過程でもリターンは大きいと考えています。
お客様にとっても、当社メンバーの技術向上は喜んでもらえますし、当社が開発した製品
を使って安価に効率的にお客様のサポートができるようになれば、Win-Winの関係が築け
ると考えています。
このような良いスパイラルができて、当社の利益率が向上すれば、社員へは給料という形
で還元できるようになるので、既存のメンバーにとっても、これから入社を考えてくれる
求職者にとっても良い話になります。
役員の経営的な考えがあったと思いますが、なにより私としては、一開発者として、自分で製品を開発できることは、夢のようなことなので、役員から話があった際には、すぐに「やりたい！」と手を挙げたんです。
宮坂さん、ありがとうございました！
開発のスタート時点のお話を伺おうと思ったら、いろいろな話に繋がって、
とても面白かったです。
次回は、「なぜ、宮坂さんにチャンスが巡ってきたのか？」というお話を
お聞きしたいと思います。
