読者です 読者をやめる 読者になる 読者になる

砂日記ばーじょん2.0

IT関連の仕事中に浮かんできたポエムとか読んだ本の感想とか書いていきます。

【デブサミ2017聴講記】【17-A-4】C#で簡単にモバイルアプリを作ろう!

デブサミの参加記録(5/8)

Togetter

Togetter

感想

講演前の心持ちから

2万2千人超えのフォロワーを持つちょまどさんですが、
今回の講演を聴く前は正直なところ私はその実力を疑問視していました。

なぜなら、常にTwitterで何かつぶやいてていつ仕事してるのかよくわからないし、
ツイートの内容もほぼ松屋エバンジェリストってくらい松屋の話ばかりだし、
Xamarinのアドベントカレンダーで真っ先に25日を抑えてラスボス宣言しておきながら
海外旅行に出かけられて他の人に記事書いてもらっちゃうし、ガチポケモン勢だし、
この人は大丈夫なのか、本当にマイクロソフトエバンジェリストなのだろうか、
単に美人でオタクで腐女子松屋推しの漫画家っていう多属性が受けてる人なんじゃないかって思ってました。

そこでデブサミで登壇者として参戦されると聞いて、これはもう直に確かめるしかないと。
がっかりするようなプレゼンだったら迷っていたWindowsからMacへの乗り換えを決めてしまおう
とか考えながら講演に臨ませていただきました。

そして45分の講演後、それはもう完膚なきまでにボコボコに私の価値観は叩き壊され、
C#素晴らしい、Xamarinはいいぞ」しか喋れない体になってしまったわけですが、
一体何が起こったのか、ありのまま話したいと思います。

C#はツール?いいえ、友達です。

講演の冒頭から「緊張で昼に食べた牛めしを吐きそう」とかこぼすちょまどさん。
見ている観客の方が不安になってきます。
本講演はC#って何?Xamarinってどういうの?っていう人がターゲットだったので、
C#からして未経験の自分も参加要件満たしていて安心しましたが、そのC#の説明が雑。

普通、C#って何って聞くと、
「CやC++を源流としたマルチパラダイムプログラミング言語で~」とか説明すると思うんです。
ところがちょまどさんは「C#はCがなんか進化してC++になってそれがぽっぽっぽっぽっとなったやつです」
みたいな感じに言うんです。ぽっぽっぽっぽて。
C#を広めるための説明がそんな友達を軽く紹介するみたいな・・・とここまでは不穏な空気だったんです。

だが、ここからが本当にすごかった。

数百人の猛者エンジニアの前でライブコーディングできますか

その後C#の良いところがひょひょいと紹介されて、イベント処理簡単に書けますとか説明されて、
おおこれは確かに簡単かも~と興味が出てきた直後、
「では実際にデモしてみます」
って言うんです。さらりと。衝撃。
ライブコーディングですよ。300人~400人のエンジニア達の前で。
できますか。私にはできない。
緊張してるとかいいながらちょまどさんはやってのけるんです(エラー出てたけど)
C#とVisual Studio2017を駆使して、
Hello Worldなんてちゃちなものでなく非同期処理のサンプルを書き上げ、
コレクション処理、非同期、ラムダ、Jsonのクラス変換機能などを説明し、
モダンなプログラミングができることをものの数分で実感させてくれました。すごい。
そして合間合間に「C#素晴らしい」をしっかり刷り込んでくる。
私はJavaプログラマですが「Java素晴らしい」などとちょまどさんのように曇りなき眼では言えない。
C#の紹介を友達みたいに・・・と先述しましたが、本当に友達なのかもしれない。

笑いの裏に見え隠れする緻密な計算と努力

もうこの辺ですでにちょまどさんへの当初の疑惑は完全に晴れてしまったのですが、
素晴らしかったところをもう少し。

終始観客の笑いと関心の絶えない絶妙なプレゼンだったのですが、
その裏で相当の努力があったのだろうとうかがえるところがいくつもありました。

例えば、 C#の説明の中で、C#マルチプラットフォームでどこでも動く。
わたしは、あらゆるプラットフォームで動くと聞くと彼を思い出すんです」

と言った後に切り替わったスライドで「30億のデバイスで動くJava」のインストール画面が出て会場笑い。
Javaプログラマの私にはとてもツボだった場面なのですが、振り返ってみると、ここの演出すごい。
スライドの順番、話す内容を完全に暗記して、何度も練習しないとできない。

緊張の中で、しかしそれを全く感じさせないスムーズな流れで演出してる。相当練習してる。
私も、会場の人もしっかりうけてる。
付け焼刃なプレゼンではスライドの合間合間に間が空いたりしてしまう。それでは笑いは起きない。
このライブ感。努力で作られているプレゼンだと気付きました。

良かったところを上げるとキリがないのでまとめ

ざまりんの名前空間汚染のくだりとかも面白くてもう座間市は早くちょまどさんと手を組んで
ハッカソンイベントとかXamarin開発企業を誘致すればいいじゃないかなとかいろいろあるのですが、
書ききれないので割愛。

こうなると、もうこのプレゼン相当しっかり計算してできてるんじゃないかという風に見えてきます。
Azureの説明(本編)が3分しかなかったり、
最後は緊張による手の震えのせいにしてAzureはいいぞってまとめをすっ飛ばしてましたが
それすら計算と演出かもしません。
ダメ押しに時間が足りなくなると思って補足資料作ってブログに上げる徹底ぶり。
それをデブサミ講演前日に夜通しでやる計画性には多少疑問符がつきますが、
最初から最後までプロフェッショナル。

私の拙い文章で伝えきれなかったところ、
まだちょまどさんの講演を見たことが無い方は是非見ることをおすすめします。
C#はいいぞ。Xamarinはいいぞ。VisualStudio2017はいいぞ。Azureはいいぞ。

余談

デブサミの講演の後渋谷で英語セッションされたのだそうです。
すごすぎ。

余談2(私個人の話です、すみません)

講演実況中の私のツイートをちょまどさんにRTしていただき、
特に1ツイートが2桁RT、2桁いいねされました。
2桁フォロワーの弱小ツイッタラーの私にとっては本当に珍しい。ちょまどさんの影響やばい。

フレンズってところがトレンドでうけたのでしょうか。
けものフレンズ駆動開発という記事を先日書いたので、
良ければ併せてチラ見していただければ幸いです、と完全にちょまどさんの威を借りるきつねで宣伝します。

【デブサミ2017聴講記】【17-C-3】オルタナティブなチーム開発のすゝめ

デブサミの参加記録(4/8)

公開資料

Togetter

Togetter

感想

自分たちも、お客さんも、みんなが楽しくなれる受託開発をする

一風変わった受託開発といえばソニックガーデンさんが有名どころですが、
福岡にも独特な開発の進め方をする会社さんがオルターブースさん。
「チーム開発にワクワクを混ぜる」を顧客と行うことを目指しているそうです。
経営テーマを体現するために以下のような多くの施策を実施しているとのことです。

  • サービス品質優先を突き詰めた結果の、機能的組織(私は機能指向開発という言葉が浮かびました)
    • 徹底的に機能を洗い出す
    • 機能に人をアサインする
      • どうしても割り当てられない機能は外注するか、受注しない
  • 組織開発文化の既成概念を壊すためWebディレクターやサービスプロデューサーを入れる
  • 顧客とワールドカフェ形式のMTGを開催して一緒にブレストする
  • 新技術検証を顧客とする
  • システム構成図を矢印とアイコンに絞るなど、ものの見た目の楽しさにもこだわる

顧客を巻き込んでサービスを作るというのは受託開発ながら
非常にアジャイルで合理的なやり方をしてて素晴らしいなと思いました。

一方で、結構コストがかかっていそうだな、とも。
例えば、学ぶ楽しさを得るための新技術を常に追い求めるという姿勢はいいなーと思うところ半面、
せっかくコストかけて新しい技術を習得しても、
顧客の課題解決にマッチしなければ使われないという結果に終わることもあるかと思います。
また、顧客を巻き込むということは、
その分顧客にもコストがかかっているところがあるのかなと思ったのですが、
その辺どのように折り合いつけているのか気になりました。

新しいシステム作りの考え方を求める顧客がもっと増えればいいな

受託開発って、まだまだ発注側が受託側に仕様を投げっぱなしになるのが大多数だと思っています。
サービスの観点からシステムに関わり、業務をきちんと設計し、
受託側とパートナーシップを強めてシステムを共に作る。
そんな姿勢がこれからはサービスを回す発注側にも求められ、
広がっていけば、受託開発の在り方ももっと多様化してくるのではないでしょうか。

【デブサミ2017聴講記】【17-C-L】まだ見ぬコミュニケーションAIの実現に向けて

デブサミの参加記録(3/8)

Togetter

感想

NTTPCコミュニケーションズのコミュニケーションAIへの挑戦

「また会いたくなる」
「言葉に頼らないコミュニケーション」
「雰囲気を察する」
をテーマに、人に寄り添う人工知能の開発に取り組んでいる話。

ビジュアルの色付けに無料・表記不要・改変可・商用利用可の
中野区応援キャラクター「中野シスターズ」を採用。

質問に対するYesNo形式の回答結果だけでなく、
画像センシングカメラで性別、年齢、感情、ネガポジなどを判断し、
対話者の性格を判断するといったことをしているそうです。

人に寄り添う人工知能の開発ははじまったばかり

特徴量抽出による表情判断など、
機械学習について調べるとよく出てくる分析技術を積極的に活用しているなーという印象でした。
機械学習とか分析技術とかちんぷんかんぷんな方なので、
後半の技術詳細はあまりついていけてなかったり・・・。

  • 会話プログラムの域を出るのはまだまだ先な感じ(機械学習≠AIというのが僕の考えです)
  • 他所の研究でもやっていそうな話が多く、
    NTTPCだからココがすごい!みたいなのがあまり聞けなくて残念。
    (性格分析の仕組みとかがそうなのかもしれないけど、
    非公開情報ということで流されて凄みが伝わってこなかった)
  • (本筋の話ではありませんが)3Dキャラクターが人っぽく喋る様子は
    もう10年も前からボーカロイドがやってきてしまっているので新規性を感じにくかった。

という点から、講演タイトルはちょっと釣りすぎかなぁというのが率直な感想です。

とは言え、日進月歩の技術分野なのでこれからの進化に期待しています。

【デブサミ2017聴講記】【17-B-2】完全ベンダーロックインのMicroservices / DevOps でマイクロソフトに貢献しよう!

デブサミの参加記録(2/8)

Togetter

感想

牛尾さんらしい挑戦的なタイトル

牛尾さんの講演に来ていて牛尾さんのブログを読んでいない人ってほとんどいないんじゃ?と思うのですが、
言わんとしていることは大体ブログに書いておられることをポイントを絞ってまとめたものに、
MicrosoftのDevOps/Microservices製品の宣伝を上乗せしたようなプレゼンでした。
ベンダーロックイン気にしすぎじゃない?みんなでOSSを使った車輪の再開発に人件費割くのはやめて、
Microsoftのクールなツールを使ってみようぜ!という始まりから、
DevOps導入レクチャー入門編につなげていきます。

バリューストリームマッピング流行ってほしい

バリューストリームマッピングの紹介がやはりされましたが、
他の講演でもDevOpsの話題になると当然のようにバリューストリームマッピングがセットで出てきました。
アジャイルの研修ってエンジニア向けなものが多くて、エンジニアがいくらアジャイルに適用しても、
組織構造そのものがボトルネックになるとあまり効果が出なかったりして、
経営層やマネージャー層向けに特化したアジャイル研修をもっとやるべきだよなぁ。という一つの解が
バリューストリームマッピングを用いたトレーニングじゃないかなと思っています。

「本番で失敗して成長する」のデモ

その後のDevOpsかくあるべし論は牛尾さんのブログでもよく書かれているので割愛。
DevOpsスターターキットは見なきゃですね。
そして、Visual Studio TeamServicesやVampのデモに入ろうとしましたが、
ネットワークが重すぎて接続できず、断念・・・。

  • 実践投入すること
  • 悩む前に先に進むこと
  • 愚直に実践すること
  • 本番で学ぶ

というDevOpsに立ち向かうための意識のありかたを最後に説いてくれましたが、
本番で(失敗して)学ぶをデブサミ本講演の場で即実践して見せてくれた牛尾さんなのでした。

【デブサミ2017聴講記】【17-E-1】自動化はどこに向かうのか~まだ開発・運用の自動化で消耗しているの?~

デブサミの参加記録(1/8)

公開資料

Togetter

感想

さくらインターネット前佛さんによる自動化の話

サーバやクラウドいったキーワードは全くの専門外ですが、自動化テーマに興味があったのと、
多少タイトルに釣られました。
内容は以下の3つをいろいろな切り口で語ってくださいました。

  • 自動化が目的になると地獄行き
  • 「ツール」は私たちの問題を解決しない
  • 問題解決の道標「必要は発明の母」

つい昨日、現場でSlackを使ってみようということでアカウントをもらい、
「おおー流行りのSlackをついに自分も体験だ~」とか喜んでいたので結構耳が痛い話となりました(笑)

手段の目的化あるある

アジャイル開発やDevOpsの流行が拡大する中で、自動化を推奨する声が増えていますが、
ちょっと待てよという。
そのツールを使うことで課題は解決できるか
組織はみんなハッピーになれるか。
ツールに運用を捻じ曲げられて逆に働きにくくならないか。
ツールを入れるという手段が目的になってしまうのはありがちだよなぁと思いました。

体制や環境で課題はそれぞれ異なる

あるチームで良かったから他のチームでも自動化するのは良いとは限らない。
自動化云々の前にまず課題を洗い出し、解決手段を探ることから始めるのが大事。
そのうえで必要とされるものを入れていくべしというのが非常に納得できる話でした。
また、個人レベルならとりあえず使ってみようは僕はよくやりますが、
そのノリをチームに持ち込むのは危険だなと気付きました。

声の大きな人に屈しないこと

結構組織の声の大きい人(役員とか、技術トップとか)の声に屈しないようにするのが
難しいところだなーとも思ってます。
「いや、それをするとうちのチームのここが回らなくなる待ってほしい」
みたいな話ができるかどうか・・・。
大きな声に流されて不要な仕組みを導入してしまうケースもあるあるですが、
自分の中で効果的な対処法を見つけるのは大変そうです。
偉いひとは、偉いもん(笑)

運用とか、自動化に限った話でない

省力化、時間短縮、人的ミス防止といった観点とか登壇者様の背景から
運用寄りの話をイメージしていましたが、
スライド見返してみるとテーマは運用だけでなく開発にも当てはまるし、
自動化だけでなく組織運営に関わるすべてのツールに当てはまるよなぁということで、
開発エンジニアの自分にとっても非常に役に立つ内容でした。

けものフレンズ駆動開発はじめました

原典(たぶん)

けものフレンズ駆動開発とは

けものフレンズに登場するフレンズたちの精神に則り実現する、楽しく生産性の高い開発のことです。
重要なのはだいたい次のようなことです。

  • 相手を褒める
  • 相手を認める
  • すごいと思った時に「すごーい!」と言う

褒めるという行為は難しい

設計書のウォークスルーやプルリクエストなどを含むコードレビュー作業において、褒めるということができている人はあまりいないと思います。

「設計書の記述が冗長でなく読みやすい」
「変数名がわかりやすい」
「あとでリファクタリングしやすいようにテストコードが書かれている」
などなど

レベルの高いエンジニアほど、当たり前で褒めるほどのことでないことが多く、自然と口から出るのは指摘ばかりになってしまうと思います。

しかし、けものフレンズを視聴したあなたは気付いたはず。

相手を認め、称えることはそんなに難しいことじゃあないと。

「きみは〇〇ができるフレンズなんだね!すごーい!」が使える場所を探す

褒めよう褒めようと、強く意識する必要はありません。
流行り文句を出せそうな場所が無いかなって探します。
そうすると、何気ないちょっとしたところが、
普段当たり前でスルーしていたところが、良いように見えてきます。
そうしたらコメントしてあげるのです。
「きみは読みやすい設計書が書けるフレンズなんだね!すごーい!」
「変数名がわかりやすーい!」
「テストコードがちゃんと書けてるからリファクタリングかんたんだね!わーい!」

そんな軽いノリで話せる空気じゃない、という現場の場合

もちろん相手との関係性とか、立場上、けものフレンズ語録が使えない人も多いと思います。
無理にけものフレンズ語録でコメントする必要はありません。
頭の中だけでつぶやき、実際の言葉は丁寧な感じにすればいいだけです。

(きみは読みやすい設計書が書けるフレンズなんだね!すごーい!)
「読みやすい設計書を作っていただけて助かります」

(変数名がわかりやすーい!)
「変数名から役割のイメージができて良いと思います」

(テストコードがちゃんと書けてるからリファクタリングかんたんだね!わーい!)
「しっかりテストコードを書いていただけたおかげで後でリファクタリングしやすいです」

脳内でならけものになり放題です。どんどんしゃべっていきましょう。

褒めるのが上手になると、指摘の仕方も上手になる

褒め方が分かってくると、冷たくなりがちだった指摘も柔らかり、相手が受け入れやすくなります。 「行数が長いので、本質的でない箇所はプライベート関数に外だししてください」

「行数が長いと感じましたので、本質的でない箇所をプライベート関数に外だししてみるとスッキリすると思います」

「このコードちょっと長いねー!プライベート関数に外だしすると読みやすくなるんじゃないかなー!」
・・・多少例に無理がありますでしょうか。私もまだまだこれからです。

実際にやってみて

まだ始めたばかりですが、相手の良いところも良くないところも以前よりよく見えるようになってきた気がします。 同時に、伝え方により気を遣い、スムーズな意思疎通ができるようにもなってきています。
これから社内で広まっていくといいなと、密かに拡大を目論んでいるところです。

SQLアンチパターン読了 外部キーの取り扱いは難しい

SQLアンチパターンを読んだ

読了後、ビンゴをやった。

ビンゴの結果

f:id:snufkin127:20170127023651p:plain
縦一列に綺麗なビンゴが並びました。

4章キーレスエントリ(外部キー嫌い)について

丸ついたもの全部の体験や感想を話すと長いので、ひとつだけ。

僕はSIer企業に就職し、9年間色んな現場でシステム構築に関わったが、
外部キーをきちんと扱うシステムに出会ったことが一度もない。 どこのシステムでも参照整合性はプログラムで担保していた。

理由は本書にも書かれている通り、

外部キー制約を省略すれば、データベース設計がシンプルになり、
柔軟性が高まり、実行速度が速くなると思っている読者もいるかもしれません。

 

多くの開発者が外部キーを避けるのは、
複数のテーブルの関連し合う列を更新する際に、
外部キー制約が邪魔になると感じるからです。

このあたりに尽きる。
他にも、テスト環境でのプログラムの動作確認時やテストのときに、レコードをちょっと削除したり更新したいなーと思っても、
参照制約で関連しているために、テスト箇所とは直接関係のないテーブルを更新しなければならなかったりするのがしんどかったりする。

外部キーを正しく扱えるプログラマーは残念ながら多くなく、
コードで参照整合性を保証する手段が多く選ばれるのだと思う。

小規模のシステムならいけるかもしれないが、
システム規模が大きくなると複雑度も増大するので、
制約に振り回されず外部キーを使いこなすというのはなかなか難しい。
ずっと課題とは思っているものの、中々解決できないことの一つです。