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

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

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

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

コスモルートの互助会

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

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

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

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

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

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

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

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

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

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

東京本社の熊手

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

Paving the way―未経験から英語×ITを実践!―ブリッジシステムエンジニアとは?

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

前回はこの英語×ITブログを始めるにあたって、簡単に自分のことを紹介させていただきました。
今回は、コスモルートに入社してから現在に至るまで、ブリッジシステムエンジニアとしてどのような業務をしてきたか、紹介させていただきます!

ブリッジエンジニアとは???

まずブリッジシステムエンジニアと聞いて、皆さんはどのようなエンジニア像が浮かびますか?

…外国人エンジニアと英語でコミュニケーションを取りながらシステムを開発する人?
…日本と海外を行き来しながらプロジェクトを推進していく人?

おそらくいろいろなイメージがあるかと思いますが、ひとまずWikipediaを見てみると、以下のように定義されています。

『グローバルなプロジェクト環境下において、ITと異分野・異業界との架け橋となり融合を行い、製品やサービスをプロジェクトチームとして生み出す人材を指す。』

おお、何だかかっこいいですね(笑)

さらに読み進めてみると…。

『「ブリッジシステムエンジニア」はITと異分野・異業界の架け橋として、「異分野とITの融合」をチームとして行うことにより重点を置いている。また、プロジェクトチームが自然言語の違うグローバルなチームで構成される環境下においては、チームとしての生産性向上・品質確保を担保したデリバリを行うためのソリューションを展開しながら自然言語の壁を排して情報の橋渡しをすることが求められる。そのため、一般的なシステムエンジニアと比較して、ビジネス分析、交渉、スコープ&デリバリ、市場特性に合わせた自然言語の実践基礎能力がより要求される。』

おおお、いろいろスキルを求められていますね(笑)

と、ざっと引用してみましたが、ブリッジシステムエンジニアとは、外国人メンバーと外国語を駆使して協力しながら、製品やサービス開発・エンハンスするPM・エンジニアを指しています。

このブリッジシステムエンジニアという言葉自体は比較的新しい単語なので、もしかすると今後意味が変わってくるかもしれませんね。

ただ、Wikiの引用と比較しても、私がこれまで1年半携わってきた業務・役割によく当てはまっているなという印象です。

ブリッジエンジニアとして、プロジェクトに参画!

ここから私が携わってきた業務・役割について話を進めますが、私はこれまで2つのプロジェクトにブリッジシステムエンジニアとして参画してきました。
1つは去年1年弱参画していた、大手自動車メーカー向け基幹系業務システムの開発・導入プロジェクト(要件定義・基本設計)、
そしてもう1つは今年の夏から参画している、別の大手自動車メーカー向けBtoC向けアプリ開発のプロジェクト(要件定義・基本設計・開発・テスト)です。

どちらのプロジェクトも発注元は自動車メーカーの日本本社であり、直接は日本のベンダーに発注しているため、クライアントならびに私のチームメンバーは主に日本人で、日本語でやりとりをしてきました。ただ、開発の発注先は外国人チームとなるため。ここからコミュニケーションが英語となり、私の担当領域となります。
この一緒に働いてきた外国人チームについてさらに詳しく話すと、1つ目のプロジェクトではインドの開発ベンダーのインド人エンジニアたちと仕事をし、現在のプロジェクトではアメリカと中国の開発ベンダーとタッグを組んでいます。
インド人エンジニアたちはそのプロジェクト発足中は日本に滞在しており、直接口頭でコミュニケーションをとることが多かったのですが、今回のプロジェクトは COVID-19の影響で開発チームメンバーがアメリカまたは中国から移動できないため、メールやチャット、ビデオ会議ツールを使って、遠隔でコミュニケーションをとっています。

では、彼らと具体的にどのような業務を行ってきたか、についてですが、両方のプロジェクトで共通していた業務が非常に多く、以下が挙げられます。

・外国人メンバーがいる会議での英語でのファシリテーション
・日本語・英語の通訳
・英語での議事録作成
・英語でのメール・チャット
・日本語または英語でのドキュメント作成
・日本ベンダーチームでの要件定義・基本設計とそれ以降のフェーズの計画
・開発ベンダー側へプロジェクト状況・要望の英語での説明
・開発ベンダーとの英語での技術的な要件定義・基本設計とそれ以降のフェーズの計画
・開発ベンダー作成の成果物レビュー・英語でのフェードバック
・開発ベンダーの進捗・課題のクライアント・日本ベンダーチームへの日本語での報告
・IT知識のキャッチアップ (自習)

なんとなく、イメージが沸いたでしょうか?
主に外国人チーム・メンバーとの窓口としての業務も多いですが、普通のシステムエンジニアと同様に日本語での要件定義や基本設計も行っており、どちらの業務も刺激的で面白いなと思っています。

また、私の担当領域は上流工程が多いですが、担当工程によっては外国人エンジニアたちと一緒にコードを書くようなブリッジシステムエンジニアの方もいらっしゃるかと思います。

まとめると…

ただ、どの工程にせよ、これらの業務は外国語ができればいい!というものではありません。
先ほどのWikiからの引用にも書いてありましたが、ビジネス分析能力や交渉力だけでなく、プロジェクト調和能力、チームリード力など様々なスキルが必要となってきます。
また、そのスキルが足りなかったばっかりに私自身大変な状態に陥ったこともあります。

次回は、業務で私が個人的に大変だった話、またその経験から学んだブリッジシステムエンジニアに必要なスキルについて、お話しいたします。

次回もお楽しみに!

前回の記事こちらです。

オランダの大学のオフィス内の写真です。

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

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

僕自身コスモルートは2社目で、前職はAndroidアプリの開発や機械学習の業務を行っていました。
その後コンサルタントとして入社後、2年程上流工程を経験してます。
なので仕様変更に対する上流と下流(そもそもこの呼び方が良くない笑)のせめぎ合いや、「これ要件に書いてないですよ?」や「そもそも要件というより前提だよね?」といった喧嘩会議を両側から経験してきました。
要件定義で完璧に仕様が決まり、未来永劫変更が無い—そう断言できれば安心して開発ができます。
しかし実際のところ、プロジェクトは生き物のように変化し、仕様が固まるということは殆どありません。
選択肢は2つ。
1:「仕様が確定しないのが悪いんだ!」と悪態をつく
2:プロジェクトの変化に柔軟な開発を目指す
あなたはどちらを選びますか?

1.Android/Kotlin再入門

この章ではAndroidをJavaでしか書いたことが無い人向けのKotlinの紹介と、僕のように数年開発現場を離れていた人向けのアップデート事項をまとめました

1.1 Kotlinとは?

もともとAndroidアプリの開発にはjavaが必須でしたが、2019年でのI/OではKotlinを第一言語とし、公式サポートもこれまで以上に充実させるとしました。
言語的な特徴はいくつかありますが、中でもnullを上手く扱い、エラーを発生させにくい仕組みが受け入れられました。
まずはそれをお定まりのHelloWorldで見てみましょう。

val str:String? = null
print(str?:”Hello world”)

`?`が沢山みえますが、これがnullを管理する印です。
具体的には`String?`で定義された変数は**String型**と**null**を許容します。
これはjavaの**String**に相当します。
2段目の`str?:”Hello world”`は**str**がnullの場合、**Hello world**を出力するよという意味です。
一般的にはnullをなるべく除外したいので、?はあまり使いたくありません。
Javaから受け取った値をKotlinに渡す場合や、サーバーからのレスポンスでnullが入り込む場合などは`Type?`で変数を定義します。

変数がnullでない時のみ、関数を適用したい場合があります。
そういう場合は`let`関数がおすすめです。

入力されたパスワードが正しいか判定する場合は、

val input:String? = "password"
val isHelloWorld :Boolean? = str?.let{checkValid(it)} // let内のitはnullでない

と書けば、`if(input!=null) … else …` のような条件式は不要で、簡潔に記述できます。

1.2 変数の定義方法

変数の定義の仕方について触れておきます。
javaでは変数は2種類で、代入可能なもの(可変変数)と不可能なものです。
kotlinも同じく可変変数と不変変数があり、それぞれ以下の様に定義します。

val str = “Hello, world” //不変
str = “Hello, kotlin” // 代入不可能なのでコンパイルエラー
var str2 = str
str2 = “Hello, kotlin” //エラーにならない

kotlinに限った話ではないですが、なるべく不変変数を使うようにしましょう。
たとえばユーザーの生年月日を定義する場合、`var birthday:LocalDate`とはしないはずです。
見た目は若くできても実年齢は変わらないので、不変であるべきです!

一方で、例えば「パスワードを変更する」や、「パスワードを再登録する」などのユーザーアクションが考えられるので、パスワードは可変です。

var password:String

ですね。

同様にニックネームや好きな食べ物などの情報は可変、生まれ故郷や性別は(特別な事情がない限り)不変として良いでしょう。

これで変数の定義方法については終わります。

ただし`var password`には少々問題があります。
このままだと、`0000`や`cosmoroot`のような安易なパスワードが入力される恐れがあります。
そこで、登場するのがjavaでお馴染みのsetter/getterです。

1.3 変数のカプセル化(setter/getter)

例えば開発要件として、**パスワードは4文字以上8文字以下とする**と書いてある場合はどうしますか?
更に**パスワードは暗号化してサーバーに送る**という要件も追加されました。
そこで役立つのがsetter/getterというカプセル化の概念です。
実際にkotlinのコードを見てみます。

var password:String? = null
set(newPass:String?){
// 4~8字以内の場合は
val withIn:Boolean? = newPass?.let{IntRange(4,8).contains(it)}
//newPassを代入
if(withIn) field = newPass
}
get = hashed(field) //Hash化関数
password = “password”
print(password) // Hash化されたパスワードが出力される
password = “tooLongPassword”
print(password) //条件に満たさない場合は、nullが出力される

コード内コメントにある通り、**4文字以上8文字以下**の条件を満たさない場合は代入できませんし(setterによる入力の制限)、出力はHash化されます(getterによる出力の制限)。
ただし、まだ`null`が残っていますね。
改善の余地がありますが、次のクラス定義にまわします。

1.4 クラス定義

上で見てきたユーザー情報はクラスにすることができます。

例として

– ユーザーID
– パスワード

をもつ`User`クラスを定義しましょう。
kotlinでは

//Userクラス定義 uidは不変
class User(val uid:String,var password:String)
val user:User = User(“cosmoroot”,”password”)
print(“$user.id”) // cosmoroot と出力

と書けます。
javaと雰囲気が似てますが、クラス変数`uid`および`password`をコンストラクタで定義できるのが便利ですね。
更にpasswordは勝手に変更されては困るので、改良します。

class User(val uid:String,_password:String){
var password:String = _password
set(newPass:String){
val withIn:Boolean = IntRange(4,8).contains(newPasss)
if(withIn) field = newPass
}
get = hashed(field) //Hash化関数
}
val user = User(“cosmoroot”,”password”)
user.password = “tooLongPassword” //無効なパスワードを代入しても
print(user.password) //passwordと出力

クラス化によってpasswordはUser生成時に指定すればよいので、`null`は削除できました。
ただし、Userクラスにしたので、パスワードはsetter/getterで定義するよりも、**changePassword**関数を定義した方が分かりやすいですね。

/***
@param _passowrd:パスワード
private変数もコンストラクタで定義できる。クラス外からは参照されない。
*/
class User(val uid:String,private var _password:String){
fun changePassword(newPassword:String):Boolean{
return if(IntRange(4,8).contains(newPasss)){
_password = newPassword
true
}else false
}
}
val user = User(“cosmoroot”,”passoword”)
user.changePassword(“tooLongPassword”) // return false

とてもシンプルになりました!
また`changePassword`メソッドを定義したおかげで分かりやすくなりました。

 

まだまだ続けたいところですが、長くなってきたので、今回はこのあたりで終わりにします。

最近はKotlin関係のオンラインのコースもかなり充実していますし、サンプルアプリの実装例がgithubに載っているので、それを元に勉強するのもおすすめですよ。

次回は「プロジェクトの変化に対応する」を予定しています。
お楽しみに。

 

Paving the way ―未経験から英語×ITを実践!―

はじめまして。私コスモルート東京本社に入社して1年4ヶ月程経つシステムエンジニアのAです。

私はコスモルートに入社して以来、英語でコミュニケーションをとりながら外国人たちと仕事を進めるブリッジシステムエンジニアとして各案件に参画しています。
もともとはIT未経験でしたが、コスモに入社し各案件に参画していく中で、業務系ブリッジSEとしての役割を果たせるようになってきました (もちろん、まだ至らないところもあるかとは思います^^;)。
そのため、これからお送りするコスモルートのブログでは、今までの私の業務経験やそれに関連する話を月1回のペースで投稿します!

記事の具体的な内容としては、

・実際にどういったシーンで英語が必要なのか
・業務中に英語コミュニケーションで苦労した話&どうのりこえたか
・業務と並行して英語力を研鑽することについて。TIPSなど
・これから英語を仕事の中で武器として使っていこうと考えている人へのメッセージ

といった仕事で必要な英語の話から、

・異文化コミュニケーション
 ・ハイコンテキスト/ローコンテキスト
 ・空気の読み方
  etc…
・国籍を超えて共通する、ヒトの性格の多様性

といった、育った環境が異なる人と協調しながら働くために知っておいた方がいいトピックを考えております。

また、これらの記事を読むにあたり、書き手はどんな人だろうと疑問に思うかと思いますので、私自身について簡略に自己紹介させてください。

私は日本生まれ日本育ちの生粋の日本人で、大学入学時点では英語は話せず、外国人との交流も全然ありませんでした。
ただ、大学生時代にオランダに1年弱交換留学し、英語の授業と大量のグループワーク課題をこなしながら何とか英語を話せる・聞き取れるようになったと共に、寮生活や課外活動を経て外国人の友達がたくさんできました。
この留学を機に異文化コミュニケーションに興味を持つようになり、有難いことに大学卒業後から今に至るまで様々な国籍の人とオフライン・オンラインで働く機会に恵まれてきました。
こうした職場環境の中で、どうすれば英語(特にスピーキングとリスニング)を上達させることができるのか、どうすれば育った環境が違う人たちと仲良くなれるのか、または協力しながら業務をこなしていけるかについてたくさん考え、時には書物やネットで調べながら今でも試行錯誤し奮闘しています。

このような経験をふまえ、私もまだまだ道半ばではありますが、仕事で外国人と英語でコミュニケーションをとることに苦労している人や、将来はグローバルな環境で働きたいと考えている人にとって役に立つような情報を、このブログで発信していけたらと思っています!

これからどうぞよろしくお願いいたします!

第2回目の記事こちらです。

オランダの上空からの景色

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

こんにちは、コスモルートの西田です。
今回は、新・契約ナレッジマネジメントシステムLegaledge(リーガレッジ)の開発者インタビューの第二回目をお届けします。
前回に引き続き、リーガレッジのプロジェクトリーダーの星野と、西田の対談形式でお送りします。

西田:本日は、よろしくお願いします。

星野:よろしくお願いします。
   今回は、開発時の話などをしていこうと思います。

【CRフレームワーク】
西田:リーガレッジはCRフレームワークで作成したと聞いています。
   CRフレームワークについて教えてください。

星野:CRフレームワークは、コスモルート独自のフレームワークです。
   特徴としては、二つ挙げられます。

   一つ目が、商品やサービスの品質が、作り手に品質が左右されないこと、   もう一つは、開発をスピーディに進められることです。

西田:実際使ってみて、どうでしたか?

星野:使いやすいと感じました。
   まず1点目の「プロダクトの品質の再現性の高さ」についてですが、CRフレームワークを用いてアプリケーションを作っていく際、メインで実装していく必要があるのはブラウザからのリクエストに応じてデータベースからデータを引き出してブラウザに返す処理(以下「API」)になります。CRフレームワークはここが洗練されており、実装のパターンが明確なので学習コストが低く、誰でも一定水準以上の品質のアプリを実装できるなと感じました。
   ここのところが2点目の「開発スピードの速さ」にもかかわっていて、APIの実装のための学習コストが低いので、実装パターンを理解してしまえばあとはどんどんプログラムを書いていくことができます。この点はプロトタイプの作成にも大いに助かるところで、日々いろいろな新機能の案が出てくるのですが、これを素早く実装して試せるのは大きな利点です。
   また、CRフレームワークはコスモルート独自のものということもあり、疑問点があればフレームワークの開発者にすぐに質問できるという環境もよかったです。技術力のある会社ならではの環境だと感じています。
   CRフレームワークは、リーガレッジなどの自社サービスだけでなく様々な請負開発の案件でも使用していて、高い評価をいただいているときいています。CRフレームワーク自体も、様々な案件で利用されることで当初は気づかなかったユースケースにも対応できるよう継続的な改善・改修を行っています。フレームワーク担当チームには、CRフレームワークをさらに使い勝手の良いものにしていただけるよう期待しています。

西田:先日、社内向けにCRフレームワークの勉強会がありましたね。
   私は参加できなかったので、録画を後日見ましたが、かなり使いやすそうだという印象を受けました。

【スケジュール感】
星野:リーガレッジの企画自体は、2019年12月にスタートしています。翌年の2020年3月に東京で法務・知財のテックサービスに関する大きな展示会が予定されていたので、まずはそれに出展することを念頭に進めていました。

西田:たった4か月で!すごいスピードですね。
   EXPOは、どうでしたか?

星野:いかに、お客様にとって使いやすいサービスを提供できるかに主眼を置いていて、特別にこみいった機能を付けることは考えていなかったので、それくらいのスケジュール感でいけそうだという判断をしました。
   ただ、EXPOは、新型コロナウィルスの感染拡大の影響で開催中止になってしました。
   
西田:それは残念でしたね。

星野:EXPOへの出展はできませんでしたが、無事4月にベータ版のリリース、7月に正式版のリリ-スをすることができました。
   リリース後も少しづつ改良を重ねています。

西田:ほぼスケジュールどおりですね。
   

【見やすさへのこだわり】

西田:開発中に困ったことや、苦労した部分はどんなところでしょうか?

星野:一番気を使ったのは、画面に表示される情報の「見やすさ」です。

西田:「見やすさ」というのは…

星野:登録した契約書情報をどのように表示したらユーザーにとって必要な情報がわかりやすく伝えられるか、ということです。あるキーワードで契約書検索したときに、ヒットした契約書の情報を最初に表示される画面ですべて表示するのか、一部のみ表示して詳細は別の詳細画面で表示するのか、別の画面を用意するのではなく同じ画面のなかでポップアップのような形で表示するのか、そもそも情報の並べ方は縦か横か・・・など、いろいろと考えました。最終的には、ユーザーもおそらく見慣れているであろう表形式で表示することに決めました。
   ただ、表形式の場合は1つ問題があると思っています。それは、情報が多くなると画面が横長になって見づらいという点です。これに対処するには、ユーザー自身がどの列をどのような順で表示するかなど、見るべき情報をユーザーが取捨選択できるようにする必要があると考えました。
   表形式でデータを表示するためのライブラリはいろいろあるのですが、グリッドとしての十分な機能を備え、列の表示・非表示なども簡単に操作でき、かつデザイン的にもモダンであるなどのニーズを満たすライブラリとして、最終的に1つのライブラリにたどり着きました。柔軟なライブラリなのでこちらの意図通りの表現ができており満足していますが、リーガレッジの機能をアップデートしていくにつれて表示される情報が増えていき、どこかで再度見直す必要があるかもしれないとも考えています。今後も、常に「ユーザーにとって見やすい画面になっているか?」を意識した開発をしていきたいと考えています。

今回は、Legaledgeのプロジェクトリーダーの星野と、西田の対談の2回目をお送りしました。
次回は、リーガルテックサービスの現状と展望をテーマにお届けする予定です。

リーガレッジの画面

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

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

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

2020/7/16に弊社からリリースされた、新・契約ナレッジマネジメントシステム、Legaledge(リーガレッジ)のプロジェクトマネジャー、星野へのインタビューを数回にわたって掲載していきます。
Legaledgeの魅力、サービスにこめた思いなどをお伝えしていければと思っています。

西田:本日はよろしくお願いします。
星野:よろしくお願いします。

●Legaledgeについて

西田:最初にLegaledgeについてご紹介いただけますか?

星野:Legaledegeは、前職の法務部での経験から感じた課題を解決するためのサービスとして企画しました。

西田:約5年間、企業内弁護士として働いていたときいています。

星野:はい、そうです。前職では、契約書の管理と活用について課題を感じていました。

西田:契約書の活用とは、具体的には、どういうことでしょうか?

星野:新規の契約書を作成する場合にイチから作るのではなく、これまでに締結した契約書の文章を参考にして作成したり、契約書をレビューする際に過去に締結した内容と比較することがよくあります。このように、締結した契約書の情報を利用することそれを契約書の活用と呼んでいます。

西田:なるほど。管理について感じていた課題を教えて下さい。

星野:契約書の管理については、最近の契約書についてはデジタル化して管理されていたものの、古いものはエクセル台帳で管理するなどアナログな要素が残っていました。デジタル化された契約書も、導入していたシステムの検索性がいまいちだったり、個人的には使いづらさを感じていました。

西田:それだと、目的の契約書を探すだけでも時間がかかりそうですね。

星野:うまく管理されていないと、活用にもつながっていきません。
契約書のレビューをしていると、「この取引先とは、このタイプの条文について過去にはこれまでどのような内容で合意していきたか?」といったことを調べたいと思うことがよくあります。
ですが、契約書自体を探すことに手間取ったり、探し当てた契約書に期待していた条文がなかった場合はまた別の契約書や条文を探して…、ということがあり非効率さを感じていました。
ほしい情報にピンポイントでアクセスできる管理の仕方でないと活用しにくいな、と。

西田:確かに。

星野:なので、Legaledgeでは、契約書の登録・管理を簡単にできるようにし、かつ、契約書情報を活用できるような仕組みを用意しています。私はこれを「契約書の管理と活用をシームレスに連携する」と表現しています。

西田:シームレスとは…。

星野:ここでは「一気通貫」という意味で使っています。これまでの契約書管理の課題の1つとして、契約書情報を積極的に活用することまで意識した管理方法になっていなかったという点があげられるのではないかと思っています。つまり、管理と活用が分断されていました。一方、リーガレッジに登録した契約書は、条文単位でアクセスできたりこれを簡単に再利用できるなど、活用できる状態で保存されています。このように「活用されることを意識した管理」になっていることを「シームレスに連携」と表現しています。リーガレッジを「ナレッジマネジメントシステム」と表現しているのも、契約書情報の活用まで見据えている点に所以があります。
   
西田:いいですね。契約書の業務がかなりスムーズになりそうです。
   

●開発への思い
西田:開発への思いをもう少し教えていただけますか?

星野:契約書の管理というと、今までは「これだ!」といえる決定打がなく各社各様のやりかたで管理していたように思います。
   そこに欠けていた視点は、何度か出てきていますが「契約書情報の活用を見据えた管理方法」という視点です。

西田:なるほど。

星野:「契約書管理」というと、どうしても単なる保管や管理のみが目的になっていたのではないかと考えています。契約書の管理はもちろん、その活用までサポートする、決定打的なサービスにリーガレッジがなりたいと考えています。
リーガレッジをご利用いただき、契約書の登録や捜索といった単純作業の時間を削減し、より付加価値の高い業務に集中していただけたら大変うれしいです。

西田:課題を何とかしたいという熱い思いと、それをテクノロジの力でどう解決していくかという視点と実行力とがマッチしてリーガレッジLegaledgeが誕生したのですね。応援しています!
   
星野:ありがとうございます。

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

Legaledge(リーガレッジ)のプロジェクトマネジャー、星野

今回は、Legaledge開発への思いなどをご紹介しました。
次回は、開発までのみちのりなどについてインタビューをしていく予定です。

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

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

当社の福利厚生―合格一時金制度―

こんにちは、コスモルートの西田です。
今回は、コスモルートの福利厚生についてご紹介します。
今回ご紹介するのは、資格の合格一時金制度についてです。

技術力の証明となる資格試験

技術の進歩は日進月歩です。
クラウドサービスの普及もあって、皆さんも ICT関係のニュースを日常的に耳にしているのではないでしょうか?
もしくは、会話の中で知らない単語や新しい単語が出てきたりして、例えば、”Legal Tech”という単語を聞いて、すぐにピンとくるでしょうか?
知らなければ???となってしまうと思います。
ちなみにLegal Tech(リーガルテック)は、「法務関係の業務効率化や課題解決のために使われるテクノロジー」というような意味です。
日々の進歩にいかにキャッチアップするか、し続けるかが、ICT業界での命運を分けます。
なので、コスモルートの社員は、勉強熱心で、新しい技術に興味津々!習得にも熱心!という人が多いです。
コスモルートに限らず、この業界の方は同じ傾向があるという印象を受けます。
でも、自分が何をどれだけ理解しているか、どんな技術を持っているか、他の人に示すにはどうすればいいでしょう?
もしくは、勉強のモチベーションを保つにはどうしたらいいでしょうか?
そこで登場するのが、資格です。

ICTの資格には様々なものがあります。
有名どころだと、基本技術者試験、応用技術者試験などがあります。こちらの資格は国家資格であることもあり、知名度が高いです。
一般の方になじみの薄い資格としては、Oracle Certified Java Programmer などが挙げられるでしょうか。
分野やレベルに応じて様々なものがあります。

コスモルートの合格一時金制度

こういった資格の取得を奨励するのがコスモルートの合格一時金制度です。
TOEICやビジネス能力検定など、 ICTに限定せず、仕事に役立つ様々な資格の取得を応援していいます。
内容としては、次のとおりです。


・受験費用を会社で負担(2回まで)
・難易度やレア度に応じて、10,000円から500,000円(!)の合格一時金の支給。
(500,000円の報奨金の対象は、中小企業診断士です。)
・対象の資格の数は229。

簡単ではない資格も含まれますが、社員同士で教えあうなどして、合格に向け切磋琢磨しています。
同じ立場の人とコミュニケーションをとることができれば、試験勉強もより楽しくできるかもしれません。

ちなみに、コスモルート社内の資格の保有状況は、以下です。

情報処理 基本情報技術者(2種)FE 27名
情報処理 応用情報処理技術者AP 12名
情報処理 情報セキュリティマネジメントSG 4名
情報処理 情報セキュリティスペシャリスト 2名
情報処理 ネットワークスペシャリスト 2名
情報処理 データベーススペシャリストDB 2名
情報処理 テクニカルエンジニア(エンベデッドシステムスペシャリスト)ES 1名
情報処理 ITパスポート(旧初級システムアドミニストレータ) 1名

SAP FI 8名
SAP Certified Application Associate – SAP S/4HANA Sales 3名
SAP SD 1名
SAP MM 1名
SAP ODF 1名
SAP ABAP 1名
SAP WebAS 1名

SAP FI 8名
SAP Certified Application Associate – SAP S/4HANA Sales 3名
SAP SD 1名
SAP MM 1名
SAP ODF 1名
SAP ABAP 1名
SAP WebAS 1名

Oracle Master Bronze 5名
Oracle Master Silver(旧GOLD) 4名
Oracle Master Fellow (旧SILVER) 1名

Oracle Java Silver 3名
Oracle Java SJC-P 2名
Oracle Java SJC-WC 2名

MCP MCP 2名
MCP 1級 1名

LPIC レベル 21名
LPIC レベル 11名

IBM WebSphere Adviser 3名

Amazon AWS 認定クラウドプラクティショナー 2名
Amazon ソリューションアーキテクト – アソシエイト 1名

PMP 1名

XML basic 1名
UML ファンダメンタル 1名

簿記 3級 15名
簿記 2級 7名
ビジネス検定 2級 46名
ビジネス検定 3級 30名

TOEIC 730以上 1名

新しいことを知るのは、大変ですが、同時に楽しくもありますよね。
私も、次は何の資格を取ろうか合格一時金のリストを見ながら検討中です。
皆さんは、どんな資格に興味がありますか?

今回は、コスモルートの合格一時金の制度についてご紹介しました。

東京本社の本棚

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

コスモルートブログはじめました。

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

コスモルートブログはじめました。
このブログでは、コスモルート社員のお仕事が見える!社員その人が見える!そんな情報発信をしていく予定です。

株式会社コスモルートのご紹介です。

1989年に名古屋で創業したICTの会社です。
創業から30年、滋賀、東京にも拠点を拡大し、社員数は100名を超える会社に成長しました。
「知を価値に代え、すべての人々に喜びと幸せを」の企業理念のもと、日々活動しています。

当社のウェブサイトはこちらです。

事業内容は、
・ソフトウェアのコンサルテーション・設計・開発・運用保守
・クラウドサービスの運営・提供
・電子回路設計
・組込みソフトウェア設計・開発
・制御インフラ設計、制御システム検証・運用

…といわれてもピンとこないかもしれません。(笑)

・ソフトウェア・コンサルテーションの醍醐味ってなんだろう?
・電子回路設計って何をするの?
・組込みソフトウェア設計・開発業務のことをもっと知りたいな。

そんな疑問にお答えするブログにしていきたいと思っています。
コスモルートの「成長の秘密」と、成長を支える「中のひとたちの思い」をのぞいてみませんか?

虎ノ門オフィスの窓から