人生100年!生涯エンジニア人生!

楽しいエンジニア人生!

デブサミ2021に参加

f:id:hideaki_kawahara:20210220133447p:plain

今年はオンラインで開催されました。
codezine.jp

色々とセッションを聞いていましたが、仕事を優先しているときは感想をツイートしていないので、ツイートをしているを中心にブログにまとめます。
特に2021年2月18日は、割り込みが多かった・・・。

18-D-4

エンジニアが経営者になるとみえる、開発の大事なポイント
後川 菜穂子さん

  • エンジニアは強力な手段です。
  • 「全員が同じ変数」で「同じ結果」を出す。
  • 非エンジニアの見積もりは、モジュール分解ができていない。
  • ドメイン駆動開発などのエッセンスを使ってプロトタイプを作る。

このような経営者から目線じゃなく、エンジニアから経営者になったときの目線というのは貴重で非常に参考になりました。

togetter.com

19-B-1

デベロッパーからはじめるレガシー組織の景色の変え方~旧ノーマルからニューノーマル
沢渡 あまねさん[浜松ワークスタイルLABO]/新井 剛さん[レッドジャーニー]/【モデレーター】近藤 佑子さん[翔泳社])

あ!ゆうこりーん!って言うの忘れた・・・orz

ツイートでも感想を言っていますが、抜粋するとこんな感じかな。

togetter.com

  • 統制管理型を否定していない。
  • メリットは考えなくていい答えが出る、管理するだけ、しかし、変化に弱い。
  • 慣れた不便に名前を付けて共感者を増やす。
  • 新しいツールをエンジニアドリブンで始動する。
  • 新しいツールの砂場(サンドボックス)で遊ばせて、ファンにさせる。
  • 3つのファンを作る。
    • テクノロジーのファン
    • プロダクトのファン
    • カルチャーのファン
  • ファンを作るのはマーケット手法そのもの
  • デベロッパーズ・ルネッサンス

19-B-6

ニューノーマル時代のコミュニティは誰もがチャンスに満ち溢れている。
中道 一志さん[ニッセイコム]

見せる登壇でしたね。

speakerdeck.com

あまり感想ツイートはしてませんが、「やりたいからやる」「踏み出す勇気」など共感できることが多かったです。

19-A-9

コロナ禍でエンジニアイベントはどう変化していくのか? オンライン時代の技術と人との出会い方
【モデレーター】仲亀 拓馬さん[さくらインターネット]/赤川 朗さん[Forkwell]/草間 一人さん[CloudNative Days]/森川 晃さん[技術書同人誌博覧会])

Miroを使用しての双方向なセッションでした。
参加者が付箋を貼り、それを登壇者が読み取りながらのセッションで、参加者が80名ぐらい居たらしく、付箋がすごい数になりました。

Miroを使ってのセッションはオンラインでの良さと新しい可能性を実感できました。
オフラインで開催になっても、この感じは取り入れたいですね。

他の感想はツイートしてます。
togetter.com

↓Miroの付箋数が物凄い量でした。

f:id:hideaki_kawahara:20210220114608p:plain:w300

途中、お絵描きに話題が行ってしまったのも楽しかったです。

f:id:hideaki_kawahara:20210220114729p:plain:w300

余談ですが、この付箋を描いたのは私です。

f:id:hideaki_kawahara:20210220123855p:plain:w400

休憩時間

Eventinといサービスで、インターフェイスは良かったで使いやすかったです。
私は、ほぼ「技術書同人誌博覧会」のところに居ました。
参加者として、技術書同人誌を書いた人という感じで雑談しました。
3人ぐらいの方が、技術書同人誌を書く意思を示してくれたのは嬉しかったです。

余談ですが、スポンサーのところに人が、あんまり来ないのは、参加者が少ないと入りにくく感じるので、2~3人居ると良いのではないかな?と思いました。

懇親会

こちらもEventinを使用、途中家事などの割り込みが入ったりしていましたが、非常に楽しい懇親会でした。
誕生月でルーム分けをしていたのですが、2月が1人も居なかったので、不吉な雑談ルーム13を選びました。
そしたら、ファシリテーションをしてくれた方が良かったので安心して会話できました。
ありがとうございました。

会社から賃金振込で銀行口座を指定されることは違法について説明

バズった

めもりーさんのツイートがバズる。

そこにぶら下げた私のツイートも小さくバズる。

知らなかったといツイートが多い中、色々な疑問も出ていたので、会社から賃金振込で銀行口座を指定されることは違法について説明します。
※ブログでは給与のことを賃金と記載します。

賃金支払いの根本ルール

労働基準法第24条を参照してください。
elaws.e-gov.go.jp

第二十四条 賃金は、通貨で、直接労働者に、その全額を支払わなければならない。ただし、法令若しくは労働協約に別段の定めがある場合又は厚生労働省令で定める賃金について確実な支払の方法で厚生労働省令で定めるものによる場合においては、通貨以外のもので支払い、また、法令に別段の定めがある場合又は当該事業場の労働者の過半数で組織する労働組合があるときはその労働組合、労働者の過半数で組織する労働組合がないときは労働者の過半数を代表する者との書面による協定がある場合においては、賃金の一部を控除して支払うことができる。

② 賃金は、毎月一回以上、一定の期日を定めて支払わなければならない。ただし、臨時に支払われる賃金、賞与その他これに準ずるもので厚生労働省令で定める賃金(第八十九条において「臨時の賃金等」という。)については、この限りでない。

いきなり難しいですね。
これが世間で言われる「賃金支払の五原則」です。

厚生労働省のFAQがわかりやすいので、こちらを参照しましょう。
www.mhlw.go.jp

賃金の支払いは以下のルールがあると覚えておくと良いでしょう。

  1. 通貨で
  2. 直接労働者に
  3. 全額を
  4. 毎月1回以上
  5. 一定の期日

今回の件では「通貨で」と「全額を」が影響するので説明します。

通貨でというのは、現物支給の禁止で、価値が異なる現物で、支払うのは駄目です。
そして、ここで言う通貨というのは「貨幣及び日本銀行法の規定により日本銀行が発行する銀行券」で、物理的な紙幣と貨幣、つまり現金です。

全額をというのは、本来の目的は賃金の支払いを滞納することで実質的なタダ働きさせないためです。
ただし、法令に別段の定めがある所得税源泉徴収地方税など一部控除することが認められています。

このことから労働基準法第24条では「賃金の支払いは全額現金を渡す」ことが規定されいます。

次のルール

賃金を現金で払うのは手間ですし、1968年12月10日に発生した三億円事件という未解決事件もあり安全な方法として銀行口座を使うことが行われております。

それに対する規定は労働基準法施行規則第7条の2になります。

elaws.e-gov.go.jp

第七条の二 使用者は、労働者の同意を得た場合には、賃金の支払について次の方法によることができる。

一 当該労働者が指定する銀行その他の金融機関に対する当該労働者の預金又は貯金への振込み

ここで重要なのは「当該労働者が指定」とありますので、会社が銀行口座を指定することは違法になります。

振込手数料天引き問題

使っている口座を会社に指定したら、振込手数料を天引きされた話もよく聞きます。

これは労働基準法第24条の項目で書いたとおり、「賃金の支払いは全額現金を渡す」ことが前提になりますので、賃金から振込手数料を天引きすることは「全額支払う」こと反するので違法になります。

このことが是正されたが、過去に天引きされた分が返金されないことも言うツイートも見かけますが、善意が少しでも残っている会社ならさかのぼって返金するでしょう。
一応、2年間さかのぼって返金請求は可能ですが手間がかかるかもしれません。

会社がお願いする問題

会社が銀行口座を指定じゃなくて、お願いすることは問題ないという意見があります。
確かに、お願いという程度なら違法とは言い切れません

だけど、会社がお願いすることは拒否できないと感じる人も居るし、会社の経費節減のためだと周りが言い出すことで「同調圧力」になる可能性があるので、問題ないという点には疑問を感じます。
特に同調圧力が生まれることは非常に危険なことで、これに歯止めがかからないことで、そこからパワーハラスメントなどを生むきっかけになり、その結果、多くの悲劇を生むことになります。

経験者ならわかりますが、同調圧力は本当に良くないことです。

そして、同調圧力は法を無視することを良しとする風潮が生まれてきます。
この関連ツイートや、引用ツイートを見てくださるとわかりますが(あえてリンクしませんが)、「会社の損は労働者にも降りかかる」とか「会社の不利益を推進するな」とか、そんなことを言う人も居ます。

そもそも「会社の損」とか「会社の不利益」とか、会社の利益って何だろうね?
会社が違法な行為をして利益をあげることが正しいのでしょうかね?

例えをあげるとすると、スポーツ競技でルールを無視して勝つことに意味があるのでしょうかね?

融資問題

この問題には、さらに闇があります。
真相は不明ですが、銀行口座を作ると融資を受けやすくなると言われることがあり、口座を作らせる行為もあります。

これこそ「同調圧力」になりますし、その行為を銀行の行員が黙認しているのなら、それは銀行のコンプライアンス違反となります。
また、その行為を黙認する行員を信用して良いのでしょうか?
結局は、行員の業績を上げることがメインなので融資をしてくれるとは限らないです

融資のためというのは絶対に従ってはいけません。

まとめ

労働基準法第24条において「賃金の支払いは全額現金を渡す」と規定してます。
労働基準法施行規則第7条の2において「労働者が指定する銀行」と規定してます。
上のことから、賃金の振込で、会社から銀行口座を指定されることと、振込手数料を天引きされることは違法となります。
会社から銀行口座をお願いされることは、ブログ主としては違法とは言い切れませんが、同調圧力を生むことになるので推奨しません。
こういう言葉のニュアンスで苦しむ人も居るので、ブログ主個人としては違法に倒したいぐらいです。

余談ですがブログ主は、ここに書いたこと全部経験しております。
蛇足になるかもしれませんが、融資問題について書きます。

遠い昔に、会社にお願いされて融資のため親族に口座を作らせるなどの協力を行いましたが、このときは、これが同調圧力とは気付きませんでしたが、今思い出すと、これが同調圧力なんだなーと思います。
そして、結果として会社は融資に失敗して、全社員に融資失敗したのを、罵倒とともに、お前らの責任だと言われたことあります。
この後は、社員と経営者の罵倒合戦が始まり、その結果、メンタルが弱い人はつらい思いをし、耐えきれない人は会社を去りました。
こんな地獄のような環境で働きたいですか?
同調圧力は不幸しか生まれません。
そして、善意で会社に協力しても、経営者は貴方を罵倒するんですよ。
会社は貴方を守りません。
それなら法律を守るほうがマシです。

GitHubは悪くない、ソースコード漏えい事件、ソースコードは正しく管理してる

概要

GitHubに会社の機密情報に該当するソースコードが漏えいする事件があり、多くの報道が出ているので、詳しくは、それらの報道を読んでください。

www.itmedia.co.jp

これらを読んで思うことは、ソースコード漏えい事件でGitHubは悪くないです。
そもそも、ソースコードの扱いは多くの会社で適切に正しく管理しております。
今回の事件の根幹は、当該者のモラル欠如と言っても良いです。

社内ドキュメントの扱い

ソースコードの扱いについて話す前に、社内ドキュメントについて思い出してほしいです。
そうです、社内ドキュメントは閲覧できる権限が設定されています。
どこの会社でも内容を精査して秘密定義を行ったのち秘密分類を行います。
下のような管理分類が定義されていることが多いと思います。
また、管理分類においてデフォルトは秘にすることで判断に困るのを回避できます。

管理分類 内容
極秘 社外に漏れたら会社経営に重大な損害を与えるもの、会社の合併情報や顧客の個人情報などが該当します。
秘(部内秘) 社外に漏れたら会社の信用情報に損害を与えるもの、プロジェクトの内容や議事録が該当します。
社外秘 社外に漏れたら会社の信用情報に損害を与える可能性が低いもの、ハウスルールや座席表などが該当します。
公開情報 一般に公開している情報、会社の住所やWebサイトに公開している情報が該当します。

適用範囲も分類します。
「役員」「正社員」「派遣社員」「委託先従業員」などが該当します。

これらを組み合わせて、社内ドキュメントは管理されています。
※細かな表現の差異などはあります。

ソースコード管理にもレベルを設定している

ソースコード管理にも管理分類を設定しています。
ざっくりですが、社内ドキュメントと同じレベル感で分類すると下のようになります。
また、社内ドキュメントと同様にデフォルトは秘にすることで判断に困るのを回避できます。

管理分類 内容
極秘 認証など、このソースコードが漏れたら直ちにシステムに損害を与える情報があるソースコードが該当します。
秘(部内秘) 各プロジェクトごとのソースコード、直ちにシステムに損害を与えることは無いが、このソースコードを調べることで将来的にシステムに損害を与える可能性があるソースコードが該当します。
社外秘 社内で共有使用するソースコード、社内で横断的に使用するユーティリティに対応するソースコード、認証をカプセル化したソースコードなどが該当し、これらが漏れることは望ましくないです。
公開情報 利用しているOSSなど

GitHubも、Enterpriseプランなら、Repository単位ですが細かな設定が可能になりますし、ソースコードが漏えいした企業もGitHub管理じゃなくても、同様な管理レベルの設定をするだろうと思います。

FYI:Enterprise アカウントで Organization のポリシーを設定する
docs.github.com

厳重に管理されている

このように社内ドキュメントとともに、ソースコードも厳重に管理されています。

情報にアクセスするときは認証を行ったのちにアクセスが可能となります。
その上で、アクセスするときにはアクセスを開始した日時や、サーバーにログインするときなどはVPNを経由したり、キーボードで入力した内容なども記録しています。

会社によっては極秘に該当するものにアクセスするときは、物理的な認証(指紋認証や顔認証など)を行いセキュリティー完備な区画に入室して、そこで作業することもあります。
また、その区画に入室するときは、個人のスマホなどを預けたり、その区画では外部のアクセスが完全に制限されていることもあります。

これぐらい社内ドキュメントやソースコードは厳重に管理されています。

また、社内から外部にアクセスするとき、禁止された場所へのアクセスを禁じているところは多く、外部へ容易に持ち出せない会社も多いです。
この辺りは専門的なツールを使用しているので、持ち出そうとしても持ち出せないと思います。(個人的には試したくない)

ただ、管理コストの面や開発効率などを考えると、極秘以外は認証だけで許可する方が多いです。
そのため極秘以外のソースコードは、モラルがベースとなって管理運用することが多くなっています。

つまり、極秘に該当するものは性悪説で管理する。
それ以外は性善説で管理する。

モラル教育

性悪説での管理は先程述べた通り、予算をかけていくことで脳みそに記憶されること以外の防御ができるようになっていきます。

しかし、性善説での管理はモラルに依存します

社内ドキュメントがきちんと区分されている会社なら、社内教育で機密情報の扱いを教育されています。
これらの教育は社員区分隔たり無く教育することが望ましく、多くの会社でも行っています。
そのため、派遣構造がひどいと言っても、モラル教育や機密情報の扱いについての教育は行われていると思われるし、そもそもソースコードは外に持ち出さないのは常識レベルなので、今回の事件は発生したのは当該者のモラル欠如と言っても良いです。

ただ、残念なことに、モラル欠如による情報漏えいは後をたたないです。
こうなってくると、性善説で扱える業務が狭くなる恐れもありますが、機密情報を適切な管理をしているところは、この管理を継続していくことが大事であり、そして、モラルの教育や機密情報の扱いについての教育を、社員区分の隔たり無く行うことで減らすことは可能だと思います。

性善説の運用は教育でしか向上することはできないのです。
そして、個人のモラルを向上することが我々エンジニアにできる最善策だと私は思います。

その招待大丈夫ですか?Clubhouseに関する4つの懸念点を確認する(招待枠を使い切っても招待が勝手に発動する仕組みも解説)

話題のSNS Clubhouse

エンジニア界隈で流行り始めた話題のSNS、小嶋 陽菜さんや、サンプラザ中野くんなどもやっている話題のSNS、それがClubhouseです。

今はiPhoneアプリのみで、しかも、参加しているユーザーから招待されないと参加できないと言うプレミアムな体験でメルカリでも招待枠が売買される状況です。

www.itmedia.co.jp

Clubhouseには、これから述べる4つの懸念点があります。

  1. 招待方法の懸念
  2. 勝手に招待を送る疑惑
  3. 連絡先(電話帳)から電話番号をClubhouseにアップロード
  4. リアル世界に貴方の匿名がバレる

順に説明していきます。

※アプリ名は「連絡先」(contacts)で、連絡帳や電話帳ではないのです。

招待方法の懸念

ツイッターなどのSNSでは招待をほしがるツイートを多数見かけております。
気軽に招待することには懸念があります。
懸念を説明する前に招待方法を下に記載します。

  1. 招待には携帯電話の電話番号が必要です。
  2. 招待する電話番号を「連絡先」(電話帳)に追加する。
  3. Clubhouseから連絡先(電話帳)を呼んでSMSを送信する。
  4. 招待される側は受信したSMSから電話番号認証を行う。
  5. 招待される側はClubhouseが使用できるようになる。

このことから、見ず知らずの人を招待すると、招待を行った側の「電話番号」が知られてしまいます。
面倒なことになりたくないなら招待は知り合いだけにしましょう。

ツイッターなどでは、「女性アイコン」のみにリプライする人を多数見かけましたので、そういう人を見かけても放置推奨です。
見てて滑稽だったのは、招待依頼を求める対象が、男性の方なのですが「女性アイコン」にしている人にリプライをしているのを見かけております!

また「3000円ほどお支払い頂けたら優先的に招待します。」とか「フォロー&リツイートしていただいた方の中から抽選でClubhouse招待します!残り1000枠あります!」など、電話番号を搾取する目的のツイートも観測しております。
このようなツイートに絶対に関わってはいけません、カモにされるだけです。

勝手に招待を送る疑惑

それからClubhouseは勝手に招待SMSを送るんじゃないか?と疑惑があります。
その疑惑をひもといて行きましょう。

まず、Clubhouseはアカウント名を確保するという目的で、招待されていなくても、アプリを起動してアカウントまでは準備できます。
アカウントを準備するときは電話番号による認証が必要です。

ここで勘がはたらくの人なら気付きましたね。

Clubhouseは連絡先(電話帳)をアクセスするので、Clubhouseを使用している人の連絡先(電話帳)に、Clubhouseのアカウント名の確保をした人が居ると、その方を招待するアクションが発動します。
Clubhouseは数多くの通知があり、すべて英語なので多くの人は、この招待アクションを読まずにLet them inをタップしている可能性が高いです。

このアクションは招待枠を使い切っても発動します。

なお、私は、この通知を見ているのですが、スクショ取るの失敗しました・・・。

追記、知り合いの「なべくらさん」がスクショを取ってくれました。
このような通知で青いボタンをタップすると招待アクションが発動するようです。

f:id:hideaki_kawahara:20210130151525j:plain:w320

通知内容の英文は、こんな感じです。

○○ is on the waitlist to join Clubhouse. You will get credit on their profile for adding them, without using up an invite. Let them in?

適当に翻訳すると、こんな感じです。

○○はクラブハウスに入会するための順番待ちリストに載っています。 あなたは招待を使い切ることなく、それらを追加するために彼らのプロフィールにクレジットを得るでしょう。 それらを入れますか?

英文を読むと意味がわかりますね。

上記補足

勝手に招待を送るのは連絡先(電話帳)を連携すると発動しますが、常に発動するわけではないです。
連絡先(電話帳)は1日に1回アクセスしてきますが、2021年1月下旬はユーザーが激増しているため、アクセスに失敗しているのを確認しています。
2021年2月に入ってから安定し始めているっぽいです。

対処方法

勝手に招待を送る疑惑には対処方法があります。
連絡先(電話帳)はメンテンスしてない人が多いので、もう連絡を取っていない人を招待するのは嫌な人が多いと思います、連絡先(電話帳)から削除する方法もありますが、Clubhouseから連絡先(電話帳)のアクセスと停止すれば良いのです。

方法1 設定からClubhouseを選択して連絡先(電話帳)のアクセスを停止します。
f:id:hideaki_kawahara:20210130002052j:plain:w320

方法2 設定からプライバシーの連絡先(電話帳)を選択してClubhouseを停止します。
f:id:hideaki_kawahara:20210130002059j:plain:w320

設定が完了するとClubhouseから招待を選ぶとAuthorize contactsのポップアップが出ます。
Not nowをタップしておいてください。
f:id:hideaki_kawahara:20210130002106j:plain:w320

これで勝手に招待を送ることは無くなります。

逆に連絡先(電話帳)を、この逆のことを行うことで連携するので、招待ができない方は、この設定を見直してください。

連絡先(電話帳)から電話番号をClubhouseにアップロード

Clubhouseで招待を行うとき、数字を気にした方は居ますか?
↓この数字です。

f:id:hideaki_kawahara:20210130022219j:plain:w320

このリストの1番上の電話番号は某IT企業の代表番号です。

ここで勘がはたらくの人なら気付きましたね。(2回目)

答えは対象電話番号を連絡先(電話帳)に入れている人で、Clubhouseを利用している数です。
このことからClubhouseは電話番号をサーバーに送ります
対象の電話番号を送信した人が何人居るのかが、Clubhouse側にはわかるようになっています。
Clubhouseの招待は連絡先(電話帳)連携が必須なので、こういうのが嫌いな方はClubhouseは使うことを控えてください。

Clubhouseは複数アカウントでの利用を抑止するために、電話番号で招待という手法を取りました。
そして、そこから個人が所有する電話番号をアップロードすることにより、その個人の特性を判定しているかと思います。
ここから、マネタイズする方法がありますが、今回はここまでとしたいです。(いつか書きます)

リアル世界に貴方の匿名がバレる

Clubhouseで本名を使っていて、ツイッターのリンクなどを貼っていない人は関係ないです。
Clubhouseでツイッター名を使っていて、ツイッターのリンクを貼っている人はご注意ください。
理由説明します。

連絡先(電話帳)をClubhouseにアップロードするので、色々な通知が英文で流れてきます。
例えば、こんな通知です。

f:id:hideaki_kawahara:20210131153213j:plain:w320

通知内容の英文は、こんな感じです。

○○ just signend up for Clubhouse. Follow them.

雑に和訳するとこんな感じです。

○○はクラブハウスにサインアップしたばかりです。 それらに従う。

Clubhouseは連絡先(電話帳)をアップロードするので、自分が招待をしてない人でも、別の人が招待してClubhouseに入ることがあります。
そうすると、この通知が来るのですが、招待アクションは発動しませんが、気を付けないといけません。

青いボタンをタップするとフォローしてしまいますので、旧知の仲でも色々あって距離を置いて居る人とは、Clubhouseでつながりたいは思わないので、闇雲に青いボタンをタップのは気を付けましょう!

この通知が来たら、この人にはClubhouseを使用していることがバレている可能性が高いです
※電話番号を交換していても相手が電話番号を削除してたらバレていません。

フォローしていなくても、Clubhouseでのユーザー名ぐらいは確認するでしょうから、ここからツイッター名やツイッターアカウントがバレます
勝手にフォローした!と騒ぐ人が居ますが、フォローしたのは、これが原因です。

これについて対策方法は3つあります。

  1. Clubhouseでツイッター名を使用しない。
  2. Clubhouseでツイッターなどのリンクを貼らない。
  3. 別の電話番号を用意して、それからClubhouseアカウント名を作る。

まとめ

話題のSNS Clubhouseを楽しむために気を付けなければいけないことを書きました。
見ず知らずの人を招待することなどは、情報リテラシーとしては基本的なことですが、この熱狂で見落としがちなので気を付けていただきたいですね。

2021年2月1日現在は特に話題にはなっていませんが、連絡先(電話帳)のアップロードなどはBYOD(私的デバイスの持ち込み)では禁止になる可能性もあることを認識してClubhouseを楽しんでいきましょう。

f:id:hideaki_kawahara:20210201124110j:plain:w0

PythonからDockerコンテナを起動する。

docker-compose.ymlでも良いのですが・・・

Scrapyの技術同人誌を書いたとき、Dockerの起動はdocker-compose.ymlを書いて起動するようにしました。
kawahara-ci.hatenablog.com

これをPythonのDockerモジュールを使って起動する方法もあるよねと思いました。
pip install dockerをやってから早速やってみました。

コンテナの状態

プログラムからDockerのコンテナを起動するとき、コンテナは3つの状態が考えられます。

  1. 該当のコンテナが起動済み。
  2. 該当のコンテナがあるが起動してない。
  3. 該当コンテナが存在しない。

この3つの状態を理解して作っていきましょう。

コンテナが起動済み

docker.from_env()でDockerのオブジェクトを取得しておき、そのオブジェクトから、コンテナリスト(containers.list())を調べて、コンテナ名と一致していたら、コンテナが起動しているので、何もしないで終わります。

コンテナがあるが起動してない

コンテナリスト(containers.list())のデフォルトは起動しているコンテナを取得しますが、パラメータにall=Trueを追加するとすべての状態のコンテナリストを取得します。

最初に起動しているかを確認しているので、このときに取得できたコンテナリストとコンテナ名が一致したら、起動していないコンテナがあることになります。

そのときはcontainer.restart()でコンテナを再起動します。

コンテナが存在しない

最後は、コンテナが存在しない状態なのでcontainers.runでDockerイメージをpullしてコンテナを起動してしまいます。
なお、Dockerイメージが既にpull済みのときは、コンテナの起動だけをします。

containers.run('scrapinghub/splash', name='splash', ports={'8050/tcp': 8050}, detach=True)このような感じでコンテナを起動します。

ここで重要なのはnameパラメータです。
コンテナを起動するとき名前を設定しないと、Dockerは良きに計らえということで適当な名前を付けてしまいます。
そうなると、コンテナの存在を確認しにくいので、コンテナの名前を付けて起動するようにします。

完成形

以上のことを踏まえて作ると、以下のようになります。
3つの状態を判別してコンテナが起動できるようになりました。

import sys
import docker

container_name = 'splash'
client = docker.from_env()

container_exists = False
for container in client.containers.list():
    if container_name == container.name:
        container_exists = True
        print('Container is up.')

if container_exists == False:
    for container in client.containers.list(all=True):
        if container_name == container.name:
            container.restart()
            print('Container restartup.')
            sys.exit()

    container = client.containers.run('scrapinghub/splash', name=container_name, ports={'8050/tcp': 8050}, detach=True)
    print('Container startup.')