2017年5月30日火曜日

「Mesos Meetup Tokyo #1」に参加しました


「Mesosってなに」からデモもあって初心者にとってはとてもわかりやすいMeetupで、非常に勉強になりました。資料だけでなく動画もイベントページで公開とのこと。すばらしい!

Opening、会場説明


Mesos User Groupsは世界で25都市が登録。Mesos Conなどが開催されている。
Mesos User Group Tokyoは、2ヶ月に1回位勉強会を実施予定。

Mesosは、2009年の論文からスタートし、2016年頃にコンテナ技術の発展とともに盛り上がり始めた。今、最も注目されている技術の1つ。

Mesosってなに



質問「Mesos使ったことある人?」 => 半分くらい

Apache Mesosの概要


仮想化環境のシステム管理では、クラスタのリソースを効率的に管理するのが難しい。今までは、クラスタは組めても、クラスタ個別の最適化まで。
データセンターのリソース全てを管理するのがMesos。Lunuxカーネルのリソーススケジュールと同じ原理でデータセンター全体を管理する。

Apache Mesosのメリット


これまではクラスタ個別の管理のため、リソースの有効活用に限界があったが、Mesosを使うと、データセンター全体でリソース配分ができ、データセンター全体で最適なリソース配分ができる。

Apache Mesosの生い立ち


2009年の論文がスタート。
2010年にはTwitterが使い始める。
2011年にMesosという名称になり、データセンターのリソース最適化というコンセプトになる。
2013年にMesosphereという会社が立ち上がる。
2016年にコンテナオーケストレーションが盛り上がり、その1つとしてMesosも盛り上がりはじめる。

Apache Mesosの主な特徴


http://mesos.apache.org/


  • LINEAR SCALABILITY
  • HIGH AVAILABILITY
  • CONTAINERS
  • PLUGGABLE ISOLATION
  • TWO LEVEL SCHEDULING
  • APIS
  • WEB UI
  • CROSS PLATFORM


Mesosの導入企業


airbnb, NETFLIX, UBER, Twitter, yelpなどモダンなサービスの多くでは既に採用されている。

Apache Mesosのアーキテクチャー


基本はこの3つ。

  • Mesos Masters
    マスターはスレーブのタスク調整と管理を行う。スレーブ、フレームワークを管理し、リソースの割り当てと最適配置を行う。冗長化構成が基本で、ZooKeeperを用いて冗長化を実現している。
  • Mesos Slaves
    スレーブはどれだけタスクを処理できるかをマスタに報告し、マスタからの要求に応じてタスクを実行する。タスクの1つ1つをコンテナ化して実行するため、コンテナオーケストレーションの技術と言われることがある。
  • Framework
    ユーザーが利用するインターフェイス。SchedulerとExecutorで構成される。SchedulerはMesosマスターへのJobの登録を担当し、オファーを処理。Executorはタスクをs実行するスレーブ上のプログラム、コマンドなど。DevOps tooling, Long Running Services, Mechine Learning, Big Data Processing, Batch Scheduling, Data Storageなどの分野で多くのツールがMesosに対応しており、Mesosのフレームワークとして用いることができる。


重要なフレームワーク



  • Marathon
    長期実行アプリを起動するよう設計されたフレームワークの1つ。Mesosを使うならMarathonも使うというくらい定番。コンテナオーケストレーションには必須。


  • Chronos
    バッチアプリを起動するように設計されたフレームワークの1つ。Airbnbによってcronの代わりに開発されたフレームワーク。

Mesosphere DCOS


Mesosをカーネルとするならば、MesosphereはデータセンターOS。Mesosの上にMesos SDK, Marathon, Chronosが乗っている。MEsosphere Enterprise DCOSは、Enterprise製品としてのMesosのディストリビューション。
Mesos単体ではカーネルレベルなので活用が難しい。MesosphereにはOSS版もある。

MesosとDCOSで実現できるあんなことこんなこと


Mesosのデモ。
MesosはThoughtWorks Tech Radar Vol.16でも紹介されている。

AWSからDC/OSをインストール


https://dcos.io/install から。
入力項目はほとんどない。お金がかかるので注意。

クラスタ環境へのアクセス方法いろいろ


ブラウザからのアクセスが簡単。慣れてくるとCLIが便利。

サービスの起動方法いろいろ

  • App JSON
    JSONでサービスを定義してコマンド1発で起動できる。
  • Universe
    GUIでパッケージを選択して簡単に起動できる。

コマンド1発でAzure上にDC/OS環境を作る方法


https://www.slideshare.net/ToruMakabe/1azuredcos

Azure上にDC/OS環境を作るデモ。
先程のプレゼンでAWSは15分だったけど、Azureはコマンド1発でいける。10分以内でできる。 => 今回は7分41秒で成功!

Azure Container ServiceはIaaS+。Managed PaaSではない。インフラとDC/OSの環境構築を楽に早く作る仕組み。DC/OS、Kubermetes、Docker Swarmを選択可能。




Mesos・DCOS Deepdive(English)


データセンターは、ハード、OS、アプリという単純な構造から変化している。マイクロサービスによって柔軟で、効率的で、頑強で、個別にスケールできるより複雑な構造になっている。アプリの言語の種類もバージョンも違う。全てがコンテナの上で動く。

データ処理は、バッチ、マイクロバッチ、イベントプロセッシングと変化している。イベントプロセッシングはマイクロ秒のレベルの高速処理。

Apache MesosはTwitterが採用し、今ではApacheのトッププロジェクトで、多くの先端企業が採用している。

DC/OSはモダン分散アプリケーションを可能にする。コンテナ上のマイクロサービスとビッグデータ分析を実現する。

ユースケースの1つ。esriはScalaでイベントソーシング、Kafkaでメッセージブローカー、Spark、Elasticsearch、JavaScriptの地図アプリというスタックで処理をしている。=> デモ

設定変更、バイナリの変更、クラスターのメンテナンス(バックアップ、リストア、再起動)などを管理することができる。

多くのコンテナで動くサービスにおける、モニタリング、ログ分析、アップグレード、障害対応、トラブルシューティングなどの課題に対処できる。

DC/OSの中のクラスターは他のクラスターからアクセス可能な仮想IPを持つ。DNSが仮想IPを指し示すことでServieに名前でアクセスできる 。

LT: おぷすた開発者がDC/OS on OpenSUSEでMesosに入門してみた的ななにか


Meoss, DC/OSをOpenSUSE(Linux)上で動かす。OpenSUSE, VirtualBox, Vagrant, DC/OSとインストール。 いろいろ大変だけど、なんとか動くよ。

LT: RancherでMesosクラスタをデプロイしてみる的ななにか


Rancherを使ってMesosを簡単に立ち上げるデモ。Rancherはコンテナ環境を管理するためのOSS。RancherでGUIでコンテナを立ち上げて、監視もできる。
Rancher ♡ Mesos

LT: サービスカタログと夏フェスにまつわるなにか


https://www.slideshare.net/cyberblackvoom/ranchermesosmarathon?next_slideshow=1

初心者が、Mesosを学ぶための情報紹介。

  1. Mesosってなに?のリンク集。
  2. RancherとMesos。Rancherにはオーケストレーション環境を簡単に構築できる環境テンプレートがある。Mesosも。本家のカタログもコミュニティのカタログもある。
  3. Rancher, Mesos, Marathonをつくる手順。



2017年2月23日木曜日

「Polymer.co-edo meetup #1」に参加しました


Reactでアプリつくって、最初はよかったんだけど段々と「うーん」となって、Vue.jsやRiotがいいと聞いてさわってみても「うーん」で、Angular2はTypeScriptが苦手なので「うーん」で、そういえば、昔Polymerさわったなぁと思っていたらちょうど勉強会があったので参加してみました。
結果、とても好きになりました。なんでPolymer0.5のときイマイチと思ったのかなぁ。


Extensible Web


Polymerの説明の前に主催者の岸田さんからExtensible Webの話がありました。
その詳細はオリジナルをみてもらうとして、私は次のムーブメントだと理解しています。

Web 標準化団体がWebをつくるのではなく、全てのエンジニアでWebをつくっていこう

これまでも、jQueryなど外部のライブラリで実現されていたことが標準仕様に取り込まれてきた歴史はあるけれど、はっきりと変えていこうという意思表示に美しさを感じます。


Web Components / コンポーネント指向


Extensible Webの次はWeb Components。
Web Componentsが何かというのはW3Cの仕様のとおりということになります。
Web Componentsはコンポーネント指向の仕様で、Webのコンポーネント指向について、私は次のように理解しています。

開発者が(HTMLとCSSとJSを使って)新しいコンポーネント(タグ)を定義して再利用できるようにする

この考えにあてはめると、ReactもVue.jsもRiotもコンポーネント指向です。
でも、これらはW3CのWeb Components仕様に準拠しているわけではなく、準拠しているものには、MozillaのX-TagsやGoogleのPolymerなどがあります。
X-TagsとPolymerを比べると、Polymerの方はGoogleらしく、Material Design、Google API、Progressive Web Appsを取り入れたものがすぐ使えるという特徴があります。


Progressive Web Apps


Progressive Web Appsは、Googleが提唱しているWebアプリです。
仕様がある訳ではないようですが、私は次のとおり理解しています。

ネイティブアプリと同じように、インストールできて、ホームから素早く起動できて、オフラインでも使えて、プッシュ通知もできるなどの特徴を兼ね備えたWebアプリ

Googleのサイトに従ってやれば、できなくないですが、Polymerを使うとPWAが簡単にできるとのこと。


Polymerを使ってみる


岸田さんがGoogleのCodelabsに登録されているチュートリアルのうち、 Polymerに関連したものピックアップしてくれています。
今回は「コーディングなしでGoogleMapを作ってみよう」をやってみました。

Polymerには、すぐに使えるWeb Componentsが用意されているので、HTMLとCSSがわかれば、JSを使わなくてもある程度のことができてしまいます。
その他のWeb Componentsも使えて、WEBCOMPONENTS.orgでは開発者が自作のweb componentsを公開できるそう。


Polymer.co-edo meetupは定期的に開催するそうだし、Polymer 2.0は2017年の第1クオーターのリリースを目指しているそうなので、今年中に何かアプリをつくってみようと思います。

2016年12月19日月曜日

優秀なエンジニアになる方法

最近、私なりに優秀なエンジニアになる方法がみえてきた。
優秀なエンジニアといってもレベルはいろいろあるけれど、ここでは、仕事をする中で、複数の人から「あの人は優秀」と言ってもらえるという基準で考えてほしい。

どれも、普通のことだけど、この普通のことを続けるかどうかで大きな差が生まれるのだと思う。
大切なプロジェクトから去るにあたり、後を任せる若い2人に向けてこの気づきをシェアしておく。

技術書を読む


昔、先輩にこんなことを言われたことがあった。

気になった本があったらすぐ買え。
積読でもいい、わからなくてもいい、はずれでもいい。
後から役に立つものもあるし、ずっと役に立たないものもある。
それでも気にせず、気になった本があったらすぐ買え。 

結局、本が一番学習のコスパがいい。
若くてお金がないうちは、ハズレの本を買ってしまうと損をしたと思ってしまうかもしれないけれど、トータルで考えると決して損をすることはない。

勉強会にでる


勉強会にでるだけで優秀になるということはない。
勉強会のよいところは、新しい技術のキーワードをひろえたり、ファーストステップを楽しくクリアできることと、社外の優秀なエンジニアとのネットワークが築けることだ。
単純に、楽しいのでモチベーションがあがるという効果もある。

知識があまりないうちは、有名そうな勉強会やカンファレンスにでてキーワードを拾ってくるだけでいい。
ハンズオン勉強会があれば、積極的にでるといい。
新しい技術を学ぶときは、ハンズオン勉強会にでると、変なところでつまずいて嫌にならないのでとてもおすすめだ。
まずは、勉強会の情報をチェックできるようにすることだ(dots.とかを使って)。

実際にサービスやツールをつくってみる


学んだことを活かして、小さくてもいいから、サービスやツールを自分でつくってみると、世界が広がる。
何をつくっていいのかわからないのなら、ハッカソンにでてみるのがおすすめだ。
初心者歓迎のハッカソン(はじめてのハッカソンとか)もあるので、臆せずに飛び込むといい。

自分で何か思いついたら、大したものでなくても、似たようなものがあっても、気にせずにとにかくつくってみる。
学習という意味では、車輪の再発明は決して悪くない。
必ず得るものがある。

コミュニティにとびこんでみる(ウィークタイズ)


興味をもって学んでいくと、気になるコミュニティがでてくる。
そのときは、自分の実力なんて気にせずにとにかくドアをノックしよう。
多くの場合、優しく受け入れてくれるし、強く束縛されることもない。
最近では、こういった弱い結びつき(ウィークタイズ)がとても重要だということがわかってきているらしい。

ワークライフシナジー


そんなことをやっていると、ただでさえ忙しいのにプライベートの時間がなくなってしまう。
ワークライフバランスといって、ワークとライフを分けてバランスをとるのはエンジニアには難しい。
その代わり、エンジニアはワークライフシナジーをしやすい。
今やITはライフと密着しているので、エンジニアとして成長すると、ハッカソンにでてライフを楽しくするアプリをつくったり、自分で自分の趣味に役立つアプリをつくったりできる。
ワークでもない、ライフでもない、ワークとライフが混ざりあった領域をつくって楽しめるエンジニアになるのが一番だと思う。

2016年9月4日日曜日

「HTML5 Conference」に参加しました


カンファレンスに参加しただけで新しい知識や技術が身についたなんてことはないけれど、新しい技術のキーワードがインプットできて、色々な刺激を受けることができました。
講演資料を探していたら、まとめを発見。

http://qiita.com/hidenorly/items/40ac3e9dbf757ce4df52

私が参加したのは次のセッション。

Reactの最新動向とベストプラクティス
小林徹(株式会社TOLOT)

丁寧に説明という感じではなく、キーワードと簡単な説明だけで歴史や特徴から最新動向まで幅広にという感じでした。
基礎については、これまで何となくわかっていたことを体系的に説明してもらえたので、自分の頭の中が整理されました。
知らなかったことは、聞いてもよくわからなかったけど、キーワードはインプットできました。

講演資料
https://speakerdeck.com/koba04/reactfalsezui-xin-dong-xiang-tobesutopurakuteisu

AudioとガジェットをWebで遊ぶ
河合良哉(Yamaha Corporation of America)

普通に音の再生や録音をする話なのかと思っていたら、シンセサイザー的なことが比較的に簡単にできるという、もっと面白い話でした。
また、音楽だけでなく、Bluetoothの話もあって飽きさせない。
自分としては、実際に使うシーンは浮かばないけど、簡単にシンセサイザーみたいなことができて、とてもおもしろかった。

講演資料
https://ryoyakawai.github.io/html5conference2016/index.html

Material Design を使ったマルチデバイスに対応するデザインの作り方
鈴木 拓生(Google)

Material Designの基本的な考え方から、フレームワーク、ツールまでの一通りをわかりやすく解説してくれました。
ご本人もおっしゃっていたとおり、内容は[Google Design](https://design.google.com/)に全てあるし、基本なんだけど、対面で説明してもらえると腹落ち具合が違う。
もしかしたら勘違いなのかもしれないけど、少なくともやってみようというモチベーションはサイトをみるよりも圧倒的。
とてもよいセッションでした。

Webアプリケーションにおける機械学習活用の基礎
中井 悦司(Google)

Linuxで有名な中井さんがなんと2年前に機械学習に興味を持ち、今はGoogleにいらっしゃるとのこと。
できる人は何をやってもできてしまうのか。。。
データを2種類にわけるような基本的な機械学習の原理から、顔認識の方法まで解説されました。
手書きの数字の認識の機械学習の説明を交えたデモが面白く、機械学習に非常に興味が持てました。
tensor flowについては結局よくわからなかったので、紹介された本をポチりました。
おまけのGoogleの顔認識APIはすぐにでも使えそう。

講演資料
http://pt.slideshare.net/enakai/web-65150969

Progressive Web Apps の導入基礎
片山 雄介(株式会社リクルート住まいカンパニー)

PWAってWebアプリでもネイティブアプリのレベルのUXにというくらいでしか理解できていなくて、実際に使う事例はとてもためになった。
もう、すぐにでも使いたい!
紹介されたSumoで使っている機能の事例は次の3つ。

  • Add to Home Screen
  • Push Notification
  • Offline Cache

特に3つめがメインで、次のような紹介がありました。

オフラインクックブック

※オフラインでWebアプリを使う際のベストプラクティス

App Shellアーキテクチャ

※テンプレートは全てキャッシュして、データだけネットワークにとりにいくアーキテクチャ





2015年12月28日月曜日

「トマトHack!!」に参加しました



少しハッカソン疲れして、最近はハッカソンお休み中だったのですが、トマト好きとしては出ずにいられないということで参加してきました。
参加して、ホンダの小林三郎(エアバックの開発者)の次の2つの言葉を思い出しました。

「イノベーションは若者からしか生まれない」
「スペシャリストはイノベーションリーダーにはなれない」

私の場合、このアイディア、この時間、このメンバーならここまでは固くて、このあたりにリスクがあると、無意識に計算してしまいます。
それが無意識のブレーキになって突き抜けられない。
突き抜け感を得られるまで、これからもちょいちょいハッカソンに参加しようと思いました。

1日目 アイディアソン



  • 午前:オリエンテーション、キーノートスピーチ、技術紹介、食材紹介
  • 午後:課題討議、課題解決のアイディアだし、ピッチ、チーミング
  • その後、Hack!、その後、トマト料理で懇親会

という流れ。

アイディアソン


アイディアがあまりソフトウェアよりではなかったのが印象的でした。

優勝したチームのアイディアはトマト売り場に、その日のトマト情報をしゃべって教えてくれるトマト大使キャラクターをつくるというもの。

私が参加したのは、トマト王子ことトマト生産者大畑さんのアイディア。
数ある高知のブランドトマトをコンプリートするために、食べて記録したり、現地にいってスタンプラリー的なことをするアプリ。
アイディア交換のときにお話した自分のアイディアを取り入れてくれていたので迷わずこのチームに参加しました。

チーム構成


リーダー(トマト生産者)
プランナー:1名
エンジニア:2名(私含む)
エンジニア兼料理:1名

最終的なアイディア


高知トマト八十八箇所 〜トマト博士の通った道〜

  • 地図のうえに、高知のブランドトマト約50種類があって、タップするとコメントや写真を記録できる
  • 各ブランドトマトごとに、記録するとレベル1、誰かにシェアするとレベル2になる
  • 1種類のトマトでもレベル2になると、御朱印帳がもらえる
  • 高知のブランドトマト(約50種類)をすべてレベル3にすると、高知県がトマト博士に認定してくれる


1日目のHack


開発方針は次のとおり。


  • 地図はGoogle Map
  • バックエンドはNiftyのmBaaS
  • HTML5/CSS3/JavaScriptでつくってMonacaでモバイルアプリに変換


もう1名のエンジニアがネイティブのiOSアプリの方が得意だったのだけど、私ができないのでHTML5にしてもらいました。

1日目でmBaaSからとってきた情報をGoogle Map上にのせるところまでつくり、MonacaでiOSアプリに変換するところまで完成。
並行して、カメラで写真をとって、Data URIに変換する(mBaaS上に保存するため)ことろも完成。
Google Map上にD3.jsで画像をのせるところに時間がかかりましたが、想定の範囲内だったのでOK。
懇親会の後、うちに帰って、画像をクリックしてモーダル画面を起動してコメントや写真をmBaaSにアップするところをつくりました。


2日目 クック&ハッカソン


2日目は作業が14:00までと短いので、機能を追加していくよりも、デザインを少し調整したり、料理をして実際にアプリを使ってみたいなぁと思っていました。
ところが、バグがいくつかみつかり、バグFixに時間が。。。
さらに、MonacaでiOSアプリに変換したら、まったく動かなくなっている!
最終的にはMonacaで1からプロジェクトをつくりなおして、解決しましたが、かなり時間のロスがありました。

並行してメンバーがトマトパンやおいしいトマト料理を作ってくれていたのですが、ほとんど会話ができませんでした。
2日目はもう少しメンバーと会話しながらアプリのコンセプトを成長させたかった。。。

発表・審査・表彰


発表はパワポではなく、模造紙くらいの大きさのポストイットで。
あえてアナログの紙でプレゼンというのもよかったですし、メッセージの伝え方もうまくて、同じチームなのに聞いていて楽しかったです。
デモもとどこおりなくでき、審査員の反応もまずまず。
アプリづくりという意味では一番しっかりしていると思ったので、もしかしたら賞も狙えるかもと思いましたが、残念ながら何も賞はもらえませんでした。

優勝したチームは、実際のトマトにプロジェクションマッピングで顔をつけて、トマトの紹介をするというもの。
凝った作りこみはないけれど、実際のものが目の前にあってインパクトがあるし、かわいいし、審査員が言っていたように、すぐにでも全国のスーパーで使えるので優勝は納得。

感想


1日目の懇親会やHack中に生のトマトやトマト料理をたくさん食べられたので、トマト好きとしては、本当に楽しめました。
日本酒にあうトマト料理のアイディアも考えていたので、それを試せなかったのは少し残念ですが。
技術的には、mBaaSとMonacaを使って短時間でスマホアプリをつくるのは良い経験になりました。
反省点としては、開発にもっと非エンジニアを巻き込んで、自分の壁を壊してもらって、もっとおもしろいものにしていく必要があると感じました。

身内へのダメ出し


とてもよいハッカソンだったのだけど、身内が主催をしているので、あえてダメ出ししてみます。

説明が長い


高知、ハッカソン、トマトと内容自体が多いのでしかたないのかもしれませんが、ギュッと凝縮してほしかったです。
あえて全部伝えずに、Hackの最中にコミュニケーションとってもらうようにしてもよかったのではないでしょうか。

説明がくどい


コンサルの職業病だと思いますが、手法などの説明がくどかったです。
価値は説明をうけて感じるものではなくて、やってみて感じるものなので、説明は最小限でよかったのではないでしょうか。
やった後に、あれってどんな手法なのかを参加者から聞かれるくらいが一番ちょうどいいし、かっこいいと個人的には思います。

2015年9月8日火曜日

とあるソフトウェア開発者と品質管理者の戦い

ソフトウェア開発は、製造業と違って品質データのバラつき大きく、定量的品質データ分析が適用しにくい業界です。
そのため、うまく品質管理ができていないことがよくあります。
以下は、私の体験をもとにしたフィクションです。



キャラクター


高見
品質管理担当者。
ソフトウェア開発の仕事をしているが、設計もプログラミングもできない。協力会社に発注してルールを守らせるのが主な仕事。



板垣
開発者。
意味がわからないルールを強制されるのが大嫌い。






戦い(その1)〜いい具合の指標値!?〜




板垣さん、お客様がコンサルタント会社の品質指標はダメだら考えてほしいって言われたので、考えてみました。
とりあえず、基本設計工程分だけみてもらえませんか
かなり、いい具合だと思いますよ。




<基本設計工程品質指標>
項目下限指標値上限
レビュー密度(人時/ページ)-20%0.3+20%
欠陥密度(件/ページ)-20%0.3+20%
※数値はフィクションです。

<選定方法>
・類似プロジェクト2つの平均値を入手。
・その2つの間をとって指標値を設定。
・そこから+-20%で、2プロジェクトの平均値が入るので、上下限は+-20%に設定。




(どこがいい具合!?)
いや、ダメでしょう。これじゃ品質分析できないですよ。
そもそも、この上下限に何%のデータが入る想定ですか?
上下限に入らなかった場合はどのようなアクションを想定していますか?





(うるせーやつだ)
いきなり、そんなに質問されても困りますね。
何%のデータが入るかとかデータ分析のことは指標値を決めた後に考えます




一度に色々言い過ぎましたね。順番にいきましょう。
上下限外はOK/NGの判断ではなく、現物・現場・現実の確認を効率的に実施する(対象絞り込み)ための道具という認識でよいですか。





(うるせーな、何でもいいよ)
そうですね。その認識です。






そうですよね。
ソフトウェア開発のデータはバラつきが大きいので。
ちなみに、同一仕様、同一プロセス、同一開発規約、同程度のスキルのチームで多数の開発を実施(12開発Gr)しても、品質データは大きくばらついたというデータもあるんですよ。





(しらねーよ)
へー、そうなんですか。勉強になります。






次に、この上下限に何%のデータが入るかです。
IPAが毎年品質データを出しているので、それをみてみましょう。
とりあえず、下限:第1四分位、指標値:中央値、上限:第3四分位として、ご提示の値と比較してみましょう





SEC BOOKS:ソフトウェア開発データ白書2014-2015
<基本設計工程品質指標>
※下限:第1四分位、指標値:中央値、上限:第3四分位
※カッコ書きは品質管理者の提示値
項目下限指標値上限
レビュー密度(人時/ページ)0.074
(0.24)
0.243
(0.30)
3.636
(0.36)
欠陥密度(件/ページ)0.099
(0.24)
0.250
(0.3)
0.514
(0.36)





IPAゆるいですねー。
ところで、第1四分位、第3四分位って何ですか?






例えば、データが100個あったときに、小さい方から25番目のデータが第1四分位、50番目が中央値、75番目が第3四分位です。
つまり、ゆるいとおっしゃっいましたが、統計的にはこの上下限に50%しかはいりません。






こんなにゆるい範囲でたったの半分ですか!?
IPAのデータって3581プロジェクト分も集めてるからデータがばらついてるんじゃないですか?




逆ですよ。
少なくとも、たった2つの標本からつくったデータよりは信頼できます。







わかりました。
他の方の意見も踏まえて、修正します。








戦い(その2)〜混ぜるな危険!〜




他の方の意見も踏まえて、次のように変えてみました。
今度はどうでしょうか。






<基本設計工程品質指標>
項目下限指標値上限
レビュー密度(人時/ページ)0.10.33.0
欠陥密度(件/ページ)0.10.30.5

<選定方法>
・品質管理者提示値、IPAの数値、お客様のコンサルタントの提示値が近い場合は、品質管理者提示値を採用。
・品質管理者提示値、IPAの数値、お客様のコンサルタントの提示値が離れている場合は、それらの平均値を採用。



最悪ですね。
統計的土台があってはじめて品質分析できます。
数値をいじって、統計的な意味付けをなくしてしまったら品質分析できませんよ。




(本当にうるさいやつだ、早く決めたいんだよ)
指標値と品質分析方法をリンクさせる意味がわかりません。






以前もいいましたが、「上下限外はOK/NGの判断ではなく、現物・現場・現実の確認を効率的に実施する(対象絞り込み)ための道具」です。
本当は全量をしっかり分析するのがベストですが、それが難しいので怪しいところを探すための言わばソナーなんです。




それはわかりました。







例えば、レビュー密度を横軸、欠陥密度を縦軸にとったとき、下限、上限を決めると、次のように9つの領域にわけられます。
レビュー密度と欠陥密度に関係がなく、下限が第1四分位、上限が第3四分位なら、平均的には、7の領域には1/4 * 1/4 = 1/16のデータが入ると考えられます









なるほど。
担当プロジェクトのデータをあてはめて、例えば7の領域に1/16より多くのデータがあるとおかしいということですね





おかしいかどうかはわかりません。
そのプロジェクトの特性上、そうなるのが自然かもしれませんから。
ですから、やはり、現物・現場・現実の確認が必要なんです。
データはあくまでソナーです。





難しいですね。






どういう意味で難しいと言っているのかわかりませんが、定量的品質分析は簡単ではありません。
例えば、どれくらい差があったら有意な差といえるのかは、本当は検定しなければわかりませんし





(あー、小難しくてめんどくさい)
で、話を戻して、何で私の指標値の案はダメなんですか?







数値を色々混ぜてしまったので、さっきの例で言えば「7の領域には平均的にはどのくらいのデータは入るはずか」というのがわからなくなってしまいます。
これはあくまで一例で他の分析も同様にできなくなってしまいます。





(よくわかんねーな、めんどくせー)
わかりました。
とにかく早く指標値を決めないとまずいので、板垣さんのご提案に従ってIPAのデータをそのまま採用しますよ。




別にIPAのデータを推しているわけじゃないですよ。
例えば、上下限は第1四分位、第3四分位でいいのかとか、対数変換しないと正規分布にならないとか、そういうことは考えてますか?
どのように分析するのかを考えないと指標値も決められないということをわかってほしいんです。




(めんどくせー)
わかりました。勉強します
とにかく、指標値は承認してください。






おしまい(続かない)


イラストは いらすとや の素材を使っています。

2015年7月5日日曜日

「ZenHack(禅ハック) 2015 Summer」に参加しました



「禅とITで世界の課題に挑む」という変わったハッカソンがあったので参加してみました。
ピザとコーラを片手に、ジャンクに、瞬間風速的にエネルギーをだすハッカソンとは違って、規則正しいハッカソンには独特の難しさと楽しさがありました。
うまく立ち振る舞えなくて、若干、不完全燃焼気味ですが、大切に向き合う食事や座禅は貴重な体験だったので、次回もぜひ参加してリベンジしたいと思います。

2015年7月4日(土)

9:30 オリエンテーション、ルール説明、インプット


会場は鎌倉の建長寺。
お題は「食」。
漫才師のような司会の2人と建長寺の和尚さんのコントラストがとても楽しいインプット。
大人の修学旅行的に楽しめました(^^)

10:45 チームビルディングワークショップ


アイディアを個人ごとにだして、ウォークスルーで星をつけ、Top3が発表。
情熱枠も先着で発表。
このあたりは、まあよくあるパターンなんだと思う。
ただ、そこからナンパ形式でチームを組むという方式は、個人的には困りました。
結局、困ってウロウロしているところを学生さんに一緒にやりましょうと言われてチームを組むことに。
アイディアベースでもなく、スキルベースでもなくチームを組んだのははじめて。
それも、また面白いかと思って流れに身をまかせてみました。
チームはこんな感じ。

佐藤さん:フロントエンドエンジニア
澤海さん:学生(マーケティングの人?)
竹澤さん:デザイナー
愛宕さん:エンジニア(Scala, PHPなど)
井戸さん:学生(経済学部だけど、フロント系勉強中)
私:広く浅く

バランスはよかったと思う。

12:30 ランチ


精進料理をいただく。
フードコーディネーターの方から料理に込めた想いを聞いたり、和尚さんからお話を聞いたり。
それも、よかったし、何より美味しかった!

13:00 API説明、メンター紹介


APIの説明は控えめ。
やはり、禅が主役?

13:30 ハック開始


もともと、自分たちのチームは誰かのアイディアに「この指とまれ」した訳ではなかったので、アイディアをまとめるのに苦労した。
ある程度煮詰まってきたところで、
「6人もいるし、そろそろ収束に向けていきたいので、エンジニア3人はできることベースでアイディアをだし、プランナーとデザイナーがコンセプトベースでアイディアをだしましょう」
と提案してみました。
ところが、すぐに澤海さんからコンセプトは全員で固めたいという意見が。
それもそうだなと、ここは澤海さんに委ねてみました。
結局、色々、発散してなんとか方向性を固めました。

15:00 おやつ


おやつは大福。
ものすごく美味しかった!

18:00 夕食&企業プレゼン


夕食は意外にも鎌倉ビールがでました(^^)
あまりに美味しくておかわりさせていただきました。

19:30 入浴


修学旅行みたいな時間を区切った入浴。
まあ、特に困ることはなかった。

21:00 就寝


こんな時間に寝れるかよ!
と思ったけど、ビールのちからもあってか、寝れました。
ただ、とーっても浅い眠りで。。。

2015年7月5日(日)


3:00 起床


こんな時間に起きれるかよ!
と思ったけど、眠りが浅いので起きれました。
でも、頭痛いし、コンディションは最悪。。。

3:30 座禅


座禅ははじめてだったので、とてもいい経験になりました。
ちゃんと、パチンとしてもらいました。
全然痛くなくて、でも、音はすごく響いたのが驚きでした。
(でも、痛かったって言ってる人もいた)

4:10 ハック再開


全く、エンジンがかからず、あまり記憶がない。。。
朝は苦手だ。

6:00 朝食(お粥・建長寺提供)


おかゆの美味しいこと(^^)
最後に、お茶を器にそそいで、たくあんでキレイにしてお茶を飲む所作を体験。
そこまで食事を大切にすることを日常で行うのは難しいけれど、いい経験になりました。

7:00 ハック再開


食事の後、頭痛も治り、エンジンがかかってきました。
ここからが本領発揮です。
ところが、デザイン重視方向に向かっていたので、プログラムはあまりなく、決めたことをHTML/CSSで実装する作業中心に。
ちょっと物足りなかったかな。

8:30 おやつ(べつばらドーナツ)


美味しかった!
梅、シュガー、シナモンの3種類だったんだけど、ベタにシナモンを選択。
最高でした。

作業も佳境。
お昼までに完成させなければならないので、マージ作業に。
ところが、ネットワークがつながらない!
もともと、ネットワーク状況は最悪だったんだけど、ここにきて全くつながらない!!
30分くらい色々試して、結局、スタッフにお願いにいきました。
スタッフの方が、不要・不急の方は一旦ネットワークを切るようにお願いしてくれて、なんとかつながるようになりました。
(お願いに行ったときにスタッフの一部の方がネットをみながら何やら楽しげに話をしていたのがちょっとイラッとしましたが。。。)

12:00  ランチ


ランチは、さっと食べられるようにということで、丼でした。
これも、お肉を一切使っていないにも関わらず、しっかり味がついていて美味しかった。

13:30 発表会



ミッションは「無駄な食べ過ぎをゆるく減らす」。
「戒」というのは、個人が守るべき各種の決まり。
八斎戒はもともと、こんなの。



この「」の字をおかずの意味の「菜」に変えたサービス名。
内容は、自分で「戒」を8つ設定して、たまにキャラが通知をしてくれて、達成状況を管理するもの。
みんなが少しずつ食べ過ぎをがまんすれば、無駄な食べ過ぎが減るはず。
和尚さんが、「仏教は実は柔軟で...」的な話をしてくれたのがヒントで、そんなゆるふわで柔軟なところと八斎戒というなんだか厳しそうなものにインスパイアされたアプリ。

デモ


http://itagakishintaro.github.io/zenhack/
※ブラウザのデバイスモードでスマホサイズでみないとレイアウトがダメです。

ソース


https://github.com/itagakishintaro/zenhack

15:30 表彰、総括


残念ながら、賞はとれず。
優勝したチームは、正直、個人的には全くもって以外でした。
でも、よく考えると、コンセプトがあたたかくて優しさいっぱいで、テーマにとてもあっていたんだと思います。

懇親会


佐藤さんの義兄さんのお店が鎌倉にあるということで、チームのメンバーと食事に。
(井戸さんはいつのまにか帰ってしまっていたので一緒に行けなかった。)
Bistrot Orangeというお店で、リーズナブルなお値段でおしゃれなステキなお店でした。
まあ、おしゃれだろうと何だろうと、いつもどおり、私は酔って毒を吐きまくりましたが(^^;)

感想


食べるもの全てが美味しかった。
夜9時に寝て、朝3時に起きるのが大変だった。
お寺の体験がどれも新鮮だった。
ものづくりはちょっと不完全燃焼だった。
次回もチャレンジしたいな。