エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

OKR

参考

Software Design 2017年12月号

OKRとは

業績を目的結果で管理する手法。
目的に対する結果をあらかじめ明確化しておくことにより、目的の達成度を測りやすくしたところが特徴。

できたか・できなかったかではなく、できなかった場合にどれだけ目標に近づいたか、できた場合、どれだけ目標を上回ったかを見る。

OKR 作成方法

上位組織から作成していき、下位組織が役割に基づき、上位の目的を達成するための貢献を考えさせる。
ただ、この運用にばかり縛られてはいけない。
基本的には上記運用だが、上位組織の意思決定が遅い場合、臨機応変に対応する必要がある。

SMART

OKR作成時に心がける概念。

  • Specific:具体的に
  • Measurable:計測可能に
  • (Stretch but)Achievable:(厳しいが)達成可能なもの
  • Relevant:(目標達成に)関連性が高いもの
  • Time-oriented:期限を明確に

上記条件をもとに、採用する目標を決める。

OKR のレビュー

目標を100%として、計測した値をもとに達成度を計る。
そうすることで、次の目標の判断材料にする。

JJUG CCC 2017 Fall参加報告

http://www.java-users.jp/ccc2017spring/assets/img/jjug_logo.png

公式サイト

www.java-users.jp

受講セッション

  • AsciiDocとPlantUMLでドキュメント作成
  • JVM上で動くPython処理系実装のススメ
  • Pivotal認定講師が徹底解説!Spring Bootの本当の理解ポイント
  • Java SE 9の紹介: モジュール・システムを中心に
  • JDKの新しいリリースモデル
  • Java x ArduinoのIoT アーキテクチャパターン

感想

ちょっと遅れて到着。
遅れた原因は、京葉線ですよ。。。
強風のせいかと思ったら、具合の悪い人を搬送したためでした。
最近の京葉線は止まらなくなったんやで。ほとんどの人が、まだ京葉線は風でよく止まるって思ってるらしいけど、とまる可能性は山手線の方が高い。
火事とか路線に人入ったとかで。

AsciiDocとPlantUMLでドキュメント作成

JJUG CCC 2017 Fall #ccc_a1

AsciiDocの存在は知ってました。
知っている理由は、ブログ書くのにもっと楽な方法がないかと探しているときに見つけた。
けど、AsciiDocをサポートしているブログってないから、Markdownをサポートしている「はてなブログ」になった。
でも、有用であることは知っていたので、今はどんなものか気になった次第で聞いた。

だいたい知ってることが多かったかな。
Markdownとの比較が多かった。

Markdownを使っていると不満はいくつかある。

個人でしか使わないので、あんまりチームでの問題点はわからなかったな。
チームで使っていくうえで、インデントがみんなバラバラは、ソースコードでもあるね。。。
一番Markdownで気に食わないのは、表の記述。
セル内で改行とか、マジでイラッと来るんだよ、Markdownは!
2次元な表記は、asciidocでも面倒くさそう。。。
表の定義とセル内容の記述を別々に分けたほうがいいのではなかろうかと最近思ってる次第。

PlantUMLも、もちろん知ってました。
ただ、記述方法は分からないけど。。。
技術系サイトでUML使いたいってことはよくある。
しかし、やるとなるとastahとかで作って、画像を張るくらいのことしかできねぇしな。。。

見た感じ、かなり簡略化して書ける上、デザイン状も問題ないな
問題は、やっぱりアウトプットが創造できないのが問題だね。。。

gradle使ってドキュメント環境そろえられるのね。
おそらく、ドキュメントのCI環境を構築していると思われる。
複雑なUMLは無理だそうな。
そんな複雑なUMLが必要な場合、大抵、設計を見直したいい気がする。
使う上で、そんなに問題はなさそうな気がする。

導入は、うちの会社じゃ絶対無理だろうな。。。
そもそも、ドキュメント=EXCEL思考だろ常考みたいな雰囲気だもの。
最近はマジで転職を考え始めたわ。

JVM上で動くPython処理系実装のススメ

www.slideshare.net

聞くきっかけは、Pythonに興味があったから。
業務で使ったことないけど、機械学習とかを視野に入れたかったので、基本的な記述は覚えてる。

cafebabepyっていうPython3のJava処理実装を作っていく上での話だった。

開発状況をツイッターにあげることで、周囲からアドバイスをもらって開発をしていたようだ。

実装するにあたっては、両方の言語の闇を見ていたのが、よく分かった。。。
聞いていて、実装したときに即時で試せるREPL環境がないと厳しいという点に興味が湧いた。
なぜ必要かと言うと、即時確認できないとフィードバックが遅くなるから。
そういった意味でも、Java9でREPLが入ったメリットは大きい気がする。

話が難しい。。。
そもそも構文木とかを考えるって概念が今までなかったから、話についていくのでやっとだった。。。
簡単な言語(Basicとか?)の処理実装をJavaで試して見てもいいかもしれないと感じた。

Pivotal認定講師が徹底解説!Spring Bootの本当の理解ポイント

www.slideshare.net

事故を起こさないために、SpringBootは、Springの基礎を覚えることが大切。
SpringFrameworkは、DIが根幹。
SpringFrameworkの問題点として、設定多すぎの問題があった。
始めるのが難しすぎて、初心者が触りにくくなっていた。それを解消するために登場したのが、SpringBoot。
大雑把に言うと、SpringBootは設定の塊。
また、spring-boot-autoconfig.jarには、SpringBootで使える全てのライブラリ(Thymeleaf, Mustache, FreeMaker...)が入っており、定義に基づいて使うもの/使わないものを選別してデブロイする。

最終的な結論、リファレンス読みましょうって認識だけど、それでOK?

やっぱり講師の人って身振り手振りが大きくなってしまうんだな。。。 林修氏もそうだし。。。

Java SE 9の紹介: モジュール・システムを中心に

www.slideshare.net

デスクトップ背景に狂気を感じる。。。
興味も湧くけど、恐怖も湧く自分がいる。
あれは、なんだったのだろう?
現代アートだろうか?

JavaSE9

プログラミングが大きく変わるわけではない。基盤部分が大きく変わる。
jar地獄の他に、内部パッケージを公開しないようにする目的があった。

  • jar地獄
    モジュール単位で依存関係整理
  • 内部パッケージ
    公開を制限することで安全に使ってもらう

module-info.java

自モジュール内は、宣言していなくても使える。 モジュールの定義エラーは、コンパイルエラーになるので、不正が早期発覚しやすくなる。
標準ライブラリは、明示的にrequiresする必要はない。
暗黙の内に使える様になっている。

リフレクション

javase9からは、公開されてないとアクセスできない。
module-infoにopensを指定すると、公開はしないけど、リフレクションのターゲットにすることができる。
java9で、リフレクションに強い制約がかかってる。

その他アップデート

  • 不変コレクション
  • try-with-resourcesの改善 tryのカッコ内に変数宣言を書かなくても良くなった
  • インタフェースにprivateメソッド定義可能
    用途は、デフォルトメソッドの処理を外部化するのがメイン。悪用されそうな気がするのは俺だけだろうか?
  • "_"1文字の変数が書けなくなった。

あと、G1GCがデフォルトになったとかね。

感想

禁則事項ってワードに反応してしまいました。。。。 未来から来た人なんでしょうね。。。

JDKの新しいリリースモデル

オラクルで後日説明あるから、正式公開ができないとのこと。

今までのリリースは、大きい機能のために、小さい機能が遅れることが多々あった。
リリースも遅れるのが常習化していた。 他の言語のバージョンアップと比べると、Javaだけすごく遅い。。。
リリースサイクルが早くなるのは、要求として強くなるのは同然か。

リリースサイクルが6ヶ月おきに変わる。
必ずリリースは行い、そのタイミングで完成した機能を入れていく方針らしい。
機能削除も6ヶ月おきになる。
だから、非推奨のものは、なるべく使わないように動かないと、あるバージョンから突然使えなくなるような事がある。
今までよりリリースサイクル短いので、注意しておく必要があるとのこと。

Zガーベージコレクション?みたいな話が出ていた。
なんかスゴいGCみたい。詳しい話は後で出るからあんまり聞いてなかった。
ドラゴンボールが、ドラゴンボールZになるくらいのインパクトかな?って勝手に思ってる。
まさか、ドラゴンボールに影響受けてZつけたとかじゃないよね。。?

JCPの承認プロセスは変わらず。
6ヶ月サイクルに間に合うのかという問題もあるが、試してみてどうなのかになりそう。
サイクル変更には、全員合意なので、なるべくリリースされるように協力していく体制はできているはず。

まだ、本決まりではないようなので、変わる可能性があるらしい。
だから、ふ~ん程度の認識でよさそう。

Java x ArduinoのIoT アーキテクチャパターン

ラズパイいじろうとは思いつつ、なかなかできてないので、他に簡単な方法あればと思い、藁にもすがる思いで聞いた。
当然、最前列で聞いてましたよ?
ちなみに、ラズパイは1つ持ってますが、棚に飾ってある状態。

Arduinoとは、OSSの電子工作が行えるボードのこと。 ラズパイとの違いは、OS焼き込み不要/低消費電源であること。
ラズパイいじっていて思ったけど、ラズパイはIoTではないってのが、ようやく腑に落ちた。
よくよく考えたら、たしかに、Linuxいじってるのと変わらねぇからな。。。
IoTとかのワードに騙された感がする。

Lチカって、LEDチカチカの略なのか~
初めて知った。字面見た時、あの青いコンビニの新商品?って思いましたわ。

やりとりをHTTPベースにしたりもできるのね。
今、ちょうどIoT製品を業務で作っていて、HTTPサーバーで連携していたりするので、今の知識が使えそう。
Webエンジニアの可能性が見えた気がした。
デモで、ツイートに応じてLEDの点灯をやっていた。山本さんらしいデモだった。
やっぱり、実物をみると触ってみたい感がする。
これは、ものづくりの血が俺にも流れていると思ってもいい?
家に帰って早速ポチりました!
自分が買ったのは、下記のやつです。

遊んだら、ブログにまとめてみようと思います。
やっぱり、実物をみるとテンションの上がり具合が違う。

全体感想

Javaから離れてるけど、追いつけないほどの技術差は出てないと思った。
今は、Typescript使ってゴリゴリ開発している。今はもっぱらsyslog調査員となっているがね。。。
1日中、黒い画面でsyslogだけを見る日々を過ごしていると、精神的にくるものはある。
たぶん、俺じゃなかったら発狂している人出てるだろうねってレベル。
Javaは、技術者として食っていけるレベルになった最初の言語なので、なるべく置いていかれないように努力せんといけないって感じてる。

あと、今回から順路が整備されましたね。
通れる道筋が決まった方向にしかイケないようになった。つまり一方通行ですね。
なんか、夏と冬にある某同人のイベントみたいだな~って勝手に思ってました。
人がかなり多くなってしまったので、そういう処置をするのは当然ですね。

セッション数がかなり多くなった印象。
こんなに多かったっけ?
それだけ人が増えたのかな?
見たいセッションが重なってるのが惜しいな。。。

そういえば、アンカンファレンス?をやっていたな。
ScalaMatsuriから影響受けたのだろうか?
いまいち仕組みを理解できずにスルーしてしまいました。

見たかったセッション

  • SpringBootとMyBatisでデータベースを可視化する
  • サーバーサイドでの非同期処理で色々試したよ。
  • ユニットテストアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て
  • Java 9を迎えた今こそ!Java本格(再)入門
  • 劇的改善 CI4時間から5分へ〜私がやった10のこと〜
  • Design Pattern in Presto source code
  • オレオレJVM言語を作ってみる(四則演算するだけだけど)
  • Java でつくる本格形態素解析
  • 最近のDeep Learning事情とJava

見たら、あとで後日談的な感じでまとめておきます。。。

タスク

  • Arduinoを使ってみる
  • Jigsoをもっと詳しく調査
  • AsciiDocについてまとめてみる
  • 見たかったセッションのスライドを確認しておく

取った写真

f:id:suzaku0914:20171118220013j:plain

気になった資料の調査(11.19 追記)

SpringBootとMyBatisでデータベースを可視化する

speakerdeck.com

DBデータ定義確認ツールの作成話。
DB定義をエクセルにまとめて、ファイルが肥大化するのは、よくある話。
しかも、必ず同期しているとは限らないのが、非常に厄介な点。

それを回避するためにshisyamoっていうツールを作ったらしい。
使っているものは、SpringBoot+MyBatis+MySQL
全部知っている。。。
久々にMyBatis見たけど、変わってないな。たぶん、今でも使えると思う。
ORマッパー周りは、あんまり進化してない印象がある。
Doma、MyBatis、Hibernateが有名なのだろうか?
SpringDataで作れそうな気もする。
触ったことないけど。。。

業務効率化のために、新たにOSS?でツール作る志は学ばないとね。
大抵は、面倒くさいから手軽な方法を取ってしまうからな。
その方法を取った場合、力が何もつかないから。。。

サーバーサイドでの非同期処理で色々やったよ

サーバーサイドでの非同期処理で色々やったよ - Google スライド

Guava → RxJava2への移行話。
Guavaが分からないので、たぶん、聞いても前提知識不足で分からなかったかも。。。
非同期処理って、意外と難しい。
Javaだと概念がそもそもあまりないから、学習コストが多いのかもしれない。

今回の資料を見てると、非同期処理はやっぱり必要な気がする。
HWの進化の限界が見えてきたから、限られたリソースを上手く使う方法を身につけておくのは、将来的に役立ちそう。

ユニットテストアサーション 流れるようなインターフェースのAssertJを添えて 入門者仕立て

www.slideshare.net

AssertJは知っていたけど、文法は見たことなかった。
ざっくり見ていた感じ、助長な記述が減っている印象。
JUnit使ってて思っていたのは、いっつもassertEquals~で始まって、処理の記述が長くなることを不満に感じていた。
IDEで補完きかせればOK って思うかもしれないが、意外と記述が多いものはストレスがかかる。
Javaをディスってるわけではない。Ruby賞賛ってわけでもない。
記述の多さ=複雑さと感じ取る傾向が、人間にはあるような気がするのです。
AssertJは、それを回避できそうな気がする。

問題は、簡素化しすぎて読めなくなるようなことが無いかだけ心配。
これは使ってみないとわからないね。。。
どっかのタイミングで使ってみます。

Java 9を迎えた今こそ!Java本格(再)入門

www.slideshare.net

Javaの各バージョン毎の記述が、どのように変化しているかの遷移だね。
基本的に理解できているので、個人的には大丈夫な内容だった。
若手や初学者で、古い環境に使っている人が最新技術動向に追いつくために見て欲しい感じの資料。

劇的改善 CI4時間から5分へ〜私がやった10のこと〜

www.slideshare.net

CIの改善を行うために、テスト戦略の見直しをしたのが、個人的には新しい発見かな?
結局、時間ばかり食っているのは無駄なことが多いからで、不安定なテストを切り捨てたりしたのは、勇気ある決断な気がする。
自動テスト作っていくと感じるのは、必ず一定数の何がしたいテストなのか分からないのが出てくるんだよね。
テストコードのレビューをすればいいのだけど、意外とそういう時間は取れてないことが多い。

自動生成とか、ゴミの塊を結構な割合で増やすと思うんだよね。
ケースレビューできていれば大丈夫な気がしないでもないが、レビューワーがちゃんとレビューできているか怪しい現場に限って、ケースを自動生成したがる印象がある。
自動化は、ちゃんと自動化する箇所を見極めてやらないと無理だと感じる。

Googleって、テスト戦略を打ち出していたのか。。。
今度、読んでみよう。

聞いていて思ったのは、CIとテスト自動化はセットなんだな~ってつくづく思いました。
CIは、開発するにあたって重要な要素になっているので、テスト自動化・テスト戦略の考え方は、アンテナの感度よくしておかないとダメだと思いました。

最近のDeep Learning事情とJava

speakerdeck.com

下記の書籍で読んだた前提知識があるので、だいたいの内容は知ってた。

ディープラーニングのユーザグループや資格試験があるのか。
知らなかった。
どう接していこうか迷っているんだよね、ディープラーニング

追加タスク

  • AssertJを試す
  • Guavaを使ってみる

Slack日本語化設定方法と思うこと

Slack日本語対応

Slackの日本語版が本日ローンチ、日本語サポートにも対応 | TechCrunch Japan

とうとう対応されましたか。。。
やっぱり、日本語はわかりやすい。
画面がスッキリした印象。
漢字は偉大。
少ない文字数でイメージを伝えら得るのは、かなりメリットだと思う。

設定方法

言語が「English(US)」前提で話します。

  1. 左メニューの自分のアカウント名をクリック
  2. ポップアップでメニューが出てくるので、「Preferences」を選択
  3. 左メニューの「Language&Region」を選択
  4. Languageの選択ボックスで、「日本語」を選択する
  5. 日本語にするか聞かれるので、「Change to 日本語」を選択する。(英語と日本語まぜんなよ。。。最初から全部日本語でええやんけ。。。)

そうすると、なんということでしょう~(ビフォーアフター風)
slackの各項目が日本語に変わります。

推察

日本語対応に踏み切った要因

日本人ユーザが多く、アジア太平洋地域で収入が多いからだと思われる。
日本語は、日本人しか使ってないため、マーケティングのコアターゲットとして入ったのではないかと思われる。

対応前でも日本語は使えたが、設定変更を利用するために英語を読む必要があった。
今回の日本語対応で、日本語で設定内容が読めるため、さらなるビジネス利用が予想される。

問題点

問題としてネットワーク障害で全て停止するという懸念がある。

直近で障害を起こしてましたよね?
真因究明できているか、対策は妥当なものかは、ユーザがチェックしないといけない。

ビジネス利用

おそらくビジネス利用は増えていくと思われる。
ただ、懸念としてある問題点がネック。

リスクがあることは事実なので、Slackがどう問題に対応していくのかがネックになりそう。

実際にビジネス利用しているが、メンションがあるおかげで、誰に対して送ったメッセージなのかはわかりやすい。
あと、アイコンがあるおかげで、「了解です」みたいな返事をわざわざ返さなくてもいい。
あのメッセージを見たのかどうなのか、理解しのかをいちいちタイピングして伝えるのは、面倒くさいしね。
最低でも2クリックで伝えられるから、ストレスはすくないと思う。
ショートカットでアイコン付けられたら、プログラマーとかは便利かもね。

【書評】USJを劇的に変えた、たった1つの考え方

読書開始日

2017.11.7

もくじ

第1章 USJの成功の秘密はマーケティングにあり
第2章 日本のほとんどの企業はマーケティングができていない
第3章 マーケティングの本質とは何か?
第4章 「戦略」を学ぼう
第5章 マーケティングフレームワークを学ぼう
第6章 マーケティングが日本を救う!
第7章 私はどうやってマーケターになったのか?
第8章 マーケターに向いている人、いない人
第9章 キャリアはどうやって作るのか?

まとめノート

個人の考え含む。
著者の意図がキチンと伝えられない可能性があるので、興味持った人は買ってみましょう。

第1章 USJの成功の秘密はマーケティングにあり

マーケティングの役割

頭脳であり、心臓。
分析は、外部の立ち位置だけでなく、内部の有力者の考えも理解する必要がある。
最初にすべきは、戦術より戦略。
どう戦うかは後。どこで戦うかが先。
消費者の理解者で無くてはならない。
会社は集団である以上、しがらみを持ってしまう。(ルルーシュも言ってた!)
そのため、パワーバランスを考慮した妥協案になりがち。
利害関係を壊して、最適解を見つけ、周囲を説得して人を動かすのが、真の役割。

第2章 日本のほとんどの企業はマーケティングができていない

マーケティングは、アメリカの自由競争の中で生き残るために生まれた知恵。
(おばあちゃんの知恵袋のような感じ?)

日本では、発展しなかった。
なぜなら、下記の理由があるため。

  1. 自由競争ではなかった(規制が多い)
    既得権益を守るやつが必ずいる。(○医師会とか)
  2. 終身雇用バリア
    年功序列が根付いてしまった。マーケターは成功すると、すぐに昇進できるので、それを阻む勢力が多かった。
  3. 技術志向バリア
    技術を優先しすぎて、マーケティングを疎かにしてしまった。そのため、技術差別化ができなくなった。
    技術力向上は必要だが、全員が一定ラインに来ると差別化が必要だったのに、それをしなかった。
    日本は、そもそも競争が弱すぎたために起こるべくして起こった。

今の小学校の競争性の排除は、最終的に日本がツケを払う感じがする。
大人ほどシビアな競争はしなくていいけど、闘争心を持たせたり、勝つための方法を考えたりするのに、競争をして、大人になったときに競争の中で戦える準備はするべき。

そして、これから真の競争が始まると思う。(もう始まってるかもだが。。。)
マーケティング能力を持たない場合、国際競争力が弱くなってしまう。
マーケティングに成功するかは、日本の死活問題。
技術力が高いから、マーケティングが成功すれば日本も活躍できる。

第3章 マーケティングの本質とは何か?

マーケターとは、マーケティングできる人。
知っているだけではダメ。実行できる力が必要。
経営学部のマーケティングの教授は、研究者としてのマーケターであることを忘れてはならない。
競争社会にでれば、役に立たないこともあるから、適応能力が必要になる。

第4章 「戦略」を学ぼう

戦略的思考のメリット

選ぶことを覚えるので、リソースを集中投資する考えが持てる。
その結果、説得力の増加につながる。

戦略の定義

目的達成のため、資源の配分を決めること。
目的とは、達成したいこと。
資源は、使える金・人員。

戦略の必要性

  • 目的があるから
  • 資源は常に不足しているから、投資先を選択必要がある

足りない資源を投入先を絞ることで、足りるようにするのが戦略。

経営における資源

  • モノ
  • 情報
  • 時間
  • 知的財産・ブランド

資源は、認識してなければ使えない。
認識することで増やすこともできる。名将や軍師は、資源を増やすことが上手かった。

数的有利

数的有利は、大局の勝利を保証しない。
何を捨て、どこに集中するか選択し、数的有利を作る局面を増やすのが勝利につながる。
とりあえず全部勝つのは、戦略なき愚か者。
ただ、勉強は違う。捨てる選択ができなくなるので、知識は多いに越したことはない。

最も重要な資源

最も重要は、人。
なぜなら、人だけが経営資源を全て増減させることができるから。
逆を言えば、人が最も不足しているリソースでもある。
リソースとして最強であるが故、企業の成長を止める可能性がある。

人的資源を成長させる会社が、成長する会社。
そのために大切なのは、人事部。

目的と目標

目的:達成すべき使命で、戦略の最優先事項。
目標:目的を達成するための具体的な事柄。

日本は混合されがちなので、きちんと分けて考えることが必要。

戦略と戦術

コードギアスを見て勉強しましょう。
戦略:目的を達成するための手段
戦術:目標を達成するための手段

戦略は大事だが、戦術の積み重ねにある。
戦術が弱ければ、戦略は成功しないことを肝に銘じる。

コードギアスだと、ルルーシュは戦略重視だったが、コーネリアとの敗北から戦術の重要性を理解するわけですね。
そして、黒の騎士団を結成し、戦術能力を向上させて戦略を引き出せるようにして大きく躍進。
だが、ランスロット(スザク)の圧倒的戦術に負けることが多かった。
対策を練ることで勝利できそうなことはあったが、そもそも目的が覆ることと重なるため、勝利にならなかった。
そして、皇帝になって、圧倒的物量と最強の戦術能力を持つスザクを得たことで、不敗になるわけですね。
戦術と戦略がバラバラに存在していたときと、一緒になったときの対比が良かったと思うよ?
あと、だいたいルルーシュが戦術を軽んじると負ける。

物事を考える順番は、目的→戦略→戦術
最初に目的を決める。目的のために戦略が存在するので、目的が変わってはいけない。
変わったら、戦略も変わる。
これは戦略と戦術の関係も同じ。

上層の戦術と、下層の戦術は違う。
当事者の視点レベルで、戦略が戦術になったりすることもある。

戦略は誤ってはいけない。
なぜなら、強い戦術で誤った戦略だと、間違いに気づかずに目的から離れることが多い。
日本の失敗する企業の典型例だね。。。
戦略が正しければ、目的から大幅にズレることはない。
ただ、戦術が弱いと、結果は最大化されないことを頭に入れておく。

良い戦略の見分け方

  • selective:やるやらを明確に分けたか?
  • sufficient:投入された資源が、戦局の処理に十分か?
  • sustainable:中長期的に継続可能か?
  • syncronized:特徴を有効に使ったか?

全てあてはまる必要はない。
あくまで目安。これで行動できなくなるのはNG。

良い戦略を立てるには、情報を得て、相手と自分の特徴差を有利に活用させることが良い戦略。

第5章 マーケティングフレームワークを学ぼう

戦況分析

市場構造を理解して、味方につけるためにやる。
市場構造に逆らうのは、エネルギーが膨大にかかるので、理解する。
ただし、無理ではないので、どう使うかはよく考える。

5C分析

戦略分析の考え方。

  • company:自社理解
  • consumer:消費者理解
  • customer:流通理解
  • competitor:競合理解
  • comunity:地域社会への理解

自社理解は大切。なぜなら水の流れに逆らうことになるため。
なるべく、流れにのってやるのが、効率的。
消費者理解は、量と質で理解する。一方だけみるのは、理解できない。
消費さえ理解してないものに事実を見抜く。
流通理解するのは、リスクヘッジに近い。
パートナーでもあるが、競合相手であることを意識しておく必要がある。
競合理解は、広義の競合を理解することで、目的の明確化に役立てる。
地域社会への理解を行う意味は、コントロールできないもの(世論や倫理など)を見方に付けるため。
コントロールできないので、モニタリングが必要。

目的の設定

実現可能性

目標は、高すぎたり低すぎたりたりしてはいけない。
高すぎれば、戦略の立てようがない。
低すぎる場合、努力する機会が失われる。

シンプルさ

要素が多い複雑な目的は、戦略・戦術まで複雑になってしまう。

魅力(カリスマ性)

人的資源を増大できるか?
上からの目的を自分たちに合わせて再定義することが出来るか?

WHO(誰に売るか)

消費者は選ぶ。
万人受けするものを作ることは、かなり難しい。
万人受けをしようとした結果、へんな機能が山盛りの製品ができたりする。
限られた人に投資すれば、勝てるラインに届きやすくなる。

戦略ターゲットとコアターゲット

戦略ターゲット

予算投入する大きな括り。
目的達成できるターゲットである必要がある。
小さすぎると、非効率になる。

コアターゲット

戦略投資の中でも、集中投資するもの。
小さすぎるのは、NG。
戦略ターゲットとの違いを明確化する。

消費者インサイト

消費者インサイトとは、隠された真実のこと。
強い消費者インサイトは、知性や感情をエグルため、拒絶から入る事が多い。

WHAT(何を売るか)

選ばれる必然を作る。
競合との相対的な位置づけを作り、ブランドに対する認識をさせる。

HOW(どうやって売るのか?)

WHAT・WHOを届ける仕掛けを作ること。

マーケティングミックス(4P)

  • product
    顧客に提供するものを決める。技術志向だと機能しないことがある。WHATを明確にすることが大事。
  • price
    目指すものに適した価格設定
  • place
    販売方法
  • promotion
    効果的な宣伝。自分のセンスより消費者視点が必要。

第6章 マーケティングが日本を救う!

日本は、高信頼社会で形成されている。
自己啓発に近い記述になっているので注意

価値の共有

日本人は、一人が大勝ちするのに罪悪感を感じることがある。
嫌儲に近い。
金持ち一人を作るより、全員で豊かになったほうが、社会的にはいいはず。
ただ、世の中の多くは、そうなってないので、気をつける必要がある。

豊かである

ゆとりがあるので、信頼もできる。
これは海外に住まないと分からない。
旅行に行っただけでは、人生なんて変わらない。

情緒が最大の強み

日本は、戦術面に強いが、情緒がブレーキになり、効果的な戦略が取れないことがある。
もしかして、AIによるマーケティングの効果を最大限に活かせるのは日本?

戦略がないことが多いのが、日本人の特徴。
合理的に準備してから、情緒的に戦うのが必要。
戦略段階では、なるべく情緒を排除。

第7章 私はどうやってマーケターになったのか?

成長が望めない時代は、人事コストの最適化で終身雇用は終わる。
それによって、企業に必要なスキルを持った人に値がつく。
だから、必要となるスキルを見極めて、身につける努力が必要。

第8章 マーケターに向いている人、いない人

リーダーシップの強い人

リーダーシップとは、人を動かして結果を出すこと。
起点になって何をやったのか。
やっていたことが重要ではない。
野球部で主将をしたからといって、リーダーシップがあるとは限らない。

考える力(戦略的思考)の強い人

知性が必要になる。
大学の偏差値と知性は、相関関係が高い。
企業が大学出身しか取らないことがあるのは、高い知性を持った人の釣り場を作りたいから。
今後、人が少なくなれば、真に知性の高い人を振り分ける考えが必要になりそう。
東大出だからといっても、おかしな奴はいる。
子どものときから、戦略的に考える思考を付けさせることが、今後必要になってくる。

人の心を読める人

判断や調査の時間を減らせる。
社交的で人気者がなりやすい。
なぜなら、人を見たり接したりしないと、社交的になったり、人気が出たりはしない。

精神的にタフ

戦略の中心にいるため、成功と失敗がわかりやすい。
失敗や挫折が多く、不安の中で過ごすため、ストレスとうまく付き合う必要がある。
優等生すぎると、挫折したときに崩れる。
個のプライドを捨て、プロのプライドを持つ。

第9章 キャリアはどうやって作るのか?

会社名で選ばず、自分にあったスキルを伸ばしてくれるところを選ぶ。

弱点克服は、たいてい上手く行かない。
弱点として指摘されるのは、いつのコミュニケーション(笑)

克服すべき弱点とは、強みを阻害している弱点。
強みと関係ない弱点は、克服しにくく、メリットになりにくい。
克服しても、効果が現れるまでにはタイムラグがある。
変われないのは、タイムラグに耐えられていないことが多い。

自分の強み

強みを見つける時は、他者と比較しない。
他人と比べると、劣等感が強く出てしまい、分析にならないことが多い。

感想

コードギアスの話が多くなってしまった感。
最後の方は、自己啓発に近くなっているので、注意しなければいけない。

書いて有ることは、効果的にリソースを使いましょうってことだけだが、それはできてないことが多い。
特に日本人は。
商売だけでなく、いろいろなところに適用できそうなレベルで記載されており、ちょうどいい抽象度合いだった印象。
技術志向が強いので、それがデメリットになることを知ることができたのが収穫かな?
業界の流れを読んで、身につける技術選定にマーケティングが利用できるのではないかと思考中。
将来性を考えたら、身につけておきたいスキルだと思う。
たぶん、AIの代価がかなり難しい領域だから。

VisualStudioCodeのアイコンについて

アイコンの変更

VisualStudioCodeのアイコンがオレンジになった時は、かなり困惑した。
何しろ、VisualStudioCodeが、どれなのか分からなくなったから。

たぶん、色を反転したのだろうけど、イメージが真逆になってしまったから、文字ベースで認識しないといけなくなったから、全然わからなかったのだろうと思った。

経緯

評判最悪だったMicrosoftの「Visual Studio Code」アイコンデザインについて公式が経緯を語る - GIGAZINE

Gigazineの内容を信じるならっていう前提条件がつくけど、以下の感じ。

  1. Visual Studio製品ファミリーを表すアイコンをリデザイン
  2. 無限大ロゴをどう変えるかで意見が割れる
  3. Insider向けリリースで新たな色のオレンジを試したところ、2カ月経過してもネガティブなフィードバックが少なかった
  4. リリースしたら、ネガティブコメントが数多く寄せられる事態に
  5. ネガティブなフィードバックは加速し、ニュースメディアから高校の友人までもが新しいロゴに否定的な意見を示す
  6. アイコンを戻すことに

個人的な意見

VisualStudioCodeが使いやすかっただけに、途中でイメージが変わってしまったのは、かなり困惑した。
Windows10を使っているのだが、タスクバーにピン留めしたけど、色が違うだけでタスクバーからの起動ができなかった。
イメージが及ぼす影響がこれほどまで甚大なのかと、改めて感じた。
UIUXの重要性を再認識した。

Microsoft内でネガティブフィードバックがなかったのは、そもそもMicrosoftの人がMicrosoftの製品を批判できるわけがないと思うんですよね。
特に開発者視点ではなく、消費者視点が必要なUIUXは。

だから、UIUX絡みの変更は、開かれてないとダメなんだと思う。
開発サポートなら、蓄積された知識があったから、良い方向にできたんだと思ってる。

初期のうちにオレンジだったら、たぶん大丈夫だっただろうな。。。

今回の件を考えると、UIUXは選択できるようにしておけば良いのではなかろうかと思った。
旧デザインがいい人もいるから、変えられるようにしておかないと、苦痛を強いることになるのは、学ばなければならないな。。。

参考サイト

VScodeアイコンの変化 - Qiita

The Icon Journey [抄訳] - Qiita

Gradelまとめ

きっかけ

なんとなく知っているけど、なんとなくで終わっていることに違和感を感じたから。

参考に、下記の本をベースに学習した。

Gradle特徴

Gradleとは、Groovyを使ったビルドツール。

  • 柔軟な言語による記述
    Groovyで処理を記述するため、処理を分割したり構造化したりすることが簡単。
  • タスクによる処理の構築
    タスク単位でビルドスクリプトを作る。
  • 基本はJava/Groovy/Scala
    JavaJVM言語以外にもC/C++のビルドにも使える。
  • 各種のツールとの併用
    Antを利用したり、Mavenのpom.xmlをGradel用に変換したりするツールがある。
  • Mavenのセントラルリポジトリに対応 セントラルリポジトリを利用できる。

試した環境

OS情報

Microsoft Windows [Version 10.0.15063]

Groovy情報

Groovy Version: 2.4.12 JVM: 9 Vendor: Oracle Corporation OS: Windows 10

Gradle情報

------------------------------------------------------------
Gradle 4.3
------------------------------------------------------------

Build time:   2017-10-30 15:43:29 UTC
Revision:     c684c202534c4138b51033b52d871939b8d38d72

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.6 compiled on June 29 2015
JVM:          9 (Oracle Corporation 9+181)
OS:           Windows 10 10.0 amd64

Java情報

java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

2017/11/05時点では、Groovy/Gradleのコマンド打つとWarninng出るけど、気にせず実行。

試し実装

プロジェクト初期化

gradle init --type java-library

プロジェクト構成

.gradleフォルダ タスクで生成されたファイルが配置される
gradleフォルダ Gradle環境をまとめたラッパークラスが格納されている。
srcフォルダ ソースコード関連の配置フォルダ
build.gradle Gradleのビルドファイル
gradlew/gradlew.bat Gradleコマンド
settings.gradle 設定情報を記述したファイル

srcフォルダの構成は、Mavenと同じ。 なお、、gradle initの際に、--type java-libraryのオプションを付けると、指定した言語のサンプルコードが生成される。

build.gradleは、ビルド内容を記述したファイル。
settings.gradleは、ビルドの設定情報が記述されている。

build.gradleの基本

ビルドが基本だが、プログラムチックな動きもできる。

例えば、下記の記述をbuild.gradleに追加してgradle heloと実行した場合、pringlnで指定した内容が出力される。

task helo {
    doLast {
        println();
        println("====================================");
        println("Welcome to Gradle!");
        println("====================================");
        println();
    }
}

タスクは、doFirst/doLastで構成されている。
実行順序は、doFirst -> doLast

パラメータの利用

まずは、実験用のコードとして、下記をbuild.gradleに追加する。

task helo {
    doLast {
        def total = 0;
        for (def i in 1..num.toInteger()) {
            total += i;
        }
        
        println("total: " + total);
    }
}

やっているのは、1からnumまでの合計を出力している。
引数は、Javaと同じくStringで渡される。
ここでの引数は、numが引き渡される想定。

実行には、下記のようなコマンドを実行する。

gradle helo -q -Pnum=100

引数の渡し方は、-Pプロパティ名=値という形式になる。

動的タスクの生成

形式

task "$変数名" { /** 処理 **/ }

def arr = ["one", "two", "three", "four", "five"];
arr.each { s ->
    task "$s" {
        doLast{
            println("this is $s task.")
        }
    }
}

gradle -q oneで実行すると、this is one task.が表示される。
動的にタスクを作れるので、共通化をしやすくなる。

javaのビルドには、Javaプラグインを使う。
apply plugin: 'java'をguild.gradleを追加し、gradle javaと実行すれば、buildフォルダが作成され、その中のclassフォルダの中にコンパイルしたソース群が出力される。

テストを実行したい場合は、gradle testで実行可能。 結果のレポートは、build\reports\tests\test\index.htmlに出力される。

Mavenまとめ

きっかけ

なんとなく知っているけど、なんとなくで終わっていることに違和感を感じたから。

参考に、下記の本をベースに学習した。

Maven特徴

  • XMLでビルドファイルを記述
  • ゴールによる目的設定
    命令の記述を全て書く必要はなく、作業に必要な情報を渡せば勝手にやってくれる
  • ライブラリ管理とセントラルリポジトリ
  • テスト、ドキュメントの生成
    JUnitの実行やJavadocの生成など、開発に付随する機能を行える。

Mavenの構成

説明
binフォルダ 実行するコマンドのプログラム置き場
bootフォルダ クラスローダプログラムが配置されている
conf 設定情報ファイルの置き場
lib ライブラリ置き場

ファイルは、特に必要ないので割愛。

今回試した環境

Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-11T01:41:47+09:00)
Maven home: E:\dev\apache-maven-3.3.9
Java version: 9, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk-9
Default locale: ja_JP, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"

↑の通りなので、パスは適時読み替えて。

Mavenを動かして覚える

Mavenプロジェクト作成

Mavenのプロジェクトを作成する。
プロジェクト作成は、下記のコマンドで実行する。

mvn archetype:genarate

そうすると、Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains):みたいなことを聞かれてくる。
テンプレートとしてどれを使うか聞かれている。特に強い意志がなければ、そのままEnter。

今度は、Choose org.apache.maven.archetypes:maven-archetype-quickstart version:って聞かれる。
おそらく、下に下記のようなバージョンのリストが出て来るので、使いたいバージョンを指定する。

1: 1.0-alpha-1
2: 1.0-alpha-2
3: 1.0-alpha-3
4: 1.0-alpha-4
5: 1.0
6: 1.1

デフォルトは、最新バージョンが指定されているので、強い意志がなければ、そのままEnterでOK。

その後も色々聞かれる。面倒くさいので、まとめて説明。

Define value for property 'groupId': 
Define value for property 'artifactId': 
Define value for property 'version' 1.0-SNAPSHOT: :
Define value for property 'package' : :

groupId、artifactIdは、任意。versionは、デフォルトで1.0-SNAPSHOTが設定されている。特に意志がなければ、そのままでOK。
packageは、groupIdに指定したヤツがデフォルト設定される。管理的には、同じものを設定するのが定石みたいなので、強い意志がなければ、デフォルト設定でOK。
※なんか、流されてばっか。。。
※最初のうちは、デフォルト設定に任せた方が安心なのは分かるが、心の反逆心が許さない感じ。厨二くせぇな。。。

Mavenプロジェクトのフォルダ構成

artifactIdで指定した名称のフォルダの中身には、srcフォルダとpom.xmlがあるはず。
それぞれの内容は、以下の通り。

srcフォルダ

ソースコード全般がまとめられる場所 中身は、下記の2フォルダ。

main, testフォルダの両方共、配下にJavaフォルダがあり、その中にJavaソースコードやパッケージのフォルダを作成する。

イメージ的には下記

└─src
    ├─main
    │  └─java
    └─test
        └─java

デフォルトでは、mainフォルダ配下を潜っていくと、App.javaが生成されているはず。
ただのサンプルファイルなので、不要なら削除してしまっても問題なし。
今回は、このファイルを使っていろいろ試す。

pom.xml

Mavenのビルドファイル。XML形式

pom.xmlの基本を覚える

<project>と基本属性

使用するMavenのバージョン。
Mavenには後方互換があるはずはので、新しいバージョンが出た場合、ココを変えるだけで基本はOKなハズ。

groupId

作成するプログラムが、どこに所属するのかを宣言する。
イメージ的には、Javaのパッケージ名に近い。
Webだとドメインに近いもの。
ここらへんの感覚は、Strutsやっていればなんとなく分かるはず。

artifactId

プロジェクトに割り当てるID。
同じグループで、別プロジェクトとして識別するために利用する。

version

プログラムのバージョンを指定する。

packaging

パッケージ化する際の種類を指定する。
通常は、jarだが、zipの指定も可能。

name

アプリケーション名。
重複してもOKだが、慣例的にアーティファクトIDが指定されることが多い。

url

プロジェクトのWebサイトURL。
デフォルトは、MavenサイトのURLが指定されている。

properties

pom.xmlで利用される属性値を用意するためのもの。
ビルドで何か定数が必要であれば、ここに定義する。

dependenciesと依存関係

dependenciesでは、ライブラリ管理と依存性の定義を記述する。
初期状態では、JUnitにあるはず。

dependencyの内容

  • groupId
    利用したいライブラリのグループIDを指定する。必須
  • artifactId
    利用したいライブラリのアーティファクトIDを指定する。必須*
  • version
    利用するライブラリのバージョン。省略すると最新バージョンが適用される。
  • scope
    ライブラリの適用範囲。
    compile/provided/runtime/test/systemが指定できる。
    デフォルトでは、compile。
scopeの指定内容
compile scope の指定を省略した場合のデフォルト値。全ての状況でクラスパスに追加される。
provided ライブラリが JDK やコンテナによって提供される場合に指定します。コンパイル時のみクラスパスに追加されます。
runtime 実行時のみに必要な場合に指定。テスト実行、通常の実行のときにクラスパスに追加される。
test テストのときのみ必要な場合に指定。テストのコンパイルと実行のときにクラスパスに追加される。
system 明示的にクラスパスに追加する場合に指定。このスコープのライブラリは常に有効であるとみなされ、リポジトリの検索は行われない。

コンパイルしてみる

pom.xmlがあるディレクトリに移動し、mvn compileと叩く。

[ERROR] ソース・オプション1.5は現在サポートされていません。1.6以降を使用してくださ い。 って出るかもしれない。
出る理由は、MavenがデフォルトだとJDK 1.5 ベースでコンパイルしているからのようだ。。。
その場合、propertiesに下記の感じで記述すれば、コンパイルするバージョンを指定すれば大丈夫。

  <properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>

もちろん、コンパイルなので、文法エラーがあれば怒られる。
IDEに頼って書かなかったので、むっちゃ怒られて泣きそうになった。。。

コンパイルに成功すると、pom.xmlがあるフォルダに、targetフォルダが作成される。
中を除くと、いくつかフォルダが作成されているはず。

  • classes
    コンパイルされたJavaのクラスファイルが格納される。
  • maven-status
    compileで利用されるcompilerプラグインによって生成されたファイルが格納されている。

test-compile

compile以外にも、test-compileというゴールが提供されている。
これは、ユニットテスト用にクラスをコンパイルする。
実行すると、src/test配下に作ったJavaファイルをコンパイルする。
ユニットテストを実行する場合は、mvn testを実行する。

パッケージ化

mvn packageを実行すれば、実行可能なjarファイルが作成される。
これを実行すると、targetファイル配下に、jarファイルが作成される。
なお、このパッケージ化する前には、テストが実行される。

その他

たまにファイルが残っていることで、動作が不正になることがある。
その場合は、mvn cleanを実行する。
そうすると、targetフォルダが削除される。

セントラルリポジトリ

http://repo1.maven.org/

一元管理されているけど、利用する側から見ると見つけにくい。
その場合は、下記のサイトを使う。

https://search.maven.org/

Maven応用

リポジトリの利用

セントラルになくても、ローカルリポジトリを用意することで、公開したくないライブラリもmaven管理することができる。
また、セントラルリポジトリではなく、別の公開されたサーバーで提供されているものは、リモートリポジトリとして利用することができる。

リモートリポジトリ ネットワーク経由で利用できる公開されたリポジトリ
ローカルリポジトリ ローカル環境にあるリポジトリ