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

特別天然記念物

日本ぱんだ(@nihonpanda)です。エンジニアです。プログラム談義とかします。

IT芸人という言葉が嫌いだ

お久しぶりです。僕です。

 

TwitterでRTでまわってきてこれを読まさせていただきました。

 

エンジニアのキャリア?「IT芸人」とは - Qiita

 

このエントリは単純にこちらを、読んだ感想です。

 

あと酔った勢いで書いてます。

 

前置きはさておき、「IT芸人」という単語に僕は強く違和感を感じました。

上記記事で、IT芸人とされている人は僕には到底、芸人と言える人とは思えなかったからです。

 

僕が記事を読んで思った、記事内で「IT芸人」とされている人は、僕には「高い技術力を持ち、それをエンジニアでもそうで無い人にも発信できるだけの能力を持った人」だと読み取れたのです。

 

エンジニアなら定義から考えよう

僕はエンジニアです。なのでなのかはわかりませんが、どうしても言葉の定義から考えてしまう癖があります。

 

「IT芸人」という言葉を分解すると、当然「IT」と「芸人」でしょう。

 

ITは説明する必要もなく、Information Technologyの事です。

 

では、芸人とは?

言葉の定義の話から始めているのでとりあえず辞書を引きました。

芸能にたずさわる専門職業人。ただし,おもに江戸時代に定型化した庶民芸能に限っていう。歌舞伎界の役者,下座,振付師,花柳界幇間 (たいこもち) ,また講談,落語,浪花節義太夫その他音曲,声色,物まね,手品,漫才,曲芸などの寄席芸人や,太神楽,万歳,角兵衛獅子,居合抜きなどの大道芸人などがある

と出ました。

 

IT芸人と呼ばれてる方達は芸能に携わる専門職人ですか?

僕にはそうは思えないです。

IT芸人と呼ばれてる人達は、高い能力を用いて、テクノロジーの素晴らしさ、有用さを伝えている素晴らしい方々です。

 

ただ、「芸人」じゃない。「エンジニア」です。

 

ある技術について高い技術力と発信力を持っている人には、エヴァンジェリスト等の呼び名があります。

テクノロジーについてメディアやイベントで発信する人であれば、ライターやジャーナリスト等の言葉でもいいかも知れません。

 

ただ、芸人という言葉に強く違和感があるのです。

僕はエンジニアとして、関わってるプロジェクトに、サービスに技術を提供する事でご飯を食べてきました。

ただ、それを「芸」だと思った事は無いです。勉強会等で登壇した事やLTをした事も片手で数えられる程ですがあります。

そこでも「芸」を披露したと思った事なんて1度も無いです。

 

何度も言いますが、IT芸人と呼ばれてる方達は素晴らしい方々だと思います。

もちもん、芸人と呼ばれてる方達も笑いや驚きを提供してくれる素晴らしい方達です。

 

ただ、IT芸人と呼ばれてる方達が提供する価値が、「芸」とされている事にそこはかとなく違和感があるんです。誤解を恐れず言えば、そこに甘んじる方達に嫌悪感すら感じます。

 

エンジニアは高尚なもの、芸人は低俗なもの。なんていう気はありません。ただ「違うもの」だと思うんです。

 

IT芸人と呼ばれてる人達を、「正しく表現する言葉が無いからIT芸人という言葉で定義いようじゃないか。」という意見もあると思うし、それを否定する気はないですけど、

なんかすっっっっっっっっごい違和感!!!!!!!!!!

って言い続けます。

 

 

って事が140字におさまらなかったので、ここに垂れ流しておきます。

 

以上でございまーーーーーーーーーーす!!!!!

 

 

 

 

20万人月の作業を1人でやる話 〜1万7千年生きたSE〜

昔々、具体的には約1万7千年前の旧石器時代、大学の情報工学科を卒業して、新卒22歳でSIerに就職した男(以下SE)がいました。

SEはある日、上司に言われました。
「2016年くらいに、銀行で大規模な基幹システムが必要になるらしいから、今から君一人で作り始めて。工数は20万人月ね。」
そういうと、上司はシステム企画構想やそれに伴う提案書、ノートPCを1つSEに渡して、自分は狩りに出かけました。
途方にくれるSE氏、ここから彼の約1万7千年(1万6666年)にも及ぶ、20万人月のシステム開発が始まるのでした。

  • 約1万7千年前
    |- 要件定義書を作成着手。
    | 周りの人達は狩りをしながら生きている。
    |
  • 約1万6千年前
    |- 要件定義書の作成が完了する。
    | 基本設計に着手する。
    | 土器を作り始める人が現れる
    | 徐々に日本列島が大陸から離れ列島になっていく。
    |
  • 約1万4100年前
    |- 基本設計がとりあえず作り終わったので、120年に及ぶレビューが始まる。
    | 人が犬を飼い始める。
    |
  • 約1万3500年前
    |- 基本設計が完了する。
    | 詳細設計に着手する。
    | 日本列島が完全に大陸から離れる。
    |
  • 約1万2000年前
    |- 詳細設計のレビュー中にムー大陸が沈む。
    |
  • 約1万700年前
    |- 詳細設計が完了する。
    | 3000年に及ぶ製造工程に着手する。
    |
  • 約1万年前
    |- 氷河期が終わる。
    | ホモ・フローレシエンシスが絶滅し、人類はホモ・サピエンスのみになる。
    |
  • 約7千700年前
    |- 大体コードが書き終わる。
    | 180年に及ぶレビューが始まる。
    | 世界では農耕が始まる。
    |
  • 約6千700年前
    |- UT開始。
    |
  • 約5千年前
    |- UTで見つかったバグを直したりする。
    | 弥生時代が始まり、土器がシンプルになる。
    | 日本でも稲作を始める人が出てくる。
    | オフィスが竪穴住居から高床住居になる。PCの充電器をネズミに噛まれなくなる。
    | たまに来る渡来人が、アジャイルとか言い出す。
    |
  • 約4千600年前
    |- バグフィックス完了。
    | 結合テスト項目書を作成し始める。
    |
  • 約4千年前
    |- マンモスが絶滅する。
    |
  • 約3千年前
    |- 結合テスト項目書の作成が終わり、テストを開始する。
    | 古代エジプト文明・メソポタミア文明などのの初期の文明が現れる。
    |
  • 約2千年前
    |- 結合テストが、発見されたバグの修正も含めて完了する。
    | バグフィックスしてる間に、前漢やができて滅び、高句麗ができる。
    | ローマ帝国が出来上がったりもしてた。
    | 日本はまだ弥生時代
    | 総合テストの項目作成に着手する。
    |
  • 約1230年前
    |- 総合テスト項目書が作成完了する。
    | その間に、邪馬台国ができたり、古墳時代が始まり、飛鳥時代が始まり、
    | 奈良時代が始まる。
    |
  • 約1230年前
    |- 総合テスト項目書のレビューが終わる。
    | ポルトガル王国が建国される。
    | 総合テストを開始する。
    |
  • 約248年前
    |- 総合テストが完了する。
    | 日本ではすでに江戸時代後期、10代将軍・徳川家治の時代。
    | ヨーロッパでは産業革命ど真ん中。
    |
  • 約174年前
    |- 世界最初のプログラマーとされているエイダ・ラブレスが、
    | 世界最初のプログラムを書く。
    |
  • 約70年前
    |- 第二次大戦中、世界最初のコンピュータ「ENIAC」が完成する、
    |
  • 約50年前
    |- バグフィックスも終わり、検品&納品作業を開始する。
    |
  • 今年
    |- 全作業終了。終止一人で作業していたSE氏、一人で打ち上げしてから家に帰る。
    |

まとめ

事の発端は、いつものようにTwitterに張り付いていた所、久しぶりにM銀行の20万人月案件の話が流れて来たことです。
4000億の費用がかかり、ピーク時は8000人がアサインされていたという20万人月案件。
なんとなく割り算しながら、「新卒で入って定年するまでずっと働く人が400人以上いるのかー」とか「一人でやったら1万6666年かかるのかー。」とか考えていたんですけど、
そこから、「約1万7千年前っていつだ?」とか「何の時代にどの工程やってればいいんだ?」なんて思っちゃったんです。

各工程の時間配分に関しては、IPAソフトウェア開発データ白書の活用 (PDF)をベースに、計算して出しました。変えてる所は多分にありますが。 まさかIPAの方々も、自分たちが作った資料がこんなくだらない話のために使われるとは思いもしなかったでしょう。

ちなみに、SE氏が40年で2億円の給料を貰えるエンジニアだと仮定した場合、SE氏は850億円の給料がもらえる計算になります。多いのやら少ないのやら。

年表上の案件以外の出来事は、Wikipediaのみを見て書いているので、間違ってる可能性も大いにあると思います。言ってもらえれば直します。ついでに算数が間違ってる可能性すら僕は感じています。

まぁあれですね、おっきい仕事はみんなでやろう!ってまとめでいいですかね。

以上でーす

Firebase AnalyticsのlogEventWithNameでハマった話

お久しぶりです。僕です。

先日、Google I/OでFirebaseの新バージョンが発表されましたね。
無料で各種機能が使えるようになって、モバイルアプリエンジニアの皆さんはさぞワクワクしたことでしょう。
僕も例に漏れず、喜び勇んで弊社の開発中のiOSアプリに導入致しました。

ここで導入の仕方とか話すつもりは無いんですけど、
cocoapodsでさくっと入れて、1行初期化API叩くだけで、Firebaseのコンソールにあらゆる情報が表示されて「ひょえーーーーーーーーーーこいつぁすげーーなーーーーーー」と思ったものです。

さて本題です。

今開発中のアプリは、Screen TrackingとEvent TrackingをGoogle Analyticsにまかせていたのですが、FirebaseにScreen Trackingの機能が無いから仕方ないとして、Event Trackingやその他FirebaseでできることはすべてFirebaseに移行しようということになりました。

と言っても、いくつかのイベントのTrackingするコードをFirebaseに書き換えるだけで特に苦労はしなかったです。
Firebaseが自動で取得するイベント(first_open、os_update等)以外に、独自のイベントを取得したいときは、以下の1行で良いです。

FIRAnalytics.logEventWithName("eventName", parameters: params)

第1引数にStringでイベント名、
第2引数に[String : NSObject]の詳細情報を付与できます。
簡単ですね。

簡単だと思ったんだけどなぁ・・・・・・

待てど暮らせど、Firebaseのコンソールにイベントが表示されません。
しびれを切らして色々調べましたが全くわからず。

そんな中、救世主のような これ を発見。

回答は意訳すると「とりあえず、Firebaseが出力するデバッグ文をちゃんとよんでみな。」とのこと。
早速Xcodeここに書いてある設定を加えました。

それで実行!!
早速エラー!!!

<FIRAnalytics/ERROR> Event name is too long. The maximum supported length is 32: 
<FIRAnalytics/ERROR> Event name must contain only letters, numbers, or underscores

イベント名は32文字までって言ってるのと、
イベント名に、英数字アンダースコア以外は使うなって言ってますね。

言うとおりに直したらエラー出なくなりました。

ドキュメントちゃんと読め案件でしたね。

以上でーす。

インターン生に出したアプリ開発の基礎を学ぶための課題を公開します

お久しぶりです。
僕です。

まず、軽く近況報告を。
ガルパンはいいぞ

以上です。

嘘です。
Twitterなんかではよく言ってますが、弊社にはエンジニアが1人しかいません。サーバサイドには外部からお願いしてる人がいますが、アプリエンジニアとしては僕だけです。
なので、とても寂しかったのです。寂しかったので、母校に連絡してインターンを1人来てもらうことにしました。

ここからが本題

インターン生にはiOSアプリ開発の勉強をしてもらうつもりですが、来てもらう子はAndroidアプリの開発経験はあれど、iOSアプリの開発経験は無いらしいので、まずは弊社でリリースしているアプリに触ってもらう前に、iOSアプリ開発の基礎を学ぶための課題をやってもらうことにしました。

ところで、アプリ開発の基礎ってなんですかね。っていう話なんですけど。
賛否両論あるかとは思いますが、僕は以下の事ができればAndroidiOS、WP問わず最低限のことはできるのかなぁとは思っています。

  1. 開発環境を構築できる
  2. gitが使える
  3. ライブラリ管理ツールが使える(cocoapodsとかnugetとかGradleとか)
  4. ライブラリを用いてWebAPIを叩ける
  5. ライブラリを用いてJsonをパースできる
  6. パースしたJsonの中身を表示できる

くらいです。まぁ多くのエンジニアが「1時間くらいでできるじゃん・・・」と思うでしょうが、アプリ開発学んだことのない学生にやらせる課題としては、これくらいのことが2週間程度でできれば僕は充分だと思っています。
なので、上記を満たすような課題の仕様を作ってやってもらう事にしました。っていう話をTwitterに書いたら、誰とは言わないけど、怖いデザイナー達が、その課題をよこせ。と言ってきたの公開します。

公開しようと思ったのですが、インターン生の課題に使ってるWebAPIが非公開のAPIで、それごと公開するわけにはいかないので、APITwitterに置き換えたやーつで書いていこうと思います。インターン生に渡した課題と大意は離れていないはずなのでやってみてください。
ちなみに、怖い人達にはswift3.0を学びたいと言われましたが、そんなものは「ものづくりしながら公式ドキュメント読んで覚えろ」派なので、課題の中で言語仕様について言及はしていません。(もちろんインターンの学生にはちゃんとレビューします。)

課題

概要

以下の仕様を満たすアプリを作ることによって、アプリ開発の基礎、使用する言語の言語仕様を学ぶこと。

課題の狙い

  • iOSアプリ開発&Swiftの基礎を学ぶ
    • 言語仕様を理解すること
    • Xcodeを使用できるようになること
    • 情報の一覧表示ができるようになること
    • 画像の表示ができるようになること
    • 画面遷移ができるようになること
    • Interface Builderを使用できるようになること
    • 非同期通信処理を書けるようになること
    • JSONのパースができるようになること
    • ライブラリをCocoaPodsから導入できるようになること
    • Githubによるバージョン管理ができるようになること
    • レビュー時にコードの説明を論理的にできるようになること

アプリ仕様

以下の機能を満たすTwitterクライアントを開発する。

  • ログイン・ログアウト機能
  • タイムライン表示機能
    • ツイートの内容
    • ツイートの日時
    • ツイートしたアカウントのID
    • ツイートしたアカウントの表示名
    • ツイートしたアカウントのアイコン
    • ツイートに画像が含まれている場合はその画像(可能であれば複数画像にも対応すること)
  • ツイート機能
  • タイムラインに表示しているツイートをタップでツイートをお気に入りする機能

開発環境

  • 最新のSwiftを使用すること
  • 最新のcocoapodsを使用すること
  • 最新のxcodeを使用すること
  • リポジトリgithubを使用すること
  • Swifterを使用すること

まとめ

ちょっと仕様の提供の仕方もざっくりすぎて、ほんとに賛否両論あるかとは思うんですけど、非エンジニアの人達はエンジニアのために懇切丁寧に仕様を説明してはくれないし、学生の事を考えればざっくり仕様からプロダクトオーナーやユーザーの要求を抽出するのも大事な能力なので・・・(目を逸らしながら)
ただ、上記の簡単なアプリを2週間程度で作る事ができれば、即戦力とは言わないまでも、アプリ開発における初歩の初歩くらいは学べるかと思います。 iOS以外でも、仕様を適宜読み替えてもらえればある程度は学べると思います。たぶん。

で、わからないこともあるかと思うので、僕で良ければなんですけどSlackチャンネル用意したので、時間があれば質問なんか答えようかななんて思ってます。
とりあえずTwitterでDMかなんかくれれば招待しますので。

今回はこんな感じで終わりです。
次はインターン生から僕が得た気づきなんかの記事が書ければいいなぁ。

朝ドラ「あさが来た」のへぇさんに学ぶ、コミュニケーションコストの削減方法

どうも。僕です。
最近少し体調を崩し、大好きなお酒類をがっつり断っておりました。
逆にストレスで死にそうです。

話は変わりまして、最近弊社では朝ドラブームが来ております。
弊社では5人しかいないんで、お昼ごはんは誰か(主に僕か、デザイナーのけん様)が作って、皆で食べるんですけど、去年の秋ごろから、なぜかお昼ごはんを食べながら録画してた朝ドラを見るのが習慣になっております。
今やってる朝ドラは「あさが来た」という作品で、明治時代に女性実業家として活躍し、日本女子大学校の設立にも尽力した、広岡浅子という人の生涯を描いたドラマです。

www.nhk.or.jp

広岡浅子 - Wikipedia

波留さん演じる広岡浅子さんをモデルとした「あさ」が両替屋の加野屋に嫁入りして、単行経営や銀行経営に関わり、大阪経済の礎を作っていく姿はとてもおもしろくて、社員全員お昼時にはテレビに釘付けなんです。
が、今回はそのあさ本人の話では無く、作中に登場する山崎平十郎、通称「へぇさん」の話です。

へぇさんとは

朝ドラ見てる人はこの辺読み飛ばして下さい。

へぇさんは、辻本茂雄さん演じる、山崎平十郎という加野屋の従業員です。
f:id:nihonpanda:20160130184026j:plain モデルとなった人は中川小十郎という人で、西園寺公望の秘書を経験した後、朝日生命保険会社(現 大同生命)の副社長や、貴族院議員、立命館大学創設という数々の偉業を成し遂げた、すごい人です。

中川小十郎 - Wikipedia

ですが、作中では芸人の辻本茂雄さんが演じるコミカルで憎めないキャラクターです。
へぇさんの登場は突然で衝撃的なものでした。
毎週月曜日に現れて、何を聞かれても「へぇ」としか答えない、加野屋の従業員には「月曜日のへぇさん」というおかしな客がいるというくだりからへぇさんは現れます。
その後、ただの客であったへぇさんが急に加野屋で働きたいと言い出します。
あさがへぇさんを面接すると、案の定へぇさんはへぇさんとしか答えません。
耐えかねたあさが「なにか喋っとくなはれ!!」と言うとへぇさんは突然饒舌になります。
自分の名前が山崎平十郎であること。大蔵省(中川小十郎は文部省)の官僚であったこと。日本を支える銀行を作りたいと考えていること。大阪中の両替屋や銀行を歩きまわり、日本を支える銀行になり得る銀行を探していたこと。加野屋はそうなり得ると思ったこと。
を堰を切ったように喋り出します。
へぇさんが有能な人材だと見ぬいたあさは、へぇさんを加野屋に雇い入れます。
しかし、加野屋で働き始めてもへぇさんは基本的に「へぇ」としか言いません。
そんなへぇさんを見て、加野屋の大番台の雁助さんはへぇさんが「極めつけの始末屋」ではないか。と言い出します。
始末屋とは、倹約家という意味でへぇさんはそれが徹底されているということです。
鼻紙は何回も使い、帳簿も隙間なくびっしりを文字で埋め尽くし使い切る姿はまさに倹約家。
その倹約ぶりは会話にも活かされており、基本的には「へぇ」の言い方のみで意思疎通を済ませ、業務上必要に迫られた時だけ喋りまくる。というスタンスで会話を最小限にとどめている。ということです。
はい、長々と書きましたがここからが本題です。

へぇさん流コミュニケーション

前述した通り、へぇさんは倹約のために発言を最小限にしています。
そのスタンスは以下の2点が主です。

  • 基本的に「へぇ」のみで済ませる。
  • 業務上必要に迫られた場合のみ、喋りまくる。

僕は「あさが来た」を見ていて気がついたこの2点を、現代のサービス開発現場で使えないかと考えました。

つまり、このエントリで上記2点を主軸にした、「へぇさん流コミュニケーションコスト削減術」を提案します。

へぇさん流コミュニケーションコスト削減術の開発現場での応用

オフィスでの応用

とは言っても、オフィスで皆が「へぇ」しか言わなくなればコミュニケーションコストの削減どころか、コミュニケーションそのものが成り立たなくなります。
ではなぜ作中でへぇさんはコミュニケーションが取れているのでしょうか。

端的に言ってしまえば、「へぇ」としか言わないのがへぇさんだけだからです。

作中ではあさをはじめとする加野屋の面々がへぇさんに話しかけ、へぇさんはそれにいろいろな「へぇ」で返事をしています。
ここで重要なのは、「どの役職であればへぇさんでいられるのか」です。
作中で、へぇさんは経営者ではありません。加野屋の店舗でせわしなく働く従業員です。
経営者たるあさや加野屋の8代目、大番台の雁助さんからの指示で銀行業務を遂行する従業員です。
つまり、経営者や、サービス開発の現場で言えばプロダクトオーナーではへぇさんになってはいけないのです。
現場で手を動かす人間にのみへぇさん流コミュニケーションは使えるのです。

例えばへぇさんがエンジニアだった場合。
PO「へぇさん、この機能の仕様は◯◯で××です。」
へぇさん「へぇ(承知)」
〜〜しばらく経って〜〜
へぇさん「へぇ(できました)」
PO「◯◯の動きが違うなぁ」
へぇさん「へぇ?(というと?)」
PO「つまり、(仕様についての詳しい説明)ってことです。」
へぇさん「へぇ!(なるほどそういうことだったんですね!)」

いけそうじゃん!!!! へぇ万能!!!!

とは言え、極めつけのエンジニアのへぇさんにも、質問したいことがあるはずです。仕様に対して気になることをPOに聞きまくりたいこともあるでしょう。
そして、明治に生きたへぇさんはきっとそうするでしょう。
しかし、それではPOとエンジニアが時間を合わせてじっくり話す場が必要です。大きな仕様や方針を決める場合はそれでもいいでしょう。
しかし、今は平成。IT革命が起きて何年も経ってしまった世の中です。
では平成に生きる極めつけのエンジニアのへぇさんはどうするのがいいのでしょうか。

そこで使うのがドキュメントベースのコミュニケーションです。ツールGithubのissueでもesa.ioでもQiitaTeamでもなんでもいいです。
へぇさんはそこに、指示に対する実装方法、実装上の問題点、時間的問題点、予算的問題点など、思ったことを書き連ねます。
そうすることで、へぇさんの意思は開発チーム内で共有され、知見として蓄積されていきます。
POやPMはへぇさんドキュメントにより指示の改善をすることもできるはずです。

リモートでの応用

時代が変われば働き方も変わります。現代においては、在宅でリモートワークをしてる方もいます。
基本的はコミュニケーションはドキュメントやSlack等のチャット、たまにSkype会議で喋る。なんて方法を使う人も少なくないはずです。
ですが、Slackでの会話の返事がいつも「へぇ」の人。嫌ですよね。
何考えてるかわからないし、文字に起こすとえらく淡白でシュールな会話になるでしょう。

そこで使えるのがEmojiです。

へぇの代わりに絵文字を使うことで情報量は段違いになります。先ほどの会話を例にしましょう。
PO「へぇさん、この機能の仕様は◯◯で××です。」
へぇさん「👍」
〜〜しばらく経って〜〜
へぇさん「できました😏」
PO「◯◯の動きが違うなぁ」
へぇさん「😱」
PO「つまり、(仕様についての詳しい説明)ってことです。」
へぇさん「😊」

まぁちょっとくらいは日本語使いますけど、絵文字があるだけでどういう気持ちかがわかりやすくなりますね。

へぇさん流コミュニケーションの問題点

求められる「へぇ力」

作中で、へぇさんは様々な「へぇ」を使います。
にこやかなへぇ
気合の入ったへぇ
しかめっ面のへぇ
小首をかしげながらのへぇ
といった具合に、表情や態度にを付加した数々のへぇを使いこなしているのです。
このへぇさんがへぇを使いこなす能力、へぇ力が無いことにはへぇさん流のコミュニケーションは使えません。
思ったことを顔に出せない人は、へぇさん流のコミュニケーションは難しいでしょう。

信頼と実績のへぇ

作中でへぇさんが登場した時には、へぇさんはへぇとしか言わない変人です。
しかし、元大蔵省の官僚として、銀行に関する抱負な知識と知見を持った人だとわかると、へぇさんの評価は一変。終いには極めつけの始末屋と言われる程にまで。
つまり、へぇさんでいるためにはそれなりにデキる人間であることが絶対条件なのです。
「へぇさんがへぇと言えば大丈夫」と皆に言われるような信頼があってこそのへぇなのです。
たまにマシンガントークするへぇさんに対しても、信頼と実績があるからこそ皆耳を貸すのです。 へぇさんへの道のりは1日にしてならず。なのです。

まとめ

以上、へぇさんに学ぶコミュニケーションコストの削減方法でした。
皆さん、きっと僕と思ってる事は同じでしょう。

どう考えても普通に会話したほうが手っ取り早いです。

だめじゃんへぇさん。
書いてて我ながら使えそうだと思ったの絵文字くらいですもの。
へぇさんにはフィクションの中にとどまってもらうことにしましょう。

つまるところ僕がこのエントリで何が言いたいかというと、

あさが来たおもしろい。

たまには朝ドラとか見るもんですね。

以上、書き始めてみたものの、思ったより下らない内容になってしまったやーつでした。

ZenFone2 Laserを使ってみて1ヶ月

お久しぶりです。僕です。
今回はZenFone2 Laserを購入したため、1ヶ月くらい使ってみてその使用感なんぞをレビューしていきたいと思います。

www.asus.com

事の発端

単純にレビューが見たい人はここは読み飛ばしてください。
僕のアホさ加減を指差して笑いたい人だけ読んで下さい。Fone

私はAndroidが好きだ。
仕事ではiPhoneアプリを作っているので、開発機としてiPhoneは持ってるけど、圧倒的にAndroidが好きだ。
でも開発者として1番好きなのはWindowsPhoneだ。これについて語り出すと止まらなくなるので、WindowsPhoneの話はこれ以上しない。

Androidの中でもXperiaが好きだ。初めてZ1を購入して以来、その良さに惚れ込んでしまった。

そのZ1が9月にぶっ壊れた。

会社の自席で触っていたら、手が滑って転げ落ち、イスの足に画面を下向きにして落っこちた。
当然画面は全損。
馬鹿な私はdocomoのケータイ補償に入っておらず、2年契約の1年半目で機種変更を余儀なくされた。

仕方ないので、出たばかりのZ4は高いので、Z3に機種変することにし、docomoオンラインストアからZ3を購入した。

翌日Z3Compactが届いた。

ええ、焦りましたとも。Z3を買った気でいたのにちっちゃいのが届いたんですもの。
焦ってサポセンに電話してみると、間違いなくZ3Compactを注文しているとのこと。
一応サポセンのお姉さんに交換はできるのかと尋ねた所、完全に未開封なら可能との事。
しかし、僕の手元には喜び勇んで開封した箱があったのだ。
まぁ僕のミスなので、仕方なくZ3Cを使うことにした。

ところがどっこいこれがむちゃくちゃ使いやすい。

小さいボディながらも、操作に違和感はなく、固まったり強制リブートされたりといったこともほぼ無く、とても快適に使うことができて、正直結果オーライだった。

そして翌月、Z3Cがぶっ壊れた。

友人の結婚式に向かう最中のことだった。
道中にポケットから取り出し、また手が滑ってアスファルトに画面を下にして落ちた。
画面は全損。また交換を余儀なくされたのだった。

しかし、僕も同じミスを2度するほど馬鹿じゃない。
今回はちゃんとdocomoのケータイ補償に入っていたのだった!!
そのため、8000円はかかったものの、本体を交換することができたのだった!!!
こうして無事再び新品のZ3Cを手にすることができたのだった。

その翌月、再びZ3Cがぶっ壊れた。

手が滑って(以下略)ケータイ補償で(以下略)

まさかの3ヶ月連続でも携帯全損事故に悲しくなりながらも、愛するZ3Cを大事に扱うことを誓ったのだった。

1月、三度Z3Cがぶっ壊れた。

手が滑って(以下略)
しかし今回はケータイ補償は使えない。なぜならdocomoのケータイ補償は1年に2回まで。修理に出すと非常に高額になってしまうため、開発機のiPhoneで生きようとも思った。(docomoショップで働く友人2名にはめっちゃ笑われた)

そんな中、安いsimフリー機を買って次のケータイ補償が使える日まで持ちこたえることを思いつき、ZenFone2 Laserを買うに至ったのであった。

購入編

新宿のヨドバシカメラで購入しました。
価格は2万6千円くらいだったと思います。 色は黒を買いました。 ヨドバシポイントは1%しか付きませんでした。なんででしょうね。

買ってその場でsimの入れ替えをしたんですが、
まず箱がめっちゃ開けにくいです。
まぁ携帯の箱なんて数えるくらいしか開閉しないものなんでいいんですけど。

箱の中には、本体・充電器・USBケーブル・イヤホン・説明書が入ってます。
携帯が壊れて携帯を買ったため、写真は無いです。ごめんなさい。

2万6千円の携帯で充電器とイヤホンが入ってるのはとても良心的ですね。
Z3Cには入ってなかったし。
充電器とケーブルは特筆することはない感じで、まぁ普通に使えます。
イヤホンは、カナルタイプでリモコンとマイクがついてます。
リモコンはボタンが1つあり、音楽の再生/停止等ができるもので、音量調節はできません。マイクもまぁ普通に使える感じ。
音質はあんまり良くないです。量販店で1000円前後で買えるイヤホンくらいの音質かと。
しかしまぁ、2万6千円で買える携帯にマイクリモコンつきのイヤホンがついてるのはとても好感が持てますね。
余談ですが、ZenFone2 Laser購入4日前にイヤホンも壊れたので、今も付属のイヤホンを愛用しています。

本体は、元Z3Cユーザーとしてはでかいような気がしました。
しかし、特段重いようには感じなかったです。
背面は、つや消し加工がされており、さらさらして触り心地が良いです。
加えて背面は丸みを帯びた形になってるので、フィット感もあってとても良い感じ。

simの入れ替えですが、ZenFone2 Laserにはsimスロットが2つあります。
サイズはどちらもmicro-simで、裏蓋と電池を外すことでsimの抜き差しができるようになってます。
案の定画像は無いので、画像が見たい人はGoogleの画像検索とかすればいいんじゃないでしょうか。

Z3Cはnano-simだったので、simの変換アダプタも購入しました。
simを入れるのは、簡単でただ刺すだけです。スロットに強度的な不安感は無く扱いやすいです。

使用編

ここからは1ヶ月使ってみての感想です。

まず、プリインストールアプリが少ないので、アプリの一覧の画面がすっきりしててとてもいいです。
ASUSのアプリが何個かは入っていますが、まぁ基本的に使うものは無いかと。

次に動きです。
値段が値段だけにここを1番心配していたんですが、普通に使うぶんには全く問題無いです。
僕はソシャゲとかそもそも携帯ゲームをほとんどやらないので(デレステはちょっとやってたけど)ゲームとかの動きはわかりませんが、普通にブラウジングSNSをやるくらいならストレスはほとんど無いです。
しいて言えば、画像の読み込みはちょっと遅いかなといった感じはします。 あと、唯一やる麻雀ゲームアプリがたまに画面半分真っ黒になります。結構CG使ったリッチなUIの麻雀アプリなんですけど、ツモった牌が見えなくなるのはつらいです。もしかしたらCGもりもりな感じのゲームには弱いのかも。

次にネットワーク。
これがとても困っています。個体差だと信じたい気持ちはあるんですが、1日に数回、突然simを認識しなくなります。
焦ります。原因は不明なんですが、2つあるsimスロットのどちらに挿しても同じ現象が起きるので、これに関してはそろそろメーカーに問い合わせてみようかと思ってます。なにかあったら追記します。
あとWi-Fiですが、5Ghz帯が拾えないのもいただけないですね。

次にカメラ。 名前にもあるように、レーザーオートフォーカス機能なるものがあるらしいです。
暗闇や逆光でもさくさくオートフォーカスが機能するらしいです。
らしいですと言ってるのは、正直差がよくわかりません。
わかるひとにはわかるんでしょうけど・・・としか言いようがないです。
一応取った写真を載せておきます。みたらしちゃんです。可愛いですね。
f:id:nihonpanda:20160124200114j:plain

次にハードボタン。
まずスリープボタンですが、本体上部についてます。場所的には非常に使いづらいです。比較的手が大きい僕ですら使いにくいと感じるので、女性だったりは使いづらさをより感じるのではないでしょうか。
でも心配はございません。
なぜならこのボタン、基本的に使いませんので。
というのも、この携帯はスリープ状態から画面をダブルタップすることでスリープが解除になり、解除したあとは画面の上部をダブルタップすることでスリープ状態に鳴ることができるからです。
これ、めっちゃ使いやすいです。この携帯で僕が1番満足しているポイントかもしれません。
次に音量調節ボタン。
これは本体背面に銀色で大きめのサイズで付いています。
初めはダサい位置にあるなぁと思ったんですが、いざ使ってみると結構いい感じ。
握った状態で人差し指で操作しやすい位置にあるので、かなり満足です。
滑り止めなのか、ザラザラした加工がされており、たまに無意味に触ります。
次にバック・ホーム・タスクボタン。
ZenFone2 Laserはこの3つのボタンがハードボタンになっています。
これは賛否両論あるかと思いますが、僕はすごい嫌です。
まずメリットとしては、画面が広く使えます。以上です。
デメリットは、ボタンは画面下部に刻印(?)されているだけなので、光ったりしません。暗い所ではとても見づらいです。
次に、当然ですがボタンの見た目が変わりません。
Androidはバージョンごとに3つのボタンのデザインが変わることが有りますが、これを楽しむ事ができません。あとキーボードが出ているときに、バックボタンの向きが下向きになったりとかもないのです。もっと深刻なのは、仮にこの先Androidのバージョンアップで3つのボタンが2つや4つになった時にどうなるでしょう。もう闇です。時代に取り残されます。つらすぎです。

次にバッテリーです。
ざっくり言うと、丸1日の使用は無理です。
1日普通に使ってたら電池切れます。
感覚としては、朝から使い始めて、3時間画面を触る操作、2時間音楽、4時間スリープくらいな感じで電池切れな気がします。あくまで感覚ですけど。 使用頻度にもよりますが、モバブが必須でしょう。

次にマイクとスピーカー。 特筆することは無いです。可もなく不可もなく。普通に使えます。

落下編

タイトルからお察しかとは思いますが、また落としました。画面を下にして、アスファルトに。
うああああああああああああああああああああああああ!!!!ってなりましたとも。
僕は携帯には基本的にケースはしないで画面フィルムだけ貼ります。Z3C君は画面フィルムなどもろともせずにぶっ壊れていきました。

しかしZenFone2 Laserは違います。
無傷です。

なぜ無傷で済んだかと言いますと、ZenFone2 LaserにはGorilla Glass 4というディスプレイが採用されています。
これが!!!!!これがあるから!!!!僕は!!!!!!ZenFone2 Laserを!!!!!買ったんです!!!!!!

Gorilla Glass!!!名前からして強そう!!!しかも4!!!もはや最強なのでは!?!?!?!

というわけで、無傷でした。すごいですねGorilla Glass。もう落としてもへっちゃらです。
まぁ落とすなって話なんですけど。

総括

総括です。
一言で言うと、

悪くない!

良いとは言いません。
何故かと言うと、使用編に書いたsimスロットの件が非常に大きいです。別のレビュー記事では特になにも言って無い気がするので、個体差かsimアダプタのせいかもしれませんが。
あとはバッテリーです。ちょっと弱いですね。僕は基本的に大容量モバブは常に持ち歩いてますし、会社等では充電しっぱなしなのでいいですけど、充電環境がない状況で丸1日の使用ができないのはきついです。
次にストレージ。16GBです。小さいです。SDカード必須です。少しでも音楽聞いたり写真取る人は、32GB以上のSDカードを買いましょう。
しかし、それ以外の使用感については非常に満足しています。
いろんなメディアやブログで言われているように、コスパ最強の称号は伊達じゃないです。
正直、各キャリアで売ってるプリインアプリもりもりで、動きもぐだぐだ、最新OSも全然来ない国内メーカーの携帯買うよりも全然良いんじゃないでしょうか。
加えて、simフリーでしかもsimが2枚刺さるので、よく海外に行く人や、通信制限によく引っかかる人は、MVOとMVNOのsim2枚運用なんかも良いかもしれないです。

メイン機としてじゅうぶん使える携帯なので、おすすめだと僕は思います。

以上、テキストばっかりで長ったらしいレビューでしたが終わりです。
間違ってることもあるかと思いますので、あくまで参考程度にでお願いします。

技術がわからないデザイナーやディレクター、プロダクトオーナーとのコミュニケーション

コミュニケーションのAdvent Calendar 16日目です。

みろなるさんコミュニケーションのAdventCalendarやるから書いてって言われたので、つらつらと書いてみます。

今年春にSI屋さんをやめて、デザイン事務所のような会社で唯一の常駐エンジニアとして、アプリの技術なんかほとんど知らないWebデザイナーさんやディレクターさんとのコミュニケーションについて思ったことを書きます。

経緯

今年の春に2年務めたSIerをやめました(参考:退職しました)
SIer時代には、基本的にどこの現場に行っても周りはSEかPG。
お客さんもSEかPG。
エンドユーザーがSEなんて仕事も。
多々ストレスは有りましたが、話す方も聞く方もエンジニア。ある程度の共通の認識や知識を持ってコミュニケーションを取れることが多かったです。

そんな会社をやめて、今いる会社はWebデザイナーやディレクターがメインのメンバーの、IT企業というよりはデザイン事務所のような職場で働いています。
アプリエンジニアどころか、エンジニアと呼ばれる人間で常駐してるのは僕だけです。 退職を期に個人でも小さなアプリ開発案件を請け負い始めたので、デザイナーさんと話す機会は増す一方です。
なので、ディレクターさんとコミュニケーションを取らなければならない状況に置かれた僕の、ここ数ヶ月の気づきを書いていきます。

まず徹底的にわがままを聞く

SI屋さんにいると、まず要件定義を作って、設計して、作ってテストして・・・・。なんてことをしますよね。
でもせっかくプロダクトオーナーもデザイナーもディレクターも同じ部屋にいるんだから、そんな手間は掛けたくないですよね。
だからと言って、ろくに要件も決めないままいきなり作り始めるとろくなことにはなりませんよね。
さらに言えば、「じゃあ要件定義をしていきましょう。」なんていきなり始めてしまうと、プロジェクトを進めるのに慣れてない人は、
割りと萎縮してしまう場合なんかもあります。
そこで魔法のコトバ 「まずわがままを書きまくってください」です。
このわがままは、「こんな感じの機能がほしい」「この画面はかっこいい感じにしたい」といった抽象的なものから、
「この画面のここのフォントは◯◯にしたい」「このボタンはこのデザインがいい」等の具体的なものまで、とにかくなんでも列挙してもらいます。 これが出来上がれば、かなりスムーズに要件定義やタスクの分解ができます。
例えば「この画面はかっこいい感じにしたい」というわがままの場合、わがままの定義付けと実現方法を考えます。

  • どのような画面デザインで、どのような機能がどのように動けばかっこいいかを決める。
  • かっこいい画面をデザインする。
  • かっこいい機能を作る。
  • かっこいい動きを作る。

という過程を踏めば実現できることがわかります。
つまり「かっこいい画面」という抽象的な表現の定義付けと、この機能の要件の決定、タスクの分解ができるわけです。

具体的なわがままについては、定義付けやタスクの分解どころか、そのままissueにすらなってしまう場合があります。

大きなチームではわかりませんが、プロダクトオーナーのわがままをリスト化することで、要件定義に近いもの、もしくは要件定義を作るための足がかりになります。

わがままに優先順位をつける

次にわがままに優先順位をつけます。
これは言わずもがな、要件定義ができたらスケジュールを決めたいですよね。
わがままをタスク化した時点で、ある程度ですが工数の見積もりも見えてきているはずです。
つまり、後はわがままに優先順位をつければ、ざっくり開発スケジュールが出来上がるわけです。

無駄なドキュメントは作らないけど、必要なドキュメントはちゃんと作ろう

デザイナーさんとおしゃべりするのは楽しいです。ついつい長話してしまうことも多々有ります。
そんな長話のさなかに、隠れわがままが出現することがあります。
隠れわがままは、我々の天敵である「仕様変更」「機能追加」である場合があります。
仕様変更や機能追加をしたくないわけではないです。いいものを作るために必要なことならば積極的にやりたいです。
問題なのは仕様変更や機能追加がふわっと現れることにあります。
ふわっと現れたタスクをふわっとさせておくと、なんの機能なのか、いつやるのかが曖昧になったまま、結局忘れさられるといった悲劇がおこることがあります。
これは、デザイナーさんとのおしゃべりに限らず、仲の良い開発チームやタスク管理が苦手な人達のチームで起こりやすいことでもありますね。
これを避けるために、めんどくさいですが機能について正解を示すドキュメントは、機能毎やわがまま毎に作っておきましょう。
会話のさなか隠れわがままが出てきたら、このドキュメントと照らし合わせながら仕様変更や機能追加をしましょう。
このわがままの再設定的な作業をしておけば、隠れタスクは生まれないはずです。

急がせないでやりたいようにやらせる

たまにあるんですけど、「この画面のデザイン、とりあえず手書きでざっっっっっくりでいいので下さい」って頼んだのに、
きっちりしたデザインが上がってくることがあります。なんか手書きでざっくりみたいなのが苦手らしくて、
ちゃんとした完成形のデザインじゃないとイメージができないらしいです。
最初は、「まじかー。とりあえずざっくりデザイン見ながら、機能だけ作っちゃって後でデザイン反映するかー。」なんて思ってましたが、
無理なものは無理らしいので、諦めましょう。というか諦めました。テストでも書きながら待ちましょう。
無理に急かしてもモチベ下がって、逆に遅くなることもあるし、急がば回れです。
デザイナーさんに限らずこういう人っているよね、って話なんですけども。 ただ、スケジュールに遅れが生じる可能性があることなどはちゃんと説明しましょう。

専門用語を避けない

非エンジニアと話すとき、こちらから専門用語を避けがちになってしまっていませんか? 専門用語を避けて、話すことで正しく意図が伝わらない事があったりしませんか?
そういった自体をさけるために、僕はあえて専門用語は専門用語のまま使っています。
ただ、そういった専門用語を使う前に必ず「今から技術の話をします。」というようにしています。
急に知らない単語がいっぱい出てくるとびっくりしますので。
なので、専門用語を使って正しく意図を伝えるために 「今から技術の話をします。この機能を実現するには、データベースに○○のためのテーブルが必要です。ここでいうテーブルとは〜〜」
といったように、はっきりと専門用語である事と、その意味を伝えましょう。
これにより、正しい意思の疎通と、その後のコミュニケーションコストの軽減が見込めます。
また、これについては逆も然りで、エンジニアも相手が使う専門用語を理解しようとすることが大事ですね。

甘いものやごはんを与える

定期的にシュークリームやらワッフルやらを買い与えましょう。
糖分は頭を活性化させるような気がします。 あとうちのデザイナーは茶碗蒸し与えると頑張ります。
出汁と卵と具を混ぜて、器に入れて、アルミホイルかぶせて、器が半分浸かるくらい鍋に水を入れて沸騰させて、鍋に器を入れて鍋に蓋をして10分くらい蒸せば出来上がりです。簡単ですね。 🍣や🍕や🍖なども有効です。

おわりに

技術がわからないデザイナーやディレクターとのコミュニケーションと題しましたが、非エンジニアとプロジェクトを進めるにあたっての気づきみたいな事を書いた気がします。

長々と書きましたが、大事なのは相互の歩み寄りと仲良くすることが、チーム内で最もコミュニケーションコストを下げるのに大事なことだと思います。
こういう考え方もあるんだー。程度の参考にしていただければ幸いです。