未経験からのチャレンジ!

※イメージです

新年度の慌ただしさも落ち着き始めたこのごろですが、皆さんいかがお過ごしでしょうか。コスモルートのTTです。

今回はコスモルート内にいくつかある社員同好会のうち、設立間もないゴルフ同好会の活動報告です。

同好会とは

コスモルートには社員の親睦を深めるため、会社公認の同好会があります。4人以上の会員を集めて会社に申請を出し、活動内容が役員会で認められると一定の基準で補助が出ます。

謎解き・スポーツ・ボードゲーム・釣り・バイクツーリング・ボルダリングなど、さまざまな同好会があり、会社帰りや休日に活動を行っています。(※人が集まりづらい2021年4月現在は活動を自粛している同好会もあります)

ゴルフ同好会発足

ゴルフ同好会は今年2021年2月に発足したばかりですが、それも昨年12月東京入社のIさん(24歳・男性)が中心になって立ち上げてくれました。彼はゴルフは全く未経験だそうです。

なぜゴルフかといえば、幅広く人とつながれる・ロケーションが気持ちいい・長くできるスポーツ、というところがあげられるでしょうか。決して松山英樹くんのマスターズ優勝を見てから盛り上がったニワカではありませんよ・・・

そして同好会立ち上げ早々、以前からお付き合いのある、とあるお取引先とコンペを組むことになりました。さっそく人とのつながりを作るチャンスです!

とはいえ、コスモルートのメンバーは全員平均スコア110~130という初心者です。かたや先方A社様は、4名のうちスコア80台が2名という強豪揃い(汗)。

いきなりラウンドしたら、会話を交わす暇もなくひたすら走る羽目におちいるので、まずは練習しましょう、ということで、同好会メンバーはシミュレーションゴルフに行こうと企画をしていました。

が、ちょうど東京にまん延等防止重点措置が適用されまして、あえなく中止。1回ぐらいシミュレーションしたからといって、ものすごく上達するわけではありませんが、集まる機会が失われたのはやっぱりちょっと残念でしたね。ま、しかたなし。

コスモルートゴルフ同好会初陣!

4月某日、ラ・ヴィスタ ゴルフリゾート(千葉)にて、午前7:46スタート。

朝6時の横浜集合で、Iさんは前日からホテル泊。準備は万全です。

週間予報でも天気は下り坂、当日の降水確率は100%…本当に土砂降りだったらツライ(涙)と思いつつ迎えた朝。日頃の行いの成果(!?)で、かろうじて降らず。


<密を避けての Enjoy Play!>

結果は!

コスモルートTさん(私ではありません)がグロスで何とか2位に食い込む健闘を見せました。

しかし、他メンバーはダース単位でボールをロストしたのでは?帰りはバッグが軽く感じるほどでした(泣)

コンペというよりも、お手合わせ願ったような形になりましたし(それは最初からそうだった・・・)案の定クラブを数本抱えて走ったりもしましたが(次打もまたとんでもないところへ行くから・・・)楽しかったですね。


<2位に入賞したTさん(左側) >

私はラウンドが終わって解散したあとで、地元の打ちっぱなしへ行って1人反省会をしてきました。次は走る距離が減るといいな~

おまけ


<優勝賞品は名古屋うまいもの詰め合わせセット 提供:コスモルート>


<コスモルート謹製ゴルフボール A社の皆さまへご進呈 ロストしないでね・・・!>

未経験からの果敢な挑戦!

振り返ってみると、冒頭に登場した経験ゼロのIさん、つま先立ちぐらいの背伸びをした状態での参加でしたが、成長幅、成長スピードは一番だったかもしれません。

同じ組のA社のスコア80台の方がフォローしてくれていましたが、後ろの組だったIさんのことをカートから振り返ると、ほぼいつも他のメンバーと一緒にグリーンに続く花道を歩いているではありませんか(そこまでどれだけ走っているかは前の組の私にはわかりませんが、努力は見えない所でするものということで)。

そしてそして、あとでスコアを確認したら、パー3のショートホールをダブルボギー(5打)であがっているではありませんか!

これは、コスモルート東京の未経験者採用にも通じるものではないかと思った次第です。未知の世界に勇気を持って飛び込んでみると、ぐぐっと自分の力が伸びるのを感じられると思いますよ。

ゴルフ同好会初活動の結果はこんな感じでしたが、参加メンバー全員が楽しい時間を過ごせました。密を避けつつ親睦を深められる屋外での活動がヤミツキになりそうです。

次回またラウンドしたら報告します!

【リーガレッジ】第2回法務・知財EXPOに参加しました

みなさん、こんにちは。瀬戸山といいます。コスモルートで、リーガレッジ広報を担当しています。

2021/4/7(水)から4/9(金)まで東京ビッグサイトで行われた「第2回法務・知財EXPO」にリーガレッジが出展したので、今日はそのご報告をしたいと思います。

リーガレッジはコスモルートが運営している契約書管理のクラウドサービスです。このブログにも、企画・開発を担当した星野のインタビュー記事を載せています。

リーガレッジ関連の過去記事はこちら↓

Legaledge(リーガレッジ)開発者インタビュー 第1回:Legaledgeって何ですか?

Legaledge(リーガレッジ)開発者インタビュー 第2回:Legaledge開発までのみちのり!

Legaledge(リーガレッジ)開発者インタビュー 第3回:Legaledgeを使ったナレッジマネジメント

法務・知財EXPOとは

リードエグジビションジャパン(株)が手掛ける大規模見本市のひとつです。「総務・人事・経理Week」として、8つのEXPOをひとまとめにして1箇所で同時開催されます。出展社は企業の総務・人事・経理に関わる製品やソリューションを提供している会社で、来場者はいろんな目的で情報収集をしに来ます。

たとえば、

・自社に導入するものを探す

・他社に紹介するものを探す

・自分たちの製品やソリューションと組み合わせるとよいものを探す

・ライバル会社の動向を見にくる

・メディア取材

などがあります。

今回私たちは、自社に導入する契約書管理ツールを探している方に向けて、リーガレッジを出展することにしました。

契約書の管理と活用をシームレスに連携するリーガレッジはこちら

なぜ展示会に出たの?―アナログの強さ

今回この「第2回法務・知財EXPO」に出展した目的は、「もっと多くの方にリーガレッジを知ってほしいから」の一言につきます。

リーガレッジは昨年7月に世に出てから、プレスリリースを打ったり、自社HPに載せたり、「企業法務ナビ」という企業法務向けのポータルサイトに掲載したり、オンラインでの宣伝活動をある程度してきました。

他にいくつか打ってきた施策の中で宣伝効果を実感できたのは、はがきによるダイレクトメールと、電話によるオンラインデモのご紹介でした。アナログなやり方ですが、はがきはメールより目に止まりやすい・電話はメールより人の行動を促しやすい、という感覚がありました。

とはいえ、1件ずつこちらからアプローチしていくのは、あまり営業効率がいいとは言えません。一気に大勢の方に見てもらえる機会はないか、ということで、ちょうど開催が企画されていた法務・知財EXPOへの出展を決めました。

実は第1回の法務・知財EXPOは2020年2月に予定されており、私たちはリーガレッジのローンチ前にそちらに出展するつもりでいました。しかし、それがコロナ禍で延期され、2020年9月に開催されると決まったときには、一旦出展取りやめの判断をしていました。

ですので、今回は満を持しての出展でした。

対面での説明・デモは情報量が多い

当日の来場者数がどのくらいなのかは、例年より予想し難いものでした。前年9月の来場者数は2万人程度と聞いてはいましたが、ご存知の通りこの1年で状況はいろいろと変わっています。

「オンラインでほとんど全ての仕事が片付く」という状況が日常化した中、わざわざ東京ビッグサイトまで足を運ぶ方がそんなにいるのか?いやまてよ、緊急事態宣言が明けたばかりで反動があるかもしれないし、もしかして例年より多いかも?しかし、報道を見れば第4波だの変異株だのと不穏な単語が…。

考えても仕方ないのですが、空振りだったらどうしよう、という気持ちは当日まで消えませんでした。

が、フタを開けてみると、その心配は杞憂でした。連日、リーガレッジのブースにはほとんど途切れることなくご来場者があり、説明に立っていた星野や担当営業の秋元だけでなく、最後の方にはお手伝いスタッフの予定だったRPAチームの安達・片岡も、立派にリーガレッジ説明員としてお客様にご案内ができていました。

私も3日間ブースに立って、お客様にご説明していたのですが、何名かに言われたのが「実物を見たいね」という言葉でした。

リーガレッジはクラウド上の契約書管理サービスなので、実物といっても見えているのはブラウザの画面ですが、その「実物を見たい」という言葉の内には、「自分の目の前で、リーガレッジが求めているものかどうか、確かめたい」という意味が込められていると感じました。わざわざ展示会にくるのは、やっぱり目の前で動くものを見て判断したいからなんだな、という気がしました。個人の感想ですが。

お客様の関心度合いも、機能や利点をパンフレットだけで説明しているうちは、ふーん、という程度だったものが、双方向にやりとりをしながらデモを行うと、おお、なるほどー、という感じに変わっていくのがわかりました。求められている情報を一気にお渡しできてるのかな、と思いました。

通常の営業活動では、リーガレッジはZoomなどを使ってオンラインデモを行っているのですが、こういう対面でのやりとりは、説明側も得るものが多いです。

お客様の視線(どこに興味がありそうか)や持ち物(他ブースもたくさん回っていらっしゃるか)、たたずまい(メモを取られるほど熱心か?など)など、非言語情報がたくさん入ってくるので、面白いなと思いました。

なお、オンラインデモはこちらから受け付けております

法務・知財EXPOが終わってみて

結果的に3日間で21,723人の方が来場し(※)、盛況でした。最終日は特に人出が多く、説明員は全員フル回転でした。ご来場頂いた方でこちらをお読みの方には、重ねて御礼申し上げます。ご来場ありがとうございました。

説明員の方々のリアルボイスです:

「お客様が興味を持った反応を見せられたときは、説明している側としても嬉しかったです。ただデモ待ちのお客様も多く、3人くらいに分身したい気持ちでした。」

「終盤ひっきりなしでデモが続いた時には、(デモ待ちのお客様をアテンドしてる)安達さんと片岡さんのことが嫌いになりそうでした」

「想像していた以上に活気のある展示会となり、嬉しい限りです。お互いマスクをして会話するので、ピーク時は軽く息切れすることも…。」

ちなみにリーガレッジとしては初の展示会出展だったため、ブース設営は手探りな部分が多く、だいぶその場で軌道修正しております。

設営時。デモ用パソコンとパンフレットラックしかないシンプルなブース

よそと比べてあまりにさみしいので、急遽ハイエースを借りて(!)オフィスから大きなモニタや観葉植物を持ってきてみたり。

棚にノベルティのメモ帳(ロディアとのダブルネーム)やロゴ入りボールペンを飾ってみたり。

ま、結果オーライということで…。

そして今はご来場いただいた方への御礼や、お申し込み頂いたトライアルの手続きや、アンケートの集計などを進めながら、合間にこんな記事を書いております。展示会は出展して終わりではなく、このあとどれだけフォローできるかなのですよね。

次は大阪!

次は11月に大阪で行われる展示会にも出展を予定しています。

今回の反省を生かしつつ、よりよいものにすべく計画を練っていきたいと思います!

契約書の管理と活用をシームレスに連携するリーガレッジはこちら

※リード・エグジビジョンによる速報 ※外部サイトに飛びます

当社の制度―フレックスタイム制―

こんにちは、コスモルートの西田です。

前回は、当社の互助会についてご紹介しました。
今回は、フレックスタイム制度についてお伝えします。

フレックスタイム制とは?

フレックスタイム制とは、「労働者が日々の始業・終業時刻、労働時間を自ら決めることによって、生活と業務との調和を図りながら効率的に働くことができる制度」※です。
(※厚生労働省 フレックスタイム制のわかりやすい解説&導入の手引き https://www.mhlw.go.jp/content/000476042.pdf)

フレックスタイム制のメリットは、定時での始業終業が難しい場合でも、うまくバランスを取りながら仕事を続けられることだと思います。
家庭の事情(子どもの保育や家族の介護等)や、健康上の理由で定期的な通院が必要な場合などがあるでしょうか。

新型コロナウィルスの対応もあり、フレックスタイム制を採用する企業が増えてきた印象です。
当社でも、フレックス制を採用しています。

コスモルートのフレックスタイム制

当社の就業規則によると、フレックスタイム勤務制は、すべての正社員に適用されており、清算期間の中で始業・終業時間を調整することができます。
当社では、午前10時から午後4時がコアタイムで、清算期間は、毎月1日から当月末日に至る1ヶ月と定められています。

コアタイムとは、「必ず勤務しなければならない時間帯」※です。(※同上)
フレックスタイム制では、その前後のフレキシブルタイムのどこを労働時間に充てるかを労働者が自分の裁量で決めることができます。
また、清算期間とは、「フレックスタイム制において労働者が労働すべき時間を定める期間」※のことです。(※同上)

なので、例えば、
「今日は、クリニックを17時に予約したので、16時に終業して、かわりに明日は少し長めに働こう」
といった具合に、コアタイムを含む時間で、月内で労働時間を自ら決めることができます。

私自身も花粉症の薬の処方箋をもらうために、この制度を利用しました。
フレックス制度がなければ、こういった場合にも一日休または半日休暇を使わざるを得ず、有給休暇を申請することになります。
個人的には有給休暇は有事のために取っておきたいので、フレックスタイム制はとてもありがたいと感じています。

ただし、プロジェクトやその繁閑等によっては、即時にフレックスな働き方ができるわけではないのでご注意ください。
また、コアタイムや清算期間は今後変更される可能性があります。

フレックスタイム制に関する法改正が行われたことや、新型コロナの影響により、こういった制度を採用する企業は、今後さらに増えていくのではないかと思っています。

今回は、コスモルートのフレックスタイム制について、ご紹介しました。

次回以降も、当社の制度や福利厚生についてご紹介できればと考えています。

「とりあえず動く」を卒業するためのアーキテクチャ入門編(2)

2.プロジェクトの変化に対応する

皆さんこんにちは。株式会社コスモルートでアンドロイドアプリの請け負い開発をしているT.Mです。

前章でKotlinの感触が少しだけ理解できたと思います。
javaで書くよりもコードが減り、バグも少なくなるのでお勧めです。
興味のある方は充実したオンラインコースやサンプルアプリの実装例がgithubに載っているので、それを元に勉強するのもおすすめします。
もしかしたら簡単なアプリを作ったことがある人もいるかもしれませんね。
単にボタンを押したら画面遷移するアプリから、電卓アプリやToDo管理アプリを作ってみるのは学習としてテッパンですね。
そういう場合は自分で要件定義をして仕様を決めているので混乱はありませんよね。


一方、実際のプロジェクトではあなたが要件定義に参加することは稀です。
中規模以上の開発(10人月~)になると、要件も複雑になり、それぞれ矛盾する仕様も出てくるでしょう。
完璧な人間は存在しないのと同様、完璧な仕様もあり得ません。
ウォーターフォール型のプロジェクトであれば、要件定義と開発期間を区切りますが、開発期間にも仕様変更って絶対ありますよね?
要するに、変更に強い開発手法を探ることが大事です。

2.1 プロジェクト構成を考えよう

改めて、変更に強いという意味を考えてみましょう。もう少し詳しく定義すると
仕様変更により生じるバグが少ないと置き換えても良いと思います。これをもう少し掘り下げると、

・変更によるコード修正の範囲が明確かつ限定的
・テストコードが書きやすい

が挙げられます。
他にも「コードの意図が伝わりやすい」、「ドキュメントが整備されている」など挙げられますが、上の2つに絞って考えてみましょう。

2.2コード修正の範囲が明確かつ限定的とは?

まず、「変更によるコード修正の範囲が明確かつ限定的」を意識したプロジェクトはどうすればよいでしょうか?
考えるヒントとして、Twitterのバスツイートだけを表示するアプリを作ることを考えてみましょう。

要件としては、簡単のため

・バスツイート=フォロアーの100倍のいいね!がついたツイート
・当日のバズツイートをリストで表示
のみ考えます。
さて、どうやって実装しましょうか?

まずはActivityに全部実装してみましょう。

```kotlin                            
                              
  class MainActivity: AppCompatActivity(){                            
                              
      //Retrofit(Httpライブラリ)                        
      val twitterService = Retrofit.Builder().baseUrl("https://twitter....").build().create(TwitterService::class)                        
                              
       override fun onCreate(state:Bundle?){                        
            super.onCreate(state)                
            setContentView(R.layout.activity_main)                
                            
            val listView = findViewById<RecyclerView>(R.id.list_view)                
            //TODO adapterの設定                
                            
            //コルーチン(メインスレッドでの処理を回避する目的)                
            GlobalScope.launch(context = Dispatchers.Main){                
                withContext(context = Dispachers.IO){            
                               
                    val info:TweetInfo = twitterService.get(LocalDate.now())        
                    val items = info.tweets.filter{ tweet->        
                        //フォロアー数×100以上の場合をフィルター    
                        tweet.likes>=info.followers.size*100    
                    }        
                    //リストを表示する        
                    listview.adapter = TweetListAdapter(items)        
                }            
            }                
        }                    
  }                            
                            
```      


サンプルコードなのである程度省略して書きました。
コードが何をしているかは理解できると思います。

しかし、急にクライアントから次の要件が加わったとしましょう。
①オフラインでも直近に取得した情報を表示したい
②データを取得している間は,ローディングを表示してほしい
③リスト上からいいね!を押せるようにしてほしい

上記の修正に対応するには、
①はデータベースを用意し、
②はactivity_main.xmlにローディングダイアログを用意、
③はいいね!を押すAPIを用意すれば良いでしょう。
しかし、確実にコードは分かりにくく、複雑になっていきます。

複雑さを回避する方法として、コードを分割すれば良いと考えるのが自然でしょう。
ではどうやって分ければよいのか、基準を設ける必要があります。
有名なMVC(モデル・ビュー・コントローラー)でも良いかもしれません。
この場合は
・Model アプリ特有のロジックのこと。
    例えば,バズツイートの取得,オフライン時にデータベースから直近のデータを取得など。
・View バズツイートのリスト表示,ローディングダイアログの表示など。

  • Controller ユーザーによる画面アクション。「いいね!」を押す動作。

でそれぞれフォルダーを分けてみると、恐らく次のような構成になると思います。

  • model/
    • TwitterRepository.kt オンライン/オフライン時を判断して、TwitterApiとTwitterDatabaseからデータを取得および、いいね!の反映。
    • TwitterApi.kt ツイートの取得と、いいね!を押して反映するAPI
    • TwitterDatabase.kt ツイートのデータベース
    • TwitterModel.kt ツイートのモデル(フォロアー数やツイート内容などを格納、バスツイートを判断)
  • view/
    • MainActivity.kt TwitterListFragmentのActivity
    • TwitterListFragment.kt リスト表示画面
    • TwitterItem.kt リストに表示される内容を格納
    • LoadingView.kt ローディング画面のカスタムView
  • controller/
    • PushLike.kt View.onClickの実装。TwitterRepositoryから、いいね!を反映する

実際にはもう少しファイルが増えると思いますが、機能ごとにうまく分けられている感じがします。
肝心のメリットについて考えてみましょう。
例えば、更に次の要件修正が入るとします。

・リツイート数も表示してほしい。

  • バスツイートの定義を、100,000ツイートで固定にしてほしい

「この要件、もっと早く知りたかったな…」って思いながらも、どのファイルを修正すれば良いか、初めてコードを見た人でも理解ができるのではないでしょうか?


1番目の修正については、TwitterItem.ktを修正、3番目はTwitterModel.ktを修正すれば良いと分かります。
これがMainActivity.ktにすべて実装してあったら、修正箇所の当たりを付けづらく、1つの修正が他の機能に影響するかも知れません。
上手くコードを分割した場合のメリットが分かりましたね。

さて、今回のタイトルが「アーキテクチャー入門」なのでMVCの概念を知らない前提で話しましたが、改めて見ると問題点もあります。
例えばcontroller部分ですが、わざわざonClickの実装だけ分けるメリットはあるでしょうか。
またデータ取得の途中でアプリを閉じた場合はどうなるでしょうか?


Android特有のライフサイクルが考慮されてない気がします。
Androidフレームワークに依存する部分とそうでない(いわばPureなkotlinで書ける)部分を分けなくてもよいでしょうか?
実際には上記に挙げた問題点は、ライブラリの発展とアーキテクチャーの洗練で補えますが、それは第3章に任せましょう。

今回は、
2 プロジェクトの変化に対応する
2.1 プロジェクト構成を考えよう
2.2 コード修正の範囲が明確かつ限定的とは?
について、説明しました。

次回は、テストコードについて考えていきます。

弊社秋元が執筆に参加した書籍が、3/23に発売されます!

こんにちは、株式会社コスモルートの西田です。

2021/3/23に発売される、弊社営業企画部の秋元隆が執筆に加わった書籍のご紹介です。

経営のイロハをDX化する「開発しないシステム」導入のポイント: パッケージで、管理業務を早く・安く改善

DX(デジタル・トランスフォーメーション)は、どの業界でも喫緊の課題となっています。
こちらの書籍では、余計なコストをかけないスピーディなシステムの導入について、そのポイントを説明しています。
これからの開発のあるべき姿を考慮する際に、大変役に立つ内容です。

執筆者の一人である、弊社の秋元から「執筆への想い」が届いております。

執筆への想い


 本書は、パッケージシステムの導入において、個別のシステム機能要件や業務とのギャップ部分を追加開発で補う、「日本型のシステム導入手法」を取り上げています。
 ムリ、ムダな追加開発への問題提起から、実例や失敗例を交えて「開発しないシステム」導入のメリットとポイントが書かれています。 
 私は前職で国内大手メーカー系SIerにて、全国のユーザへの基幹系業務システムの導入提案活動を行っておりました。 
 5年ほど前の話ですが、当時はクラウドの活用や、モバイル端末のビジネス利用等、テクノロジーの進化を感じることは多くあるのに、いざそれを企業に導入するとなると、その導入手法は過去のものから大きく変わっていない印象を持っていました。
 過去の導入手法とはつまり、要件定義を行い、設計、開発、テストという流れのいわゆるウォーターフォール型のシステム開発です。
 2021年現在も、パッケージシステムをベースにこのような工程を経て導入されるシステムが少なくないと考えています。 
 私も当時はこれが当たり前と思っていました。
 「追加開発を行わない」「極力業務をシステムに合わせる」という方針を掲げたプロジェクトをいくつか経験しましたが、気が付くと、この方針はどこかに忘れ去られ、現場からの細かい機能要望に対する追加開発の仕様を詰める打合せを行っている、ということも珍しくなかったからです。 
 2018年ごろより本書の略歴にも載せていただいた、パブリッククラウド型のERPであるSAP S/4AHANACloudのセールスを担当することになり、いままでの「Fit&Gap」ではなく、「Fit to Standard」による導入方式を学びました。
 「Fit to Standard」は、数多くの標準機能の中から必要なものを組み合わせて使うSAP S/4HANA Cloudの導入方式のことです。
 国内での前例がほとんどない導入プロジェクトだったため、大変なことも多くありましたが、改めて「開発しないシステム」の有用性を認識しました。 
 現在のコスモルートへ転職した後に著者の広川様とお会いし、上記の経験から「開発しないシステム」に強く共感し、共著者として参加させていただくこととなりました。

amazonでのご予約・ご購入は、こちら

是非ご一読ください!

書籍情報

経営のイロハをDX化する「開発しないシステム」導入のポイント: パッケージで、管理業務を早く・安く改善

広川 敬祐 編著
大場 みち子 監修
木村 俊一 監修
板井 実 著
緒方 瑛利 著
髙橋 昌太郎 著
倉本 真司 著
東 義弘 著
秋元 隆 著
渡辺 康雄 著
植木 貴三 著
上條 英樹 著

発行日:2021/03/22
A5判 / 276ページ
定価:3,300円(税込)
ISBN:978-4-502-37301-5

お問い合わせはこちらからお願い致します。

BizRobo! 開発面の特徴

こんにちは。
株式会社コスモルート RPAソリューション部の池田です。

前回は「RPAとは何か」という内容で簡単に説明させていただきました。
もしまだ、見ていない方がいらっしゃれば、まずそちらを読んでいただくと
良いかと思います。
https://blog.cosmoroot.co.jp/2021/02/04/rpa%e3%81%a8%e3%81%af%ef%bc%9f/

さて、2回目となる今回から、RPAツールの1つである「BizRobo!」について

・開発(ツールの操作)
・管理・運用
・運用する上でのサポート

の3回に渡って詳しく紹介していきます。

BizRobo!とは?

最初にまず「BizRobo!」とはどういったものか説明します。
これは、RPAテクノロジーズ株式会社が提供するRPAツールです。
アメリカKofax社のRPAツール「KofaxRPA」が元となっており、
日本語化などのカスタマイズがされています。

※RPAテクノロジーズ株式会社によるBizRobo!の紹介記事はこちら

大きく3つのラインナップがあり、
・ロボットの管理・運用が手軽に行えるサーバー型、
・パソコン1台から始められるデスクトップ型、
・インターネット上で環境構築できるクラウド型、
といったように企業形態に合わせた導入、スケールアップがしやすいRPAツールとなっています。

では今回の本題についてお話ししていきます。

BizRobo!の開発(ツールの操作)面の特徴

BizRobo!はロボットへの指示(ステップ)を作成し、それをつなぎ合わせることで自動化できるツールとなっています。

ロボットの開発(ツールの操作)と聞くと、「なんだかよく分からないけど難しそう…」と感じるかもしれませんが、
そんなことはありません。
ここで、実際に使用されている開発の画面を見てみましょう。

図1

BizRobo!の開発ツールの画面は図1のように、大きく
A(実際に操作する部分)、
B(手順がわかる部分)、
C(操作の詳細が表示される部分)
に分かれています。

開発では基本的に、Aのみを操作(主にクリックやメニュー選択)することで、
自動的にB・Cが作成されていきます。

現在の指示(ステップ)が知りたい場合は、
Bの指示(ステップ)をクリックすることで、
A・Cに詳細が表示されるようになっています。

例)図はwebの乗換案内を操作しているイメージで、Aの箇所にブラウザの画面が表示されています。
現在、Bの一番右の[EnterText]が選択されている状態で、
Aでは[到着]のオレンジ枠に対して文字を入力すること、
Cでは入力するテキスト「名古屋」を確認することができます。

このように、1つの画面で操作しながら実際の動きを確認していくことができるのです。

いかがでしょうか。
開発といっても、複雑なプログラミングコードを書く必要はありません。
「思っていたよりも気軽にできそうだ」と感じたのではないでしょうか。

加えて、多彩な変換機能をもっており、Excel関数のように
「実際に試してみないと結果がわからない!」ということはなく、
1つの画面で入力内容からその結果までを把握することができます。

図2

図2の”テスト入力値”(赤枠部)で値を変えることによって、
様々なパターンを検証することもできます。

他にも、
・特にExcelやWebの自動化がしやすくなっている点
・ロボット実行時にPCを占有されることがない点
など、様々な特徴があるのですが、
長くなってしまいそうなので、今回は割愛させていただきます。

今回はまず、BizRobo!の開発面に焦点を当てて紹介させていただきました。

・開発(ツールの操作)画面がわかりやすい
・多彩な変換機能をもっている
・Web操作、Excel操作が得意
・実行中でもPC操作が可能

など、親切な特徴が多く、
プログラミングに不慣れな方でも導入しやすいのではないでしょうか。

少し難しかったかもしれませんが、
これを機に興味を持っていただけたら幸いです。

次回の3回目では、BizRobo!の管理・運用面について紹介していきます。


私たちコスモルートはBizRobo!の操作方法の教育、サポートも行っております。
気になる方は下記からお問合せください。
https://www.cosmoroot.co.jp/support/bizrobo/

Legaledge(リーガレッジ)開発者インタビュー 第3回:Legaledgeを使ったナレッジマネジメント

星野:よろしくお願いします。

西田:よろしくお願いします。ついに、第3回目ですね。

星野:今回は、リーガレッジで行うナレッジマネジメントの方法についてお話しさせいていただきたいと思います。特に、法務チーム内でのナレッジマネジメントについては、私も前職で自分事として常々考えていました。その1つの方法論として、リーガレッジで「法務チームでこのようなナレッジマネジメントをすることができるのではないか」という提案をしたいと考えています。

西田:ナレッジマネジメントというと、知見の共有化と認識しています。リーガレッジでのナレッジマネジメントとは…?

星野:法務業務に限った話ではないと思いますが、業務の属人化は法務業務に携わる人々の間で広く課題だと認識されているものの1つだと思います。属人化はまったくの悪ではないと思いますし、法務のような専門職においては自身の知識や経験を高めていくことが重要であるという考え方もある程度は正しいと思います。ただ、組織に所属する者としては、個人のことばかりでなく組織を継続させていくという観点を持たなければなりません。そこで必要になるのがナレッジマネジメントという考え方です。

西田:法務の業務は、「専門的」、「難しい」というイメージがあります。共有化するにも、一筋縄ではいかなさそうです。

【リーガレッジを使った、縦と横のナレッジマネジメント】

星野:私は、ナレッジマネジメントには、縦と横という考え方があると思っています。

西田:縦と横、ですか。

星野:縦のナレッジマネジメントは、上長のもつ知識や経験を部下に共有することです。その目的は、部下の育成です。
一方で、横のナレッジマネジメントは職位に関係なく自身の持つ知識や経験を他のメンバーに共有することです。その目的は、チーム全体のレベルアップや標準化です。
縦と横のナレッジマネジメントのいずれもが、法務チームの継続、ひいては企業などの所属組織の継続につながるものと考えています。

西田:リーガレッジを利用すると、このナレッジマネジメントをうまく行える、ということでしょうか。

星野:はい、そのように考えています。
リーガレッジには「条文テンプレート機能」という、条文単位で雛形(テンプレート)を作成・管理することができる機能があり、これが法務チームのナレッジマネジメントにおける中核機能です。
一般的には契約書単位の雛形を作成していると思いますが、条文単位のテンプレートも用意することによって以下のようなメリットがあると考えています。

● 条文という小さい単位でテンプレートを作成できるので、アイディアや気づきをすぐにテンプレート化してチームに共有できる。また、共有されたテンプレートは条文単位で利用できるから、必要な箇所にのみテンプレートを利用すればよく、使いまわしが簡単。
● 一般条項のような複数の契約書に共通して利用される条項について、重複管理を避けて効率よく管理できる。
● 条項単位の小幅なメンテナンスで済むのでメンテナンスへの心理的な負荷が下がり、短いサイクルでアップデートできる。
● 契約書レビューの際に条文単位の比較検討が容易になるので、より精度の高いレビューが可能になる。

西田:なるほど。

星野:例えば、法務チームのメンバーが一人しかいない、いわゆる一人法務のチームに新しいメンバーが入ってくるとします。これまでは自分しかいなかったので仕事のやり方は自分の頭の中にだけあればよかったものの、これからは新メンバーに業務を教えていかなえればならない。しかもジュニアなメンバーなので、契約レビューの作法なども一から教えなければならない、という状況を考えてみます。

通常であれば、OJTとして一度契約書をレビューしてもらってそれを添削することを繰り返して徐々に知識や経験の継承を行うと思います。しかし、これだと添削や対話の時間を十分に取る必要があり、なかなか時間を割くことができないということがあるかと思います。また、新たにメンバーが入ってくる際に同じことを繰り返す必要があり、やや非効率です。

西田:そういうことは、起こりそうですね。

星野:そんな時にはリーガレッジの条文テンプレート機能を利用していただきたいです。メンバーを迎え入れる方は条文テンプレートを作成しておくことで、新メンバーにとってこれが「上長の知識と経験に基づく生きた教科書」になります。これを新メンバーはこれを参照しながらレビューをすることで、OJTを受けるのに近い効果を得られます。条文テンプレートにはメモも残せるので、テンプレート使用上の注意点なども残していただくとさらに教育効果の高いものになります。

また、上長は部下に課題を出して、あるテーマの条項の雛形を作成させる、という利用の仕方もできます。契約書単位の雛形だとハードルが高いですが、条文単位であれば課題として手頃でありつつ、一つの条文について深く理解させるという教育効果を得られると考えています。チームで使用できる雛形も増えるので、横のナレッジマネジメントにもなります。

横のナレッジマネジメントも、目的は意味合いは縦のそれと異なるものと整理していますが、条文テンプレートを利用した知識・経験の共有という点ではやることは同じだと考えています。

【社員を教育することで、長期的には会社の成長にも】

西田:リーガレッジは、短期的な業務の効率化だけではなく、ナレッジマネジメントを通じた社員の教育にも利用できるという例をご紹介いただきました。

星野:社員を教育することで、長期的には会社の成長にも貢献すると考えています。

西田:本日はありがとうございました。
星野:ありがとうございました。

前回のインタビュー記事こちらです。

新・契約ナレッジマネジメントシステム、LegaledgeのWebサイトこちらです。
デモのご希望などございましたら、こちらまでご連絡ください。

Paving the way – 未経験から英語×ITを実践!ー苦労話①

こんにちは!システムエンジニアのAです。

前回はブリッジシステムエンジニアの仕事内容について記事を書かせて頂きました。
その記事の最後に、ブリッジシステムエンジニアとして仕事をしている中で直面した、大変だったことをチラッと頭出しましたが、今回からは業務で個人的に苦労した話と、それぞれに対して(自分なりに編み出した)対応策を書こうと思います!

海外の人と働いたことがある方には、「あるある」と思いながら、また、これからグローバルな職場で働きたいと考えている方にはちょっとした心の予防策として読んでいただけると幸いです。

まず、私が個人的に大変だった/今も大変だと感じていることを以下にざっと挙げてみますね。

· 英語の訛り
· 時差
· 通訳
 · 日本語の難しさ
 · IT系の知識や経験不足
· 異文化コミュニケーション
 · 業務を抽象→具体に進めるか、具体の視点のみで進めるか

ブリッジシステムエンジニアの業務から派生するので、当たり前ですが、英語でのコミュニケーションに絡む苦労が多いですね。
上記のそれぞれを詳しく書いていくと記事のボリュームが大きくなってしまうので、今回は一番上に書いた英語の訛りについて書いていこうと思います。

【英語の訛り】

これは英語を第二外国語として話す人とコミュニケーションをとる上で、一度は苦労することではないでしょうか。

職場によるとは思いますが、英語でのコミュニケーションが必要な職場にいるのはアメリカやイギリス、オーストラリアといったネイティブの人たちだけではありません。
非ネイティブ圏出身で英語を第二外国語として話す人もいます。

話者人口比を考えるとおそらく後者の方が多いでしょう。

国際色豊かな職場の「音」とは…?

相当訓練を積んだ人でない限り、第二外国語としての英語は母語の発音の影響を受けます。

例えば日本人は「r」の発音ができない、と言われますが、これと同じことが他の非ネイティブ圏の人たちの英語にもおきます。
例えばインド人は(インドは公用語が多数あるのでその人の母語にもよりますが)「r」の音が巻き舌っぽかったり、中国人は「sh」など子音の音が強く、母音が弱く聞こえたりします(あくまで個人の感想ですが)。

ところが、私たち日本人が学校で英語を習う時にリスニングで聞くのは、ネイティブの英語です。
国内の英語の試験や公共放送もネイティブの英語です。

そうなると、耳がネイティブ向けの英語にしか慣れていない状態になってしまいます。

なので、訛りのある第二外国語としての英語を聞くと一部が聞き取れず、例えば、「I can submit the document to you by ///.」と相手に言われて、「うわ、一番大事なところが聞き取れなかった…!なんて言ったんだろう!?」とか一瞬考えている隙に、相手が2文目、3文目を話し終えてしまい、結果的に動揺しなければ聞き取れたであろうはずの箇所を聞き逃す、
なんていう事態になるわけですね。。。

この問題に対して、私は普段2つの対策をとっています。

【1つ目の対策】相手の英語の発音に慣れること。

経験上気づいたのですが、相手の英語訛りが独特で聞き取れない箇所が多くても、何度もミーティングや会話を重ねると聞き取れるようになります。

なので、最初は聞き取れなくても落ち込むことなく「まあそのうち聞き取れるようになるでしょう」ぐらいのかんじで構える。

そして、それでも聞き取れないところは「Would you mind repeating again?」や、もっと具体的に「You can submit the document to me by when?」みたいな感じで聞き返しています。
そう言えば相手ももっと簡潔に、もしくは少しゆっくり話してくれるので、聞き取れなかった箇所もクリアになります。

それでも聞き取れなかったら挫けずもう1回聞いています!笑

ちなみに余談ですが、この「You can submit the document to me by when?」という文章、「By when can you submit the document to me?」じゃないの?と思った方もいると思います。
「By when can you …?」は相手がまだいつ提出するかを伝えていないニュアンスが出ます。
例えば相手が、「I can submit the document to you soon.」と伝えてきた場合などに使えますね。
一方「You can submit … by when?」という表現は、既にいつ提出するかを一度明示しているが、こちらが聞き取れなかったというニュアンスが出るため、後者の言い方の方が今回の場合だと自然です。

【2つ目の対応策】相手が話したことをディクテーションし、その聞き取った内容を相手に見せること。

私の場合、普段のオンラインミーティングでは自分のパソコンのスクリーンを投影することが多いです。
その時にOneNoteやメモ帳を開き、相手が話したことをほぼ同時に書き出しているので、相手も自分の話したことが私にどう伝わったことを知ることができます。

この方法をとることで、例えば私が聞き取れなった箇所や聞き間違いをした箇所に指摘・訂正を入れてもらうことができるわけです。

ちなみに私の場合このディクテーションの時は相手の発言を一字一句丁寧に聞き取っているわけではありません。

基本的に相手が話すスピードの方が速いので、省略形を多用しながらメモみたいな取り方をしています。
例えば、Nancyが2月1日にドキュメントを提出できる、と言ったのであれば、「N can submit the doc to me 2/1」みたいなかんじです。
なんとなく、意味はわかりますよね。

あとは、ミーティング中は別の参加者がスクリーンを投影していることもあるので、そういった部分はミーティング後作成する議事録で発言者に確認をお願いしています。

以上2点が、私が普段とっている対応策でした。

もちろんこれらの対応策を読んで、いや、そもそもネイティブの英語ですら聞き取り切れないんですけど…、英語を聞き取りながら書き起こすなんて無理なんだけど、と思われた方もいらっしゃるかと思います。

わかります。
かくいう私も最初は全然できませんでした。

やはりそれなりの反復練習は必要になりますが、このあたりもまた別の記事で書ければいいなと思っています。

最後に大切なことを1つ

少し脱線しますが、自分が話す英語の発音にも意識を向けましょう。
やはりネイティブの発音に近い方が聞き手にも聞き取りやすいですし、発表者やミーティングのファシリテーターなどに採用されるチャンスが高くなります。

まあ、かくいう私も she と see の発音が一緒になっているのをこの前指摘されましたし、母音の/æ/や/ɒ/の音を区別して発音できているのか怪しいのですが。。。

以上が、1つ目の苦労話でした。

いかがでしたでしょうか?次回は2つ目の苦労話と、字数の余裕があれば3つ目の苦労話についても書いていこうと思います!

お楽しみに!

RPAとは?

はじめまして。
こんにちは。
株式会社コスモルート RPAソリューション部の池田です。

突然ですが、仕事をするうえでこのような作業に対して「面倒だな……」と思うことはありませんか?
同じ内容なのに複数のツールへの記載。似た作業の繰り返し。
単純作業ですが、量が多く時間が掛かるもの。1回あたりの時間は短くても、頻繁に行うもの。
業務内容は仕事によって様々ですが、誰もが一度は経験されたことがあるかと思います。

このような作業を簡略化できる1つの手段として
注目されているのが、RPAです。

私たちRPAソリューション部では「RPA」をメインに
お客様の業務効率の向上や、ひいては働き方改革を実現するために活動しています。

当ブログでは、「RPAとは何か」という話から開発の話まで。
私たちが関わっている仕事について少しずつ発信していきたいと思います。

ではまず、「RPAとは何か」というところからご紹介していきます。

RPAとは

RPA(Robotic Process Automation)は、直訳すると『ロボットによる処理の自動化』。
つまり、習慣化された業務をパソコン上のロボットを用いて自動化することを言います。

オフィスで働く人が、この習慣化された業務に割く時間は実に5割にもなるといわれています。
この作業の一部または全てをRPA(ロボット)に任せることによって
他の業務に集中できるようになります。

このロボットは、教えられた内容をそのまま正確に行います。
正しく教えることで繰り返し業務を任せることができ、業務の時間短縮に繋がります。
(ただし、間違ったことを教えてしまうと、その間違いを繰り返してしまいますので注意が必要です。)

それでは次に、ロボットに代行させる業務でRPAと相性が良いとされているものには
どういったものがあるでしょうか。

代表的なものとして、以下が挙げられます。

・一定のルールに従って繰り返す
・データが構造化されている
・Windowsやクラウドのアプリを使う
・業務が標準化されている
・プロセスに3人以上のリソースを求められる
・ヒューマンエラーが起こりやすい
・毎日実施しないとならない(所要時間が短い場合も含め)

上記のような業務から優先的に少しずつ教えていくことが一般的とされています。

コスモルートの取り組み

コスモルートでは、RPAツールの提供による業務効率化の提案や、
働き方改革を実現するため、以下の活動を行っています。

・ロボット導入のご提案(どのような業務に使えるか、導入ノウハウをお答えします)
・全社化サポート(一部門で使用開始したあと、社内でどう広げていくかを一緒に考えます)
・ロボットの操作を行うRPAツールの使い方トレーニング
・ロボット作成代行

いかがだったでしょうか?
このブログを通して、RPAについて少しでも興味を持っていただけたら幸いです。

次回は弊社がメインで取り扱っているRPAツール、「BizRobo!」について紹介していきます。

当社の福利厚生―互助会―

こんにちは。
株式会社コスモルートの西田です。

寒い日が続きますが、いかがお過ごしでしょうか。
今回は、コスモルートの福利厚生についてご紹介します。

前回は資格の合格一時金制度について書きましたが、今回ご紹介するのは、互助会についてです。

コスモルートの互助会

コスモルートには、互助会があります。
会員は、「互助会の目的に賛同したコスモルート社員」で、目的は次の2つです。
・会員の福利厚生の増進。
・会員相互の親睦とコミュニケーションの増進。

もう少し具体的な話をしますね。

毎月1000円を会員から徴収し、それを原資に互助会が主催する行事への給付や慶弔見舞金の給付が行われます。
徴収方法は給与天引きです。

慶弔見舞金とは、結婚した場合、子どもが誕生した場合、入院へのお見舞いなどで給付されるお金のことです。
一覧を掲載します。

・死亡弔慰金 最大100,000円
・災害見舞金 被災状況によりその都度協議
・結婚祝い金(同一人1回限りとする)100,000円
・出産祝い金 50,000円
・疾病見舞金(入院1週間以上)10,000円
・その他必要な事項 その都度協議

災害にあった場合にも給付されることがあるのですね。(私も知りませんでした。)
災害や病気はただでさえ嬉しくないイベントですが、互助会からの援助があれば、何かの足しにできそうです。

社員みんなの明るい未来の為に

互助会は、会社からの福利厚生というよりは社員同士の支え合いという側面の強い会です。
「社員みんなの明るい未来の為に」という、代表メッセージを体現する会でもあります。
慶弔見舞金給付のタイミングで、社内のグループウェアに「おめでとうございます。●●部◇◇さんに 第一子がお生まれになりました。互助会よりお祝い金を準備致します。 」といったようなメッセージが流れてくるので、社員同士の会話の糸口にもなりそうですね。

私も、グループウェアの慶事や弔辞を見ては一喜一憂しています。(笑)

次回以降も、当社の福利厚生についてご紹介できればと考えています。
資格の合格一時金制度のご紹介こちらです。

東京本社の熊手

ホームページこちらです。
採用のページこちらです。