- リニューアルした須磨の水族館に行きたい
- スマホで見れるスライドショーアプリを作りたい
- 常夜灯代わりの大きなLED時計を買いたい
- ちゃぶ台にリモコン類をいれるちょっとしたポケットを発明したい
- アクスタを壁に飾るためのソリューションを発明したい（それが100円ショップで買えるものなら尚良し）
- コントの脚本書きたい
- 映画の予告編だけ編集したい
- 溶接やってみたい（ちょっとした金属棚や椅子を作りたい）
- サイボウズみたいなやつのオープンソース版つくりたい
- FFMPEGだけでフィットネス向けの動画（ほとんど音とリズムのみ）を自動生成したい
- ダイエットレシピ動画をまとめたい（GoProつけて主観アングルで）
- 主成分がほぼワセリンでありながら伸びやすい保湿クリームを発明したい
- R-1出場したい（謝罪会見芸で極めたい。大企業の広報の設定、教育委員会の設定など）
- ボルダリング始めたい（すぐに飽きてもよし）
- 肘当てのついたジャケットをオーダーしたい。擦り切れたら同じものを同じテーラーで補充したい
- 藤井隆のようにダンスを踊りたい。ヨジャドルの一節でいい
ふるさと納税の返礼品を地域通貨にしたらどこまで節税の範囲で散財できるのか
渋谷区のふるさと納税の返礼品にハチペイがある。ハチペイは渋谷区の地域通貨で、QRコード決済として使える。渋谷区の店舗ではよく見かける。ミニマリストにとっては一番うれしい返礼品かもしれない。
じゃぁふるさと納税の上限いっぱいまでハチペイに変換してしまえば、節税の範囲で渋谷区で散財できるのではないかという検証をしてみた。
ハチペイが使える店舗の全てでふるさと納税経由のパチペイが使えるわけではなかった
例えば新宿高島屋は新宿と言いながらも住所は渋谷区なのでハチペイが使える。しかしながらふるさと納税経由の地域通貨は物販には使えない。したがって、高島屋でルイヴィトンのバッグをハチペイで買ってそれを換金化ということはできない。
じゃぁいったいハチペイ加盟店のうちどこがふるさと納税経由のパチペイが使えるのさ！となると、PDFで公開されているのでそれをみてみる。
https://www.hachi-pay.tokyo/handout/pdf/furusato_list.pdf
PDFをエクセルに変換してみよう
PDFだと項目別に集計しづらい。PDFをエクセルに変換してみよう。
手動でPDFをエクセルに変換する時には「PDF to Excel」でググると一番上にでてくるサイトを私は使ってる。
Solid Documentsという有償ライブラリを使って変換している。私の知る範囲では一番賢い。
PDFをExcelに変換するとこんな感じ
シートが以下の３つに分かれてる。（これはPDF to Excelがいい感じにシートを分けてくれた）
- 飲食店
- 宿泊施設
- 美容室・ネイルサロン
宿泊施設は３つくらいしかない。圧倒的に多いのは飲食店（1233件）。美容室は362件。表参道の美容室がそこそこ含まれてる。
エクセルに変換したらこっちのもの
エクセルシートに変換したことで分析可能になる。例えば業種の欄でグループ化して多い順に並べるとこんな感じ。
飲食店もチェーン店は使えないようになってる。あくまでふるさと納税の思想として渋谷区の企業を応援する思想からするとごもっとも。
気になるカテゴリをドリルダウンしてみる。
キャバレーもふるさと納税で使えるの？と思ったけど、小さなスナックが多いようだ。
ファーストフードも大規模チェーンではない。
業種でくくると「贅沢度」が絞れない。店舗名には施設名が含まれることが多い。店舗名に「セルリアン」が含まれる条件でフィルタするとどうだろう。ホテルの中に入ってる飲食店ならそれなりのレベルのはずだ。
ちょうどいいラインナップが出てきた。コーヒーが1,580円する坐忘も含まれてる。「節税の範囲で散財」という元のテーマではちょうどいい。自分ではなかなかこの価格帯には手を出せない。スタバがいっぱいでオロオロするくらいなら節税の範囲で高級喫茶というのはありだろう。
この調査を始める前に「あるかなぁ」と思っていたマッサージ店は意外になかった。無制限に節税できてしまうからだろうか。
ということで元のお題にある「地域通貨で散財できるか」ということに関しては、飲食店と宿泊と美容室に絞られるため、単価・購買数ともにむやみに散財するのは難しそう。
PDFで公開するなんて野蛮？
ふるさと納税経由かどうかは無関係にハチペイが使える店の検索フォームは実は存在する。
ただし、この検索フォームだと「住所に道玄坂が含まれる店舗一覧」みたいな検索方法は使えない。PDF形式で公開されてるのは一見ださいけど、テキスト部分一致で探せるPDFはそれなりに便利だし、今どきのPDF解析ツールは賢くなってきているので一気にエクセルに変換するのもプログラミングスキルなしにできるようになってきた。エクセルに変換しちゃえば一般的なPCスキルをもった人が自由に加工可能なデータになる。
そもそもルールが流動的なふるさと納税周辺業務ロジックをITシステムに組み込むのってシステムメンテが大変。自治体の従業員が手元で管理してくれてるエクセルファイルをPDFとして公開することで速報性という価値があがるならそれも良い。
納期と生産性の関係
この記事の感想。
生産性の定義は経済学上は右往左往してる。そもそも生産量の定義から違う。都市伝説として語られてるのは「生産量とは重量である」みたいな話。だから旧ソ連のテレビにはレンガが入ってた、みたいな。これは笑い話であるというとがわかりやすいけど、上記の記事でも生産性の定義はあやふやだ。
ところが会計上は「労働生産性」として定義ははっきりしている。「従業員一人当たり付加価値」のことだ。付加価値も一般名詞に近いので定義が迷うところだけど、会計上も付加価値の定義は明確となってる。細かい差はあるけど、ほぼ「粗利」とか「売上総利益」と同等だと思っていい（原価に何を含めるかの差はあるので厳密には粗利と付加価値は違う）。売上から原価は引かれてるけど人件費はまだ引いてない状態。まだ「会社と従業員が山分けする前」のお金だと思っていい。
労働生産性をわかりやすく言うと「従業員一人あたりの粗利」。
つまり「納期がなければ生産性が上がる」という説は「納期がなくなれば一人あたりの粗利は増える」と同じ意味になる。
粗利の増やし方はシンプル。で売上が上がるか原価が下がるか。じゃぁ以下の問に答えてみよう。売上は商品単価ｘ販売数で分解される。
- 納期がなくなれば商品単価が上がる？
- 納期がなくなれば販売数が上がる？
- 納期がなくなれば原価が下がる？
どれも納得感もなければ、相関もない。
じゃぁ、納期がない職種の人でもそれなりにお給料がもらえているのは事実だ。どんな企業でも納期がこれといってない従業員はいる。パートタイマーも依頼されたタスクを数分で繰り返すだけなら「いわゆる納期」はない。
マイクロソフトの今のビジネスモデルは、Azureというクラウドサービスで稼いでいる。ユーザがお金を払っているのはマイクロソフトの新しいソフトウェアに支払ってるのではなく、Azureのデータセンターのコンピュータの貸出にお金を払ってる。だからマイクロソフトのソフトウェアエンジニアに納期がないのは当然。じゃぁマイクロソフトに納期はないかというとそんなことはなく、拡大し続けるAzureの契約者数に対してデータセンターのマシンをキッティングしている人はめちゃくちゃ時間に追われてる。新しいデータセンターも確保しないといけない。どこかの誰かは用地確保で地上げも大急ぎだ。
Azureのビジネスが始まる前はマイクロソフトの商品はソフトウェアそのものだから、新バージョンの発売に合わせて納期が存在した。闘うプログラマーを見ればわかるように、地獄のような納期を前にマイクロソフトのエンジニアだって苦労をしている。ちなみに闘うプログラマーの原題は「Show Stopper! - The Breakneck Race to Create Windows NT and the Next Generation at Microsoft」なので、納期を目の前にした地獄の行進で屍を超えた結果が今のNTカーネルといえる。
「納期など私には関係がない」と言ってる従業員はそもそも販売にも製造にも関係がない可能性がある。「今私が会社から居なくなったら、この会社の売上は下がる？原価は上がる？」という問いに対していずれかがYESなら生産性にプラスの影響を与えてる。
ここでは生産性の定義を「一人あたり粗利」と私にとって身近な定義で抑え直したのでやや意地悪かも知れない。ただし付加価値の総量をGDPとして定義されていたりもするので、会計的にも社会的も生産の定義はもはや勝負がついてる。
CSVサンプルを使ったデータ中心アプローチ設計
企業間のデータのやり取りはCSV形式でのデータのやりとりが多いです。 なんでCSVがいいのかってとこのメモ。
CSVのいいところ
エンジニアも非エンジニアも読める
エンジニアにとってCSV出力はさほど難しくありません。 非エンジニアにとってもCSVの読み書きはエクセルでできるレベルの操作です。
データとドキュメントの違いを理解してもらえる
稀にエクセルベースでのデータ納品をするケースもあります。「同じ値が続くときにはセル結合をお願い」されるケースがあります。当然データとしては壊れてしまうのでお断りをすることにはなるのですが、「それがエクセルドキュメントの常識」という考えからすると、なぜ断ってるのかが伝わりにくいです。
Officeドキュメントはあくまでドキュメントであってデータではないです。エクセルは表計算ソフトではあるものの、ドキュメントでもあるため、「加工済みデータ」です。単なるデータとして扱うにはオーバースペックです。むしろエクセルファイルをデータファイルとして扱う方が誤解を生むことになります。
そこでCSV形式でやりとりすることで、データとドキュメントの違いを際立たしてくれます。 エクセルでCSVファイルを作ることもできるので啓蒙・学習ともに可能です。
データ指向でシステム全体を設計できる
「どのCSVをどの会社が作って、どのCSVをどの会社が読む」という取り決めでシステム全体が設計されます。クラス図とかじゃなくて、CSVサンプルが要件定義段階で飛び交います。UMLでいうところの「オブジェクト図」に近いものですが、サンプルのCSVの方がより実業務のプロトタイプとなります。
弊社ではお見積り段階でサンプルCSVを作りそれを見てもらうことで、「必要な項目が揃っているか」と「意味のあるデータの偏りがあるか」を見ていただいています。
情報システムで大事なのは「情報」であって、「データの量・顔ぶれ」が何よりもユーザ体験の本体です。
CSVを見るための機能は今やTableauなどのBIツールで済ませるケースも増えています。BIツールは基本的には参照専用。あちこちでデータが作成されたり更新されたりするのが何よりも設計が難しいのだけれど、「全てのデータはTableuに集まる」という業務フローができあがると、あとはTableau様に食わせるCSV作り師が重要になってきます。「今のデータの偏りをみて次のアクションを決める」これが情報システムのやるべきことであって、それまでのデータはただの中間生成物に過ぎません。
CSVを加工したダッシュボードはまさに「ダッシュボード」であって、計器が並んでおり、計器をみて車体・機体の状況を把握し、ハンドル・操縦桿を操作するという経営そのものとなります。
データ中心アプローチは非エンジニアでも設計できる
紙の書類であってもベースでもデータ中心アプローチで業務設計されます。伝票がレコード、インデックスが台帳です。 紙ではない場合であっても複数のエクセルファイルを使ってデータ中心設計はできています。「誰がどのタイミングでそのエクセルファイルを触ってもいいか」は業務設計のなかで決められます。 エクセルファイルを直接触るのでは、複数人が登録できないなどの問題があるときに、データベースを使ったデータ中心アプローチに変更が可能です。
データ中心アプローチで何もしないと、「一つのテーブルを修正するのに複数のプログラムや画面が発生する」というところがデメリットとされてはいますが、そもそもCRUDマトリックスを作る段階で「一つのテーブルを寄ってたかって修正するの？まじで？」ということがわかるので、「じゃぁ一箇所からしか更新できないようにしようか」という整理をします。混乱しているということがわかるのがCRUDマトリックスです。DOAでデータの上流下流を整理できない人が他のアプローチをとっても別の混乱を生むだけでしょう。
エンジニアでなくても、求人サイトや不動産情報サイトも1万件くらいのCSVをダウンロードさせてよというのがある程度のITリテラシーをもったビジネスパーソンのニーズです。
CSVのつらいところ
エンジニアがエクセルが苦手
そもそもエンジニアの方がOfficeリテラシーが低いケースが散見されます。CSVをエクセルで文字化けせずに読み込むということがひと手間かかります。ひと手間ではあるものの慣れが必要です。「vlookupでテーブルのJOIN的なことができる」「ピボットテーブルでgroup by的なことができる」ということを知ってないと、業務とシステムの翻訳ができません。
さらに言えば、SQLもプログラミング言語の中では第二外語的なポジションで避けて通るエンジニアも多いです。「たくさんのデータが入ったエクセルを集計」「たくさんのデータが入ったDBをSQLで集計」ということが独学ではなかなか習熟しません。
「まずはサンプリングしてクロス集計をしてデータの偏りを見ましょう」がデータサイエンスの基本であるはずが、いきなり機械学習モデルを作ってしまうケースもあります。
ITエンジニアを標榜するものの「Tecnologty」にばかり目がいって「Infomation」の方がおざなりになりがちです。
エンジニアがCSVの仕様を理解してない
\" でESCAPEできると思ってる人もいます。
自前でパーサーを作ってしまって、フィールド内にカンマが発生することや、フィールド内の改行を考慮しないケースもあります。
UTF8のCSVが未だに市民権を得てない
UTF8の.csvのファイルをダブルクリックすると、エクセルはSJISだと解釈して起動します。ひと手間かければUTF8も読めますが、そのひと手間がダブルクリックに負けます。
UI/UXまとめて語るな警察
UI:ユーザーインターフェース UX:ユーザー体験
ユーザーインターフェースはコンピューターの画面のデザイン それだけじゃぁダメだよねということでユーザー体験という言葉もできた
UIデザイナーが手を抜きがちの画面の代表例 チケットぴあの503エラー画面
UIデザイナーがユーザ体験までカバーしている例 グレープカンパニーの404画面
本当のアートディレクターはユーザ体験までカバーする
例）過去にアルバム印刷サイトを作りました。 以下デザイナーがデザインしたもの
- 画面デザイン
- アルバムの紙
- 郵送する封筒
- 宛名のフォント
- 緩衝材の色と形
送付されてテンションがあがることがゴール 週末にあつまって緩衝材を作るという作業さえもUX向上のためには必要だった。
AppleのUXは「売り場」も含まれてる
- AppleStoreのデザインはもちろん
- ヨドバシカメラのApple製品売り場も完全コントロール
- 言うことを聞けない店舗はApple製品をおろさない（そこで代理店契約が切られた会社もある）
自社プロダクトに戻でUXの向上を考える
- 「検索レスポンスの良さ」こそUX
- 「データの鮮度・質・量」こそUX
サービス以外にも目を配ると - 呼びやすいサービス名 - わかりやすいドメイン - レスポンスのよいお問い合わせ対応 - デモのしやすさ - わかりやすい課金プラン
UXをまとめると 「しっかり顧客対応しましょう」ということでしかない。 UXはUIと一緒に語るには大事すぎる。独立して考えるべき。
なぜ進捗会議が必要か
以下過不足なくテキストベースで網羅されていたら進捗会議（≒同期コミュニケーション）は要らない
- 計画おさらい
- 実績
- 実績との差分
- 今後の見通し
- 見通しが悪い場合の対応策
- 次のタスク（計画内と計画外含めて）
- 次のタスクの難易度推定
- メンバーのリソース調整（計画内と計画外）
- プライベートとの調整
- 自分の現スキルとのギャップ（誰かヘルプお願いします）
- 外部環境による計画ギャップ（しかたないのかリカバるのか）
これらが一発で合意形成されることは稀なので会議が必要となる。
ゲームのUIが業務系アプリのUIに比べて優れている理由
ゲームUIに比べて業務系UIは使いづらい。
なぜか。
本業が違うから。
例えばゲームのUIが使いづらかったら「作り直し」が命令される。 牛丼屋の券売機UIが使いづらくても出店が延期されることなどない。牛丼屋の場合、新メニューが美味しくなかったら発売は延期される。 飲食店はメニューさえ満足度高ければ、少々しんどいUIでも乗り越えてくる。初心者殺しのオーダー方法でも乗り越えてくる。
どの企業も本業は大事にする。
