Pythonでも型を明記しよう

こんにちは、Scalaエンジニアのnishikawaです。今回はpythonについて少し話したいと思います。

Pythonって世間では

• ライブラリが充実している
• インタプリタ言語でコーディングから実行までが手軽

という印象が強く、初心者やプログラムが本職じゃない人からも好かれる言語だと思います。特に動的型付けによりスクリプトっぽい書き味に加え、オブジェクト指向プログラミングや関数型プログラミングなど、色んなスタイルでコードを組めるのも人気の一つなのではないかと思っております。

そんなPython、書き捨てレベルのコードならいざ知らず、本気で何か組もうと思うとある問題に差し掛かります。

それは

コードを書いているうちにどのようなデータを扱っているかを見失う

ということです。

これを読んでいる人は「そんなことないでしょw」と思うかもしれませんが、少しでもそのアプリから離れると途端に何をやってたか分からなくなることは少しプログラムを組んだことある人なら誰しも経験があると思います。これは動的型付け言語あるあるだと個人的には思っています。

これを解決するには型を宣言するのが一番でPython3からではそれができます。

そもそもPythonにはどんな型があるのか

Pythonにはどんな型があるのか代表的なものと自分が少し気になったものを以下にまとめてみました。

組み込み型	説明
bool	真偽値
int	整数
float	浮動小数点数
complex	複素数
list	リスト
tuple	タプル
str	文字列
bytes	バイトオブジェクト
bytearray	可変バイトオブジェクト
memoryview	バッファプロトコルをサポートするオブジェクトの内部データへ直にアクセスすることができるオブジェクト
set	集合型
dict	マッピングオブジェクト（俗にいう連想配列やハッシュマップ）

複素数のcomplexやmemoryviewなんかは目からウロコでした。（複素数の型があるとか斬新w）

Pythonで型を宣言しながら変数を定義してみる

では、本題の型の宣言を行いながら変数を定義してみます。

書式は簡単で変数の直後にコロン区切りで組み込み型を定義します。

<変数名>: <組み込み型>

以下はREPLで変数宣言して値を代入し、出力した時の例

>>> zero: int = 0
>>> print(zero)
0
>>>

変数宣言時の例

>>> def test_print(txt: str):
...     print(txt)
...
>>> test_print("test")
test
>>>

実装時に型を宣言した方がいいと思った場所

ここまで型について色々書いてきましたが、最後にpythonでアプリケーションを実装する上で最低限こういう場合に型の宣言を入れておいた方がいいなと思った箇所をまとめておきます（備忘的な意味も込めて）

• メソッド宣言時の引数と返り値
• フィールドメンバー
• 生成したインスタンスを格納するための変数

メソッド宣言時の引数と返り値

メソッドを宣言する時、何をするものなのかをメソッド名に込めて実装することは多いと思いますが、メソッド名やコメントだけではどういうデータをインプットにどういうアウトプットを出すのかを見失うことがあります。そのため引数やメソッドの返り値の型を明確にすることでこの問題を回避できます。

フィールドメンバー

クラス内に定義するフィールドメンバーの型定義も重要なポイントだと思います。フィールドメンバーはクラスがどういう属性のデータを格納しているかを知るにはとてもいい情報だと思うからです。

これらの情報をしっかり書き込むことで、クラスの改修時や設計の見直しにも役立つと思います。

生成したインスタンスを格納するための変数

これはどちらかというとIDE用にあるといいなという感じです。IDEで全く型を定義しないでコーディングを行うと補完機能が使えないことが多々あります。 そのため型の定義はやった方がいいと思います。

もっと言うとIDEの機能を最大限に活かすなら全ての変数の型を定義した方がいいと思います。

まとめ

Pythonはバージョンが3になってからより多くの機能が追加されました。変数に型を明示してもどんな値も受け入れてしまうなど、依然として型の重要性は低いですが、少なくとも人間がコーディングを行う限り今回紹介した型を明示的に表記できる機能は地味ながらとても重要だと思います。

この機能を活用してpythonのコードをより良いものにしてみてはいかがでしょうか。　

PostgreSQL の バグ修正状況を調べてみた。

はじめに

初めてこちらのblogに登場いたします。データエンジニアのt-sugai です。
今年の1月頃からアスタミューゼにJOINしています。
前職はJavaをメインとしたアプリケーションエンジニア……だったと思うのですが、エンジニアはエンジニアでいっしょくたの組織でした。そして最近は運用やDBAのような仕事を任されることが多かったこともあり、アスタミューゼではデータエンジニアとして働いています。

今日はデータエンジニアらしくデータベースのお話をしようと思います。

アスタミューゼで利用されているPostgreSQL

国内外の特許の情報をはじめ、様々な技術情報を持っているアスタミューゼですが、RDBMSとしては主としてPostgreSQLを利用しています。 （もちろん、RDB以外のDBMSもデータの量や特性、利用目的に応じていろいろ使っているのですが、今回はRDBのお話です）
私が入社する以前の話ですが、PostgreSQLを9.6にUpgradeした話も書かれています。

そう、世界にイノベーションを起こすための原石たり得るアスタミューゼの技術情報を保管しているDBなので、世の中の流れに追随して適切にバージョンアップしていかなければなりません。
論理レプリケーションが使えれば、バックアップの考え方はもちろん、準リアルタイムでのデータ加工についても利用方法が広がるでしょうし、大規模データに対してのSELECTではパラレルクエリーの効果だって期待できます。
さあ、早くPostgreSQL12にしましょう！
おっといけない、12はまだbetaだった。でも11なら正式リリースから半年以上経ったし、そろそろアップグレードしましょう！！

冷静な視点

新しもの好き、なによりも便利な機能とPostgreSQLが大好きな私はともかくとして、インフラ・事業に責任を持つ部長の namikawa からは

「ちょっと落ち着け。当たり前だが客観的にみて安定したといえるバージョンを使うようにしたい。バグ曲線みたいなものを参考にしながら、今後も使えるアップグレード方針を検討してほしい」

という、至極まっとうなリクエストが出たのでした。

PostgreSQL の 開発プロセス

PostgreSQLはオープンソースのDBMSです。そして、近年のOSSプロジェクトにしては珍しい（と思う）のですが、基本的に本体の開発に関する議論はすべてMailing List（ML）で行っており、Issue Trackerに類するものがありません。
そうなるといわゆるバグ曲線的なものはすぐには得られませんね。
ないものは仕方がないのですが、「たぶん大丈夫だとおもうからUpgradeしようぜ」とはさすがに私もいえません。
このリクエストをいただくときに、「アスタミューゼでの話ではないが、某DBMSをうかつにUpgradeしてひどいバグを踏んでデータが壊れた経験がある」などという話をされていたのでなおさらです。

代替手段はないか？

要は新規リリース直後の、多くの人に使っていただいたからこそ出てきた不具合修正が収束してきていることがわかれば良いのです。
修正の情報が一番わかりやすそうなのはリリースノートじゃないでしょうか。
ということで、PostgreSQLのリリースノートを眺めてみましょう。
コミットメッセージなどでもよく使われる表現ですが、不具合の修正に類することは、ほぼ必ず「FIX 〜」という記述になっているように見受けられます。
これを数え上げたら、割とそれっぽい情報として代替できないでしょうか？

ところで Jupyter Notebook というやつがあるよね。

と、いうことで、スクレイピングというのもおこがましいレベルの話ではありますが、リリースノートのページをいくつか巡回して、内容を抽出して数え上げて、なんなら最後にグラフにでもできるとうれしいですね。

ここまで考えたとき、こういうのは「PythonとJupyterNotebookを使うといいぜ」と心のどこかで囁く声が聞こえた気がしました。 勝手知ったる curl と grep と sed と awk 、あとはスプレッドシートでもあればどうにかなってしまいそうな気もしましたが、その場合次回アップグレード時などにもう一度やるのが面倒くさそうだったし、なによりも私はデータエンジニアに転向したのです。Pythonとももっと仲良くなりたい。そんな気持ちでJupyter手習いをやってみようと思ったのでした。

最近はDockerという便利なものがあるので、ちょっと使ってみたいくらいの用途だったら

$ docker pull jupyter/datascience-notebook
$ docker run --name notebook -p 8888:8888 jupyter/datascience-notebook

こんな感じでサクッと環境が作れてしまいます。簡単ですね。

プログラミングしてみる。

PythonやJupyter NotebookのTIPSについては、ほかに詳細なドキュメント・記事が豊富にありますし、ここですべてを解説することはしませんが、やってみたことをいくつかご紹介してみようと思います。

今回書いたソースコードは github.com/t-suga/postgresql_release_checkに置いておきます。

後半でデータをソートしたり分割したりするところで試行錯誤が多くなりすぎて力尽きました。
もう少しきれいにできたような気もするのですが……精進いたします。

Webページの取得とデータ抽出

HTTPリクエストは、 requests 、 DOMのパースには BeautifulSoup というライブラリがよく使われているようなので、これを使ってみました。 正規表現には re 、 集計には pandas グラフには matplotlib という定番ライブラリです。

これらを使えば、リリースノートのページから Fix〜 の 記述を抽出して、数え上げることは簡単です。 累積のFix数にするためには cumsum というメソッドを使いました。

PostgreSQLは初版からリリースノートがありますが、EOLになっているものまでスクレイピングすることはないでしょう。今回は9.3以降を対象とするようにしました。

初回の失敗。

当たり前ですが、素朴にやるとプロットはリリースごとになります。
そして、もちろんですが日々のアップデートには既存バグの改修というのもあり、そういったバックポートされるようなFixがあるため、このグラフはいつまでたっても収束しているようには見えなくなってしまいます。

リリースの間隔を考慮し、グラフを調整する。

リリースごとにリリース日を収集するようにして、リリース日の差分を取ることにします。
今回は、間隔の比が保存できていればいいと割り切って大分横着をしてしまいましたが、どうにかマイナーバージョン1を0として、リリースまでの期間が横軸になるようにデータを成形することができました。
このあたりもう少しきれいな方法があれば是非教えていただきたいです。

最後に、古いメジャーバージョンのものはそれだけ累積バグ数が大きくなりますが、ある一定のところまできたらあまり意味がないはずです。ということで、縦軸は対数にしてしまいます。

そんな感じで得られたグラフがこちらです。

得られたグラフ

グラフを読み解く。

といっても、一目瞭然で、きれいにほぼ同型のグラフになっています。
一番新しい11のラインすらもほぼ安定のカーブに半ば程度到達しており、10に関しては峠は越えたなという感じでしょう。
バージョン全体を概観すると、PostgreSQLはリリースから大体半年も経てば安定し始めており、1年経てばほぼ十分に安定すると考えてよさそうです。

まとめ

これらのことから、現状では（まだ）最新の11を利用するというのもある程度安心できるんじゃないでしょうか。と進言することができそうです。
また、スクリプト化したので次に更新を検討する際にも、リリースノートの公開方法が大きく変わっていなければ少ない手直しで再実行できることでしょう。

最後に、毎度のお願いで恐縮ではございますが、アスタミューゼではエンジニア・デザイナーを募集中です。 興味のある方は是非下記のバナーからご応募をお願いいたします。

プロジェクトにBIツール「metabase」を導入したらいい感じになった話。

こんにちは、アスタミューゼでデザイナーをしている@YojiShirakiです。

最近、新規プロジェクトでBIツール（metabase）導入していい感じに機能しつつあるので、どのように導入したかその変化をご紹介したいと思います。

BI導入の背景

BIの導入は次のような理由で早い段階で導入しようと考えていました。

1. プロジェクトが横断的で共通認識とコンセンサスの土台が必要であること
2. Webサービスではあるがキャッシュポイントが契約（オフライン）にあること
3. 初期の機能実装が最低限で、リリースした後の機能実装ニーズが継続的に相当量見込めること

２番目の「キャッシュポイントがオフラインにある」点は特に注意が必要です。というのも、キャッシュポイントが近いところの意見はどうしても強くなりがちで、「お客様の声」事案は優先順位が高めに設定されやすくなるためです。

「お客様の声」はとても重要です。しかし、現状クリアすべき事業課題・サービス課題 とお客様の声は必ずしも同次元ではありませんから、そこを無自覚に「お客様の声」を優先し続けてしまうと、本質的な事業課題への対処が遅れ、プロジェクトが遅延するリスクが高まります。

そうならないように、プロジェクトの初期段階で基本的な数値基盤を構築し、ユーザーシナリオやそれに付帯するKPIと照らし合わせながら課題解決をしていく目線醸成が重要になるわけですね。

「お客様の声」で明らかに改善すべき箇所は継続的に改善しつつ、一方で、数値によって明らかにされるマクロなサービス課題への対応をロスを少なく実行していく、そのための数値整備というイメージです。

なお、余談ですが優先順位判断のメソッドについては様々なものがあるので調べてみてください。

例）プロダクト開発における意思決定のための「ユーザーストーリーの優先順位付け手法」まとめ

機能は計測可能に設計しておくこと

BIは数字を可視化するツールですから、数字が取れることが前提です。そのために比較的早い段階から計測を意識した機能実装の意識醸成に配慮します。

具体的には、企画時にその成果をどのように計測するのかを議論できるように企画書のフォーマット作りを行います。企画書の骨子として以下のようなフォーマットを定義し行動を強制するようにします。

1. 企画意図・目的
2. 期待する効果
3. その計測方法
4. 具体的な実装内容

計測方法が定義されていない企画書はフォーマット違反なので、別途議論するというふうになります。

計測方法はGAでも良いですし、ログでもいいと思います。ただログデータの収集機構を構築するのはそれなりにコストがかかるので、手っ取り早く履歴テーブルなどを新たに整備してしまうのも良いかと思います。何れにせよ行動が記録に残るように企画段階で方針を固めておきます。

試験導入（とツールの選定ミス）

ある程度状況が整ってきたら試験導入です。今回は以下の5つを検討しました。無料ツールではメジャーな選択肢だと思います。

• re:dash
• superset
• metabase
• PowerBI
• Google Data Studio（現 Google Data Portal）

上記のうち re:dash, superset, PowerBI は既に触ったことがあり感触はわかっていたので、今回は（あまり時間も割けなかったということもあり）インストール不要で、且つ、アカウント管理が容易な Google Data Studio を選択しました。

なお最初に作ったダッシュボードはこんな感じです。

ぼかしが多くて解りにくいですが営業活動向けダッシュボードを作りました。まず最初に営業に役立つものを作ることで、営業・企画メンバーに対して数値化メリットを感じてもらいたいと考えたためです。思った以上に好評だったのでこの意図は奏功したと思っています。

metabase への乗り換え

ただ一方で以下のような誤算もありました。

1. 思った以上にもっと数値を見たいという要望が挙がってきた
2. Google Data Studio の画面レイアウト思ったよりもが使いにくい・面倒
3. Google Data Studio のDBとのコネクション設定動作が安定しない
4. Google Data Studio のグラフ表現力が弱い・設定が難しい

1 はともかく、2,3,4 についてはかなり辛いものがありまして、早々に Google Data Studio に見切りをつけ別のツールの検討を始めます。

結果的には、この時、たまたまプライベートで試していて頗る感触の良かった metabase への乗り換えを決めます。

圧倒的な metabase の使いやすさ

metabase の選定は良かったと思います。インストールが簡単で DB の設定も容易です。他にも

1. Googleの oauth が使えるためアカウント制御が容易（Gsuiteとの相性が良い）
2. GAとの連携が可能で他のデータと重ね合わせて見せることができる
3. データの抽出が超簡単
4. ダッシュボードレイアウトがしやすい
5. デザインがきれい

など。特に、3, 4, 5 は日々の利用が楽しくなるレベルで洗練されています（なお、1, 2 は re:dash でも可能です）。

デザインとUI/UX が優れているのが最もポイント高かったです。

とは言え、なかなか伝わらないと思うので YouTube にあがっている Demo が参考になるので貼っておきます。

作ったダッシュボード

さて、ではその metabase でどんなダッシュボードを作ったかと言うと下記のようなものです（数字はいじってあります）。デイリーで追うべき数字とその推移をメインに置いたもので、一つのダッシュボードの情報量は少なくして、見るべき数字に集中できるように心がけて作っています（そのかわりダッシュボードの数はやや多め）。

※数字はダミーです

※数字はダミーです

最近ではもっと込み入った情報などの可視化も行っていて、あるデータ母集団と別のデータ母集団のマッチング判定データなども可視化しています。

だがしかし…メンバーからのフィードバックが思ったより薄かった

ただ意外なことに作ったダッシュボードについては、あまり大きなフィードバックを得られませんでした。 Google Data Studio でダッシュボードを作っていたからか、「あ、こういう数字見れるのね、ふーん」くらいです。悲熊・・。

そこでもっとアピールするために企画の MTG の時に metabase を映し出して必要な数字やグラフを即時に出すことを何度か行いました。

これが結構刺さりまして「おお、凄い」とか「あ、これいいですね」など言われるようになり「数字が即座に見られる」「色々な数字が手軽に見られる」という感覚が広まりました。ライブ感って大事ですね、いい勉強になりました。

加えてやはり metabase が気軽に数字を引っ張ってこれる様になっているので、人によっては「あ、それ自分も使いたい」となったと思います。

議論と企画の質の変化

こんなゲリラをしばらく繰り返していった結果徐々にチーム内で以下のような変化が生まれました。

1. 課題がどこにあるのか数字も交えて議論するようになった
2. 何かをやる時に事前に軽く調べてみるという理解が進んだ

1 については、例えば「●●機能は面白いけど、今はその手前の数値が悪くてボトルネックだから、まずはそこを改善するのが先じゃない？」とか「そこって数値どうなってんだっけ？効果でる？」などの発言が増えていくような変化でした。

2 については、「面白そうな機能を考えてみたものの今のデータ数だと有効にワークしないので一旦置いておこう」や、逆に「数値見たら●●に課題はあるけど、そこを改善すればワークする可能性が高いからやってみよう」とういケースも出てきました。

何れにせよ、数値をもって一定の客観性と共通認識を確立したことで「思いついたら実装する」から脱却し徐々に良い方向に向かようになりました。

とは言えデータドリブンの限界は認識しておくべき

とは言え私たちのチームメンバーはデータが全てとは思っていません。データと同じくらい発想・インスピレーションも大事に考えています（そもそもこの2つは相反するものではなく補完関係です）し、またデータによって明らかにできない課題（というよりも付加価値の可能性）があることも承知しています。

大事なことは、そういったマインドも持ちつつも定量的アプローチでシャープに課題認識と優先順位判断を行い、より良いサービスを作っていく姿勢を全員が持つことだと思っています。

まとめ

ということで、今回は BIツール導入の流れと、どのように変化したかをメモがてらまとめてみました。

長々書きましたが、こういう取り組みは、プロダクトマネジメントがしっかりしている企業から見ると、至極普通なことだと思っています。ですので、私たちももっとレベルアップしていかないとなぁ、と日々日々感じる次第です。

もし本稿について何かご質問等あれば@YojiShirakiにDM頂ければと思います。本文では触れませんでしたが metabase のインストール方法などはそれなりにしっかり検証したのでお役に立てると思います。

では、本日も最後までお読みいただきありがとうございました。

例によって当社では一緒にサービス開発してくれるエンジニア・デザイナー・ディレクターを超絶賛募集しております。

カジュアル面談も随時行っておりますので、「ちょっと話聞きたい」という方は、このブログのサイドバー下にあるアドレスか@YojiShirakiにDMいただければと思います。いつでもウェルカムです。採用サイトもありますので下の水色のバナーから是非どうぞ！ではまた:- )

（@YojiShirakiの過去記事）

• オフィス移転したので移転ポイント・反省をまとめてみた
• デザイナーが「デザイン経営」宣言を読んでみた
• デザイナーもデブサミに行った方がいい理由をざっくりまとめてみた
• デザイン採用担当はポートフォリオで何を見ているか、何が見えているか？
• 広告費用を自動取得し100時間分の作業をなくす話
• デザイナーが「言葉」についてちょっと真面目に考えてみた
• お手軽に英文文書にメタ情報を!!Pythonでgensimを使ったLDAに挑戦してみた。
• 英文の自然言語処理におススメ！お手軽なPolyglotを使ってみた。