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

※イメージです

新年度の慌ただしさも落ち着き始めたこのごろですが、皆さんいかがお過ごしでしょうか。コスモルートの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 コード修正の範囲が明確かつ限定的とは?
について、説明しました。

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