やぎしんぶろぐ

C#er/プログラミング作法

〜UX生トーク vol.5 プロトタイピングを振り返る - 人気4サービスのプロトタイピング事情大公開〜に参加してきました! <2016/12/9 (Fri)>

ブログを見てくださっている方々

 

お久しぶりです。やぎしんです。

 

最近、”情報を発信することの重要性を考える”ことが偶然ですが重なって、なんか久しぶりにブログを書きたくなって書くことにしました!笑

どこかのブログで見た

「情報を発信する人に情報は集まる」

という言葉を信じて続けてみようと思います。

 

今日のテーマ 〜勉強会の報告〜

先週の金曜日は

eventdots.jpに参加してきました。

イベントに記載されている概要をそのまま引用させていただきます。

概要

UXを生み出す現場の創り手達が、刺激を与え合う場を作ることを目的として開催している「UX生トーク」。

第5弾となる今回は「プロトタイピングを振り返る」をテーマに掲げ、Cookpad、CROSS ME、Yahoo!ニュース、Rettyの4サービスに登壇頂きます。 各サービスのプロトタイピングの変遷やプロセス、お蔵入りとなったデザインなど…他では見られないプロトタイピング事情を大公開して頂きます!

 

  UXについては私が説明するよりも詳しく描かれていることもあるかと思いますが、ざっくり言うと、”ユーザーがそのサービスを使用することによって得られる満足度を考慮してUI設計すること”ですかね?

※あえて検索せずに投稿してるので、ご指摘お願いします!笑

 

私がなぜこれに参加したかったかというと、現在の仕事柄、ユーザーの皆さんの声があまりにも遠すぎて、要件だけ聞いて作業することにもどかしい気持ちになっていたからです。ダイレクトにConsumerの声が聞こえて来る環境にいらっしゃる皆さんは、普段どういったことに気をつけてUI/UXを考えてらっしゃるのか、とても気になったので参加したかったのです。

憧れだったCyberAgentさんが主催されていることもあって(笑)、楽しみにしてた勉強会でした。

 

それでは早速・・・

緑字が私のコメント

 

Alt text

近藤 雄亮(Retty株式会社/UX Lead・Designer)
「作る楽しさ、壊す楽しさ」


デザイン  = 未来を創る

デザイナー = 未来を創る人

冒頭から凄いなこの人、と。

自分の仕事に誇りを持っているというか、

責任感があるというか、

仕事への向き合い方がわかる一言だな、と。


壊した方がいいものがたくさん!
〜つくることはたやすく、壊すときは難しい〜
①ゴールを明確に
②制限は徐々に強めていく
③中間ゴールの設定

最近仕事で、ある課題解決に時間を掛けてしまったことがありました。自社の先輩がその課題解決を一緒にしてくださったときにしていた手法が、私には思いつかない方法でした。私はそれを”切り分け法”と言っています。

「問題となっている登場人物を洗い出し、その登場人物を別の環境で同じように0から再現してみる」という方法。そうして、どこが問題なのかを明確にしてから課題に取り掛かる。0から考えるというのは、この”壊す”という意味に非常に似ているな、と感じました。一度脳内で固定されてしまった考えを一般化して考えることによって解決の糸口を探る、というのはとても重要だなと改めて感じました。

”壊す”のが難しい、という部分。これって、日本の会社(特に業務システムを仕事の支柱とかにしている会社)の文化もこういった考え方って否定的だと思いました。(私の勝手なイメージ)

労働時間や、それにかかる人件費なども考慮しないといけないですが、品質が保たれたプロダクトをしっかりリリースできるエンジニアになりたいと強く感じました。


マイリスト機能改善
課題
・行きたいお店が増えすぎて選べない
・マイリスト見返したいと思えない
・お店リストお友達とシェアしたい
ターゲット
マイリストが溜まっているユーザー

数が多いなら制限を設ける!

ターゲットに沿った意思決定をすべき!(課題解決の目的・本質は何?)

GOOD POINT
・最初は自由度高い、徐々に制限を設けた
・「壊す前提で創る」意識を全員で持つ
・新しい価値は判断が難しく、「会話で使われるか」などのユースケースを考えたこと
壊すことが楽しくなると、創ることはもっと楽しくなる!

具体的な例を挙げてご説明いただきました。ユースケースを考える、ここは品質を担保する上では必須ですね。

Alt text

関 愛奈(株式会社サイバーエージェント/デザイナー)
「プロトタイプ=コミュニケーションツール」
プロトタイプの質が高まると、共有できる項目が増えて意見の合致につながる
1. ユーザー視点に近づく
2. 認識ズレを防ぐ
3. 開発工数の無駄をなくす
これ!非常に同感です!

DBを扱ったりするお仕事の方々にはちょっと当てはまらない話かもしれませんが、せっかく可視化できる方法があるので、それを一度具体化してみるという方法は自分のアイディアを共有したり主張したりする方法としては最善だと思いました。そうすることによって、自分がユーザー目線でその案件に向き合うことができるなーと感じました。

プロトタイピングに注力するのではなく、コミュニーケションツールとして使用して
コミュニーケーションの質を高める。

勉強させていただきます。

 

Alt text

倉光 美和(クックパッド株式会社/デザイナー)
「広げる、深める、プロトタイピング」

倉光さんのプレゼンではメモを取れませんでした・・・(パソコンを膝の上でカタカタしていたので、私が暑くなってしまって断念・・・。)。

覚えていることを書きます。

 

倉光さんのチームで実践したアイディア共有ツール〜付箋〜

付箋という同じ紙媒体を使うことによって、

・みんなが

・同じ環境で

・迅速に

アイディアを共有することができるようになったらしいです。

バラバラに書いた付箋を、ホワイトボードに貼って簡易的な画面遷移図を作ったり、構成管理ツールを使わずとも簡易的なドキュメントとそのログが作れたり・・・など、凄く手頃でわかりやすくアイディアを共有できるようになったとか。

一番驚いたのは、海外のエンジニアも同じ手法でやらせてみたときに、言葉はわからずとも、”その人のアイディア”は理解できたと。言葉だと時間がかかるところを絵を描くことでカバーするというのは、私のような若手が重宝すべき「上司に自分の考えをいち早く伝える」手法だと感じました。

 

Alt text

宇野 雄(ヤフー株式会社/ニュース・スポーツ事業本部 デザイン部 部長)
「150億PVを支えるプロトタイピング」
ちょっとずつ変える。(一気に変えてしまったことによるユーザーのストレスを減らす。)

確かに、の一言です。

一気にアプリのUI変わったらストレス感じますよね・・・。


アジャイルを2週間で回す!
夢を語れるチームは強い。(現実路線で進んでしまう・・・)

深すぎますね。自社の先輩方との飲みで議題にしてみようと思います。

多分ブログ、十記事くらいになりそう・・・。


プロトタイプの基本はスクラップ&ビルド
・ツールは柔軟に使い分ける
・コードを書いた方がいいって人もいる。
・素早くイメージをぐたいかするために使う(xxxを踏襲してくださいでもいいしね!)
・あくまでゴールを目指す一つの形として
・作ったものに固執しない。

こういったマインドを持った人にである環境って凄い羨ましいと思ったし、そう言ったチームにいないのであれば、自分の力で変えていきたいと強く思いました。

働く環境というより、誰と働くか。は非常に重要ですね。

 

と言った感じでした!

いやー、勉強会に行ったらデザイナーの方々がたくさんで、エンジニアの私はちょっと「来るところ間違ったかな・・・」って思いましたが、スピカーの皆さんの貴重なお話をお聞きできる有意義な時間を過ごすことができました!

 

と、ここまでかかった時間は2時間。

ブログを書くのは非常に長いですね・・・。もっと早めに書けるように頑張ります!

(今日は定時で上がって、池袋のおしゃんなカフェでブログ書いてました。笑笑)

 

※ご意見・ご感想・ご批判、お待ちしております!※

 

それでは、また次回です。

次は1年間の振り返りでもしますかねー。

 

やぎしん

 

同期のみんなとBBQ&アルティメット東北リーグ2016 北上大会に参加してきました!

みなさん、こんばんは!

ご無沙汰しております。やぎぬましんやです。

ブログを書くことができないくらいに忙しい毎日でしたー。

久しぶりに何か投稿したかったのでブログ書きまーす!

という、3連休は割と充実してましたー!笑

 

7月16日(土)は会社の同期達とBBQ!

渋谷のBBQハウスで同期のみんなとワイワイしてきました!

久しぶりに同期のみんなに会えたのが本当に楽しかったし、嬉しかったです。

なかなか集まれなくなってきちゃって寂しいですが、今後もこういう機会には積極的に参加したい!

そのあとは4時間くらいカラオケ!笑 まだまだ若いなーなんて思ったりしました。

だってそのあとそのまま会津まで行きましたから。 (自慢にはならないか。)

後輩のかずやの家に少しお世話になって、いざ北上へ!

 

7月17日、18日(日、月)はアルティメット東北リーグ北上大会に参加!

待ちに待った北上大会参加でした!

那須大会は私のエントリーミスで参加できませんでしたが(いやー倍率高すぎるよ福島大会・・・)、やっと会津大学OBOGチームで出場することが叶いました!

土曜日練習したんですが、俺は参加できず・・・後輩との練習試合でコテンパン(?)にされたってチームのみんなから聞いてたので、俺が入ったらもっとやばいだろうなーなんて思っていました・・・。

試合一つ一つを振り返るのはさすがに長くなるので止めておきますが、今回は決めごとも少なかったし、ゲーム中に話し合うのも少なかったので、”チームとしてどうすれば確実に点数を取れるか&ディフェンスしやすいか話し合う”というのを自分から実践していきたいと思います。※そんなに知識ないけど

 

結果としては、準優勝!!!

チームのみんなのおかげで、いい試合だったなーって思える機会が多かったです。

一番に感じたことは、「まだ動ける!上手くなれる!」でした!

 

これまでいろいろ葛藤はありました、アルティメット絡みで。

なかなかこういうところでは言えない内容です・・・。

でも、今回の北上大会でまたアルティメットやりたいなーって思えました!

何にせよ体が資本なので、体作りをしていきます!とかさんがおっしゃっていた、「5分10分でも毎日体を動かす」というのをやっていきます!そして米沢大会で過去の自分と大学の後輩達にリベンジします。

そうそう、エンジニアの方々にはこの本がおすすめです!

Amazon CAPTCHA

エンジニアとして、どのようにしたら仕事もプライベートも充実させることができるのか。というところが書かれています!

この本の中に、「ブログを書くと良い」って書かれててすごくうれしかったです。笑

あと、東北リーグとかで「ブログ見たよ!」って言ってくれる方々がいらして、それもまたすごく嬉しかったです。

誰かが見守ってくれている、そんな気持ちを持ってこれからもブログを書いていこうと思います!

 

また書く暇が出来たら書きますねー!(ネタはいっぱいあるんで)

DevOpsハッカソン

先週の土日、6月11、12日に日本マイクロソフト株式会社の牛尾剛さん主催のDevOpsハッカソンに参加させていただきました!

 

率直な感想ですが、「あー、まだまだだなー。」と。

なぜなら、ハッカソンは環境構築で詰まって終わったから。笑

Gitサーバーにコミットしてプッシュして、プルリクエスト出して―・・・(ムシロコノタンゴノイミスラシラナイジョウタイ)

あれ?コミットした内容が競合?ん? dllが競合????動かない・・・。ってのが起こって結局何もできなかった。

 

でも、イベント全体で学べることはたくさんありましたよ。学べることしかなかったです!

  • ”Ask for Help”という考え方

  1. わからなかったら聞く。
  2. 聞かれたら答える。
  3. 聞かれた内容がわからなかったら「わからない」と言う。

上記の3つを”普通”にやる。(ここでの”普通”の意味は、感情や固定観念に左右されずにただ受け入れるという意味です。)これがソフトウェア開発の生産性をあげることができる方法!らしい。牛尾さんの上司の方はこの考え方で牛尾さんに接してくださるらしいです。何でもかんでも質問するのは微妙かなーと思ったので、質問の線引きは怠らず行こうと思いました!

  • 弊社で推しているMicrosoft Azureについての勉強ができた!

Azureって凄いなーと思ったところが、DevOpsの為に作られてんじゃないかってくらい作りが精巧だってことですかね。開発、運用プロセスをどのように早く回していくかのエッセンスが盛り込まれていて、本当に便利なんだなーと思いました。(日々の業務で”強制的に勉強する”環境が欲しいなーと思いました⇒わがまま。)

  • そのAzureにはどのような便利な機能があるのか知れた

特に、自動ビルドのところ。ビルドして、デプロイまでしてくれるところ。まぁこれもなんかふわっとしてるなー。泣 勉強。

  • ”機能フラグ”という何とも便利なAPIもあるということを知れた!

プログラミングであらかじめif文を書いておいて、それを別のWebページからそのif文分岐をスイッチできるようにさせておけるもの!これによって、”今はこのページは表示させたくないから簡易モードで開くようにしておこう”とか、”この人からアクセスされたら、このボタンを押せるように表示させておきたい!”とかが簡単にできる。俺は使ったのはこれ!(Feature Flags | LaunchDarkly

※これは自分的にすごく良かったです。QCDのQ(Quality=品質)はどこで実現していけばよいのか結構考えてるんですが、この方法によって”一つ一つの課題を解決していく”感がすごいしました。

  • チームビルディングの重要性。

ハッカソンの経験者がほとんどいない今回のハッカソン(そもそもOpsの人たちはハッカソンをやる、という機会が少ない。)。なかなか最初の時点で打ち解けることができなかったし、自分よりも年齢が一回り(失礼極まりない)も違う人たちとコミュニケーションを取ることがすごく難しかった。発言しても言葉を遮られたりしてしまって、上手く自分の意見を伝えることができませんでした・・・。これって普段の仕事でも凄い大事ですよね!

あと、自信なさげに発言すると、相手が受け取る印象も違うと思うので、自分の言動にも客観的視点で見れるように意識付けしていきます!

  • 改めて、C#頑張ろう・・・。

やっぱりね、凄い思う。Visual Studio入ってるパソコンがあるんだから、もっとやってみます。Xamarinも楽しそうだし、今回のハッカソンで久しぶりにMVCモデルで開発したけどなかなか思い出せなかったし、今現場で使ってるのWPFだし。

 

総括

ハッカソンに出て、正直落ち込みました。普段の仕事で、やってる感出してて何もわかってなかった。ショックすぎて、家に帰って一人でビール飲んでしまった・・・。

牛尾さんの、「失敗から学ぶことは、成功から学ぶことよりも多いし、感じることも多い。」という言葉を信じて、今後も何事にもチャレンジ精神を通していきたいと思います!

 

コードのコメント文の書き方について

皆さんお久しぶりです。笑

昨日、同期の川村くんに”お前、ブログ止まったな”って言われたので、溜めてたネタ出していきます。笑 (勝手に名前出してごめんな)

 

さて、先日以下の本を買いました!(といってもデブサミの時だから2月18、19日か。)

 

www.oreilly.co.jp

 

この本には、コードを書く上で成果物の品質をどこで高めていくか、というところのエッセンスがたくさん書かれています。

抜粋すると、

  • 変数の命名力向上
  • ”1行で書く複雑なロジックでどやぁ” よりも ”簡単に理解できる複数行のコード”(C#で例を挙げると、LINQを思い浮かべます。)
  • コメントの書き方~そこでコードに想いを込める~
  • タスクの細分化をコードベースやる方法

もっといろいろあるんですけど、この本で学ぶことは中々に多かったです。

 

・・・で、先日尊敬する先輩社員の方にソースコードレビューをしていただいたんです。

結構自信ありげに「お願いします!」って言ったんですが、レビュー指摘の中にこんなものが。下記、そのまま引用です。

 

コメントの書きっぷりについて

コーディングの内容をそのままコメントとして書くのは、

メリットより、デメリットの方が多いと思うので、私的にはあまりやらないようにしています。

コーディングとコメント、両方メンテナンス対象になるため。

私的な「そのままコメント」を書く指針としては、以下の感覚です。

  • そのままコメントがいらないように、極力シンプルにコーディングできないか検討する
  • (考えてもダメなくらい)実装がすごく複雑である場合は、必要な分だけコメントを書いておく(全てはなるべく書かない)。

コメントに関しては、諸説あるので一概には言えません。

なので、意見の一つとして参考にしてもらえればと。

 

この内容、まさにあの本に記載されている内容のことを指摘されてしまいました。

うわー・・・と。自己レビューで気付かないくらいそんなに焦ってたかなーと。

 

コーディング&コメント書いてて、”ただ何の気なしに書いたコメント”程、可読性が下がるものはないなということを身をもって感じました。

また、コードレビューで指摘される内容が、徐々にリーダブルコードに書いてある内容に近づいてきた(つまり、コーディングの指摘ではなくなってきた)ので、自分の日々の成長も少しだけ実感することができました。

 

 

コメントって難しいなー。最近コードで時間を掛けてしまうのが、変数とメソッド共通化検討。それにコメントが加わってきたら、今後自分の工数はどこまで膨れ上がっていくのでしょう・・・。QCDのバランスをみて、”早く、質の高いコメントを残せる”ように!これは、慣れ?笑

 

 

de:code Day 2

Day2

5 月 25 日 (水) 9:30 - 18:30

09:30 ~ 10:30 DEV-022 これから始める Xamarin ? 環境構築から iOS/Android/UWP アプリのビルドまで ?
10:45 ~ 11:45 DEV-011 TypeScript ~ Any browser. Any host. Any OS. Open Source ~
13:10 ~ 14:10 DEV-001 リアルタイムデモで実感!Visual Studio Code の極意
14:25 ~ 15:25 DEV-005 200 時間以上お客様と向き合ってみえた Team Foundation Server による開発業務効率化の実現方法
15:55 ~ 16:55 DEV-023 Xamarin Deep Dive - Xamarin.Forms の可能性
17:10 ~ 18:10 CHK-001 All about DevOps ? DevOps 第一人者のガチトークバトル!

ちょっと遅くなりましたが、de:code2日目の振り返り。

いやー。熱すぎる2日目。ではレビューを殴り書きで。

 

 【これから始める Xamarin 〜環境構築から iOS/Android/UWP アプリのビルドまで〜】

<Speaker>

写真:千代田 まどか

千代田 まどか日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
テクニカル エバンジェリスト

 
写真:田淵 義人 氏

田淵 義人 氏 エクセルソフト株式会社
ソフトウェア事業部 
Business Development Manager

 
写真:砂金 信一郎

砂金 信一郎 日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
部長 エバンジェリスト

 
写真:高橋 忍

高橋 忍 日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
プラットフォーム エバンジェリスト

 

ちょまどさん人気は凄かった。笑

 

  • ターゲットプラットフォーム特化型のこれまでがXamarinで変わった!!
  • クロスプラットフォーム特化型>と呼ばれるXamarin。Xamarinの導入によって、C#/.NETだけでiOSAndroidWindows Appアプリが作れる。
  • 高価だったXamarinが、Windowsが買収したことによって、タダVisual Studio上でコンパイルができるようになった。
  • ※ただ、UIはネイティブコードで作ったほうがよい。(エンドユーザーの求めているものに少しでも近づけられるから。)
  • Xamarin.Formsという、Xamarin Nativeの進化版で画面の共通化が容易になった。
  • UIコードも統一&XAMLで記述 (XAMLC#によって全てを開発できる環境が整っている。)これね。C#覚えたら勝ちってこと?笑
  • ページのレイアウトは6つから選択して、19種のコントロールをレイアウトにはめ込む形。WPFxamlとはちょっと違う感じがする。

ちょまどさんから一言。

①すぐに始めよう ②JXUG(ジェイザグ)と呼ばれるXamarinコミュニティあるよー
③ちょまどをこれからもよろしく。

 

【TypeScript ~ Any browser. Any host. Any OS. Open Source ~】

<Speaker>

写真:井上 章

井上 章 日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
テクニカル エバンジェリスト

 

井上さんのプレゼン、すごい聞きやすかった。なんでなんだろう。堂々としてるってだけじゃないんだよなー。

 

  • TypeScriptはコンパイルをするとjsファイルが作成される。(コンパイラはTypeSctiptで作られているらしい。)
  • TypeScriptはオブジェクト指向型の言語としてコーディングすることができるので、C#でコーディングしている現場の人たちは入り込みやすいのかな?
  • TypeScriptでの記載がC#と違ったのでちょっと見づらかったけど、getterとsetterの考え方などを導入できるし、protectedなどの修飾子も使えるので、始めのうちは明示的に宣言しておくと、より入り込み易いかな。

TypeScriptも面白そうだけど、やっぱりC#の勉強を進めていくべきかなーって改めて。

 

【リアルタイムデモで実感!Visual Studio Code の極意】

<Speaker>

写真:戸倉 彩

戸倉 彩 日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
テクニカル エバンジェリスト

 

写真:池田 尚史 氏

池田 尚史 氏 GitHub, Inc
Solutions Engineer

 

戸倉さんに一度お会いして見たかったんですが、お忙しすぎてタイミングを逃してしまったー。

Visual Studio Codeを使ったデモが大半占めていました!

 

以前、自分のMacに入れてコーディングしてみようと思ったんですが、よくわからないエラーが出てきたので断念してました。(開発環境構築で手詰まりしてたら何の意味もない、って砂金さんか高橋さんがおっしゃってたなー・・・)

 改めて着手してみたら、できた。というか、Permissionがそもそもないところに作ろうとしてただけだった。笑

 

IDE(※)でもなく、ただのエディタでもない、それぞれの良いところを持ってるVisual Studio Codeを使ってこれからコーディングしてみようと思います。まだ.NET入れられてないんだけどね・・・。.NETが入ればC#で開発できるらしい!

 ※プログラミングするための開発環境のことで、エディタとかコンパイラとかばらばらで存在しているものを一つにまとめて開発しやすくしたもの!

 

 

【Xamarin Deep Dive - Xamarin.Forms の可能性】

<Speaker>

詳細を見る
 
写真:田淵 義人 氏

田淵 義人 氏 エクセルソフト株式会社
ソフトウェア事業部 
Business Development Manager

田淵さんのセッション!

朝一発目のちょまどさんとのセッションでXamarinの面白さをずっとお伝えしてきている、という熱い魂を持った方と印象を受けたので、田淵さんだけのセッションでは何がお聞きできるのか、というところが気になったのでこのセッションに!

以下、箇条書きで!

  • Xaml.Plugin.Mediaでカメラなどのプラグインを使うことができる(つまりカメラアプリとかつくれちゃう)!
  • Xamarin.Forms はこれまでUIは個別に作り込む必要があったNativeを変更し、ビルド時に自動マッピングしてそれぞれの言語で使えるUIの作成に成功!

(Xamarin.Formsの可能性)

  • OSS、将来性、Microsoftのバックアップ
  • 良さ:ワンソース ⇄ マルチUI 自動マッピングして、各ネイティブのUIコードができる(例①) DataPages = JSONのURLを指定するだけで、UIも綺麗にまとまっちゃう例。(例②) WorkBook = 仕様書+コードを書く 仕様書を基にコード化してくれるらしい。それが広まったら世の中のエンジニアの仕事の形態が変わっちゃわない?って単純に思いました。上流工程大だね

 

田淵さんのGithubアカウント。ここにXamarinに関するコードやらなにやらが掲載されているらしい。

github.com

 何やら楽し気な雰囲気を感じたので、早速Xamarin Studioをインストールしました!土日にちょっとコーディングしてみようかなと思います。(実機で試してみたいので、Android端末欲しい・・・)

 

【All about DevOps ~DevOps 第一人者のガチトーク バトル! ~】

詳細を見る<Speaker>
 
写真:牛尾 剛

牛尾 剛 マイクロソフト コーポレーション
ITPro - Japan
シニア テクニカル エバンジェリスト

 
写真:吉羽 龍太郎 氏

吉羽 龍太郎 氏 Agile , DevOps, Cloud コーチ

 
写真:前佛 雅人 氏

前佛 雅人 氏 クリエーションライン株式会社

 
写真:高添 修

高添 修 日本マイクロソフト株式会社
デベロッパー エバンジェリズム統括本部
エバンジェリスト

 

以上の4名の他に、倉貫さんというDevOps界では名の知れた方が傍聴者でいらしてたらしく、急きょ5人体制でやってた。形式は座談会。

一番熱い話が聞けたセッションでした。

”本当にその選択が正しいの?ってのを常に考える、それを会社全体で選択していかないといけないよね!って皆さんがおっしゃってて感慨深かった。

以下、箇条書きで。

 

  •  日本は遅い!!(CHEFの人に聞いたら”日本は8年遅れている”らしい)

<どうしたら早くできる?>

  • そもそも日本が遅いのは→従来型の開発モデルでやらないと、リスクが・・・ってところが大きい。
  • 経営者はプロジェクトの承認を恐れる。Opsは外にあるから、ってなるとそもそもDevOpsになってない。
  • いい加減、開発の流れを変えていったほうがいいよねー。
  • Opsの面での悩み、その解決法は?)→それがあったらセッション化してる!笑
  • 底上げが大事!若手!⇒単純に、頑張ろうと思った。
  • DevOpsは宗教に負けてはならない!※宗教とは、会社の伝統的な?なぜやっているかわからないような行事や言動。俺もこれがあったら、ちょっといろいろ考えるなー。
  • 前佛さん「クラウドを見ることによって、開発者と運用者が同じゴールを見るようになった。だからクラウドを導入する動機が”クラウドをやろう”ではなかった。」
  • SIerが儲からないから誰もDevOpsやらない。
  • 今の日本は、”ITがあるからビジネスを発展させていこう”ではなくて、”ビジネスを成功させるためにITを使おう!”ってなってる。

Opsは今後どうしていくべきか?>

  • 高添さん:IT系、人間系の二つに分かれる。
  • 圧倒的敗北を経験すべき。(人が運用をするコスト>>機械が運用するコスト)
  • だからコードが書けないOpsの人は今後使われない。スキルで金を稼げないとだめ!(ただ、人に優しくないとか協力的じゃないやつは絶対重宝されない!)
  • 日々の学習は非常に大事。
  • 定年まで仲良く頑張ろう!の時代は終わってる。会社としては、勉強&教育の機会を与えてあげなければ、だめ。

ー牛尾さんがDevOpsが好きになった理由ー

アジャイル開発の推進の人だとそれしか話せない。でもエバンジェリストだとなんでもできる!それを伝えていきたいから、何でもやる!→牛尾さんのDevOpsハッカソンに出ることにしました。

 

<DevOpsに関してどのようなテクノロジーを学ぶと良いか?>

  • トレンドの技術を学ぶとか、自動化したいからとかだったら出直したほうがよい。テスト自動化でどれだけのコストが削減できるのか、などの少し深いところまで考えた時にDevOpsがいいなと思ったらやるべき。
  • サーバレスアーキテクチャ!(アマゾンでは導入している。コードをサーバにおいておけばサーバのコーディングは何もしなくて良い!Azureはそこらへんもすごいらしい。)
  • ってなると、やっぱりXamarinはすごいきてる!エンドユーザからのフィードバックは重要。カスタマイズ指向だと、バージョンが変わったときに大変。GOがきてるらしい。

 

このセッションで、”Xamarinを学んでおいたほうがよい”というのが繋がって、締めのセッションとしてはとても充実していたと思う。

 

ではでは総括を後程。

 

 

 

de:code Day 1

行ってきました!de:code 2016

〜Day 1〜

10:00 ~ 12:00 KeyNote すべての人の可能性を拡げるモバイルファースト、クラウドファーストの世界
12:45 ~ 13:30 SNR-002 間違いだらけの IoT プラットフォーム~今すぐビジネス拡大に繋げるためのデータ基盤構築~
13:50 ~ 14:50 SPL-003 黒船襲来!世界DevOps トップ企業 x マイクロソフトによるトーク&デモバトル セッション
15:05 ~ 16:05 SPL-005 オープンソースから見たマイクロソフト
16:35 ~ 17:35 DEV-020 Bot Framework & Cognitive Services ~自動応答ソリューション開発に挑戦~
17:50 ~ 18:50 CLT-005

今こそ WPF ~ モダンデスクトップアプリケーション開発再考 ~

 

 タイムスケジュールはこんな感じっすね。

 

【すべての人の可能性を拡げるモバイルファースト、クラウドファーストの世界】

<Speaker>

写真:Satya Nadella
 

Satya Nadella

Chief Executive Officer,
Microsoft Corporation

 
写真:Steven Guggenheimer

Steven Guggenheimer

Corporate Vice President &
Chief Evangelist,
Microsoft Corporation

 
写真:Akira Sakakibara

Akira Sakakibara

Chief Technology Officer
Microsoft Japan Co., Ltd.

 
写真:Katsura Ito

Katsura Ito

General Manager,
Developer Experience & Evangelism Lead,
Microsoft Japan Co., Ltd.

でも、他にも!

牛尾さんや井上さん、戸倉さん!

そして、海外の企業からDevOpsの先駆者の方々・・・

(Chef、MESOSPHERE、Hashicorpのそれぞれの社長と米MicrosoftSam Guckenheimerさん

激アツすぎるよー。歴史的瞬間を目の当たりにしました(ってまじで適当なこと言ってますが、本当に凄かったんです・・・。)

 

で、ざっくりな内容を箇条書きにて。

  • りんなちゃんの話から。人間にはやっぱり自然言語が一番身近で、Bot conversation & Conversation as a platformで実現しているりんなちゃんにこの自然言語を学ばせることによって、ほとんど人のAIが今後生まれるらしい!  で、"Botはテクノロジーの塊”らしい。将来は、"ピザ3枚注文してー"って文字列を打つと何枚?って返してくれて注文までやってくれたり・・・”飛行機が遅れているから違う飛行機予約する?”って話しかけてくれたり・・・”ホテル予約してー”ってお願いしたら近くのホテルを探して勝手に予約してくれたりするかもらしい。りんなちゃんにLINEして、みんなで育てよう!※タレコミ情報だけど、近々りんなAPIが公開されるらしい。
  • 先日アメリカ(?)で行われたMicrosoftのBuild 2016では、cmdで開いたターミナルでbashシェル動かして、lsコマンドを打つだけで現地の人たちは興奮していたらしい。笑 でも、正直Windowsの環境でUNIXコマンド打てるのは俺でもびっくりした。
  • ”自動車の会社はもうソフトウェアの会社だ”ってSatya Nadellaさんはどっかの社長に言われたらしい。笑 どこだっけ?トヨタ

  • からの・・・Satya Nadellaさん、”未来はソフトウェアで動く”。生活の中にもっとコンピューティングというものが浸透していくと。ユビキタスコンピューティングが今よりもっと身近になると。(ユビキタスコンピューティングは死語だと思ってたけど、まさかこの言葉が出てくるとは・・・。)

  • Microsoftは、分散型のクラウドインフラとかIoTとかに力を入れていきたいみたい。(社内ハッカソンでRaspberry PIいじってるし、それをAzureにつなげてた。)

  • ”すべての開発者のためにマイクロソフトは提供していくだろう。”って。これは最近のMicrosoftの動き方を見ると”そうですよねー”ってなりました。Satya Nadellaさんに社長が変わってから動き方も変わったのかなーと。

  • ”テクノロジーとは?何ができる?” → そのテクノロジーで、”あなたは何ができる?”と問いかけ。世の中にはこれだけのテクノロジーがあるのに、何もしないの?と少しワクワクさせられました。

  • 開発者同士の会話、知識共有は非常に重要。これは俺も最近現場で感じております。
  • 全てがWindowsのデバイスであれば何でもできるし、スケーラビリティ(柔軟性)の点でも価値の高いものが今後Microsoftのソリューションから出てくる。
  • そして、Office365のおかげですべてのソリューションを一つに管理することができる(?)。本当?
  • Xamarinのデモで(戸倉さん)Azureで動く対話型のデータビジュアライズツールであるPower BIとD3.jsを使ってde:code関連のツイートが世界のどの地域で多かったのかを可視化するデモをやってた。スペックの高いマシンを使うとD3.jsでもしっかり動くんだなーと感じました 。僕は卒論でD3.js断念してccchart使いましたが。※D3.jsとかccchartとかは、あるデータを見易いように加工して表示してくれるJavaScriptのライブラリです。

そして僕は話に夢中でパソコンのタイプを諦めた・・・。笑

 

【黒船襲来!世界DevOps トップ企業 x マイクロソフトによるトーク&デモバトル セッション】

<Speaker>

写真:牛尾 剛

牛尾 剛 マイクロソフト コーポレーション
ITPro - Japan
シニア テクニカル エバンジェリスト

 
写真:Sam Guckenheimer

Sam Guckenheimer Microsoft Corporation
Partner PM Manager

 
写真:James Casey 氏

James Casey 氏Chef
VP of Partner Engineering

 
写真:Aaron Williams 氏

Aaron Williams 氏Mesosphere, Inc.
Head of Developer Advocacy

 
写真:Mitchell Hashimoto 氏

Mitchell Hashimoto 氏 Hashicorp
Creator of Vagrant, Packer, Consul. CEO of Hashicorp

 
写真:鈴木 逸平 氏

鈴木 逸平 氏 クリエーションライン株式会社
執行役員

※え、なんか写真貼れた。

 

とりあえず、殴り書き。
サムさんはTFSなどのサービスなどをリリースした。まさにDevOpsの先駆者
 

  • DevOpsを会社に導入する際に何に気をつけたらよいのか。どういう準備すればよいのか。→会社を挙げての改革が必要。でも変革には覚悟が必要だ。経験値が豊富な会社とのつながりが非常に重要。変革というのは本当に大変だ。
  • 正しいツールを使ってDevOpsを広げていく→DevOpsのイベントには絶対に人は集まる
  • 新しい技術を導入し続ける(学び続ける)ということは非常に大事(というかやるべき)。
  • DevOpsで自動化するところはする。DevOpsの良さを見極めるためにもまずはやってみることが重要。
  • どの事象においてもコミュニティーが大事。一人では何もできないということかな?

 

オープンソースから見たマイクロソフト

<Speaker>

 

写真:まつもとゆきひろ 氏

まつもとゆきひろ株式会社ネットワーク応用通信研究所フェロー
一般財団法人Rubyアソシエーション理事長

 

 

RubyMicrosoftを嫌っていたのではない。MicrosoftRubyを嫌っていたのだ。”

 

良き隣人として、Microsoftと関わっていくらしい。

ほとんど愚痴だった。笑

 

 

Bot Framework & Cognitive Services ~自動応答ソリューション開発に挑戦~】詳細を見る

写真:ジニアス平井 (平井 昌人)

ジニアス平井 (平井 昌人) 日本マイクロソフト株式会社
マイクロソフトテクノロジーセンター
テクニカルアーキテクト

 

ジニアスさんの話、難しすぎて全く覚えてない(泣)

 

SkypeBotを使う → ピザの注文がチャットでできる!それが、企業でも応用できるよね!ってやつ。

一番の謎。Bot FrameworkでMicrosoftが目指すゴールってなんだろう?

今後の動向は目が離せません。

 

【今こそ WPF ~ モダンデスクトップアプリケーション開発再考 ~】

<Speaker>

写真:東 賢 氏

東 賢 氏 インフラジスティックス・ジャパン株式会社
代表取締役/シニアUXアーキテクト

 
写真:山口 慧 氏

山口 慧 氏 インフラジスティックス・ジャパン株式会社
ソリューションコンサルタント

今の現場ではWPFを用いて開発しているのですが、”なぜWPF?”ってところはブラザーのasiさんに教えてもらったようなもらってないような・・・って感じだったので、改めて学びたかったので!

Web言語とWPF
本気でJavaScriptで取り組む覚悟があるのか。(スクリプト言語の進化のスピードに柔軟に対応できるシステムが作れるのか?ってことですかね。)
 

UWPとWPF
〜UWPにできないこと〜

DBに直接アクセスできない。
ファイル、印刷関係、UI上では画面はシングルページでしか起動できない。
 

※まずUWPって何?→Universal Windows Platformの略で、新しいOSと考えてよい・・・のかな?UWPの上にWindows10が乗っかってて、10で動作する様々なデバイスで柔軟な画面レイアウトの配置変更だったり、機能を変えたり、ってできる、でよい?笑

Q.10年後、安定して使えるテクノロジーは?
A. ない。マイクロソフトですら考えてない。
→3年くらいのスパンで考える。もっとも安定したランタイム環境は.NET
 
なぜあの時、WPFにしなかった?
GPUの普及の問題でWPFのためのランタイム環境に問題があった。
・スキルセットがない。(Windows.Formsで慣れているから・・・)

Windows.Formsって、WPFとかSliverlightとかが普及する前にクライアント画面を作成するために用いてたAPIのこと
 
WPFXAMLって?
・データバインディングでデータを表示。
バックエンドロジックとの疎結合(画面レイアウトの変更が容易になっている)
 上の太線が結構一番の良さだと思う。


Click Once

主な特長として、(ノータッチ・デプロイメントと比べると)何といってもローカルにプログラムがインストールされるために、実行時のセキュリティ設定を柔 軟に指定できるようになり(セキュリティ制限をまったく受けずに実行されるようにすることもできる。ただしこのように書くと、セキュリティ面で問題がある ように思われるかもしれないが、それについては続編で詳しく述べよう)、またこれによりオフラインでも利用できるようになることだ。もちろん従来のノー タッチ・デプロイメントのようにインストールせずにWebから直接実行する配置オプションも残されている。ClickOnceには、状況に合わせて選べる 多彩な配置オプションが用意されているのだ。

 の技術を用いてWPFが動いているのも良さらしい。

現実的なことを東さんがおっしゃっていて、ビジネスに用いるならこれを考えろと。

  • 「クライアントテクノロジーは変わるもの」と納得する。
  • システム全体のメンテナンスサイクルとクライアントテクノロジーは切り分けて考えよう。
  • UWP or WPF or Webを考える前に、クラウドへの対応を考えるべき。サーバサイドはより安定しており、API志向の設計に切り替えていくほうが安全。
  • WPFは直近の選択肢。数年先に切り替えることも視野を入れてモダンなUI設計をするきっかけにすると割り切る(もちろん、切り替えないかもしれない。)

 

と、もうセッションの最中でログを残すのも一苦労で・・・。

家に帰ったらばたんきゅーでした。

 

これをみて、後で思い出せるかなーは微妙(泣)

少しずつ編集していこうと思います。

 

Day 2は後ほど!