600000007

プログラムと折り紙のブログです。

裁判員やってみた

f:id:sakamoto_desu:20180214215449p:plain

裁判員やってみました。

ある日突然裁判員の候補者リストに入りましたと通知が来て、それも忘れた頃に裁判やるよと連絡があり、運良く選任されて7日間裁判所に通いつめました。なかなかに刺激的かつ勉強になる体験だったので、もし機会があれば是非やってみてください。

今回は横領・殺人事件を審理する裁判でした。

お勧めする理由

レアな体験

実際に裁判員に選任される確率は1年あたり0.01%だそうです。ソシャゲにはまってる同僚もびっくりする確率でした。そして法廷では裁判長の横に座ります。傍聴席から皆が見ています。被告人とも真正面から向かい合います。そこからはドラマで見たシーンのオンパレードでした。本物の「異議あり!」、涙ながらに語る証人、うつむく被告人。さらに極め付けは記者会見への出席です。それ自体は小規模で記者3名からおきまりの質問をされるだけでしたが、取材されること自体が人生初でした。

全力サポート

裁判のやり方なんて分からないし、素人でも大丈夫なの?と心配なさるかもしれません。しかし全くの無用です。書記官や裁判官、裁判長が一体となってサポートしてくれます。裁判の基本的な仕組み、裁判員の役割、刑の決め方、etc... なんでも質問に答えてくれました。また裁判資料も、裁判員のためにわかりやすい資料が準備されます。検察官や弁護士が使い慣れてないパワポを駆使して作ってくれたことが資料から伝わってきて胸が熱くなりました。殺人事件となると証拠として遺体の写真も出てくるのですが、ショックを受けないようにイラストにしてくれます。それでも裁判後にトラウマになってしまった場合は、なんとカウンセリングを無料で受けられます!手厚いですねー。

裁判官、裁判長の皆さんには本当にお世話になりました。色々な省庁でのランチに連れて行ってもらったり、普段の働き方とか裁判ドラマがリアルかどうかといった話をしてくれたり。農林水産省の食堂がクジラも食べれて人気だそうです。

裁判の仕組みが分かる

やはり裁判や刑の種類などは詳しくなりました。なんとなく検察と弁護士が争うんだよねというのは知っていましたが、法廷で提出された証拠しか論拠にできない事は知りませんでした。刑の種類や区別も詳しくなりました。保険金殺人とかは無期懲役以上になるんですね。

裁判の重さが分かる

裁判員としては最終的に量刑を決める務めがあります。これはやっぱりしんどかったです。量刑が重いと1年ぐらいは誤差な気がしますが、1年はやはり1年です。人の人生に影響を与えるには十分な時間です。被害者や被告の人生、関係者の人生が垣間見え、それらに自分の決断が影響を与えるという事を考えると、真剣に審理に取り組むしか道はありませんでした。そしてそういった裁判が日々行われ、日々人生を左右している。しばらくはニュースを見る目が変わりそうです。

意見が反映される

もともと裁判員制度の目的のひとつに、国民が刑事裁判に参加する事により国民の良識が反映されるようになること、というものがあります。今回参加してみてまさに反映されていることが実感できました。自分で証人や被告に質問することもできますし、裁判官、裁判長は必ず裁判員の意見を確認してくれました。実際この裁判員制度が始まってから、介護殺人の量刑は軽くなってきたそうです。

FAQ

以下は実際に質問された事を答えてみます。

こわくない?

確かにちょっと怖かったです。殺人事件だったので、人を殺した人と対面するわけですよね。逆恨みされるんじゃないか?って心配もしました。ただし矢面に立つのは裁判長なので、いちいち自分が恨まれる事もないかなと思いました。また質問したいけど怖いから自分でしたくなければ、代わりに裁判官がやってくれます。事件の内容を聞いてから辞退するタイミングもあります。

拘束期間は?

今回は選任手続きを入れて7日間でした。朝10時から法廷で、16時くらいまでには終了します。前倒しになることもあります。裁判によって長さはまちまちで、3日で終わる事もあれば3ヶ月かかったケースもあるそうです。

有給?

労働基準法で会社は従業員を裁判員に参加させる義務があります。休みの形式は特別休暇を設ける事が推奨されていますが、有給・無給どちらにするかは会社に任されています。今回は会社に相談したら特別休暇を新設してもらった人、有給休暇をとった人、無給休暇だった人と様々でした。

今日書かなかったら一生書かない気がしたので一気に書きました。また候補になったら多分やらないとは思いますが、ぜひ一度はやってみることをお勧めしたいです。

障害切り分け

いつものように後輩へ障害対応方法を指南していたところ、ふと我に返り「そもそも自分はどうやって切り分けているのだろう?」という疑問が湧いてきました。
経験的にこれを確認したほうが良い、そっちは関係ないなどということは分かっているんですが、どういったルーチンを自分が行っているのかは整理されていませんでした。

というわけで自分が普段なんとなくやっている切り分け方法を整理して言語化してみました。障害に遭遇したけど原因がわからず手詰まりになった、もっと効率的に切り分けたいといった場合の一助になれば幸いです。ここでは如何に切り分けていくかということだけに焦点を当てており、障害の検知や再発防止などには触れていません。

障害とは?

ここで言う障害とは、以下のような事象を指します。

  • サイトに繋がらない
  • エラーでプログラムが落ちる
  • PCの電源が入らない

構成情報を把握する

障害が発生している環境の構成を把握しましょう。特にバージョン情報は過去事例と照らし合わせる上で重要な情報となります。

  • システム構成
    • サーバ構成
    • ネットワーク構成
    • データベース構成
    • データフロー
  • H/W詳細
    • サーバのスペック、バージョン、設置場所
    • ネットワーク機器のバージョン
    • 部品のバージョン
  • S/W詳細
    • OSのバージョン
    • フレームワークのバージョン
    • ライブラリのバージョン
    • プロトコルのバージョン
    • データフォーマットのバージョン
    • ブラウザのバージョン

時系列で整理する

発生した現象を時系列で整理しましょう。複数の障害が発生している場合、最初の障害が大元の原因となっていることが多いです。単に障害の発生時刻だけではなく、発生している環境の設定変更・環境の変化も併記するのがお勧めです。

  • 障害発生日時
  • 障害発生期間
  • 設定変更日時
  • 構成変更日時
  • メインユーザが変わった日時
  • ユーザ数が増加した日時

エラー内容をちゃんと読む

エラーメッセージをいきなりググったりせずに、まずはきちんと何を言っているのか読み込みましょう。

現象を分解する

発生している現象をフェーズで分けて、どの範囲まで正常でどこから異常なのか調べましょう。さらっと1行で書いてますがこれは切り分けの上で最も重要な作業であり、きちんと正常動作を把握しているかどうか、より細かく分解できるかどうかが切り分け力=技術力の差に直結します。

再現を試みる

ある程度発生条件の見当がついたら、現象の再現を試みましょう。可能な限りデフォルト環境で、小さい構成で再現を試みるとより効率的です。

他の環境と比べる

もし同じ構成で正常に動いている他の環境があれば、設定などの差分を調べましょう。また以前のバージョンに切り戻すと復旧する場合は、その差分が原因である可能性が高いです。

  • 各種設定
  • 各種バージョン
    • 以前のバージョンとの差分
  • システム構成
  • データ処理量
  • 処理したデータの種類
  • 負荷
  • 温度

可能であれば正常な環境と同一になるように少しずつ設定を変更して、どの時点で改善するかを調べるのも手です。

規則性を見つける

障害の規則性を見つけると、切り分けの手がかりになります。

  • 時間に偏りはないか?
    • 朝7時に発生する
    • 営業日に発生する
    • 現象が続く時間の長さが一定
    • 再発するまでの間隔が一定
  • 手順に偏りはないか?
    • 特定のユーザのみ発生する
    • 特定の操作のみ発生する
    • 特定の回数繰り返すと発生する
    • 特定の接続元からのみ発生する
  • 環境に偏りはないか?
    • 特定のサーバだけで発生する
    • 特定のネットワークを経由したときだけ発生する
    • 特定のバージョンだけで発生する
    • 特定のブラウザでのみ発生する
  • アウトプットに偏りはないか?
    • 壊れたファイルのサイズが一定
    • ファイルの破損箇所が同じ
    • 壊れる部品が同じ

知らない情報があるか調査する

実は自分が知らないだけで他にもエラーが保存されていたり、デバッグ機能があったりするケースがあります。

  • OSがcoreを吐いている
  • サーバのシステムボードの管理領域にH/Wログが出ている
  • 直前の印刷内容をダンプすることができる
  • 操作ログが出力されている
  • 設定が他にもある
  • 設定を反映するための特殊な手順がある
  • 利用してるクラウドサービスが仕様変更のニュースを出している
  • バグレポートがある

そういった情報が無いか調査をして、新しいヒントを得られることも多いです。

申告された内容を精査する

伝聞された情報は不正確な事も多いので、すべてを鵜呑みにせずに自分自身で確認したものを中心に整理しましょう。ユーザー申告の場合、どこをみて障害と判断して報告してきたのかを知ることは重要です。PCの電源が入らない!という申告があってもディスプレイの電源が入っておらず暗いからそう判断しただけ、といったケースはよくあります。

思い込みを疑う

設定を直したのに改善しない!原因はこれで間違いないはずなのに!と思ったら違うサーバで操作していた、なんて経験はないでしょうか?落ち着いて自分がやった作業を見直してみましょう。

  • 違うサーバで作業している
  • 違う設定ファイルを開いている
  • 設定を編集したが保存していない
  • 違うユーザのデータを見ている
  • 読んでいるドキュメントが違う


エラー番号を見ただけで過去事例と結びつけ、原因を決めつけてしまうケースもあります。あくまで目の前の事象と向き合って切り分けましょう。原因を特定できたと断定できるのは現象が改善した時のみです。

人に聞く

1人で調査しても埒が明かない時は、同僚やコミュニティに助力を求めましょう。有料サポートを契約しているならもちろん有効活用しましょう。

  • 同僚に聞く
  • メーカーに聞く
  • コミュニティに聞く
  • stackoverflowで質問する
  • twitterハッシュタグをつけて質問を垂れ流してみる

コミュニティに質問する場合は、事前にドキュメントを読み込んで質問方法、質問場所を確認しましょう。

・・・大体自分がいつもやっていることは出尽くしたと思います。これらはそれぞれ1度行えばよいというものではなく、何度もぐるぐると行ったり来たりして徐々に原因を追い詰めていきます。繰り返しになりますが、原因が確定するのはあくまで障害が改善したその瞬間です。それはエンジニアにとって喜びの瞬間でもあるので、解決を目指して突き進みましょう。

バックギャモン動画撮影

私の職場では、昼休みの度に同僚とバックギャモンをプレイしています。
参加者が増えるにつれ、トーナメントをやってみたり、レーティングをつけてみたりと徐々に遊び方も進化していったのですが、そうなると当然やりたくなるのが動画撮影ですよね。
プレイ動画を撮って後で棋譜を起こし、XGで解析するのは上達の近道です。参考までに実際どんな機材を使っているのかをご紹介します。


f:id:sakamoto_desu:20170530122342j:plain

これが実際に撮影している様子です。GoProを三脚で固定して撮影しています。


GoPro

1世代前のGoPro HERO+LCDモデルを使っています。やはり背面LCDがあるとすぐに写りを確認できて便利ですね。撮影後はUSBでPCにデータをダウンロード -> Youtubeに限定公開でアップロードして管理しています。Youtubeは容量無制限でアップロードできるので助かりますね。今はアップした動画を見ながら棋譜を起こしていますが、そのうち日本バックギャモン協会の有料棋譜起こしサービスも使ってみるつもりです。

最新の上位モデルだと、GoProから直接Youtubeにアップロードできるみたいです。

Ventlax

このVentlaxというのは要するに自撮り棒なんですが、オプションの三脚を使うと固定して使うこともできます。色々調整したところ先端のアームを1個外すと良い画角になりました。

実際に撮影した映像はこんな感じです。

f:id:sakamoto_desu:20170704202618j:plain

これで十分盤面が見えます。本当は自分から見た向きにしたいのですが、この機材だとどうにもならないですね。
そして実際に解析をしてみると、想像以上にダメな手を打っていたり、キューブアクションを見逃していたりと盛りだくさんで動画をとった甲斐がありました。
その他様々なハプニングが撮れたりして面白いことずくめなので、ぜひ動画撮影をやってみてください。

JJUG CCC 2016 Fallとキャリア

JJUG CCC 2016 Fallに参加しました。
可能な限りセッションは見たのですが、特に印象的だったものについて。

トレンドとキャリア

いちエンジニアとしては「何の技術を身につけるか」は大事です。それによって歩めるキャリアがだいぶ変わってきます。
それ故に今のトレンドは何なのか、どんな技術を身につけるべきか悩んでいたのですが、

「Webの先輩なんていなかったから、参考となるキャリアパスなんてなかった。好きなことをやればいい」

という言葉にガツンとやられました。
たぶん自分はキャリアの「正解」みたいなのを探していたのですが、よく考えたら業界自体が変化してる真っ最中なので正解もクソもないんですよね。
とは言っても自分の好きなことばかりを中心にするとあまりにもトレンドとかけ離れすぎてご飯を食べていけなくなりそうなので、その辺はバランス取らないといけないのでしょう。
ぼんやりした不安がすっきり消えたので2017年は迷わず進めそうです。

その他CCCで達成した野望

  • 後輩を連れてくる
    • 後輩と一緒にひしだまさんにお礼を言う
  • 夏の納涼LT大会で発表できなかったネタをやる

かっこわるいプルリク

JNAにプルリクをマージしてもらえました。
やったー。
長かったー。

どれくらい長かったかというと、2ヶ月以上かかってます。
マージしてもらったプルリクをみるとオープンしたのは3日前なのですが、これはぐだぐだになったプルリクをクローズして作り直したからです。
どうしてこんなに時間がかかったのか、オープンソースへの参加ハードルを下げるためにも恥を晒しておこうかと思います。

1週間に1回

8月末にプルリクを送ったんですが、予想外にやりとりが続き忙しい時期とバッティングしてしまいました。
そのため実際に対応できるのは1週間に1回。先方もよく付き合ってくれましたね・・・

英語力不足

そのやりとりが増えた原因の一つが英語力不足でした。駄目出しを受けてることはわかるけど何をどうすればいいのかわからないということが多かったです。

  • 誤読して不要なことをする
  • コメント不足でレビュワーと意思疎通がうまくいかない
  • ソースコード書くよりも英語コメント書く方が時間がかかる

こりゃいかんということで途中からしごとの基礎英語 | NHKゴガクで英語の勉強を再開したのですが、これがヒットして後半は大分楽になりました。
英語は勉強というより練習ですねー。

JNA知識不足

単純に知らない機能・知らない使い方を紹介されて、こうすればもっと良くなるよ!みたいな話が多かったですね。
おかげさまでdllマッピングについて詳しくなりました。
というかドキュメント読んでも書いてないマニアックな話ばかりで、プルリク送らなかったら一生知ることはなかったでしょうね。
このへんはプルリク様様です。

マージ失敗

そして最後の最後でマージ失敗・・・。
最後の方はレビュワーもサンプルコードを書いてくれていて、コピーするならマージしてね!と言われたのでマージにチャレンジしたのですが、最終的にコンフリクトを解消できず。何がいけなかったんだろう・・・
そしてもーどうせコミット多くてdirtyなプルリクになっているから、と開き直ってプルリクを作り直しました。
gitはまだ理解が足りてないですねー。


という感じでレビュワーに迷惑をかけながらもどうにかマージしてもらえました。
根気良く付き合ってくれる良い人に面倒見てもらえてありがたかったです。
さすがに適当なプルリクをじゃんじゃん送ろう!という話ではないですが、こんな風に誰もがスマートでかっこいいプルリクばかりを送ってるわけではないので、皆さんもチャレンジしましょう。

Backgammon:エースポイントゲームの定理。

バックギャモンとは | 日本バックギャモン協会

要するにエースポイントゲームに対してどんなに上手に対応したとしても、最悪の目が出てブロットができてしまうことがあるのはしょうがないよね、というお話です。

定理

エースポイントゲームでは、ブロットができてしまうダイスの目のパターンが必ず存在する。

証明

相手はエースポイントにずっと2駒残っているとする。
自陣のあらゆる初期状態から、限りなくブロット作らないで進めることができたとしても、最後の1手前ではインナーボードに2コマ必ず残る。
そのとき、次の手で以下のような目が出ると必ずブロットになる。
・片方はエースポイントをふさがれていることによって動かない目
・もう片方は動ける目
よってすべてのエースポイントゲームでどんな目に対してもブロットを作らないで安全にベアオフすることは不可能。
証明終わり。


・・・あってるかな?

第9回Jenkins勉強会 Jenkins+Windows

第9回Jenkins勉強会 - connpassにてLTで登壇させて頂きました。

slides.com

CIツールは乱立していますが、Windowsに対応しているものって少ないですよね。ただこんな手間がかかる状況だとJenkinsおじさんを量産するのでは?という意見は反論できませんでした。
実際自分も社内でJenkinsおじさんと化しています。その上Gradleおじさんも兼任しているので加齢臭が心配です。

あと引き続きvSphere PluginとLibvert Slave Pluginの簡単なJNLP接続方法を募集中です。
いやとっととJIRAにチケット登録しろという話なのかもしれませんが。
今後はもっと簡単にWindowsを扱えるようにできないか考えたいですね。

他にも言いたかったこと
  • xp/2003以降でGitが動く
    • Git Plugin + Artifactoryで自動インストールが可能
      1. Git for Windowsをインストール
      2. 設定を編集してからzipで固める
      3. Artifactoryへアップロード
      4. Git Pluginで自動配布