anchor.diff:  まずメリットの共有が重要。
   PerlからScalaに移行した話、Perl嫌だーってなってて型に守られた安全性の高いScalaの環境にみんな心から満足して移行した。
   
  -*Javaからの場合、Javaに満足していたら移行するメリットなさそうですよね？*
  +*Javaからの場合、Javaに満足していたら移行するメリットなさそう？*
   
   Javaを書ける人ならScalaの仕様に感動する。Javaの面倒臭いところが本当に簡単に書ける。
   
  
positive.code: 
  //:hp-alt-title: My English Title
  
  せっかく座長やったんだったら内容をまとめてくれと https://twitter.com/seratch_ja[@seratch_ja] さんに言われたので、やってみました。
  
  == まえがき
  2016年には学生ボランティアとしてScalaMatsuriに参加し、
  今年のScalaMatsuriには社会人エンジニアとして参加させていただきました。
  
  2016年はScalaのフレームワークを用いたサービス、アーキテクチャにあまり興味がなく（研究のために使っていただけなので。。。）、一番研究に近そうな機械学習に関するセッションは「数式は省きます」、のせいもあってセッションの大半はつまらない。Scalaエンジニアと知り合えたこと、Scalaの開発におけるtipsを知ることができたのが実りという感想でした。なんとなくで参加するのはダメですね(笑)
  
  一方2017年はエンジニアとしての価値観を装備し、「streamに関して知見を集めてこい」との上司の司令もあって、目的意識を持って参加してみると実りの多さに興奮しました。
  昨年のボランティア参加経験によって私のことを覚えてくださっていた方もチラホラいらっしゃり、積極的に話しかけていくことで寂しい思いをせずに楽しむことができました。
  
  *去年の参加経験は無駄ではなかったんやー！！(喜)*
  
  まえがきはこの辺りにして”聞きたい側”として座長を務めさせていただいたセッションでの議論を以下にまとめます。議事録と自分の意見が混在した文章になっていますがご了承を。
  
  == JavaエンジニアにScalaの話を聞きたい
  
  
negative.code: 
  チームでの移行の最も大きな問題か。
  
  個人で移行する分には自分のペースでScalaライクなコードに成長させていくことができるが、チームでやるには規約を定める必要がある。一人が突っ走ってFree monadがそこら中に転がってみんな読めないことがあった。とは言うものの個人個人がいいものを見つけたら共有してチームのScalaレベルを上げる必要もある。ただそれが無秩序に積み重なるとヤバくなるので*Scalaをわかる人がコーディング規約を決めていく必要がある。*
  
  == 結論
  
  