特別天然記念物

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

とあるソロキャンパーと山梨の地ビール[Beer Advent Calendar 14日目]

ソロキャンパーの朝は早、 くもない。

昼前くらいに車にキャンプ道具を積んで家を出る。

向かうは富士五湖本栖湖のほとりのキャンプ場。

高速に乗り2時間程度、河口湖ICで降り本栖湖方面へ。

道中見つけた道の駅「なるさわ」に立ち寄る。

求むは、地ビールとつまみ。

↓道の駅「なるさわ」で撮った富士山の写真 f:id:nihonpanda:20181214215152j:plain











買い出しを済まし、20分ほど車を走らせ目的地の「本栖湖キャンプ場」に到着。

時刻は15時。

ファミリーキャンプやグループキャンプの間をかいくぐり、

人気の無さそうな場所を見つけ車を駐車する。






荷物を下ろし、テントを張る、

前に1本目、「富士桜高原 麦酒 ヴァイツェン

フルーティーで甘い、気がする、めっちゃうまい。 f:id:nihonpanda:20181214214819j:plain











テントを張ったり薪を割ったりしながらヴァイツェンを飲み終える。

焚き火台をセットし、薪を組み、火をつけ、安定したところで2本目、「富士桜高原 麦酒 ピルス」。 f:id:nihonpanda:20181214214921j:plain











ヴァイツェンと違い苦味がしっかりあるが、飲みやすく、「こっち1本目にすればよかったなぁ〜〜〜〜」と思った。めっちゃうまい。

まったりと焚き火とピルスを堪能していたら、気がつけば時刻は17時、本格的に外が暗くなってきた。

ここで焚き火に網を張り、道の駅で買ったソーセージを火にかける。

ごめん、写真は忘れた。

ソーセージの皮が程よく焦げ、熱せられた肉が皮を破るか破らないかくらいのところで、3本目、

「富士桜高原 麦酒 シュヴァルツヴァイツェン」。 f:id:nihonpanda:20181214214946j:plain











黒ビールのしっかりとした苦味を期待して口をつけたものの、色に反して思ったより飲みやすい。

しかし、喉を通った後にしっかりと残る苦味は黒ビールのそれ、めっちゃうまい。

ソーセージもめっちゃうまい。

ソーセージを平らげ、シュヴァルツヴァイツェンを飲み干し、道の駅で買ったものは終わり。

正直あと2本くらい買っとけばよかった。まじで。めっちゃうまかった。

仕方なく、澄んだ空気と自然を地ビールに思いを馳せつつ、というか完全に地ビールに後ろ髪を引かれつつ、

持ってきたウィスキーを飲んで、その日のささやかな宴会は終了。

何が言いたいかっていうと、

外で飲むビール + その土地でその土地の地ビール = 最強

これに限りますね。

以上、Beer Advent Calendar 14日目でした。

転職ドラフトで転職した話

久しぶりです。

僕です。

タイトル通りでございます。
堪え性がないですね。
2年に1回転職すると死ぬ病気なんですよきっと。

今回はホントにご報告程度の話で、
前回みたいに壮絶な内容は別にないんですよね。
なのでオチもないです。

なので、何書こうかちょっと迷ったのでそもそも書くつもりも無かったんだけど、
今回の転職ではタイトル通り、転職ドラフトというサービスを使って転職したので、その話を書いて見ようかと思います。

きっかけ

転職ドラフトに登録した時には転職する気なんてあんまりなかったんです。
まったくなかったとは言いませんけどね。

なぜ登録したかどうかを知るには、転職ドラフトというサービスについてざっくり解説する必要があるのでざっくりと。

まず、履歴書と職務経歴書的なことを転職ドラフトのページから入力していきます。
で、それを見た企業は、「年収◯◯◯万円でほしい!」と言って指名していくんです。

指名された、登録した我々は入札額を見て気に入った企業と各転職プロセスに入るわけです。

で、そんなサービスがあると知った僕は、
「これ、自分のエンジニアとしての市場価格わかるな。」
と思ったのです。

自分のエンジニアとしての市場価格って、割りと大事だと僕は思っていて、
上でまったく転職する気が無いわけではなかった、と言ったのは、
今の会社よりもお給料増えたらいいなぁと思って、
でもそんなに変わらないなら別に転職する必要も無いなぁと思って登録した次第です。

指名と面接

登録したらおもったより指名が来ました。
前職(登録当時につとめていた会社)の年収よりも低い額を提示してくる会社も無くて、
「ほほーーーーん、こりゃええ」
なんて思いました。

で、せっかく年収もいい感じだし、誰でも知ってるような会社だし、興味あるなーくらいの感じで面接を受けることにしました。

面接は3回あったんですけど、面接の内容に関しては転職ドラフト関係ないし、社名を明かさずに内容を書く自信もないので、割愛します。

そんな感じで3回の面接が済み、第1希望の会社から内定を頂き、
転職するに至ったというところでございます。

まとめ

転職先で1週間仕事した週末にこのブログを書いてます。
とりあえずなれない事だらけでとても疲れました。
でもとても楽しいですよ。

前職では、自分は自分が作ってるサービスのターゲットではないという事にとてもストレスを感じていたのですが、
今回は自分がターゲットとなり得るサービスの開発に携われるところも楽しいです。

あとは、たぶん所謂メガベンチャーと呼ばれる会社に入ったんですけど、
毎日「でかい会社はすげーなぁー」とか思ってます。

今回はこれ以上も以下もないので、
質問とかコメントで貰えれば返信していきますし、
僕の事を知ってる知人友人各位は、僕にご飯を奢るなり、
僕に転職祝いをプレゼントするなりすればいいと思います。

そんな感じでーす。ばいばーい。

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日にしてならず。なのです。

まとめ

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

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

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

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

あさが来たおもしろい。

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

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