【リーガレッジ】第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月に大阪で行われる展示会にも出展を予定しています。

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

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

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

「とりあえず動く」を卒業するためのアーキテクチャ入門編(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 コード修正の範囲が明確かつ限定的とは?
について、説明しました。

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

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

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

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

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

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

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

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

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

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

西田:縦と横、ですか。

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

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

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

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

西田:なるほど。

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

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

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

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

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

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

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

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

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

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

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

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

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名を超える会社に成長しました。
「知を価値に代え、すべての人々に喜びと幸せを」の企業理念のもと、日々活動しています。

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

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

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

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

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

虎ノ門オフィスの窓から