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

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

前回までの記事はこちら
「とりあえず動く」を卒業するためのアーキテクチャ入門編(1)
「とりあえず動く」を卒業するためのアーキテクチャ入門編(2)

前回は「どのようにプロジェクトの変化に対応するか」を説明しました。
今回はテストコードなど、テストに関係した内容に触れていきます。

2.3 テストコードとは?

テストコードとは、コードが仕様通り動いているか確認するために書くコードのことです。単体テストだったり、たまに納品前に行う人力のテストと混同する方がいますが別物です。(単体テストはテストコードの狭義で使われます)

テストコードの概念自体は言語に依存するものではないですが、いざコードを書こうとすると結構難しいものです。
=- なにをテストすればいいのかわからない
=- テストフレームワークの使い方が分からない
=- コードが入り組んでいてテストするのが難しい
など様々な疑問が湧いてきます。次第にテストを書くためにコードを修正する羽目になり、嫌気がさしテストコードを諦めるようになります。

正直な話、テストを書くには勉強が必要で、開発スピードも多少落ちます。テスト駆動開発といって、テストコードを先に書いて振る舞いを定義し、テストが通るようにコードを書くという手法もありますが、難易度が高くプロジェクトに関わる全員に強要するのは無理があると思っています。
またテストコードは全体的なメリットは大きいですが、開発初期フェーズや小規模プロジェクトではバグが少ないこともありテストを疎かにしてしまう傾向があるようです。

そうならないためにも、前章でコードを役割単位に分けて、テストを意識しました。前章のバズツイートを取得して表示するというアプリにテストコードを書いていきましょう。

その前にAndroidのテスト関係した内容に触れていきます。

フレームワークを簡単に紹介します。それぞれ勉強が必要なので公式ドキュメントを参考にしてください。

=- AndroidJUnitRunner 単体テストに使用,アプリの機能をテストする。
=- Robolectric Android依存のテストをJVM上で行うことで高速なテストが可能になる。
=- Espresso UIテストに特化。アプリの振る舞いをテストする。

またテストの規模としては、
=- 小規模テスト クラス単位や機能単位に関わるテスト。単体テストとも言う
=- 中規模テスト DBやAPIのテストや,モジュール単位の振る舞いのテスト。
=- 大規模テスト UIテスト。画面操作を通じて結果を得るテスト。E2Eテストとも言われます。

に分かれます。小規模テストでAndroidに依存しないコードは動作時間が少なくて済みますが、大規模テストになるほど動作時間もかかります。公式には、小規模テストが70%、中規模テストが20%、大規模テストが10%の割合が望ましいとされています。

次回は実際にテストコードを書いてみます。

お楽しみに!

【リーガレッジ】第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 コード修正の範囲が明確かつ限定的とは?
について、説明しました。

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

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回目の記事こちらです。

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

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

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

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

技術の進歩は日進月歩です。
クラウドサービスの普及もあって、皆さんも 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名を超える会社に成長しました。
「知を価値に代え、すべての人々に喜びと幸せを」の企業理念のもと、日々活動しています。

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

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

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

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

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

虎ノ門オフィスの窓から