Make組ブログ

Python、Webサービスや製品開発、ライブラリー開発についてhirokikyが書きます

いまこそ、執筆を変えるとき。ShodoにAI校正の機能をリリースしました

なぜ、執筆することって色々と大変なのでしょうか?

実は、書くことそのものよりも、 文章のチェックや記事の管理が大変だと僕は考えています。 文章を単に書くことであれば、あまり大変ではないのかもしれません。 たしかに最初に書きはじめるには腰が重いときもありますが、筆が乗れば悩まずに書けてしまうのは皆さんも経験があるのではないでしょうか。

記事や原稿を執筆する際の面倒な作業や大変さをすべて解決する仕組みがあれば、これはもうすごく良さそうです。 その発想で Shodo というWebアプリケーションは作られています。

今日は、その ShodoにAIでの文章校正をする機能を追加したことを発表します

f:id:hirokiky:20200721001528p:plain
Shodo AIの概要

Shodoとはなにか

Shodo(ショドー) https://shodo.ink/ は原稿や記事の執筆をするためのプラットフォームです。 記事の自動校正やチームメンバーとの相互レビュー、執筆タスクの管理やアサイン、スケジュール管理を可能にします

とくにオススメなのがブログ記事を執筆するときです。複数人で記事を書く場合はより一層おすすめです。 これからの時代は単なる広告ではなく、コンテンツマーケティングが重要になってくると僕は考えています。 さらに本の執筆も、今となっては紙に手で原稿を書く人などおらず、誰しもがPCを使って人と協力しながら本を書いているはずです。

詳しくはぜひ以下のページをご確認ください。

shodo.ink

今の、リモートワークや在宅作業中心の仕事環境でこそ効果を発揮するプラットフォームです。

ShodoのAI校正では「自然さ」を判断してくれる

Shodoでは、あなたの執筆をよりクリエイティブにすることを目的にしています。 そのために、面倒な記事のチェックや校正をしてくれるAI校正機能をリリースしました。

f:id:hirokiky:20200720235911j:plain
Shodo AI校正

ShodoのAI校正を使えば、文中の単語が「自然に使われそうか」を判断してくれます

今までの校正ツールというのは、単にルールベースでの指摘しかできないものが多かったと思います。 たとえばだ・であるの統一などはチェックできるものの、「解決」と「怪傑」の変換ミスや不自然な単語やタイポなどの検出はできません。

その点、ShodoのAI校正を使えばルールベースで対応できないタイポや単語の不自然さ、変換ミスなども指摘してくれます。 Shodoはルールベースの校正も対応しているので、AI校正と両輪で力を発揮します

文章の自然さをヒートマップで表示します

僕は正直、「校正」というのがあまり好きではありません。 良くないところだけ指摘されて、あまり気分はよくありませんよね。

ShodoのAI校正では文章にヒートマップを重ねて、「文中の単語の自然さ」を表示してくれます。 さらに、特定の単語があまり良くなさそうなときは変更案もサジェストしてくれます。

f:id:hirokiky:20200721000045p:plain
Shodo AIのハイライト表示

この機能が良いのは、単にダメなところを指摘するだけでなく、全体的に自然な文になっている箇所を確認できることにあります。 単に「ここは良くない」というだけでなく、「このあたりは良さそう」、「この単語は伝わりにくいかな」といったニュアンスも把握できます。

ShodoのAI校正の弱点

ただし弱点としては、AIが把握してない世界の特定の用語などを使われると、「良くない」と判断される点です。 その記事や著者独特の造語なども指摘されてしまいます。 たとえば、PyQ新コースのリリースブログ をチェックしたときは、学習コンテンツ内に登場する「ヘビ」という言葉について変更がサジェストされていました。まぁ、プログラミングの学習コンテンツを紹介する文章で「ヘビ」という単語がでると自然ではないかもしれませんが、PyQのこの記事の文脈ではOKな内容のはずです。

ですので、「一般的な自然さで見たときに、どう見えるか」という判断材料にこのAIでの校正機能を使ってください。 もちろん、タイポや変換ミスは自然ではないので指摘してくれます。

AI校正はどんな方法で実現しているか

僕自身、Shodoでの校正機能を強化するためにAIをどう活用できるか実験をしていました。 RNN・LSTMなどを使ったりもしましたが、イマイチ性能がでませんでした。

そこで最終的にはBERTを使って文章の校正をしています。 この BERTがすごくてビックリしました 。日本語の文章でのAI・機械学習は難しいと思っていたので、BERTで誤検出がかなり少ないことに驚きました。 8年前にも機械学習を使って記事のオススメをするWebサービスを作っていましたが、今回はそのときを遥かに超えた実用レベルでの性能になったかと思います。

本当にすごい。

エンジニアとしてプログラミングをしたり、多少は機械学習やデータ分析をかじっていると、どうしてもAIという言葉を斜に構えて捉えてしまいがちです。 僕自身もそうなのですが、このBERTについては考えを改めざるを得ません。 10年、20年という単位で考えればAIがより多くの仕事をサポートしてくれるというのは十分あり得る未来 だと思います。

今後、ShodoではAIへの研究開発を進めていきたいですし、課題解決の際もAIや機械学習で抜本的に解決できないかと発想していきたいです。 もちろんBERTのもつ課題やShodoのAI校正の弱点や足りない点も改善していきたいです。

Shodo AI校正の利用方法

Shodo https://shodo.ink/ のページからクローズドベータの利用にご応募ください

現状は完全に 無料です。いきなり大金を請求するとかはないのでご安心ください。

ぜひ、Shodoを利用してみての率直な感想をお寄せください。Shodo内のフィードバック機能からたくさん送ってくれると嬉しいです。 Twitterに書いてくれても嬉しいです (おかしな点や不適切な表現などがある場合はTwitterよりもShodo内のフィードバック機能を使って教えてください)。

ただ注意点として、現状ShodoのAI校正機能は 平日の10時から15時までのみ 利用できます。 理由は単純で、サーバーのホスティングにものすごくお金がかかるからです。AI校正って結構、大変です。

あと、クローズドベータの利用にご応募いただいてもすぐに利用開始できるわけではありません。利用が開始できないかもしれません。 これもサーバーリソースと私の対応できる範囲に限界があるからですので、ご理解いただけると幸いです。

ぜひ、 クローズドベータに応募して、使ってみて、感想を教えてくれると嬉しいです! ぜひ、ぜひ、ご協力いただけると嬉しいです。

shodo.ink

デスクの横に置く専用のラックを買ったら幸せでした。テレワーク/リモートワークのお供に

リモートワークをしていると自宅のデスクが本当に重要になってきます。 デスクのうえがどうしても物であふれがちだったので、デスクの横に置く専用のラックを買いました。

デスクの横専用ってなんじゃそりゃという感じですが、ラックにしては横幅はかなり細く高さもそれほどない作りになっています。 デスクの天板と ラックの板の高さを合わせてデスクを延長 できたり、なかなかに快適です。ちょっと感動したので紹介させてください。

f:id:hirokiky:20200423214600j:plain
ラックの様子

棚板は穴開きのスチールなのですが、1つだけ板が木になっていて机の延長に使うことが想定された設計になっています。さらにコの字のフレームなどもついていたので物を置いても落ちる心配がなくて良いです。

僕はもともと物理ノートやiPadなども使いながら仕事をしていたり、最近だとマイク用のオーディオインターフェースもあったりでデスクが手狭になっていました。 それら「手元にほしいけどデスクには置いておきたくないもの」を置く場所として導入しました。

結果としてデスクまわりがスッキリしたので大満足です。

f:id:hirokiky:20200423215036j:plain
デスクがスッキリ

ラックの下にはタワーPCも置けます。 このPCケースが上部にも排熱があるので、素で置いておくと上から水をこぼしそうでこわいのもあって良いです。

f:id:hirokiky:20200423213918j:plain
ラック下にタワーPC

トミカも飾っています。 まぁこれは他に優先度の高いものができれば別の場所に置く予定です。

f:id:hirokiky:20200423213911j:plain
トミカ

ラックと言えばアイリスオーヤマメタルラック、というイメージでしたが、このデスクサイドに置くために設計されたラックは局所的にかなりオススメしたいです。ちょうど欲しかったものを見つけられました。 僕はサイズが幅60.5cm、奥行き 25.5cm、高さ120.5cmのラックにしました。ドスパラのガレリア(幅20.5cmのPC)はちょうど入ります。僕の机の高さは70cmでした。

値段も1万2000円と悪くない値段ですし、品質的にもシッカリ作られているので満足です。 まだ今なら在庫もあってAmazonプライムなら2日でくるのでぜひ買ってみてはどうでしょう。

このリンクから買ってくれると僕のRedbull代になるので助かります。

他にオススメの記事

2年前の記事でこのときからアップグレードしてますが、基本のデスクなどはこのままです。 このときにひとしきり整備しておいて良かったです(今は在庫が少なかったりするので)。

blog.hirokiky.org

なぜ「メルカリCEOからの緊急事態宣言を受けてのメッセージ」は問題を含むのか

メルカリCEOからの緊急事態宣言を受けてのメッセージというページがメルカリから公開されました。

about.mercari.com

これを受けてTwitterはてなブックマークコメントでは、一部このメッセージに批判的なコメントがされています。 僕としてこのメッセージやコミュニケーション上で何が問題だったのか?を話したいと思います。

私のスタンスから

先に軽く私のスタンスを話しておくと、 このメッセージ自体には問題はないと思います 。 ですが、 コミュニケーションとして大きなズレがあるのが問題です 。 CEO、経営者として全く問題ないメッセージを発信していると思います。

では何が問題だったのか。一部の読んだ人たちに反感を買ったのはなぜなのかを考えたいと思います。 これはあくまで私の意見ですので、軽い読み物と思ってくれると嬉しいです。

メッセージと批判の要約

「メルカリCEOからの緊急事態宣言を受けてのメッセージ」は以下のような内容です。

  1. 緊急事態宣言が出た。メルカリは政府要請にも応えていく
  2. メルカリUSはロックダウン中もサービス運営ができた
  3. 日本のメルカリでも在宅勤務へ完全に移行する
  4. 在宅勤務にあたって6万円を手当として支給する
  5. メルカリで生命を直接救うことはできないが、暮らしに必要な物を届けることで社会貢献をする

https://about.mercari.com/press/news/article/20200408_message-from-ceo/

批判的なコメントとしては以下のようなものがありました

  • メルカリが止めればマスクや消毒液の不足もなかったのでは?
  • 6万円は転売で稼いだお金か
  • 利用者に関係のないメッセージを社長から利用者に投げても自慢に聞こえる

もちろん、「がんばれ!」や「社会的にリモート化の流れが進みそうだ」、「6万円支給は英断」のようなコメントもTwitterをみると見受けられます。 正直、はてなブックマークのコメントは少し「叩きすぎ」な印象です。ですが、批判自体に筋が通っていないわけではありません。どういうことでしょうか?

コミュニケーション上の問題は何か

端的に言いますと、 「誰に対するメッセージかを間違えている」のが問題 だと僕は思います。

このメッセージ自体は問題ありません。むしろとても良い取り組みだと思いますので、応援したいと思います。 ですがそれはメルカリで働く人、メルカリで働くことを想像できる人、メルカリの投資家、経営者としての視点です。 在宅勤務でもサービス運営できることや、6万円の支給などは、会社としてであり人事としての話でしかありません。 サービスを利用する人たちという視点が欠落しています。対外的に発信されるメッセージであれば、サービス利用者を忘れてはいけません。

多くの一般的な人の気持ちとしては「メルカリ」という名前はサービスであり、手元にインストールされているアプリのことです。会社のことではありません 。そこでコミュニケーションの齟齬が発生しています。

とくに今はコロナウィルスの感染拡大によって、高額転売が問題になっています。Amazonやメルカリで転売が横行しているのは事実です。マスクや消毒液、NintendoSwitchが高値で取引されて、本当に必要な人の手に適正な価格で届いていないという背景があります。

「ウチの会社ではこんな取り組みをしている」、「6万円を支給する」とメッセージを向けられれば、「何の自慢を聞かされているのか?」「まず他に言うことがあるのでは?」という反感がまず生まれても自然です。 一般的な感覚で読むと、背景にある時流を意識せざるを得ません。もちろん「メルカリは高額転売」と直接イコールと考えるのは大きな間違いですし、メルカリも高額転売対策もされていると思いますが、「悪い目で見れば」そういった批判はできてしまいます。

マイナスの見方をしている人が欲しかった言葉はまず「ごめんね」でした。その後に取り組みの話をしても良かったのではないでしょうか。

どうすれば良かったか

私なりの解決としては2つあります。1つ目は会社とサービスを分離すること、2つ目は会社代表がお客様代表であることです。

1つ目については簡単で、会社名を「メルカリ」というサービス名から変えることです。そうすることで「会社代表としてのメッセージ」として、サービスの言葉ではないと分離できます。会社名を変えるのは大変だと思うので、今回のメッセージは社内向けにだけにするのが手っ取り早いかなと思います。

2つ目はサービス運営、会社運営そのものについてです 。会社の代表者である以前にお客様の代表者であるべき です。今回のメッセージは圧倒的に利用者の視点が足りていないです。ひとこと「マスクなどでご迷惑をおかけした」、「だが対策を引き続き講じるし、より良いサービス提供を続けていきたい」と添えておけば万人に受け入れやすいものになったでしょう。マイナスの視点を持つ人は必ずいます。その人がプラスの気持ちに転じられるように、まず一言「申し訳なかったな」と気持ちを添えるのが大切です。その瞬間だけは、ちょっとくだけた文体になってるほうが心に響きやすいと思います。

イメージしてください、自分が買えなかった消毒液がメルカリで高額転売されていたら。自分が予約もできなかったNintendoSwitchどうぶつの森同梱版がメルカリで倍以上の値段で売られていたら?まずその気持ちに応えるべきです。

「CEOとして言うべきことか?」と思われるかもしれませんが、そこが問題です。メルカリCEOという名前を使う時点で、一般的に利用する立場としては 「僕たちの使っているサービスの代表者」と感じます 。会社経営者としては違うと思うかもしれませんが、 避けられませんし、避けるべきではありません

サービスを運営する会社の代表者は、 会社の代表者である以前にお客様の代表者であるべき です。 お客様の視点をもって、会社やサービス、従業員、投資家を鼓舞して導いていくべきです。私自身言っていて、相当に難しいと思います。私もPyQというサービスをビープラウドという会社の従業員として開発、運営していますが、その「お客様の視点」は常に意識していないと抜けていってしまいます。これは本当に難しいので、私自身も道からそれてしまうことはよくあります。

あなたの会社が成り立っているのは、お客様の課題を解決しているからです。 従業員が頑張っていたり投資家がいてくれるのも大切ですが、根本的にはお客様の課題があって、それを解決して初めて会社に価値が生まれます。 今回のメッセージはそれを完全に忘れています。高額転売の問題はお客様に課題を与えてしまっています。このことについてはメルカリが一生懸命取り組んでいるのを知っていますが、それでもこの「メルカリCEOからのメッセージ」としては無視してはいけなかったと思います。

社内でレビューしよう

こういったメッセージや記事、コンテンツはお客様との大切な対話の瞬間です。 人にはいろんな視点がありますので、ぜひ社内で十分にレビューすることをオススメします。

そんなときはShodoというWebサービスを使うことをオススメします。 これは私が個人的に運営しているWebサービスで、記事の執筆、レビューなどをオンライン上ですべて賄えるプラットフォームです。 メルカリの皆さん。ぜひShodoの導入はいかがでしょうか?クローズドベータ利用者を絶賛募集中です。

shodo.ink

家にいる子供に見せたいサイエンス系のYouTubeチャンネル・動画

新型コロナウイルスの影響で学童がなしになって、午後も子供がずっといる!

そんなときに、リモートワークの邪魔にならないようにとYouTubeばかり見せるのはイマイチです。

そこで、見せるにもものによるだろうということで、子供に見せたいYouTubeチャンネル・YouTube動画を紹介します。 僕が普段好きで見ている動画ということなので、サイエンス系の動画をオススメします。

Kurzgesagt – In a Nutshell

サイエンス系のチャンネルであれば、間違いなくオススメするのがKurzgesagtです。 難しい問題をわかりやすく説明してくれますし、情報元になるソースへのリンク、専門家へのヒアリングなどもちゃんとされており信頼できます。

英語のチャンネルですが、 日本語の字幕がほとんど必ずついているので、字幕を有効にしてください 。 正直、Kurzgesagtだけ見せておけば十分だと思います。

www.youtube.com

個人的には以下のダイソン球(Dyson Swarm)の話が大好きです。

www.youtube.com

あとアルゼンチンアリの話。

www.youtube.com

オーガニックとは何かについての話。

www.youtube.com

NIMS PR

NIMS、国立研究開発法人物質・材料研究機構の公式チャンネルです。 これもサイエンス系の面白い動画がたくさんあります。どちらかというと物性についての話が多いです。 Eテレっぽい感じです。

www.youtube.com

超電導の紹介など、

www.youtube.com

この金属の強さを調べる実験の話はオススメです。

www.youtube.com

JSTScienceChannel

JST科学技術振興機構のチャンネルです。

www.youtube.com

とくに、「~ができるまで」シリーズが面白いので絶対に見てほしいです。 こんなふうに作られてるのか!思ったよりも大変だなぁと、家にいながら社会科見学ができます。

ぜひ、ひよこ饅頭ができる様を見てください。

www.youtube.com

ブルドーザーができるまで、も圧巻です。

www.youtube.com

ちくわもオススメです。

www.youtube.com

あとたこ焼きとか、ビンとか、そうめんとか、ピンポン玉とか、オススメは色々あります。

LearnEngeneering日本語

エンジニアリングについての解説をするチャンネルです。機械の仕組みなどについて学べます。 日本語化されているチャンネルですが、翻訳や元の解説そのものが微妙だったりもするので、「へー」くらいに見るのが良いかと思います。

www.youtube.com

車の部品についての説明なんかは面白いです。

www.youtube.com

ヘリコプターも、まじですごいな!と驚かされます。

www.youtube.com

おわりに

YouTubeを見る、というとあまり良くないイメージもありますが、見るチャンネルによってはとても有益です。 他にも SpaceX のチャンネルや、 ナショナルジオグラフィック のチャンネルもおすすめです。

あと英語学習とかであれば あいうえおフォニックス など、良質な情報は探せばあります。 YouTubeにオススメされるまま、くだらない動画を見るのも楽しいですが、ぜひこの家にいる機会にお子さんと一緒にサイエンス動画を見るのはどうでしょうか?

僕にはたぶんトゥレット症候群があります。

僕にはたぶんトゥレット症候群があります。

僕のことをよく知っている人は、僕にチックがあると知っていると思います。 トゥレット症候群は、俗にいうチック症です。トゥレット障害とも言います(僕は"症候群"という語選びのほうが良いと思います)。 僕は20年以上この性質と一緒に生きています(今、28歳なんで)。

ビリー・アイリッシュがトゥレットを公言していて、なんてすごいんだと救われたような気持ちになったので僕も書きたいなと思いました。 (まぁ実際は、書こうかなと思ってから長いこと考えて、何度も書き直しているのですが)

ぜひこの動画を見てください。スパイス・ガールズのくだりなども笑えるので。

Billie Eilish Gets Candid About Tourette Syndrome

www.youtube.com

僕の記憶にある一番最初のチックは、幼稚園のころにシャツの襟を引っ張る癖でした。そのせいで僕のシャツや体操着はすべて襟がデロデロに伸びていました。 嘘だと思う人は僕の親や幼稚園の先生に聴いてみてください。幼稚園の運動会のときに僕は締太鼓を演奏したのですが、演奏が終わったときに誰かが「今日は襟を引っ張らなかったね」と褒めてくれたのをよく覚えています。そのときは、とても複雑な気持ちでした。それを良いことだとこの人は思っていたんだなと。

そこから小学生のころに目を強くつぶるチックやお腹を引っ込ませるチックなどに変わっていきました。 ただ、チックによってはものすごく体調が悪くなるものもあります。たとえばお腹を引っ込ませるものなどは吐き気も催すので、かなり体調が悪くなります。

僕は今、ほほを釣り上げるチックがメインになっています。ここ10年以上続いていますがこれが一番安泰です。症状としても軽めなのかもしれません。 人に見られてもまぁそこまで突拍子もなくないですし、身体的なダメージも小さいからです。せいぜい表情筋が痛くなるくらいでしょうか。 他にも細かいものはたくさんあります。トゥレット(チック症)の人だと分かるのかも知れませんが、チックには流行りみたいなのがあったり、転移したりします。 特定の歯の裏を押すだとか、腹筋に力を入れるだとか、足の人差し指の上に親指を乗せて強く握るだとか。まぁ、本当に色々あります。

症状の強弱などにも波があって、ストレスを感じているときや疲れているときは出やすくなります。 あとは年齢とともに出やすくなっている気もしています(これはちょっと怖い)。 人前などではうまくコントロールしていますし、まったく意識しなくてもコントロールできているときも多いです。それも状況や相手、体調や心理状況によって変わります。 登壇しているときとか、歌っているとき、マイクに喋っているときとかはかなり収まるなど、特定の場面で落ち着いたりもあります。幼稚園のころ演奏した締太鼓も、こういった場面だったのでしょう。自分でもなぜなのかよくわかりません。

ここ最近トゥレット症候群について理解が広まっている気がします。昔よりも個性の一環として受け入れられているのでしょうか。 僕は性格面でも妙なこだわりがあったり、自分ですら色々と大変だなぁと思っているのですが、それも最近は受け入れられているようでありがたいです。

ただ、僕はとくに医師の診断を受けたいとは思っていません。 診断を受ける理由もとくにないですし、投薬して治療したいモチベーションもないので精神科には行ったことがありません (何か利点があればぜひ教えてください)。 あとそういう人のソーシャルグループみたいなのに行こうかなと昔思ったこともありましたが、他の人から転移しないかが心配で行くのをやめました。 これもわかりにくい問題ですが、人の動きとかをコピーする性質もあるので難しいものです。

結論を言うのはとても難しいです。周りの人にはあまり気にしないようにしてもらうのが一番良いかもしれません。 とはいえ別にその話をするなというわけでもなくて、ちゃんと信頼関係のある人にはチックについて聞かれても嫌な気持ちにはなりません。 ただ、性自認についてや宗教観と同じくらいパーソナルな話題であることは間違いありません。 僕にとっては、与えられた性格や才能、宗教観と同じように、自分自身の一部だからです。

追記

こんなTogetterを見つけました。この人も音声チックなんじゃないかなと思います(注意されて治そうとしたけど治らなかったとあるので)。 でもブコメとか見てもトゥレットについて書いてる人は1人くらいしかいなくて、社会的な認知の低さを感じました。

togetter.com

10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました

f:id:hirokiky:20200220104314j:plain
自走プログラマー表紙

「自走プログラマー」という本が出ます!

この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。

僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕(著者全員)が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー(とPythonプロフェッショナルプログラミング)を読んでもらったうえで普段話をしたいです。

私個人としても PyQShodo を作りながら会得したこと、ビープラウドで学んできたことを詰め込んだ内容の本になっています。

プログラミングで手戻りが多くありませんか?

レビューなどで、多くの指摘をうけて 手戻りが大きくなっていませんか ? 実際に 本番環境で運用しはじめてから問題に気づく ことは多くないですか?

自走プログラマーはそういった人のための本です。自走プログラマーの前書きより引用します。

開発現場で起こった実際の問題とその解決法をもとに,文法以外に必要な「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。

こんな方におすすめ:

  • プログラムを書けるけど,レビュー指摘などで手戻りが多い人
  • 優れたエンジニアになりたい人
  • 設計の仕方や,メンテナンス性の高いプログラムの書き方を知りたい人

自走プログラマーは120個のプラクティスを通して学べる本です。 各プラクティスには具体的な失敗とベストプラクティス、説明が書かれています。 120個のプラクティスはこちらです(以下、長いです)。 気になるものがあるか見てみてください。本の雰囲気も伝わると思います。

自走プログラマーの目次

  • 1.1 関数設計

    • 1 関数名は処理内容を想像できる名前にする
    • 2 関数名ではより具体的な意味の英単語を使おう
    • 3 関数名から想像できる型の戻り値を返す
    • 4 副作用のない関数にまとめる
    • 5 意味づけできるまとまりで関数化する
    • 6 リストや辞書をデフォルト引数にしない
    • 7 コレクションを引数にせずintやstrを受け取る
    • 8 インデックス番号に意味を持たせない
    • 9 関数の引数に可変長引数を乱用しない
    • 10 コメントには「なぜ」を書く
    • 11 コントローラーには処理を書かない
  • 1.2 クラス設計

    • 12 辞書でなくクラスを定義する
    • 13 dataclassを使う
    • 14 別メソッドに値を渡すためだけに属性を設定しない
    • 15 インスタンスを作る関数をクラスメソッドにする
  • 1.3 モジュール設計

    • 16 utils.pyのような汎用的な名前を避ける
    • 17 ビジネスロジックをモジュールに分割する
    • 18 モジュール名のオススメ集
  • 1.4 ユニットテスト

    • 19 テストにテスト対象と同等の実装を書かない
    • 20 1つのテストメソッドでは1つの項目のみ確認する
    • 21 テストケースは準備,実行,検証に分割しよう
    • 22 単体テストをする観点から実装の設計を洗練させる
    • 23 テストから外部環境への依存を排除しよう
    • 24 テスト用のデータはテスト後に削除しよう
    • 25 テストユーティリティーを活用する
    • 26 テストケース毎にテストデータを用意する
    • 27 必要十分なテストデータを用意する
    • 28 テストの実行順序に依存しないテストを書く
    • 29 返り値がリストの関数のテストで要素数をテストする
    • 30 テストで確認する内容に関係するデータのみ作成する
    • 31 過剰なmockを避ける
    • 32 カバレッジだけでなく重要な処理は条件網羅をする
  • 1.5 実装の進め方

    • 33 公式ドキュメントを読もう
    • 34 一度に実装する範囲を小さくしよう
    • 35 基本的な機能だけ実装してレビューしよう
    • 36 実装方針を相談しよう
    • 37 実装予定箇所にコメントを入れた時点でレビューしよう
    • 38 必要十分なコードにする
    • 39 開発アーキテクチャドキュメント
  • 1.6 レビュー

    • 40 PRの差分にレビュアー向け説明を書こう
    • 41 PRに不要な差分を持たせないようにしよう
    • 42 レビュアーはレビューの根拠を明示しよう
    • 43 レビューのチェックリストを作ろう
    • 44 レビュー時間をあらかじめ見積もりに含めよう
    • 45 ちょっとした修正のつもりでコードを際限なく書き換えてしまう
  • 2.1 データ設計

  • 2.2 テーブル定義

    • 49 NULLをなるべく避ける
    • 50 一意制約をつける
    • 51 参照頻度が低いカラムはテーブルを分ける
    • 52 予備カラムを用意しない
    • 53 ブール値でなく日時にする
    • 54 データはなるべく物理削除をする
    • 55 typeカラムを神格化しない
    • 56 有意コードをなるべく定義しない
    • 57 カラム名を統一する
  • 2.3 Django ORMとの付き合い方

  • 3.1 エラーハンドリング

    • 63 臆さずにエラーを発生させる
    • 64 例外を握り潰さない
    • 65 try節は短く書く
    • 66 専用の例外クラスでエラー原因を明示する
  • 3.2 ロギング

    • 67 トラブル解決に役立つログを出力しよう
    • 68 ログがどこに出ているか確認しよう
    • 69 ログメッセージをフォーマットしてロガーに渡さない
    • 70 個別の名前でロガーを作らない
    • 71 info,errorだけでなくログレベルを使い分ける
    • 72 ログにはprintでなくloggerを使う
    • 73 ログには5W1Hを書く
    • 74 ログファイルを管理する
    • 75 Sentryでエラーログを通知/監視する
  • 3.3 トラブルシューティングデバッグ

    • 76 シンプルに実装しパフォーマンスを計測して改善しよう
    • 77 トランザクション内はなるべく短い時間で処理する
    • 78 ソースコードの更新が確実に動作に反映される工夫をしよう
  • 4.1 プロジェクト構成

    • 79 本番環境はシンプルな仕組みで構築する
    • 80 OSが提供するPythonを使う
    • 81 OS標準以外のPythonを使う
    • 82 Docker公式のPythonを使う
    • 83 Pythonの仮想環境を使う
    • 84 リポジトリのルートディレクトリはシンプルに構成する
    • 85 設定ファイルを環境別に分割する
    • 86 状況依存の設定を環境変数に分離する
    • 87 設定ファイルもバージョン管理しよう
  • 4.2 サーバー構成

    • 88 共有ストレージを用意しよう
    • 89 ファイルをCDNから配信する
    • 90 KVS(Key Value Store)を利用しよう
    • 91 時間のかかる処理は非同期化しよう
    • 92 タスク非同期処理
  • 4.3 プロセス設計

    • 93 サービスマネージャーでプロセスを管理する
    • 94 デーモンは自動で起動させよう
    • 95 Celeryのタスクにはプリミティブなデータを渡そう
  • 4.4 ライブラリ

    • 96 要件から適切なライブラリを選ぼう
    • 97 バージョンをいつ上げるのか
    • 98 フレームワークを使おう(巨人の肩の上に乗ろう)
    • 99 フレームワークの機能を知ろう
  • 4.5 リソース設計

    • 100 ファイルパスはプログラムからの相対パスで組み立てよう
    • 101 ファイルを格納するディレクトリを分散させる
    • 102 一時的な作業ファイルは一時ファイル置き場に作成する
    • 103 一時的な作業ファイルには絶対に競合しない名前を使う
    • 104 セッションデータの保存にはRDBかKVSを使おう
  • 4.6 ネットワーク

    • 105 127.0.0.1と0.0.0.0の違い
    • 106 ssh port forwardingによるリモートサーバーアクセス
    • 107 リバースプロキシ
    • 108 Unixドメインソケットによるリバースプロキシ接続
    • 109 不正なドメイン名でのアクセスを拒否する
    • 110 hostsファイルを変更してドメイン登録と異なるIPアドレスにアクセスする
  • 5.1 要件定義

    • 111 いきなり作り始めてはいけない
    • 112 作りたい価値から考える
    • 113 100%の要件定義を目指さない
  • 5.2 画面モックアップ

    • 114 文字だけで伝えず,画像や画面で伝える
    • 115 モックアップは完成させよう
    • 116 遷移,入力,表示に注目しよう
    • 117 コアになる画面から書こう
    • 118 モックアップから実装までをイメージしよう
    • 119 最小で実用できる部分から作ろう
    • 120 ストーリーが満たせるかレビューしよう

こうやって見ると、よく書いたもんだなと思います。 著者の3人が個別のプラクティスを分業して書きました。

ちなみに僕の担当は1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 22, 23, 25, 28, 29, 30, 31, 32, 49, 50, 51, 52, 53, 54, 55, 56, 57, 69, 70, 71, 72, 73, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120です!

手取り足取り教えてくれる本ではありません

網羅的かつ段階的に設計やアプリケーション開発を教える本ではありません。 ですので「入門書はとりあえず終わったので次に何かを教えてくれる本が欲しいな」という人には残念ながら向いていません。 本が課題やサンプルを提示して、 「あなたもこれを作ってみよう」という本ではありません

ですが、設計やアプリケーション開発に重要なこと、ノウハウやプラクティスはたくさんお伝えしています。 何か作りたいものがあって、挑戦しているがうまくいかないことが多く悩んでいる人にはオススメします 。 逆に、何か作りたいものも分からない人や、自力でプログラムを書いてみたことがあまりない人にはオススメしません。

もし先輩プログラマーの人でこの本を後輩さんに読ませたいなというときは、この本がアドバイスや導きのキッカケになると嬉しいです。 もしかしたら、キッチリ題材を作って学ばしてあげる必要があるかもしれません。1プラクティスに書かれている内容が、先輩的には十分とは思えないかもしれません。 そのときはぜひ、直接後輩さんや他メンバーにあなた自身のノウハウを教えてあげてください。

"Pythonの本"ではありません

自走プログラマーは、 Pythonに限らない広い範囲で使える知識を読める本 です。 そういう意味では既存のPythonの本とは少し違います。どちらかというと、リーダブルコードに近いかもしれません。

内容はプログラミング言語Pythonを使って書かれていますし、Python製のライブラリーやフレームワークを元にした説明が中心になります。 なので、プログラミングも詳しくないし、Pythonも詳しくないという人には分かりにくいかもしれません。 逆に、RubyRuby on Railsに慣れている人などは勉強になると思います。具体的にPython製のライブラリーを紹介しているトピックなどはありますが、その部分は「Rubyでもこういうライブラリーはあるのかな?」と考えて読んでいただければと思います。

長い長い執筆期間と込めたノウハウ

この本は著者陣が仕事の中で他の人に教えたことを中心に執筆しています。 たとえばコードレビューや、社内でのサポート、社内外の研修、コンサルティングの中で伝えてきたことをまとめています。 ビープラウド社内のメンバーも積極的にレビュー、コメントしてくれて、社内のかなりのノウハウが取り込まれています。

執筆に際しては社内で半年から1年をかけてネタを集めて、選別する時間を設けました。 著者の3人が日々の業務で伝えたことや感じたこと、過去に社内で伝えたことをネタ帳として集めてから執筆しています。 たとえば「ログには5W1Hを書こう」という僕が執筆を担当したプラクティスがあるのですが、これは5年前(2015年)から社内では共有していた知識です。これは社内でも好評で、「ロギングって大事だけど、何を書くべきかを学べる場所がなかった」とフィードバックを受けていました。 そのノウハウがやっと日の目を見ることになって、僕個人としてはとても嬉しいです。こんなにうれしいことはない。。

それ以外にもこの本は紆余曲折あり、一旦けっこう書いた内容を、構成や構造を変えて新しくしたりと大変でした。 執筆メンバーが抜けて再スタートしたり、正直、時間をかなり書けたので費用対効果はかなり悪い本になってしまったなと思っています。 ですがその分、長い時間を使っただけに本当に良い内容だけが本に抽出されたように思います。

ぜひ、この本を読んで日々のプログラミングやチームの改善に役立ててもらえると嬉しいです。

電子書籍は発売中です! (2020年2月22日より発売)物理本も発売中です!(2020年2月27日より発売)

Epub/PDF版は技術評論社のサイトから購入できます(2月22日より)。 PDFで欲しい!という方は技術評論社からご購入ください。

他に知りたいこととか気になることがあれば何でも @hirokiky に聞いてください。

他にオススメの記事

shacho.beproud.jp

blog.hirokiky.org

shodo.ink

Pythonのリストはイテレーターでない。わかりやすい(はずの)イテレーターとイテラブルの説明

こんにちは。 Pythonに関する書籍を書く際や、人に説明するときに「リストはイテレーター」と言っていませんか? それは間違いです。僕自身も勘違いしちゃうことがよくあるので、記憶を整理する意味でもブログにまとめておきます (もし間違えていたら教えてくれると嬉しいです)。

とくに、「リストはイテレーターです」、「rangeはイテレーターです」、「dict.keys()はイテレーターを返します」、など間違いが多いので注意しましょう。

リストはイテレーターではない

まず、リストはイテレーターではないということを感じてもらいます。 以下をPythonインタプリターで実行してください。 TypeError: 'list' object is not an iterator とエラーが表示されるはずです。

>>> l = [0, 1, 2, 3]
>>> next(l)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not an iterator

はい。Pythonさんもリストはイテレーターではないと言っています。

「forループで使えるものはイテレーターじゃないの?」 という疑問があるかもしれません。うーん、惜しい。 その答えは イテラブル(Iterable) です。

リストもrangeオブジェクトもdict.keys()も、「イテラブル(Iterable)」と言えば間違いありません。 イテラブルは for in ... に渡せるものです。

早く答えが欲しい人へ

早い説明をします。イテラブルかイテレーターかの簡単な判別方法をお伝えします。 超ざっくりと説明すると、以下です。

  • iter(...) できるものは、イテラブル
  • next(...) できるものは、イテレータ

本に説明を書くときとかは、一度上記を実行しておくと安心かもしれません。 往々にして説明したいのは「イテラブル」だと思いますが。

じゃぁイテレーターって何?

イテレーターは反復するもので、その進行状況を持っているものです。 forループは指定されたイテラブルからイテレーターを取り出して、ループの1回1回を処理していきます。 おっと、意味がわかりませんね!(ブラウザを閉じないで!)

ではfor文の気持ちになってリストの処理をしましょう。 for文は以下のようにして、リストをループします。

>>> l = [0, 1, 2, 3]  # これはリスト
>>> l_iter = iter(l)  # リストからlist_iteratorを取り出す
>>> next(l_iter)
0
>>> next(l_iter)
1
>>> next(l_iter)
2
>>> next(l_iter)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration

このようにリストイテレータを順次 next(...) することで1つ1つリストの要素を取り出しています。 すべての要素が取り出されると、イテレーターは StopIteration を送出します。

なぜこのようになっているかというと、簡単に言えばforループの繰り返し処理を制御するためです。 リストをループするときに、ループがどこまで進んでいるかを管理するためにリストイテレーターが使われています。

もしリスト自身がイテレーターであれば、1度ループしただけでリストはループできなくなってしまいます(ループの進行状況が管理されるので)。 そのために、リスト自身ではなくリストイテレーターさん(つまりイテレーター)にループの状況を管理してもらっています。Pythonってすごい!

イテレーターは同時にイテラブルでもあります。 なので、イテレーターは for in ... に渡せます。この場合、イテレーターは iter(my_iterator) をすると my_iterator 自身を返します。

また、for文は以下のようにも模式的に書けます。 この my_for 関数は、第一引数にイテラブルを、第二引数にforブロックの処理に相当する関数を渡します。

>>> def my_for(iterable, iter_func):
...     it = iter(iterable)
...     try:
...         while True:
...             el = next(it)
...             iter_func(el)
...     except StopIteration:
...         pass
...

そうすると、forを使わずにforのような動きができます (あくまでも模式的にですが)。

>>> def print_pow(el):
...     print(el ** 2)
...
>>> my_for([0, 1, 2, 3], print_pow)
0
1
4
9

イテレーターって何があるの

じゃぁイテレーターって何があるの?と思われるかもしれません。 たとえばジェネレーターや BytesIO などがイテレーターです。よく「ループしたら使い切られる」やつがイテレーターです。

  • イテレーターではない(イテラブル)
    • 文字列
    • リスト
    • タプル
    • rangeオブジェクト
    • 辞書、辞書.keys()、辞書.values()、辞書.items()
    • 集合
  • イテレーター(イテラブル)
    • リストとかタプルとかrangeとかを iter したら返ってくるやつ
    • ジェネレーター
    • ファイルとかのI/O

ちなみに yield を使った関数は「ジェネレーターを返す関数」であり、イテラブルではありません。