業務ソフトウェア巡回日記 #1 RPAの野良ロボット対策

前提

このシリーズでは、私が展示会やセミナーを通して各社のプロダクトを見て感じた事を書いていきます。

このエントリは各社のプロダクトを通して得た考え方や気付きをアウトプットするためのもので、プロダクト自体のレビューではありません。

今回は、1月のJapan IT Week 関西でお話を伺いました、コムスクエア様のロボシュタインについてです。

ロボシュタイン

patrolclarice.jp

ロボシュタインは「RPAガバナンスを可能にするクラウド型RPA」として昨年の6月にリリースされました。

GUIベースでワークフローを定義して、サーバーでRPAを一括監視できるそうです。

コムスクエア様製のRPA製品だけでなく、他社製品WinActorやUIPathなどの他社製品も監視できるそうです。

展示会では「野良ロボットへの対策」というワードが気になってブースに立ち寄りました。

気づき

私がRPAのブームに感じていた違和感が、この製品によって解消されるかもしれないと思いました。

RPAツールの流行は2-3年前くらいからだったと思います。2018年の展示会では私が目についただけで4つの会社のブースでWinActorを見ました。

このRPAの流行については当初冷めた目で見ていました。

いわゆるRPA製品は、Excelのマクロ機能をデスクトップ全体に拡張したようなもので、ツールの実態は「デスクトップマクロ」と呼ぶのが適切に思えます。

そういったツールは当然有益です。

私も前職ではuwscでGUIベースの帳票ツールの効率の悪い部分を補って効率化したりしていました。

ただ、デスクトップマクロが企業の全体最適に繋がるかというと、むしろ業務のブラックボックス化からの業務フローの固定化に繋がるリスクも大きいのではないかと感じていました。

ロボシュタインはそういったRPA製品のリスクを、統合監視というかたちで解決するもののようです。

今後はどうなるか

ロボシュタインのような統合監視型が、「いわゆるRPA製品」のリスクを解決する唯一の手段かどうか、私にはわかりません。

全く違うアプローチでRPAの野良ロボットの問題を解消する製品が出てくる（あるいは既に出ている）かもしれません。

今後もコムスクエア様の製品も含めて業界の動向をウォッチし、取り入れられそうなものは取り入れていきたいと思いました。

「【大阪】SaaSを支える開発原則/DDD、プロダクトマネジメント、カンバン、技術的負債＠RAKUS」でLT登壇してきました

今回の発表テーマについて

ラクス様主催の勉強会の勉強会でLT登壇をしてきました

speakerdeck.com

rakus.connpass.com

勉強会のテーマ「ソフトウェア開発の法則・原則」にちなみ、

現職の社内システム開発で意識している「YAGNI」「機構と方針の分離」について思いを語らせていただきました。

YAGNIは非常に重要だけど、それを言い訳に単なる付け焼き刃になっていくと技術的負債が溜まりトータルのコストが増大するリスクがあります。

それを避けるための指針として重要な考えの一つが「機構と方針の分離」だと考えており、このテーマについては今後も掘り下げて考えていきたいです。

勉強会全体の感想

非常に丁寧な司会進行と案内で、といっても堅苦しい感じもなくフランク過ぎもせず、個人的に一番ちょうど良い空気でした。

ラクス様の勉強会は初参加で知り合いの参加者も殆どいない中でしたが、お陰様でLTもさほど緊張せずできました。

本編での4つの登壇は、ラクス様の各プロダクトの開発チームのエース級（想像）の方々がそれぞれの開発で直面した課題と、その解決にあたって大事にした「原則」についてのお話が中心でした。

割とどの現場でもおこりがちな問題についての取り組みが中心でした。

こういった開発者の問題意識をキチンとオープンにして改善に繋げていける風土は見習っていきたいと思いました。

LTでは個人開発もされているkintoneの開発者の方がモブプロについて語って下さいました。

（詳細はコンパスページを見た方が正確だと思いますのでそちらを御覧ください）

懇親会では、基幹システムのアーキテクトをされている方が声をかけて下さって、そこでも有意義な意見交換が出来たのも収穫でした。

発表した感想

やはり発表する事で得られるフィードバックは大きいです。

その場の質問やツイッター上での感想といった直接的なものだけでなく、発表中での表情の変化や頷きあるいは無反応や微妙な表情も、重要なフィードバックだなと肌身で感じました。

長年、色んな勉強会に出ている割にこれまで外部のアウトプットが少なかったのは去年の反省点としてあり、今年は意識して多めに外部発表の機会を作ろうと思っています。

当たり前ですがエンジニアが全員勉強会に参加して登壇すべきとは思っていませんし、コードやプロダクトこそ最大のアウトプットだとも思うのですが、 今は外部発表の機会を増やしていくのが自分にとってプラスになる時期だという直感があります。

業務エンジニアの2020年1月のふりかえり

ふりかえり

目標は立てただけでは意味がないので、今年は毎月ふりかえりをしていこうと思います。

目標①自社内製基幹システムを全部署に展開

昨年末に新規システムをファーストユーザーの1部署を対象にリリース。今年はこれを全部署に展開していく予定

1月は2部署目にリリース完了。3部署目の業務資料も入手して分析も開始した。 基本的には、データと帳票レイアウトの追加、および細かな項目追加のみで対応できるため、1部署あたり分析含めて1ヶ月とかからなそうな手応えがあり。

そうなるように設計して昨年9ヶ月かけて設計・開発してきたとはいえ、実際に想定通り進んでくれてホッとしている。

目標②30分以上の外部登壇を2回以上

今年の登壇の第一弾として、2/5にラクス様主催の勉強会でLT登壇を予定している。

rakus.connpass.com

初参加で初LTなのだけど、落ち着いてやりたい

目標③読書年100冊以上

1月の実績は15冊（小説3冊、技術書 4冊、業務関係4冊、その他4冊）。

良いペースだけど年初から飛ばしすぎたと思う。

2月以降は少しセーブしてアウトプットに時間を割きたい

目標④英語・数学のインプットを原則毎日

英語は31日中24日。数学31日中23日やった。

週5くらいのペースを維持できているので良いペースだと思う

勉強内容は、英語はTOEICの公式問題集数学は数学検定のテキストを数問ずつやる事に限定している。

問題集一冊を一周したタイミングで、試験を受けてみるかどうかを検討する

目標⑤中小企業診断士1次試験3科目以上合格

今月はサボりがちになってしまった。

毎日の分量や毎月の進捗の目標は定めてなかったのが敗因。

2月以降は、一ヶ月で1科目ずつ仕上げるのを目標として進めていく

目標⑥アルコール摂取を年8回まで

1月、新年会や懇親会には3回ほど参加したが、全てノンアルコールビールやソフトドリンクで済ませた。

良いペース

身体を壊したとかではないので、飲み会には誘って下さい

目標⑦学術論文読むのを習慣化

これは全くできていない。

調べ物でググるときに、Google Scholarを使うというところから始めてみようと思う。

目標⑧個人製作アプリリリース

これも進捗ゼロ。個人ブレストを少しやった程度。

作りたいものを探すとかじゃなくて、なんでもいいから動くものを作る方が良いのかもしれない。

目標⑨その他目標に縛られず柔軟に対応

今月は特になし

全体を通して

順調なものから全く動いてないものまである。

動きが遅いものも、概ね次のアクションを明確にできていってるので良いのだけど、個人制作アプリについてはだけは次のアクションすら見えてないので何らかテコ入れが必要だ。

業務エンジニアの2020年の目標！

今年の目標

ツイッターでは既に出しましたが、今年の目標をあらためてブログに投下します。

まずは昨年の実績の振り返り

昨年の公私含めた主な実績は以下です

• 第二子誕生
• 自社内製基幹システムを開発・リリース
• スクラムマスターとしてスプリントを2W✕24スプリントまわす
• 関Javaで30分の登壇（業務システムについて）
• 中小企業診断士1次試験2科目合格
• 統計検定4・3級合格
• 書籍を104冊読了

特に、基幹システムを企画段階から、アーキ選定・基本設計・内外との調整・実装・リリース準備まで一気通貫でやれたのはビジネスマン・エンジニアとして自信に繋がりました。

勿論自分一人だけの成果じゃないですが（もう一人のエンジニアの方がメッチャ出来る方で技術面でハマったときに死ぬほど助けられました）。

まだまだ課題も山積みで機能も少ないので今年も引き続きこのプロダクトを育てていきたいです。

本については昔から大好きで、人生も折り返し地点に近いところまで来たので、読書記録のつけかたを見直す事でスピードアップしました。

今年の目標

今年の目標は以下の通りです。

多そうに見えますが、昨年の実績を見て達成可能なラインにしました。

2020年の目標
・自社内製生産管理システム全部署展開
・個人製作アプリリリース
・中小企業診断士1次試験3科目以上合格
・英語・数学のインプットを原則毎日
・アルコール摂取を年8回まで
・読書年100冊以上
・30分以上の外部登壇を2回以上
・学術論文読むのを習慣化
・その他目標に縛られず柔軟に対応

— つねまげ (@tunemage) 2020年1月3日

• 自社内製基幹システムを全部署に展開
• 個人製作アプリリリース
• 中小企業診断士1次試験3科目以上合格
• 英語・数学のインプットを原則毎日
• アルコール摂取を年8回まで
• 読書年100冊以上
• 30分以上の外部登壇を2回以上
• 学術論文読むのを習慣化
• その他目標に縛られず柔軟に対応

目標は立てただけでは意味がないので、定期的に棚卸ししていきたいと思います。

v-kansai Vue.js/Nuxt.js meetup #13 に参加してきました

概要

1/15（水）に開催されたVue.jsのミートアップに「ブログ書く枠」で参加させていただきました。

vuekansai.connpass.com

参加者が登壇・LTを行い、それをベースに質問や意見を交わし合う、ミートアップ形式の勉強会です。

今回は登壇４・LT1の構成でした。

毎月開催で、現在は大阪と京都で原則交互に開催されているそうです。

なお、大阪での会場提供および主催をしてくださっている株式会社chatboxの @_mikakane 様は、Web開発者向けのハンズオンイベント等も同会場で開催されてらっしゃるそうです。

こちらも機会あれば参加したいです。

私の参加のモチベーション

昨年4月に開発開始し、12月にリリースした内製の社内基幹システムが、Spring Boot + Kotlin(一部Java) + Nuxt.js + TypeScript（大半JavaScript）という構成になっています。

チームには、Vue/Nuxtの経験者はおらず、公式ドキュメントや各種情報を頼りに手探りで開発をしてきました。

今後のシステムのバージョンアップに伴い、Webや書籍の情報のみでは様々なトレードオフを判断するのに厳しくなってきており、意見交換できる場所を求めて参加しました。

全体の雰囲気

私は今回が初参加で知人も1人もいない状態でしたが、いくつか質問や社内の事例などを発言しました。

慣れている常連の方ほど発言が多い傾向は当然あるものの、いわゆる身内のりという印象は全くなく、ディスカッションにも参加しやすい雰囲気でした。

登壇者やスタッフの募集も随時されているようで、新規参加者も入りやすいコミュニティなのではないかと思いました。

後の懇親会にも参加させていただきました

（私が出来ればもう少し話を聞いてみく「懇親会はありますか？」と聞いたので、懇親会の流れになった感があった気がします。

気を使わせてしまっていたらすいません＾＾；）

発表内容

以下、今回の発表についての簡単な感想です。

詳細はイベントページのリンクを辿っていただければと思います。

登壇①「Vue.Draggable で手軽にリストを ドラッグ&ドロップで並び替え」 @azuki_eater 様

speakerdeck.com

ドラッグドロップ機能をVueと同期できるライブラリの紹介です。

こちらは弊社のシステムでも利用しているのですが、未使用の機能など知らなかった情報も含まれていたので助かりました

登壇②「頑張らないオレオレVuex規約を作った話」 @is_ryo 様

speakerdeck.com

Vuexの規約の事例紹介です。

「Vueは大規模になるとカオス化するリスクがある」みたいな話はよく聞きますが、

特にVuexはどういう場合にどの程度使うか開発者に委ねられているため、放っておくとカオス化するリスクは私も感じます。

Nuxtだと少しマシですが、それでもどういう情報をどこまでStoreするかは一定のルールが必要になりそうです。

弊プロダクトはメインの保守担当者が私一人（最大時も3人）なのでまだ明文化された規約はありませんが、やはり指針だけでも早めに明文化する必要はあるなと認識しました。

登壇③「Introduce to Pinia」 @chan_kakuz 様

slides.com

「Vueの次期バージョンの目玉機能のComposition APIを利用してStoreがどうあるべきか追求するためのプロジェクト」だそうです。

このあたりは勉強不足でついていけませんでしたorz

Vue3系への移行は今年中には検討する事になるため、それとあわせて勉強したいと思います。

登壇④「Nuxt.js と Light house CIについて」 @_mikakane 様

Light houseは、アクセシビリティやSEO対策などの状況を解析してくれるツールです。

登壇内容はそれをCIに組み込んだ事例紹介でした。

非機能要件をある定義したい場合に便利との事でした。

私は社内システムという事に甘えて、このあたりは割といい加減にすませてしまってますが、パフォーマンスやアクセシビリティは社内でも重要なので、知見はためておきたいです。

LT①「 Vue.js & UIKitでSSAEのポートフォリオ作成が爆速になる」 Toshiki Ohnogi 様

speakerdeck.com

UIKit（CSSフレームワーク）を採用した経緯などについてのLTでした。

発表者の方は、ドメイン分析などにも取り組まれてるらしく、個人的にはそれについても今後聞いてみたいです。

今回の気づきと今後のアクション

皆様のお話を聞いてると、弊社のチームでトライ・アンド・エラーをしていた箇所が、皆様も当初迷われたようで、やはり技術コミュニティの存在は重要だなと思いました。

弊社のプロダクトで現在進行で問題になっている事についてもいくつかヒントをいただけたので、実際の改善に繋げていきたいと思います。

そして、現場で得られた知見をまた別の機会に発表してコミュニティにも還元していきたいと思います。

QC検定3級のテキストを読み終えました

QC検定3級のテキストを読み終えました。

この一冊で合格! QC検定3級集中テキスト&問題集

QC検定の勉強のモチベーションは以下の2点です

• 製造業の会社で生産管理システムを開発しているため、製造業の管理者の人達の業務について理解する事を期待して
• 今年受検予定の中小企業診断士の「運営管理」と重なる部分があるため、周辺の理解を深める事を期待して

QC検定の教科書は多数ありましたが、書店でざっと見た中でロングセラーで読みやすそうなものを選択しました。

全体は4章構成で、3章までがテキストで4章が本番形式の模擬試験でした。

QC検定の勉強は初めてでしたが、 統計の知識は昨年受験した統計検定3級の勉強で、製造業の品質についての知識は実務で、QC七つ道具の知識は基本情報技術者試験や中小企業診断士の勉強で、ある程度知っていたのでスムーズに読めました。

優先度は高くないため受験するかどうかは迷っていましたが、 4章の模擬試験は8割以上正解できていたので今年の3月に受験する事にしました。

今週にでも過去問題集を購入して、当日までに一周したいと思います。

「他人の成長に期待するな」について考えている事

「他人は成長しない」という経験則

私たちは、よく部下や同僚に対して「もっと積極的に取り組んでほしい」と考えます。

また、家族や友人・知人に対して「悪い癖をなおしてほしい」と考えます。

私たち自身も、周囲からそのように思われていると思います。

残念ながらその願いは、かなわない場合が大半です。

遠回しに、こうした方が良いと伝えても、気づいてさえ貰えないでしょう。

かといって、ストレートに正論をぶつけても、その時は理解してくれてなおったような気がしても、数日後には元に戻ります。それでもまだ良い方で下手をすると逆ギレされてお互い嫌な思いをするでしょう。

こういった経験則から得られる結論は、概ね以下のようなものです

• 人はなかなか変わらないし、成長しない。
• 考え方や習慣というものは生まれつき、もしくは長い年月をかけて身についたものなので、口で言っただけで簡単には変わらない。
• 口で言って気づくのなら、最初から自分で気づいているだろう
• そもそも、他人に成長してほしいとか変わってほしいとか期待するのは、自分の考えの押し付けであり傲慢なのではないか
• そんな無意味な努力をするよりも、適材適所で得意なところを活かして組織や人間関係を円滑にまわす方が有意義だ
• それでも無理なら、距離をとるなり縁を切るなりして別の道を歩むしかない

「人は成長する」という事実

一方で、「人は成長しない」という命題はどう考えても間違っています。

反証はいくらでもあります。

これまで出来なかった事が1年足らずで出来るようになったりしますし、驚くほど知見が広まり考えが深化した人はたくさんいあす

「人は成長する」という事実と、「他人は成長しない」という経験則とは矛盾しているように思えます。

成長するには条件がある

人が成長するには、少なくとも以下の3つの条件を満たす必要があるでしょう

• 本人に「変わりたい・成長したい」という意思がある
• 変わるための具体的な行動をとっている
• その努力の内容が適切である

これを他人に動機づけるのは不可能じゃないにしても難しいです。

「痩せないと健康を害して苦しむ事になるから運動した方が良い」とか「もっと勉強しないと会社の経営が傾いた際に今の生活レベルを維持できなくなる可能性がある」とか他人を説得しても、相手が具体的な行動に移る事は非常にマレだというのは経験が物語っています。

相手に動機づけを与えて適切な努力ができるように指導する事が、自分に出来るかどうかをよく考えないといけません。

それもないままに「こうした方が良いと」あれこれ口出しするのはただの無責任です。

結論

基本的に他人は変わらないし、他人の成長を前提にするのはお互いにとって不幸です。

それをするくらいなら、自分自身が成長する方が簡単です。

一方で相手に成長する意思があり、そのための努力をする見込みがあるのであれば、それを支援する価値がありそうです。