Make組ブログ

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

卑下すると自分にも他人にも良くないんじゃないかという考え

「悪く言っても、自分のことだから良いだろ」と言えばそうです。 でも僕は卑下することはすごく損失が大きいことだと思っています。

ここで言う卑下は、何かあるたびに自分(や自分の周りの人やもの)を悪く言う、癖みたいなもののことです。

卑下 自分をあえて低い位置に引き下げてへりくだること。

www.weblio.jp

もちろん個々人には好きに自分を卑下する権利がありますので、そこを脅かすつもりはありません。 ただ卑下することは自分にも他の人にもマイナスの影響を与えると僕は考えています。ここで、僕なりに気をつけていることを話したいと思います。

この文章は自戒です。受け取り方も自由です。

謙遜との違い

卑下と謙遜の違いはなんでしょうか。 語の定義としては、卑下は謙遜を含んでいそうです。 ここでは「プラスのチャンスがあるときにあえて悪く言う」を謙遜とします。卑下はそれ以外の、単に自分や身内を悪く言ってしまう癖や、悪い状況のときに自分をさらに下げることと捉えましょう。

褒められたときに「ありがとうございます。でもまだまだ頑張らないとですね」と謙遜して言えることは悪くないことだと思います。

自己批判、評価との違い

自分の悪いところを捉えるのが悪いことだとは思いません。

論理的な理由があったり、改善点を探すために自分を客観的に見るのは大切と思います。 感情的・反射的に自分を悪く言うのでなく、自分の性質や思考を外部からトレースできるのは良いことです。

ただ対象として「反射的な卑下」、「癖のような卑下」、「『そんなにあなたは悪くないよ』と言って欲しい卑下」をここでは扱います。

なぜ卑下しないよう気をつけているのか

僕が「卑下すること」を良くないと思う理由は2つあります。 1つ目はもちろん自分のモチベーションや可能性を潰すことにあります。2つ目は自分自身を卑下することで周りの人も下げてしまっているからです。2つ目は気づきにくいうえ損失も大きいので気をつけています。

  • 「私なんてダメです」と言うとき、あなたを好きな人の評価を下げてしまっている
  • 「私が作ったこれは役立たずです」と言うとき、一緒に作っている、関わっている人も下げてしまっている
  • 「私の仕事はダメだった」と言うとき、一緒に仕事をしている人や仕事を教えてくれた・教えようとしている人を下げてしまっている

卑下すると周りの信頼も失ってしまうのではないでしょうか。誰かが信頼してくれている僕を、不当に悪く言う僕は、信頼に値するでしょうか。

僕も自分自身や作ったものの悪いところを見つけるときはあります。僕の場合は「なんだこれは!ひどいな!」とあえて怒ってしまうほうがポジティブな改善にもっていきやすいです。ここは個々人の性格によると思いますが、マイナスに流れそうなときに断ち切るのが大切です。

ともかく卑下することで、自分のモチベーションや他人のモチベーション、信頼を潰しまいがちです。 卑下することで得られるものは少ないです

  • 「自分の悪いことは知っているから言わないで」というアピールがしたい
  • 「自分はこんなに悪い」=>「そんなことないよ」と言って欲しい(交流分析でいう)心理ゲーム

酒の席では許されるかもしれませんが、過度にこのカードを使うのは悪手に思います。 他の人からの信頼や関心、好意を自分の快楽に変換しているようなものです。

仕事や人生は波乗りのようなものだと思っています。自分へのポジティブなエネルギーや挑戦、報酬、改善、快楽をうまく波乗りするとうまくいくと思っています。まずは勢いをつけて、その勢いをなくさないように次の勢いに繋げていく、それが大切なんじゃないでしょうか。うまくいったら「よし!いいぞ!」と自分をあげていきたいものです。

未来の僕へ、卑下しそうなときはこう考えよう

  • 卑下するのは「自分が気持ち良いから反射的にやってるだけだ」と思い直そう
    • 周りの人はもうウンザリしているかもしれない
    • 自分だけでなく他人からの信頼も失うかもしれない
  • 卑下しそうなときは論理的に分析しよう
    • 本当に悪いのか?
    • 悪いとして、『まだ今は』悪いだけで改善できるはずだ
  • 良いところに目を向けよう
    • 褒めよう
    • 良いところをどう活かせるかを考えよう

自分の人生をより良くできるのは自分しかいません。

この辺りの本もオススメなのでぜひ下のリンクから買ってください。

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

Djangoのcacheのキーには必ず文字列を指定しよう

Djangoのキャッシュ(cache)にはキーを文字列として指定しましょう。

>>> from django.core.cache import cache
>>> cache.get("mykey")  # OK
>>> cache.get("1")  # OK
>>> cache.get(1)  # よくない

キャッシュバックエンドの実装によっては数値でも指定できますが、ドキュメントでは「キーは必ず文字列で」とあります。

key should be a str, and value can be any picklable Python object.

docs.djangoproject.com

だいたいのキャッシュバックエンドでは make_key を内部で先に実行するので、数値だろうが文字列に変換されるのであまり問題にはなりません。 例えば以下のような処理でも問題になっていない場合もあります。

>>> from django.core.cache import caches
>>> cache = caches["somemycache"]
>>> cache.set(1, "users-value")

user.id をキーとして使ってしまったときなど、キーを数値として渡してしまいます。 ちゃんと str(...) としておきましょう

Django2.2から、DBバックエンド(DatabaseCache)を使っているときに cache.get(1)cache.delete(1) をするとTypeErrorになります。

>>> cache = caches["..."]
<django.core.cache.backends.db.DatabaseCache object at 0x7f2d5ce37ac8>
>>> cache.get(1)
Traceback (most recent call last):
  File "/usr/lib/python3.7/code.py", line 90, in runcode
    exec(code, self.locals)
  File "<console>", line 1, in <module>
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/db.py", line 52, in get
    return self.get_many([key], version).get(key, default)
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/db.py", line 60, in get_many
    self.validate_key(key)
  File "/home/hirokiky/.../venv/lib/python3.7/site-packages/django/core/cache/backends/base.py", line 245, in validate_key
    if len(key) > MEMCACHE_MAX_KEY_LENGTH:

ここの validate_keymake_key より前に呼ばれるよう動作に2.2からなっていて、エラーになります。

django/db.py at 2.2.3 · django/django · GitHub

もちろんこの動作はバグではありません。もともと、cache.get などのキーには文字列を渡すべきです。 ですが、今まで動作していたり他のLocMemBackendでは数値でも動作していたりで問題に気づきにくいです。気をつけてください。

一応、DjangoTracに「Release Noteにこのことを書いたら」と起票しましたが、まぁ仕様どおり使ってないのが悪いので却下されるかなぁとは思っています。

#30625 (DatabaseCache backend raises TypeError if get/delete received key as integer.) – Django

仕事を人に任せられず忙殺されてる人へ: 小さな組織向け業務設計の方法

f:id:hirokiky:20180505200854j:plain

こんな悩みはありませんか?

  • なぜか忙しくてメインの仕事が進まない
  • 人に任せられない仕事を常に抱えている
  • 人に任せたは良いがうまくいかない

私はあります。日々仕事をする中で悩んでいます。その中で実践して、見つけたことを今日はお話します(まだまだ勉強中なのでフィードバックを貰えると嬉しいです)。

  • 忙しいのは「見えない仕事」に追われているから です。
  • 人に任せられないのは見えない仕事を定義しないから です。

ただしこの話は「手順書を書こう」という話ではありません。 むしろ手順書は無い方が良いです。

ではどう業務設計すれば良いのでしょうか? それを説明します。

対象の人

業務要件定義や業務設計というと、かなりお硬い印象があるかもしれません。 実際に「業務設計」などで検索すると硬い組織での情報が多くでます。 でも私は小さな組織にこそ業務設計が必要だと私は考えています。

数人規模の組織を対象にしています。とくに新しい事業を始めているチームやスタートアップを想定して書いています。私自身が PyQ のチームでの経験などを元にしているからです。 この記事で言う「業務設計」はあくまでも私の中での方法と定義になります。

見えない仕事とは何か

見えない仕事とは「業務として明確に認知されてないがやっている仕事」です(私が今しがた作った言葉です)。

  1. 「インフラの状態を確認する」など日々何気なくやっている仕事
  2. 「サポート対応」のようにぼんやり認知されているがフローや時間の使い方が明確でない仕事

今回の話では2のような「明確になっていない業務フロー」も改善の対象と考えます。 2を含めれば、組織の中にはむしろ見えない仕事のほうが多いかも知れません。 暗黙知として共有されているものの、何をすれば良いかや求める質は人によって違うことが多いものです。

業務になっていないことの問題は?

業務として設計されていない問題はなんでしょうか?理由は2つあります。

  1. 仕事として新しい人に任せにくい
  2. 任せたとしても品質や作業時間にバラつきができる

定義が曖昧なまま作業を依頼すると、個人の解釈やその人の中での「求めるレベル」に質は依存してしまいます。「なんでこれもできないの」、「なんで反応してくれないの」、「なんでこのレベルで出すの」など依頼者側は思いがちですが、単純に共有できていないのが問題です。

傾向として依頼する側はその仕事や事業により深く関わっていることが多いです。なので「意識レベル」のようなものは依頼される側よりも高いはずです。この意識の格差が軋轢を産んでしまいます。逆に考えれば、あなたにとっても「事務処理」などは重要でない仕事かもしれませんが、総務の人に取っては大切な仕事ですよね。

「それらを共有できてる人とだけ仕事をする」というのは1つの正解です。ですが、それがうまくいっているのは 仕事のできる人は自分の中で業務設計ができる からです。 永遠に居続けてもらえるわけではないですし、新しいできる人が脳内で業務設計するコストもかかってしまいます。自分にとっても覚えておくという見えないコストがかかっています。なので、簡単にでも業務設計をすることは大切です。

なぜ業務設計をすべき?

業務設計や業務の定義をするのは、「誰でも効果的に仕事をできるようにする」ため です。 上記のような問題を解決するために、先に決めておこう、明確にしておこうというのが業務設計です。

ただし、何でもかんでも業務として定義すれば良いという訳ではありません。 暗黙知で回っていて十分な業務はそれで良いです。業務設計をするタイミングは以下です

  • 何もできていないのに、なぜか忙しい
  • 人に依頼していて、かつ依頼される側の負荷や人によるムラが大きい

基本的には人と関わるときにコミュニケーションとして定義するのが一番です。 ですが、自分の業務を定義して改善していくキッカケになることを思えば、自分自身のために定義しても良いでしょう(明確でないものを改善していくことはできません)。

業務設計、定義の仕方

ではどう業務を設計すれば良いのでしょうか? 重要なのは以下を書き出すことです

  1. 「業務」の存在の明確化と細分化
  2. 背景、ビジョン、とりくむ姿勢
  3. 役割
  4. 評価指標の用意
  5. フローや流れ、やること
  6. テンプレートの用意、自動化
  7. (おまけとして)手順書の用意

「業務設計」というと一般的には最後の手順(マニュアル)を指すように思いますが、そうではありません。 多くの人はいきなり手順書や事例ベースの説明だけ書いて、本質の伝わらないドキュメントを量産しすぎです。

まずは以上の順でドキュメントに書き出すことが大切です。

1. 業務としての存在と細分化

まずは「その業務がここにある」が分かるだけでも大きな一歩です。 仕事には何があるかを細分化して書き出していきましょう。

例えば「サポート対応」という未定義の仕事を対象に考えると、以下のような内容があるのではないでしょうか。

  • サポート対応
    • お客様への質問への回答
    • 製品、サービスへのフィードバックの対応
    • 法人向けプランの問い合わせや見積もり依頼

細分化することで、明確にすべき業務に何があるのかがよりハッキリ分かるようになります。 これにより業務の目的やゴールが見えてきます。人間は名前をつけていないものを認識できません 。まず、「こういう業務があるな」と定義することから始めましょう。

2. 背景、ビジョン、とりくむ姿勢などのバックグラウンド

マニュアル化の問題は作業者を無知にしてしまうことです 。 そのならないように、背景の情報や、自分たちのビジョン、とりくむ姿勢があれば共有しておきましょう。「依頼者の期待するレベル」に引き上げるために、バックグラウンドの説明と共有が大切です。

  • システム系の作業であれば「背景」や「構成」を共有する
  • タスクや開発であれば「ビジョン」や「あるべき姿」を共有する
  • お客様対応や人とのやり取りであれば「とりくむ姿勢」や「マインド」を共有する

例えば「サポート対応」業務であれば、以下のような「マインド」を共有しておくと良いでしょう。

  • サポート対応にとりくむ姿勢、マインド:
    • お客様を助けてあげようという姿勢でサポートしよう
    • 何かできることは無いかと考えよう。お客様が成功するためには何ができるか考えよう
    • クレームはあくまでサービスへの不満として考え、自分の心への攻撃ではないと考えよう
  • サポート業務への姿勢:
    • なるべくFAQや回答のテンプレートを活用して効率化していこう
      • お客様も質問したりメールするのは大変

あなたの姿勢や背景の理解は素晴らしいものです。それを明文化して、関わるすべての人がその水準やポジティブな気持ちで仕事できるようにしましょう。

3. 役割を分ける

仕事の中で複数の役割があるのであれば、明確にしておきましょう。 とくに「どの範囲について責任を持つのか」を明確にするとトラブルを避けやすいです。

例えば「研修をする仕事」について役割を設計するとすれば以下のようになります

  • 講師
    • 研修当日に研修生が内容を深く理解することに責任を持つ
  • アシスタント
    • 研修当日に講師が滞りなく研修ができることに責任を持つ
  • マネージャー
    • 研修をしたいお客様の求めるレベルに研修生が学ぶことに責任を持つ
    • お客様とのやり取りが滞りなく行われることに責任を持つ
    • 研修内容、費用、日程、アサインする講師とアシスタントを決める責任を持つ
  • 総務
    • お客様への請求、お金のやり取りに責任を持つ
    • 研修に必要な新幹線のチケット、ホテルの手配に責任を持つ

このとき 役割は1人が複数を兼任しても良いと考えます 。1人で仕事をしているときは兼任が多くなります。ですが、「それぞれどういう役割があるか」を意識するとこでやるべき業務が明確になります。

4. 評価指標を決める

できれば業務について評価指標があるとより良いでしょう(必須ではありません)。 仕事についてどこまでのクオリティを求めるかが明確になるからです。

  • 求める指標が分かることで注力すべき点が明確になる
  • 指標を改善していくサイクルが生まれる

例えば研修後にいただくお客様のアンケートの結果などが考えられます。

注意したいのが、数値に対して早すぎる最適化をしないことです。 指標が良い指標であれば良いのですが、業務設計した最初は指標そのもののや取得方法の質が低いものです。指標がどの程度参考にすべき値なのかも共有しておくと安心です。

5. フローや流れ、やること、やらないこと

業務に「大まかにどういった流れがあるのか」を明確にします。 役割とあわせて明確にするとより良いでしょう。

例えば「お見積」であれば以下のようなフローが考えられます

  • お客様からメールでお見積もりの問い合わせをいただく
  • (事務)メールで一次回答をする
  • (事務)社内システムに見積もり依頼があったことを登録する
  • (経営者)担当者をアサインする
  • (担当者)依頼内容を見て見積もりをする
    • 情報が不十分であればメールで返信し、問い合わせする
    • 対面のほうが早そうであればお客様にヒアリングをするミーティングを設定する
    • ミーティングはお客様が良ければオンラインのほうが効率的
  • (担当者)社内システムで見積もり書を発行してお客様にメールする
  • ...

このように大まかな流れと、どんな役割の人が関わるかを明記すると良いでしょう。 これによって「作業の取りこぼし」や「誰にも触れられない仕事」が発生することを防ぎます。

「やってはいけないこと」があるのであれば明確に書いておくと安心です。 やることは書いていて 「やらないこと」「やってはいけないこと」が書いていないと、どこまで自由に考えてやっていいかが分かりません 。ある程度は自由に動けるように、やらないこと・やってはいけないことを明確にしておきましょう。

また、「こうした方が良いよ」というTipsもあれば書いておくと良いでしょう。 新しく仕事をする人がノウハウを身につけるよりも、教えてあげたほうが早いです。

6. テンプレートを用意、自動化

上記のフローについて「タスク」のテンプレートなどを用意しておくと良いでしょう。

  • 業務を追跡するタスクのテンプレートを用意しておく
    • フローをTodoリストにして順次進めるようにする
  • 作るべき書類やシートのテンプレートを用意しておく
  • 必要な作業を自動化して短縮できるようにしておく

このテンプレートがカッチリと決まっていると、作業者は「何を作れば良いのか」が明確になって安心です。また、仕事を終わりまでトラッキングするタスクがあれば「仕事の取りこぼし」も発生しませんし、「背景」や「姿勢」を説明したドキュメントへのリンクも書いておくことができます。

7. 手順書(はあまり大事じゃない?)

手順は、明確にどういう操作をすべきかを書いたものです。 これは操作方法を知らない人がどうすれば良いかがハッキリ分かるように決めたものです。

ですが、私個人としては 手順書はないに越したことはない と考えています。 理由は以下です

  • 簡単な画面の操作方法であれば一度伝えれば十分
    • 画面が分かりやすく、ミスや失敗がおこらない用に設計されているべき
  • 手順よりも「テンプレート」を用意したほうが効率が良い
    • 「メールを書く」作業よりも、そのテンプレートを用意した方が楽で早い
  • 自動化する
    • 仕組みで自動化したり、ヒアリングしなくて済むようにシステムを用意したほうが早い

手順書は画面が変われば壊れてしまいますし、手順通りでない場合の対応ができなくなりやすいです。 私は用意するコストの割に効果が薄いと考えています。

大事なのは上記の「背景」を共有しておくことと、テンプレートやフローを定義しておくことです。 それがあれば「業務」としては十分に明確です。

業務設計と聞いて手順書を用意するのは絶対にやめましょう。むしろ、一番費用対効果が悪いのが手順書です。

おわりに

「見えない仕事」があるから忙しい、「見えない仕事」だから人に依頼できないと話しました。 それには業務設計が必要だと話しました。業務設計には「明確化と細分化」、「背景」、「役割、「フロー」、「テンプレートと自動化」とおまけで「手順書」が大切と話しました。

今回の話は私が PyQ で製品開発をするなかや、会社での仕事を見直すときに使った考え方です。小さい組織にこそ大切な考え方だと思っています。 繰り返しになりますが、これはあくまでも私の考えであり、私なりの定義です。

謝辞

今回の内容は以下の「はじめの一歩を踏み出そう」という本から強く影響を受けています。 学んだ中で実践して、私なりに定義したのが今回お話したことです。

はじめの一歩を踏み出そう―成功する人たちの起業術

はじめの一歩を踏み出そう―成功する人たちの起業術

レッツトライ

明日からの仕事で、ぜひ参考にしてくれると嬉しいです

  • どういう「見えない業務」があるかを考えてみよう
  • 人に依頼している、一緒にやっているが明確でない業務はどれくらいあるだろう
  • 依頼したほうが楽になるなということはどれくらいあるだろう

できれば、今回の内容で業務設計をしてみて、フィードバックいただければと思います。 私もまだまだ勉強中で改良中の身です。ぜひ新しく事業を始める人たちの助けになり、私も勉強できればと思っています。

ウィーンモダン展に行ってきたWebアプリ開発者の感想

今日は、総合的な芸術、そして人の集まりというものの大切さを感じました。 ウィーンモダン展というものに先ほど行ってきましたのでその感想です。

artexhibition.jp

展示会として、行くべき?

個人的な感想の前に答えておきます。

今この記事を読んでくれているあなたは、千代田線乃木坂駅に行けて、1600円と1時間30分という時間を使えますか? Yesで、かつ興味があれば難しく考えずに行ったほうが良いと思います。 平日の4時に仕事を少し早く切り上げて行きましたが空いていました(スケジュールなどはサイトを見てください)。

この展示会について平たく言うと:

  • 美術品だけでなく1800年、1900年のウィーンの文化とか美術史にもついて知れてとても興味深い
  • 「そんなことよりクリムトの油絵がたくさん見たい」という人にはあまりオススメしない

美術品を眺めるというよりも、ブラタモリを見る感覚でも楽しめます。 僕は美術史の背景を教えてもらいながら美術品を見るのが好きなので良かったです。

まぁ、1パイント1600円するクラフトビール飲むなら、1杯だけ我慢して国立新美術館にいくのが良いんじゃないでしょうか。

個人的に良かったこと

エゴンシーレ

そもそも、私の個人的にはエゴンシーレの作品が見たかったのでこの展示会に行きました。 昔からシーレの作風や表現、人生などがとても好きなので地下鉄の広告でこの展示会を知ったときはウヒョウ!となりました。

ja.wikipedia.org

展示会でもエゴンシーレの自画像が見れたことはとても良かったです。ただ印象としては「ひまわり」のほうが予想を超えてすごかったです。 シーレのエンピツ画や水彩の人物画も多数あり良かったです。が、「大量」というわけでは無いのはもう少し寂しい気持ちになりました。 まぁでも実際に生で見れたのは本当に良かったので、エゴンシーレ美術館やプラハ国立美術館に行けということでしょうね。

www.musey.net

分離派ポスター

予想外、というか期待していない点でとても感銘を受けたのは分離派のポスターでした。

とくに「作品だけでなくポスターでも芸術性を発揮しよう」という総合芸術が素晴らしいと思いました。 私も PyQ のようなWebサービスを作っているので、その考えにはとても共感します。 例えばマーケティング用のクリエイティブや文章も、Webアプリケーションという作品の一部と考えられます。 分離派のポスターもアテナを描いたり、タイポグラフィにこだっていたりと大変面白いです。

クリムト

今回の展示会の目玉はやはりクリムトでした。 人生で死ぬまでに見れて良かったなという気持ちです。

ですがこれも予想外で、クリムトのアテナの絵や分離派のポスターなどが印象的でした。 アテナの絵の「やっていくぞ!」という気概は本当に良かったです。 こういうやっていく気持ちを素直にぶつけていくのは大切だなと思いました。

また分離派のポスター用の下書きなども見れて良かったです。 タイポグラフィのためにガイドの線を引いていたり、修正液で文字を直したりしているのが見えました。 芸術の後ろには数多くの習作や練習、計算があるものなんでしょうね。

印象派ポスターの1つ目は検閲を受けて一部が隠されていて、当時の保守的な雰囲気を感じました。 そこも、「歴史から描く」というこの展示会として良かった点ですね。

人の集まりが何かを生むのか

印象派にしろサロンにしろ、芸術のジャンルを超えて交流することで新しいものが生まれたという背景も展示会で描写されていました。 個人的にはこの点が感動して、「まるで現代のIT勉強会だな」という風に感じました。 アテナイのアゴラもそうですが、やはり人が集まって交流する場所には新しいものや素晴らしいものが生まれるものなのかもしれません。

DjangoCongress JPやコミュニティ活動をしていると大変なときや「意味あるの?」と不安になることもあります。 ですが歴史に学ぶと、そういったコミュニティ活動や人との関わり、対話、議論というのはとても意義のあることなんでしょうね。

まとめ

ウィーンモダン展はとても良かったです。 ただの美術展というよりも、歴史資料展や文化の変化を伝える展覧会としてとても良かったです (どうでも良いですが「シューベルト」と聞いてイメージするあの肖像画の本物を見れたのは何気に良かったです)。 個人的にはエゴンシーレの作品に触れられて嬉しかったです(他に見れる良い場所を知ってるという人はぜひ教えてください)。

またそこからWebアプリケーション開発やコミュニティ活動、組織運営というものについて刺激を貰えました。

ぜひ時間があればウィーンモダン展に行ってみてはいかがでしょうか。 1時間30分と1600円に見合うものは得られると思います。

Slackで「お節介しちゃうチャンネル」が増えすぎて疲れてませんか?ROM専力を鍛えよう

仕事用のSlackで時間と集中が奪われすぎていないでしょうか。 Slackは相当優秀なコミュニケーションツールですが、あまり反射的に使っているとSNS疲れのような状態になってしまいます。僕は「お節介しちゃうチャンネル」が増えすぎると疲れて良くないと最近気をつけるようにしています。

こういうことを言うと「雑談をするな」とか「助け合わないのほうが良い」というような極端な話なのかと誤解されるかもしれませんが、そうではありません。 Slackでどうでも良いことを話したり、人に相談したり助けたりするのは大切なことだと思っています。ですが、無作為に自分のリソースを使って良いものか?という意識付けの話です。

(この記事は自戒です)

何が危険なのか

「ちょっと大事そうな話」 が一番危険だと思います。 なぜなら意識、集中、感情、決定など脳のリソースを使ってしまうからです。 力をかける場所はそこでしょうか?

「本当にくだらない話」は無視したり適当にダベれば済みますが、この「お節介しちゃうチャンネル」は要注意だと思います。 「今日はどの曲を聴こうかなー」みたいな話は脳は大して使わないですよね。でも「何だかお客さんとのやりとりが不穏だ」というような話には脳がビビッと強く反応してしまうのではないだろうか。

人間年を取って経験ができると色々言いたくなるものです。でもそれは本当に言う必要があるんでしょうか?

リソースの分散を避けたい

そのお節介はとても大切ですし、すごい能力なのはもちろん分かっています。では問題とは何なのでしょうか。それは リソースが分散されてしまうことで、できることが小さくなってしまうこと です。 人間の脳みそや感情、「決定する意志力」は有限です。そのリソースをどこに使うかを制御しないと、人生や仕事の成果が小さくなってしまう問題があります。

先の例だと「お客様とのやり取りが不穏だなぁ」と気づいてアラートを上げるのはチームにとって有用です。ですが、すでに誰かが問題に気づいて誰かと相談しあってるときは一瞬立ち止まりましょう。大したアドバイスでも無いのならスルーしといたほうがお互いにとってプラスです。

とくに、勤続が長くなったり、スキルがついて頼られるようになったり、重要なポジションになったりすると参加しているチャンネル数は増えるものではないでしょうか。そして自分が役に立てる瞬間も自ずと増えてくると思います。ですが「 反射的に人の役に立っていてはいけない 」と最近は考えています。役に立てることは嬉しいことですが、少し考えてみましょう。自らの意思でどこに力を使うかを制御しないといけません。より多くの人の役に立てる場所が他にあるはずです(例えばコードを書いてお客様のために良いものを作るとか!)

お節介チャンネルには何があるでしょう?例えば...

  • 直接は関係していないけど一応見ている別のプロジェクトのチャンネル
  • あまり自分がコアな話題ではないけど入っている質問チャンネル

逆に、今メインでやっている仕事のチャンネルや、自分が得意な分野の質問チャンネル、従業員連絡用のチャンネルなどは重要と考えたいものです。

ROM専力が必要

大切なのはROM専力を鍛えることだと思います。

親切な気持ちがあるときほど色んなチャンネルを見て「それなりに役立つ」ことをしてしまいがちです。繰り返しになりますが、それなりに助けになってしまうのが罠なところです。良いことをしているけど、本人の集中とエネルギーが分散しているのが問題です。

だからROM専力を鍛えるのが大切だと考えています。「優先度の低いお節介」を見極めて、スルーしないといけません。「自分でなくてもいいかな」ということはスルーして、「誰も反応してないが、これは拾っとかないとヤバイぞ」、「これは自分が答えたほうが早いな」という部分だけお節介を焼きます。

自分がヒーローになろうとするのでなく、全体での最適化を考えると言っても良いかもしれません。

お節介焼かなくても意外と大丈夫

「お節介焼かなくて大丈夫だろうか?」と思うかもしれません。でも意外と大丈夫です。 ココ最近あまりSlackのチャンネルで反応しないように心がけましたが、意外と自分の存在なんてそんなものです。

  • 1つ、すでに何かやり取りがあるところに反応する必要はほとんどない
    • リアクションでイイねとか付けとけば良い
  • 2つ、お節介を焼かなくても、より何とかしようとすべき人が何とかしようとしてくれる
  • 3つ、何とかならないなら困っている人が(より広いところで)助けを呼んでくれる
    • ここで参加したほうが良さそうなら参加する
  • 4つ、それでもうまくいかないなら社内のアサインやコミュニケーションのあり方が良くない

私も「意外と自己満足でお節介焼いていたかな」と振り返れば思うときがあるので、そこまで一生懸命に反応しなくても大丈夫だなと思っています。

まとめ

お節介を焼かない分、今集中すべき仕事に全力を傾けましょう。 お節介を焼かない分、他の人が頑張るチャンスができるでしょう。 本当に見ておきたい案件のチャンネルや、質問チャンネルなら全力で助け合いましょう。でも優先度の低いチャンネルや優先度の低いお節介もあると思うので、場所を選んでROM専になっていきましょう。

明日からは「このお節介、いるかな?」、「今集中すべきことって何だっけ?」と気にしてみませんか? やるべき仕事がシッカリして、良い気分で布団に入りたいものです。

(この記事は自戒です)

もうPythonの細かい書き方で議論しない。blackで自動フォーマットしよう

  • 「ここで改行するほうがキレイで良いと思います」
  • 『いや、私はこちらのほうがキレイ良いと思います』

コードレビューでこういう議論をしたことはありませんか? 大切なことだとは思いますが、生産性にはあまり直結しません。議論を避けるために書き方を決めるほうが良いでしょう (個々の問題について逐次議論するのがエネルギーを無駄にしてしまいます。一度決めて、再利用するようにしたいものです)。

今日はそのために使える black というツールを紹介します (「私はflake8を使ってるから結構です」と思われるかもしれませんが、少し違う話なので読んでみてください)。

blackを使おう

Pythonのコードを自動でフォーマットしてくれる black を紹介します。

github.com

blackはPythonのコードフォーマッターで、自動的にPythonプログラムの書き方を修正してくれます。 PEP8 というPythonのコードスタイルにも準拠していますので安心です。

Python向けの自動フォーマッターはいくつかありますが、他のフォーマッターとの違いは何でしょうか?一言で言うと、blackはより制限が強いということです。

blackの特徴

Pythonの自動フォーマッターといえば autopep8yapf などありますが、blackはより制限が強く、自由に設定ができないのが特徴です。

PEP8では触れられていない、改行の仕方や、シングルクォートとダブルクォートの統一、末尾カンマの統一、余計な丸括弧の削除、数値リテラルの書き方統一などをしてくれます。 私の捉え方としては、blackは「自動フォーマッター」というよりも「制限のきついPEP8」です

設定できることはせいぜいファイルの幅(文字数)や除外するディレクトリーの設定くらいでしょうか。 開発プロジェクトごとの違いや好みを反映することはほぼできません 。 「うちのプロジェクトはルールで、こう改行するように決めている」というのであれば、改宗するか、諦めるしかありません。 改行位置とかも自動で揃えられるので「ここの論理行はここで改行するのが好き」とかそういうのは無理です。

  • PEP8に自動で従ってほしい
  • PEP8で触れられてない以上のルールを設定したい
  • どこで改行するか議論したくない
    • \ で改行するか
    • () で改行するか
    • () のどこで改行するのか
  • シングルクォートを使うのか、ダブルクォートを使うのかで議論したくない
  • 「プロジェクトごとに色々設定」できないほうが楽で良い

私個人としてはこの「設定させない」というのは良いと思っています。

ただ「シングルクォートをダブルクォートに統一する」などのblackのルールは正直好みに合いません(私には『シンボル』的な文字列ならシングルクォートを、『文字列』的な文字列ならダブルクォートを使うというマイルールがありまして、そういった美的センスも大切だとは思いますがmuble mumble...)。

誰がblackを使っているの?

ココ最近、私の仕事での開発環境を整備していて、black をプロジェクトに導入しました。 Used by を見ると他に使っている人のコメントが読めます。

また、Djangoソースコード開発ではblackを使うというプロポーザルがアクセプトされています。

github.com

ただ、blackはまだ公式には 「まだベータだよ」 と言っていますので、性急に捉える必要はないでしょう。

https://github.com/python/black#note-this-is-a-beta-product

blackを使おう

blackは単なるコマンドなので、インストールして使うだけです。

pip install black
black <target>

blackを設定しよう

基本的にblackにはあまり設定できる項目がありませんが、文字の幅や無視するパスを指定できます。 Pythonのプロジェクト配下に pyproject.toml をおいて、以下のように書けます。 この例では「1行の文字数は99文字」という設定と、blackの対象にしないディレクトリーを設定しています。

[tool.black]
line-length = 99
exclude = '''
(
    migrations
    | .mypy_cache
    | .pytest_cache
    | .tox
    | venv
)
'''

書き方はこちらを参照してください。

github.com

blackをプロジェクトに導入しよう

既存のPythonのプロジェクトにblackを導入する場合、単に「コマンドとして使う」だけでは不十分です。 プロジェクト内で定期的に実行して、Pythonコードの品質を保つようにしましょう。

オススメの方法は、 tox.ini やCIで定期的に実行することです。 以下の例は tox.ini に書いて単体テストとして実行する方法です。

[testenv:black]
basepython = python3.7
deps = black
commands =
    black . --check

--check オプションを付けると「blackの書き方に則ってるかどうか」のチェックだけしてくれます。 他にも --diff コマンドで差分表示、 --version でバージョン表示もできるので同時に実行していても良いでしょう。

blackを自動で実行しよう

エディターで実行するようにすると良いです

ただspacemacsは対応中のようです。2019年6月3日現在だとdevelopブランチにはマージされているようです(yapfでなくフォーマッターとしてblackを指定できるようになるようです)。

私はgit の precommitの実行は設定していません。

flake8と共存する

Pythonのプロジェクトであれば flake8 を使っていることと思います。 blackはflake8と併用できますが、併用する場合は一部非互換の部分があるのでちゃんと設定しましょう。

[flake8]
max-line-length = 99
ignore = E203,W503,W504

max-line-length はblackと同じ幅を指定すればOKです。blackはデフォルトで88文字なので、black側で設定しないときはここで88を指定しましょう。 次の ignore は、flake8とblackで 互換がない点を無視するための設定です

isortと共存する

Pythonのモジュールインポート順を自動で修正してくれる isort ともblackは共存できます。 blackはインポート順は直さないですが、isortのデフォルトの書き方に文句を言うので設定します。 以下のように pyproject.tomltox.ini に設定すると良いです(例によって行の文字数は99文字に設定しています)。

[tool.isort]
include_trailing_comma = true
line_length = 99
multi_line_output = 3

これは pyproject.toml に書いた例です。 細かい話ですが、isortを pyproject.toml で設定したい場合は pip install isort[pyproject] でインストールしましょう。

まとめ

blackは

  • PEP8より制限のきついルール
  • 色々設定できない
  • 使いやすい

スペシャルサンクス

aodag さんに実際のプロジェクトでどう使ってるかを色々と教えてもらいました (上記の --check オプションについてや、エディターの設定など)。

blackについてはaodagさんのこのトークでも紹介されてます。他にもPythonのプロジェクトにおいて効率的に開発する方法が説明されてますので参考にしてください。

speakerdeck.com

DjangoCongress JP 2019を主催したよという話

DjangoCongress JP 2019というイベントを主催しました。

f:id:hirokiky:20190518151953j:plain

2018年もDjangoCongress JP 2018 を主催しましたが、今年も主催しました。 全員であわせて130人くらいが参加するイベントになりました。 「130人にもなるとやっぱ人多いなぁ」 と、集合写真を撮っているときに思いました。 スタッフのみんなお疲れ様でした。去年とメンバーはあまり変わらず、考え方や効率の良さも相変わらずでとてもやりやすかったですね。 参加者の方も積極的にツイートしたり、手伝ってくれたり、交流したり、暖かいコミュニティだなぁ、ありがたいなぁと思っていました。

映画やアニメやゲームもそうですが、大体のものというのは2がつまらなくなってしまいがちですが、今回のDjangoCongress JPは2回目も大盛り上がりでした。 そして何よりスタッフも参加者の方もみんなで楽しめたかなと思います。

djangocongress.jp

f:id:hirokiky:20190521204035p:plain

後日、当日の動画を公開しますのでお待ちください。

写真

当日の写真はこちらから

photos.app.goo.gl

パーティー

とくに今年は、去年用意できなかったオフィシャルのパーティーを用意できました。 スタッフのayakoさんが中心になって頑張ってくれました 。やっぱり発注となると金額も大きいですし、規模も読みにくいですし、タイミングも重要なのでかなりヒヤヒヤしますね。

でも当日うまくいってよかったです。

f:id:hirokiky:20190518185043j:plain

f:id:hirokiky:20190518181603j:plain

発表

今年は僕も発表しました。 英語の発表ですが、練習もしていたのでそれなりに詰まらずに話せたかなぁと思います。 今年はさらに動画撮影もありましたので、後日動画も公開されます(自分の発表を観てまた落ち込みそうですが)。

f:id:hirokiky:20190518160206j:plain

gitpitch.com

他の人の発表などについては参加者の方のレポートを読むのがオススメです。ぜひ他の人の記事も読んでね。 たくさん記事あるので後でまとめるかも。

kumappp.hatenablog.com

mizzsugar.hatenablog.com

まとめ

来年もぜひイベント開催したいのでぜひ楽しみにしていてください。 スタッフになりたい方も募集中ですので、次回のDjangoCongress JPのキックスタート会ができたらぜひ来てください(そして継続して手伝ってくれると嬉しいです)。 僕は来年はより身を引いて、周りの人にもっと任せたり、仕組みで解決していけるようにしたいなぁと思います。