astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

初めての転職で感じたアスタミューゼのいいところ

「こんにちは、僕の名前はネコタンク!毎週、みんなのデスクを転々としてブログを書くよう耳元で囁くよ!」

f:id:astamuse:20170328164146j:plain

こんにちは、1月に入社したnishikawaです。私のところに  死神  もといブログの番人であるネコタンクさんがデスクにやってまいりました。先週の水曜から本日まで耳元で「ブログ書け〜、ブログ書け〜」と精神に囁きかけてきております。

そのおかげで毎晩ネコタンクさんが下の画像のような感じで私の夢に出てくる始末。シュールな顔をして侮れないネコ?です。

f:id:astamuse:20170328155646j:plain

さて、今回初めてブログを書くにあたり何を書こうか色々と悩みましたが、どんなに悩んでも天から文章は降りて来ず。結局、部長からいただいた「アスタミューゼに入社して働き方がどう変わったのか」というアイディアを基に身を絞ってブログを執筆することにしました。「職場で何かに行き詰まっている」「転職を考えている」という方の参考にしていただければ光栄です。

まずは忙しい人のためにアスタミューゼで3ヶ月働いてみてよかったところ、新鮮だったところをまとめてみます。

・ 会社の人と技術の話題で盛り上がれる(前の会社では絶対になかった)
・ 提案次第で技術的に新しいものを積極的に取り入れてくれる
・ 週1回勉強会がある
・ 勤務時間がフレックス制で働きやすい
・ 設計から運用までシステムを一貫して見ることができる
・ 営業、マーケティングの方と打ち合わせをする機会があり、自分の仕事が売り上げに繋がっていることを実感できる
・ 誕生日休暇という休みがある(とっても新鮮)
・ 職場全体や上司が家庭や子育てに関して理解を示してくれる
・ 出社して周りに人がいる(1人じゃないって素晴らしい)

こんなところではないでしょうか。こう見ると前の職場大丈夫か?と思われるかも知れないですが、私にとっては大丈夫じゃないので転職した訳で、これらのインプットを元にどんな環境だったのかというのを推測してみるものいい時間つぶしになるのではないでしょうか。(精神を蝕まれないよう注意が必要です責任は取りません)

では、私がアスタミューゼに入ることになった経緯などを以下に記載します。お時間のある方だけどうぞ。

1人で仕事をしていた前職時代

私は大学を卒業し5年間グループ企業の中の小さい会社で働いておりましたが、年次を重ねていくうちに以下のことが辛くなってきました。

・ 設計から運用までシステムを一貫して見ることができない。
・ やったことのない技術をいきなりやらされる。
・ 客先に1人で常駐させられているため、誰にも相談できず1人でなんでも解決しなければならない。
・ 仕事のコントロールが全くできない

そのため、帰りも遅い上に帰宅後は技術的な課題克服のため調べ物を朝までやり翌日の業務に備えるという状況が入社してから続きました。

転職を考え始めたきっかけは体調不良!

そんな環境で働き続けていたある日、職場での打ち合わせ中に急激に胸の痛みに襲われその場で倒れました。あの時のことはまだはっきり覚えていますが、多分あれは心臓が軽く止まっていたのだと思います。すぐに動いてくれたようですが心拍数が上昇したまま治らず、全身が痺れて動けなくなったため救急車で病院に運んでもらいました。

会社は辞めようと思ったのはその時です。

転職を考えるも、いきなり躓く!

まず、最初にやったことは転職サイトへの登録と自分の分析でした。私は学生時代の就職活動中に有名な某就活サイトに登録しておりましたので、とりあえずそこの転職サイトに登録を行いました。ここまでは順調だったのですが、自分の分析を行ったら一気に手詰まりになりました。

そうです!私には目立った経歴もスキルも無かったのです。

当時は勤続3年目で経験がなさ過ぎたためアピールポイントが無かったのです。社会人なので「部活やってました!」「会社で真面目に仕事してました!」なんて言いながら就職活動をする訳にはいきません。具体的にどんなことをやってきて、どんなことができるのかを言えないといけないのです!(ネットの情報曰く)

なので会社を辞めたい気持ちを一時的に抑えてアピールできるポイントを作ることに専念しました。具体的には

・ 獲得したいスキルセットを明確にする
・ スキルセットで足りない部分の洗い出しを行う
・ 足りない部分は独学で勉強し、できるだけ業務で使用する

そして月日が流れついにその時がやってきました。

ついに転職をすることに!

それは去年の夏のこと。休みの朝に妻がパソコンを私の前にドンッ!と置きました。

私:「ん?どうかした?」

妻:「今日は仕事の調べ物をしないでずっとリビングにいてもらいます。」

私:「今日って何かあったっけ?」

妻:「いい加減今の会社を辞めて欲しいから今ここで転職サイトに登録してエージェントに連絡してください!終わるまではご飯抜きです!」

私:「えっ!ご飯抜きは流石に勘弁してください!すぐに登録します!」

と、こんなやり取りの後エージェントに後日会う約束をして  ご飯抜きを免れました  転職活動をすることになりました。

面接を受けてみると色んな企業から想像もしなかったことを聞かれる

転職活動をし始めて一番最初に驚いたのがどの会社に面接に行っても「なぜ今転職を考えたのですか?」という質問をされることでした。私は当時30歳になるかどうかのタイミングだったのですが、初めて転職をする年齢としては少し遅いんじゃないかと色々な企業で言われたのです。

正直これには驚きましたが、確かに私の経験にはマネージャ経験等がないのでそう言われるのも仕方なかったのかも知れません。倒れたあの時に即行動を起こしておけばと面接を受けながら後悔もしました。

転職の文字が少しでも頭をよぎった方、古人は遥か昔から言っておりました「思い立ったが吉日」と。

内定を2社いただき、迷った末アスタミューゼへ

面接を受けて凄く落ち込むことも多かったですが、妻から飯抜きの脅迫を受けているので逃げ出す訳にはいきません。頑張って色んな会社を2〜3ヶ月回った結果、ありがたくも内定を2社いただきました。そのうちの一つがアスタミューゼでした。

しかし、すごく興味があり仕事をしてみたいという気持ちこそあれど、当時の私はアスタミューゼへの入社をかなり悩んでいました。

私はもともとScalaがやりたくてアスタミューゼに応募したのですが、Scalaの実務経験はなくほぼ独学でやっている状況だったため、入社しても会社の役に立てない可能性が高いと思っていたのです。また、面接時に浴びた「私たちスペシャリスト集団です!」的なすごいオーラに極度に怯えていたということもありました。こんな状態で入っても3日でクビになって路頭に迷う そう思ったからこそ激しく葛藤しました。

そんな私に、手を差し伸べてくれたのは先週ブログの当番だった私の今の上司で、メールで励ましのお言葉をいただのでとても勇気が出たのを覚えてます。そして最後の後押しはやっぱり妻で、「路頭に迷ったらその時考えよう!」と言ってくれたのでアスタミューゼへの入社を決めました。

と、ここまでがアスタミューゼに転職するまでの経緯です。転職理由や行動に移すまでの動機は人それぞれですが、私の場合はこう見ると妻にほとんど突き動かされていました。しかし、自分のやりたいことなどについては妥協せずに転職ができたので今はとても満足しております。

アスタミューゼは前職と比べてどうか

これは冒頭にまとめましたので そちらをご覧ください。

強いて言えば、もう最初に書いてありますが職場や上司が家庭や子育てについてとても理解があるので、相談しやすいですし建設的な話し合いができるところが大きいと思います。私はアスタミューゼ以外だと前職しか組織を知らないのですが、そこや友人の所属している企業の話を総じても、ここまでプライベートの相談がしやすい会社はないと思っております。

また、開発部にいる技術者はみんな凄い人ばかりですが、分からないことは質問するとみんな優しく教えてくれます。これも前職ではなかった経験で場所が変わればこんなに働く環境や仕事のやりやすさというのは変わるものなのかと常に驚きに満ちています。

最後に

今回はアスタミューゼへ入社して3ヶ月間で私が感じたところを書かせていただきました。

技術者にとってはとても働きやすい場所だと思っております。もし、弊社にご興味がありましたら採用ページをご覧いただければ幸いです。

recruit.astamuse.co.jp

また、現状の労働環境に不満があるという方!組合や労基署に走るのもいいですが、まずは転職サービスへ登録すると一気に悩みが解決するかもしれません。弊社では多数の業界に特化した転職サイトをご提供しております。

働き方を変えたい方、年収を上げたいと考えている方、もっとワクワクするような技術をやってみたい方は弊社の転職ナビシリーズをよろしくお願いします。

今回はシステムエンジニア転職ナビというサイトを貼っておきます。他の転職ナビについては、Googleで「<業界名> 転職ナビ」で検索してください!ということで続きはWebで!

※以下は弊社のシステムエンジニア転職ナビのリンクです。

systemengineer-job.com

デザイナーが「言葉」についてちょっと真面目に考えてみた

f:id:astamuse:20170322211518p:plain

こんにちは。白木と申します。デザイナーです。

前回はデザイナー採用担当者の目線でポートフォリオについてお話をしました(下記)。多くの方にご覧いただけき、「参考になった」というフィードバックもいただきました。ありがとうございました。

lab.astamuse.co.jp

さて、今日はもう少し抽象的なデザインの話をしようと思います(時間ない方はブックマークしてお時間あるときにお読みください)。お題は「デザイナーが「言葉」について真面目に考えてみた」です。

デザイナーに求められる能力は多様?

本題ではありませんが、デザイナーに求められることは実に多様です。デザインがそもそも統合的・領域横断的な性格であるため、周辺領域からの知識要請がとかく多いと日々感じています。

例えば椅子一つ作る場合、デザイナーはただ美しい形状を追い求めるではなく、構造力学、材料工学、人間工学の側面も考慮せねばなりません。また、製造現場とのすり合わせや(「それ型で抜けるの?」的な)、コンセプト落とし込みの調整役もこなしますし、場合によっては何が売れるのかをマーケティング側とすり合わせるところにも関与します。簡単なマーケティングリサーチの知識も必要とすることもあります。

Webデザインも同様です。このご時世、企画、マーケティング、エンジニアリングと無関係でサイトやサービスを完成させることはあり得ません。いずれの隣接領域に対しても越境的にディスカッションできる程度には専門知識を備える必要があります。

しかし、実際には私たちの仕事はこれらの専門的知識・知見だけでなく、その土台をなす非専門的な能力によって支えられているように見えます。むしろ非専門的な部分の方が実は支配的なのではと思わせるほどです(仮説)。

デザインの専門領域外で重要な要素とは?

では、専門領域以外の重要な要素とは何なのでしょうか?先ほどの仮説から言えば、それはデザイナーの仕事を考えればおのずと出てくる答えですが、先に私なりの結論を示すと以下の3点です。

  1. 言葉・概念
  2. 思考・洞察力
  3. 多様な経験

1は私たちが作ったものに文脈やフィロソフィー、説明を与えるために必要な要素です。2の思考・洞察力は特段デザイナーに限定される話ではないですが、デザイナーらしい思考・洞察力はあると私は思っています。3についてはデザインを生み出す原体験の多様さです。

紙面と時間の関係上、本日は1のみ整理しますが、2,3についても日を改めて整理できればと考えています。ということで以下「言葉・概念」についての考えを整理します。

デザイナーの仕事の特徴と言葉・概念

デザイナーは「抽象的なもの・ことを形にすること」を仕事にします。クライアントや企画の想い・意図を解きほぐし整理し秩序を与えながら形に変えていく生業です。ほかの職種と比べて対象テーマが感覚的・感性的なことが多く、ここがデザイナーの難しさの一つでもあります

さて、この感覚的・感性的なテーマに向かっていく中で、言葉・概念という武器が少ないとクリアが難しくなるというわけです。

言葉・概念が対象テーマの的確に把握できない

f:id:astamuse:20170322225427p:plain

まず言葉・概念の扱いがうまくないと、対象テーマを正確・的確に把握しにくくなります

例えば「信頼感を醸成したい」というテーマがあったと仮定します。この場合、普通は「信頼感とは何か」を考え「誠実」「落ち着いた」などの言葉に至るのですが、本当に表現すべきことが「内省的な印象を備える信頼感」であった場合はどうでしょう。デザイナーが「内省的」という言葉・概念を知らなかった場合、どうなるのでしょうか。的確にテーマを捕捉しえるでしょうか。

サピア・ウォーフの仮説*1ではありませんが、適切な言葉を持ち合わせていない中で曖昧・複雑なことを的確にとらえることはおそらくは困難です。先ほどは「内省的」という発見されやすい例を出しましたが、実際の現場ではもっと面倒でわかりにくいケースがゴロゴロしています。これらを形にするのに、それを表現できる言葉が少なくては、落とし込みにに膨大な時間とコストがかかるか、結構な量の情報が落ちてデザインの精度が下がるかです。

言葉・概念によるデザインの背景・哲学を形成が困難になる

f:id:astamuse:20170322230738p:plain

次にデザイン説明時にも問題に遭遇します。

何かしらのデザインができた時に、デザイナーはそのデザインに至った背景や理由の説明責任を負います。デザインの対象は感性的であることが多いため、そもそも説明コストは高いのは当然です。が、仮にデザインしたものが企業ロゴなどであったら、感性的な要素だけでなく企業のフィロソフィーすらもデザインに乗せることになりますから、それをどう言葉に落とし込むかは能力の求められることろです。

ただ、この点においては反論もあって、そもそも言葉を必要とするデザイン自体が問題なのではないかという指摘です。これは一理あります。言葉を必要としないように直感的なものを指向することも選択肢としてはあります。しかし、説明が不要かどうかを決めるのは提案するデザイナーではなく、それを受け取る側に依存しますから、依然説明ないし言葉は必要であると考えるのが自然です。

また直感的に理解し得るものであってもデザインに込められたフィロソフィーをどう伝播させるかという観点から言えば、伝達媒介としての言葉はやはり重要でおざなりにはできません

言葉をなくして観察ができるか

物事を観察するときにどこまで精緻に記憶・記録できるかは、観察の分解粒度と的確な言葉の利用が求められます。

昨今では「かっこいい」で表現できる幅が随分と広がりましたが、あらゆるものを「かっこいい」と評してしまうと、一体何が恰好よく足らしめているのかは解らないままです。色なのか構図なのかプロポーションなのか時代とのギャップなのか。観点は多様で、その観点を説明する言葉もまた様々です。日常の軽い会話であれば「すごい」「かっこいい」でもいいのかもしれませんがデザインを説明する時、またデザインを学習するときは、細かい部分にまで言及し的確に表現することが重要なのは自明のように思えます。

高尚な言葉・概念を使えばいいわけではない

さて、ここまで言うと「かっこいい言葉使わないといけないのかな」と思われるかもしれませんが、そんなことは全くありません。あくまで的確な言葉を探すこと・身につけるです。それもきちんと共感を得られる言葉、もしくは少しの学習で理解可能な言葉の中で、です。

かっこいい言葉を使うことは、排他的な面があります。専門家が専門用語で話している中に素人が入り込めないのと同じように。もしそういった高尚な言葉を使いたいのであればそれが通じる人との中でだけ使ってください。わからない人に対してひけらかし的に使わないよう心掛けてください。ひけらかしとして使うのは却って底の浅さを映すことになります。

説明くさくあれと言っているわけではない

また、ここまで言うと「随分と説明くさくしなければならないんだな」と思うかもしれませんが、それも意図しないところです。飽くまで問題の本質をとらえるために言葉が大事だとご理解いただければと思います。必要な時に必要な量の的確な言葉を出せるようになることと、物事をより正しく理解するために言葉が重要なのであって、説明的であることは重要ではありません。

最後に

デザインを的確に行い、その意図を理解してもらうことは、とりもなおさずデザインという世界そのものの理解を広げることと同義だと思っています。そのために私たちは言葉を身に付け伝え続けなければならないと改めて認識します。そこを怠り、デザイナーらが自身ら身内の言語に満足して外に向けての説明を放棄してしまうことは不信感を助長し、象牙の塔の印象をもたらすだけでしょう。そのような業界に未来はありません。

デザインとは相手とのインタラクティビティによって生まれてきます。そこでのコミュニケーションを語る前段として、まず良いコミュニケーションを行うための道具磨きが必要であり、それが豊かな言葉の獲得なのです。 日々の作業に追われているとWeb上のノウハウの収集ばかりに終始してしまいがちですが、たまには立ち止まって自分の言葉磨きなどもしてみるのはいかがでしょうか*2

*1:サピア=ウォーフの仮説

*2:ちなみに私は言葉磨きのために自分の考えていることを実際に紙に書いてます。それだけでも言葉がだいぶ使えるようになります。

KotlinでJVMのWebApplication開発は楽になるのだろうか。検証してみている。

f:id:astamuse:20170314235457p:plain

どうも、えいやです。
またお鉢が回ってきたので、担当させていただきます。

前回はJava8で楽になったか試そうとしたけど、中途半端で完成しませんでしたという記事を書きました。
これはひどい、というご意見ですが、ごもっともですね。

今回も似た感じで、Kotlinで楽しようとした感じの中途半端な記事です。

kotlinlang.org

大体のことがそんな感じなので、大抵のことを誰か代わりにやってくれないかなぁと思っています。僕より役に立つ人が沢山いるといいな。

さて、今回は、WebアプリケーションにBetter JavaとしてKotlinを使う検討をやってみているという話です。
検討途中ですし、大して詳細に調べたわけでもないので、適当に聞き流してください。

弊社では、開発言語に特に縛りはないものの、Java、ScalaGroovyと言ったJVM言語で開発している事が多いです。
そういうわけで、しばらく前に1.0がリリースされ、やや安定期に入ってきた新しいJVM言語であるKotlinの評価を始めてみました。
ScalaもGroovyも15~12年前に開発されてから、最近はわりと安定、普及してきたのはそりゃいいんだけど、そろそろ新しめの言語にも触れておかないとね。

なお、Kotlinの開発元は、最近JVM向けの有償IDEで(たぶん)一番人気*1IntelliJ IDEAを作っているJet Brains社です。

まず、Kotlinという言語の特徴ですが、JVM上で動くバイトコードにコンパイル可能、静的型付け、オブジェクト指向という点ではJavaと同じです。
さらに、Kotlinには型推論、宣言側変性(ジェネクリスの変性を宣言可能)、高階関数、ラムダ式(最近のJavaにはあるけど)、移譲の宣言、Null安全、スマートキャストなどの便利機能がついています。

Kotlinの文法や詳細は、公式ページに任せます。また、いろいろな人が日本語で解説してくださっています*2*3ので、そちらを見てください。
この記事では、弊社が開発しているWebアプリケーションで、どの程度使えるのかを検証してみた内容について述べます。

なお、2017年03月現在で、世間様でのKotlinの利用状況としてはAndroidの開発でやや人気が出てきたというところのようです。

今回は、Kotlinの採用可能性について、以下の点で調べています。

1)KotlinおよびKotlin製のWebApplicationFWでシステム構築・運用が可能か
2)アプリケーションのコード全体をKotlinに置き換えることが可能か
3)2)のコードの一部をKotlinに置き換えることが可能か
4)既存のアプリケーションから利用するライブラリを作成可能か

1)KotlinおよびKotlin製のWebApplicationFWでシステム構築・運用が可能か

検証の対象として、Kotlin製のWebApplicationFWで一番安心できそうなJetBrain社製の「Ktor」を検証してみました。

結果としては、個人的には簡単なWebApplicationを作るだけならイケるんじゃないか、という感想なのですが、コレをチームメンバーに使えというのは酷という感じです。

Ktorは、最小の作業で素早くKtolinでWebアプリケーションを作るフレームワークと自身の紹介に書いてある通り、初見の印象としてはNode.jsのExpressに似たコンパクトなルーティングと処理を記述する、非常にコンパクトな機能を提供しているイメージです。

ドキュメントがほぼ整備されていないので、Ktor本体のソースコードとサンプルのソースコードを頼りに一通り試してみました。
公式のサンプルからそう離れたことはやっていませんし、この記事が出来上がる頃にはまた変わっていると思うので、試したコードは載せません。

なお、ドキュメントのGetting Startedで紹介してあるコードは僕が検証している段階では動かなかったのですが、今確認したところ動くコードに変わっているようです。

現時点でのバーションは0.3ですので、現時点ではかなり多くの不備があるため、採用するとなるとOSS開発に協力しつつシステム構築を進める事になります。
それはそれで面白いとは思いますが、すぐに導入を決めるのは難しそうです。

他のWebApplicationも一応検証してみたのですが、まともに動かすのに時間がかかるもの、更新止まっているものばかりでちょっと。。。

数年前に期待されていたKaraWasabi*4は開発が止まっている、か停滞しているみたいです。
なお、KtorはKaraやWasabiにインスパイアされているらしいので、それらの後継と言えるので、今一番安心できる開発体制なのではないでしょうか。

なお、WebApplicationというとサーバサイドって感じですが、KotlinはJavaScriptにトランスパイルする事ができるのでそういうFWもあるみたい*5です。検証してませんが。

2)アプリケーションのコード全体をKotlinに置き換えることが可能か

今のJava製のアプリケーションFWをそのまま使ってということですね。

まず、前提としてKotlinのコードはバイトコードにビルドされますし、Javaのライブラリもそのまま使うことが出来ます。なので、可能性ということであれば絶対に可能です。
あとはそれで開発が楽になったり、いいことがあるかということです。あと、既存コードからKotlinへの一挙置換となると現状のテストコードだけでは検証が難しそう、とかは一旦考えません。

弊社でJavaのプロジェクトと一部のScalaのプロジェクトでは、自社製のJavaWebApplicatrionFWを使用していますので、その仕様に則って、WebApplicationを作ったとしましょう。
検証のポイントは、FWの仕様が、Kotlinとミスマッチだったりしないか、ということです。
さらに、既存コードからの置き換えということで、KotlinのJava->Kotlin変換機能でどの程度楽にできるか、ということも検証してみます。

検証

次のプロジェクトを変換してみます。

github.com

このプロジェクトは、弊社製のWebApplicationFrameworkのAsta4Dで作成されており、簡単なHandlerとSnippetで構成されています。

本当はDB周りも試したかったのですが、この記事のためには時間切れです。

もし実行してみたかったら、次のコマンドで実行可能です。

git clone https://github.com/aya-eiya/java2kt1
cd java2kt1
git checkout JavaSmaple 
./gradlew clean appRun

起動にはGrettyを使っています。

localhost:8080で以下の画面を見ることが出来ます。

f:id:astamuse:20170314224025p:plain

上から、path/helloに対して引数なしGet、引数(name)ありGet、Postを行います。
path/helloからの返りはJsonで、Getに対しては{“message”:“hello ○○”}を返し、Postに対しては{“name”:“○○”}を返します。

Postで送ったNameはSessionに保存され、引数なしGetの返却値の一部およびPath/の一番下の入力フォームの初期値として使用されます。

さて、Kotlinに変換をしていきます。

まず、InteliJのJava->Kotlin変換機能を使ってみます。メニューからは Code -> Convert Java File to Kotlin Fileで選べます。

f:id:astamuse:20170314225034p:plain

変換後のソースはビルドが通りません。

どうやらNull許容のところで型違反と、valで初期化するように変換した値に代入をしているようです。

単純な方法でコンパイルが通るように修正したコードではアプリが起動しません。

どうやらNull安全の機能が問題で、Null許容型とNull不可型で型が違うため、Springの設定ファイルに書いてあるBeanの作成に失敗しているようです。
型を合わせてみるとこのエラーはなくなりました。

次はFactoryとして作っていたクラスで、staticなinstance()メソッドが実装されています。
このクラスのBeanの設定でfactory-methodにinstanceを指定していましたが、Kotlinではクラスにstaticなメンバを持つことが出来ないため、JavaからはCompanionオブジェクトを通じて呼ばなければなりません。
なのでFactory.CompanionをBeanに登録して、factory-beanにそのIDを指定します。

次は、UrlRuleがInitialize出来ない、というエラー。。。

その後、30分ほど色々試してみるものの、どこかしらでエラーとなって起動できませんでした。

結論として、大きなプロジェクトを変換するのはちょっと辛そう。ということになってしました。。。

しかしながら、時間さえかければ変換はそんなに苦労はしないんじゃないかなという感想も持ちました。
作業の慣れの問題でどうにかなるんじゃないかと。

3)2)のコードの一部をKotlinに置き換えることが可能か

1)の途中の状態から一部をJavaに戻したりしながら検証してみました。
Beanに登録するようなものでなければ違和感なくKotlinに変換して利用が出来ます。

ただ、この境界をどうするのか、というのが難しく、混ぜて使うのはちょっとつらいんじゃないかな。
という感想です。

4)既存のアプリケーションから利用するライブラリを作成可能か

これは検証前は一番大丈夫なパターンだと思ったのですが、ライブラリの対象によってはBeanに登録するだの、利用シーンを限定できないこともあってかなりつらいです。
一番つらいパターンかもしれません。

簡単な機能のライブラリでは問題はでてこないのかもしれませんが、これも何をKotlinで作って良くて、何がダメなのかの境界を設定するのが辛いと思いました。

一旦の結論

  • Kotlinで書くのはそんなに辛くないが、FWなどエコシステムがまだ発展途上。
  • 現行のWebApplicationのコードをKotlinに変換するのは辛い。
  • 一部をKotlinで書き始める場合も、落とし穴だらけの可能性が高い。

今回とは逆に、Javaで作ったものをKotlinで使うのは、Null安全などの対応は別にすれば問題は少ないです。
なので、業務で使う場合、WebApplicationよりもバッチとか、それこそ今流行り始めているAndroidで使うのが、まだ安全かな、という結論です。

今回、検証とは別に習熟のためにKotlinで色々書いてみたのですが、Scalaと同じく、言語の持つ機能が多いので覚えることが多い印象です。JVM言語ではないのですが、シンプルなGo言語なんかと比べると習得に要する時間が長いかも。

Javaもそれなりに多いんだけど、経験年数長い人やドキュメントが多いので。同じ理由でだいぶ長くなってきたScalaもその辺をクリアしてきた感じありますね。

良い言語だと思うんだけど、普及率や自分たちの領域を考えると、まだチームメンバーに強要はできないかなー。

という感じで、今回も中途半端な感じで終わります。

なお、既にKotlinマスターで強烈にKotlinをプッシュしてくれる方が来ていただけると事情も変わると思います。
Javaを全部Kotlin化するって言っても、僕はことさら止めはしないので。

今回の記事は以上となります。
お疲れ様でした。

Copyright © astamuse company, ltd. all rights reserved.