Evidence based programming

エビデンス

最近、エビデンスという言葉をよく見る気がしているのですが、トレンド調べたら、2020年頃から増えてるようです。コロナのせい？

この言葉、元は医学でのEvidence based medicineがベースだと思うのですが、どうも世に流れてる「エビデンス」という言葉は、証拠といった意味合いで「エビデンスがある」「エビデンスがない」といった使われ方がしているケースが散見されます。

が、Evidence based medicineにおけるEvidenceは、レベルが明確に定められていて、たとえば、「専門家個人の意見」なんてのも、エビデンスレベル6なんですよね。なので、エビデンスについては「ある」「ない」ではなく、本来は「強い」「弱い」といった軸で使うのが正しい用法です。

Evidence based programming

で、ふと思ったのですが、これ、プログラム開発でも近いものがあるのではないでしょうか。

たとえば、とあるライブラリを利用したプログラムを利用する場合、当然ながらライブラリの挙動を考えて設計し、コードを書くわけですが、そこにエビデンスレベルが当てはまりそうです。ちょっと思いつくまま言語化してみると、下記の表になりました。

レベル	内容
1	数学的、物理的に絶対と言えるもの（三角形の内角の和は180、とか）
2	ライブラリ公式のドキュメント
3	書籍化されているドキュメント
4a	StackOverflowやQiitaなど、信頼できそうなネット情報
4b	当該技術に精通していると思われる先輩などの意見
4c	個人ブログなど、信頼できるかどうか不明なネット情報
5	様々なネット情報をもとに自分で推測した情報

これらのレベルに、「動作確認を行った(A)」「動作確認はしていない(B)」の軸を加えます。

根拠のないコードは無い

これまで、様々な人の設計やコードのレビューをしてきましたが、疑問点があって担当者にインタビューしてみると、5Aとか4cAなどの情報が元だったりするんですよね。「コードをコピペで持ってきたら動いたのでOK」ってやつです。

レベル2（公式のドキュメント）を見ていない。そこにはエラーや例外となる条件が記載されているが、そこを読んでいない（公式ドキュメントが英語のみだと増えがち）。結果、エラーや例外は自分の想像で仕様を埋めるので、2Aのエビデンスレベルで作れるはずが、5Aベースになっている。当然、エビデンスレベルの低いコードは、バグっている可能性が高い。

レビューで多く指摘を受けてる人と、そうでない人とは何が違っているのか、ってのが、長年言語化したいものだったのですが、このエビデンスレベルの考え方で言えば、前者（指摘を多く受ける人）はエビデンスを「有り」「無し」で考える人、後者はエビデンスを「強い」「弱い」で考えてる人、と表現できそうです。

4cの情報を発見し、動かしたら動作したので4cAとなる。前者はこれで「エビデンス有り」として完了となるが、後者は4cAではまだ「エビデンスが弱い」と考え、より上位のエビデンスを探す。この差があるんじゃないかなー。

JIRA×Toggl×人事労務freeeで作業時間の見える化

Jiraによる時間管理

弊社では勤怠管理として人事労務freee、タスク管理としてJiraのServer版*1を導入しています。
さらにJiraのアドオンとして、Timesheet Reports and Gadgetsを使用しています。

これらを以下のルールで運用しています。

• すべての勤務時間は、必ず何らかのJiraチケットと紐付ける。（ちょっとした雑談の時間なども、専用のチケットを用意してそこに時間を付ける）
• Jiraに入力した時間の合計が、勤務時間と必ず一致させる。

Jiraにすべての作業時間を入力することで、人事評価の参照資料にしたり、AIによる作業時間予測の学習データに使っています。
しかしながら、これには課題が2点ありました。

• 細かく作業時間を記録してないよ！
• Jiraの合計時間が勤務時間と合ってないよ！

細かく作業時間を記録してないよ！

誰かのレビューしたり、作業相談にのったり、お客様の問い合わせに対応したり、という風に、毎日突発的な割り込みが起こりますが、それらの時間をすべて異なるJiraのチケットへ記録するのは、ツールでもなければ実現できません。
そこでToggl trackを使います。
これに、Chrome用の拡張機能を組み合わせます。
そうすると、ChromeでJiraのチケットを表示した際に、時間計測ボタンが出てきます。

拡張機能の適用前

拡張機能の適用後

弊社の作業の流れだと、作業開始時にJiraチケットを確認することが多いため、ここでStart Timerを押すことで、Togglにチケット別の時間が記録されていきます。
あとは、Chrome拡張のToggl to JIRA(FREE)*2を使用することで、Togglに入力した時間が、Jiraに同期されます。 Togglの時間は秒単位で集計、Jiraの方は分単位で集計のため、多少の誤差が出ますが、そこはTimesheet Reports and Gadgetsの画面で勤務時間と比較し、手動で調整します。

Timesheet Reports and Gadgetsの画面

Jiraの合計時間が勤務時間と合ってないよ！

ここまでで、作業ごとの時間入力ができるようになりました。
が、Jiraの合計時間が勤務時間と合っていないことがある、の課題が残っています。
弊社では、勤怠入力は人事労務freeeを利用しているため、当初は、freeeの勤怠画面を見て、それをJiraの合計時間と一致しているか、目視確認としていました。

Jiraの勤怠画面

上記画面だと、7時間51分という時間が表示されていますが、この時間は休憩時間が入っていないため、各自が休憩時間を脳内で減算処理する必要があります（画面例だと6時間51分となる）。
休憩が1時間だとシンプルで良いのですが、弊社はスーパーフレックス×自由休憩制度なので、休憩時間が1時間36分など、中途半端なこともしょっちゅうあります（勤務途中に水泳に行ったり） 。 これはアカン。
こんなのを『各自で注意する』運用にしてたら、ミスはいつまでもなくなりませんし、じゃあ『ちゃんとミスがないか目視ダブルチェック』とか言い出すと、イケてない組織へまっしぐらです。

救世主freee API！

見つけたのがfreee APIです！ この中の人事労務freee APIを使えば、プログラムで勤務時間を取得することができます。
そこでTampermonkey用のユーザースクリプトを作成し、Timesheet Reports and Gadgetsの表を書き換えるようにしました。

初回アクセス時には、認証情報を求める状態になります。

認可情報を取得をクリックすると、別ウィンドウが開きます。

ここで許可するを押すと、ユーザースクリプトがアクセストークンを勝手に記憶します。

結果、Timesheet Reports and Gadgetsの表がこうなりました。

変更後の画面

入力時間があっているかどうか、一目瞭然！
❌のついた日の時間を修正して、画面をリロードするだけです。
（自転車のアイコンは、自転車通勤した日を意味しており、本記事とは関係ありません）

さいごに

Timesheet Reports and Gadgetsは若干マイナーなアドインだと思いますが、超ピンポイントに合致する人に役立てばいいなと思い、記事にしました。 リモートワークが増えた昨今、『Jiraにすべての勤務時間を入力する』というのは、需要が増えていくのかな、と思っています。 スクリプトはGitHubに公開してますので、興味のある方はコード改造して使ってみてください！

github.com

*1:JiraのServer版は、新規の販売を終了してます。

*2:2021/06/06現在、Chromeウェブストアから削除されており、代替ツールを調査中です。

起業して2年を振り返る(3) 就業規則の整備

就業規則

無事に事務所開設が決まり、2019年7月1日から本格的な営業を開始することになりまして、6月は事務所の工事と並行して、ひたすら就業規則関連の規程を作成しました。
7月1日からは、スーパーグレートエンジニア1名が入社してくれることになったとはいえ、就業規則が義務化されるのは、【常時10人以上の労働者】を雇用した時です。なので、従業員1名の時点では、法的には無くても構いません。
が、厚生労働省のモデル就業規則をベースに、ガッツリ書きました。

なぜ作成したか

これにはいくつか理由があります。

1. 自分が自分で決めたルールを忘れそうな気がする
2. 将来スケールアウトがしやすいように
3. 会社の文化を浸透させたい

ルールを忘れそう

弊社では、『性善説』『プロフェッショナル』を会社の文化として定着させようとしています。
そのため、就業規則がなくとも、文化に照らして考えれば、判断できるケースが多いです。
たとえば副業・兼業について、善なるプロフェッショナル人材が対象と考えた場合、禁止する理由がありません。

• 社内の機密情報を、外部に漏洩させようとするわけがない。
• 業務に支障が出るほど、副業の負荷を高めるわけがない。
• 副業を行うことで、新しい知識・知見を得て、会社にフィードバックしてくれるに違いない。

一方で、たとえば結婚した場合のお祝い金をいくらにするとか、休暇を何日にするとかは、「お祝い金を支給する」「特別休暇を付与する」までは間違えようがないのですが、「金額」「日数」は、正直忘れそうな要素なため、従業員毎に異なる支給をしてしまう恐れがあります。
これを避けるために、誰の時はいくらだったか……なんてのをExcelで管理しだすと、管理対象が増えるたびにExcelファイルが増えていって、やがて探すのも面倒、となりそうです。
であれば、最初が大変でもガッツリと就業規則を作成し、常に就業規則を参照するクセを付けるのが効率的と判断しました。

スケールアウト

これは前項の「忘れそう」に関連しますが、従業員が10名になると、やっぱり作成する必要が出てきます。
従業員が増え、事業活動も広がった状態から就業規則を作るとなると、意見のとりまとめが大変そうだなと思いました。
時間の経過／従業員の増加と共に、起業家のタスクは膨張する一方なので、『魂込めた就業規則を作る』なんて時間は、一番最初にやってしまうのがオススメです。

文化の浸透

日本人には「ホンネとタテマエ」というハイコンテキスト属性が備わっております。
そのため、就業規則が従業員を信頼するような素敵な構成になっていても、実際の運用が、どう解釈しても性悪説な稟議・りんぎ・リンギ！となっていた場合、「あ、なるほど、就業規則はタテマエなのね」となって、従業員はシラけてしまいます。
これでは企業文化の浸透は覚束ない。
また、いくら運用が素敵であっても、就業規則が無ければいわいる人治主義なわけで、会社のトップが変わった瞬間に文化がガラッと変わるリスクがあります。 就業規則があれば、いわいる法治主義となり、トップが変わっても、そう簡単には就業規則は変更できません。 つまり、目指すべき企業文化が就業規則に反映されていて、実際の運用も文化に合致することで、従業員への強いメッセージとなり、企業文化の浸透に繋がるのではないかと考えました。

頻繁に更新

2019年7月1日に施行した就業規則関連ですが、これまでの約2年間で、平均すると月に1回弱は何かしら改訂してます。

• 2020年4月の緊急事態宣言が出た👉すぐに在宅勤務制度を作成して施行。
• 在宅勤務なのに、タイムテーブルが決まっている（休憩は12:00-13:00など）のは不便👉スーパーフレックス制度の導入、昼寝も自由（プロたるもの、集中力向上に必要な活動は自分で決めるべき）
• 在宅勤務するのに、椅子とかテーブルとか環境が整ってないよ👉在宅勤務準備金制度の導入。
• 在宅勤務してると水道光熱費が上がった👉在宅勤務手当を導入。原資は、通勤手当を出社日数精算に変更することで捻出。

こんな感じで、従業員からの意見をもとに、会社の文化に照らし合わせ、適合するものはどんどん採用しています。
これもまた、企業文化の浸透に効果があると考えています。

スモールスタートの起業では、就業規則の作成は後回しになりがちかもしれません。
が、作成しているうちに、自分が大事にしたい企業文化って何なのか、を考える機会にもなりましたので、これから起業する方にはオススメです。

起業して2年を振り返る(2) 事務所開設

事務所探し～開設

事務所探し

2019年4月12日に登記は済ませたものの、まだ事務所がありません。

1人であればしばらくコワーキングスペースでも良かったのですが、いろいろあって、7月1日から人も雇って本格的に営業を開始することになりました。
コロナな現在であれば、「よし、いっちょフルリモートでもかましたろかしらん」となったかもしれませんが、当時はそんな会社運営など選択肢にありません。まずは事務所探しです。

Officeeにご協力頂きました。
何件か候補物件を下見して、4月25日に西新宿五丁目の現オフィスを発見。5月13日に内見をし、契約となりました。
決めてとなったのは、

• 周辺相場よりも坪単価が少しお安い！
• アドレスが渋谷区（端っこだけど）でITスタートアップっぽい！
• 都庁が見える！

でした。 5月末に正式な契約を結び、無事に事務所の鍵をゲット！
何もない、がらんどうの事務所に入った時の、「さあ、これから始まるんだ」というワクワク感は、起業の決意に対するご褒美な気がしました。

事務所工事

事務所はゲットしたものの、7月1日の事務所開きに向けて、什器／PC／ネット回線が必須です。
どうせやるからにはとことん快適さを求めたい、なので、タイルカーペットやらブラインドやらを独自ルートで仕入れ、DIYで事務所を作ります。

事務所扉(Before)

事務所扉(After) 壁紙みたいの貼るだけで雰囲気変わる

フロア(Before)

フロア(After) 床の色は大きい

将来、希少なエンジニア採用が必要となった場合に、何かしら特色のある事務所にしておきたいと思いました。

• 床はウッド調（実際はビニールタイルだけど）にして、土足厳禁。
• 休憩スペースに畳の小上がり
• ドリンクコーナーにはネスプレッソとフリーチョコレート
• 掃除はルンバ（後にブラーバも追加）

PC／ネット回線（NURO）もギリギリ6月末に調達し、ついに7月1日より営業開始となりました。
事務所DIYは、なんだかんだで1週間ぐらい工事にかかりましたが、愛着のある事務所ができあがりました。

起業して2年を振り返る(1) 設立準備～起業

合同会社ドミノソフトは2019年4月12日に設立しまして、もうすぐ2年になります。
そろそろ起業した時の記憶が薄れつつあるため、ブログに記録していきたいと思います。

設立準備～起業

設立まで

前職の某中堅SIerを退職したのが2019年3月31日。
退職日までガツガツ働いていて、起業準備といえるものはあまり出来なかったのですが、1つだけ決めていました。

『ドミノソフト』

社名です。
わりと気に入ってます。

起業するに当たって、数多のIT起業と比較した時に、何か1点差別化できる武器を持ちたい。
起業の時点で保有していなくてもいいので、長い年月、自分がワクワクし続けられるキーワード。
それが何かをぼんやりと考え続けてたところ、自分が好きで拘ってることが見えてきました。

『自動化』

役所とか病院とかの手続きで、2回も名前を書く場合があると「1回でええやん」と思っちゃいます。
2回書くのは、システムにユーザーを合わせているわけで、それは改善余地のあるシステムだと。
自動化ってのは、ちょっとしたバッチからシステム変革まで、実に奥行きのある世界で、これは新会社の基準軸になるんじゃないか。
「それ、もっと自動化できるんちゃう？」

自動化を体現する会社名って何だろうな～、自動だもんな～、パタパタ倒れていく感じだな～、それってドミノ倒しだな～、で、『ドミノソフト』。
ググってみたら、どうもスペインに同名の会社はありそう（いつか友達になりたい）でしたが、日本にはなさそうでした。
よし、決定。
細かいことは登記してから、で4月12日には設立しました。
定款なんかは会社設立freeeを利用しました。便利な世の中～。

ミッション・ビジョン・バリュー

退職の翌日からは、コワーキングスペースとしてサーブコープに通って起業準備をしていました。
会社設立後も、事務所を借りる5月末まで、ほぼ毎日通ってました。
最初は近所のレンタルデスクに通おうと思っていたのですが、人生で1回ぐらい、キラキラ感のあるコワーキングスペースとか通ってみたいと思い、契約しました。
大理石のカウンターテーブル！
親しみやすい秘書様たち！
僕の通った新宿オークシティは、すごく良い環境でした。

コワーキングスペースには、1席だけミーティングテーブルがあって、外部ゲストを招いて打ち合わせが可能になっています。
僕も税理士さんや不動産屋さんらと打ち合わせに使ったのですが、ここ、当然ながら、コワーキングスペースを使っている他の人にも会話が聞こえるんですね。
印象に残ってるのは、戦略コンサルタントなる方がいまして、その方がよく打ち合わせで、「企業で重要なのはミッション・ビジョン・バリュー」と言ってたことです。
へ～、と思って、ドミノソフトのミッション・ビジョン・バリューを考えてみるけど、なかなかピンと来ない。
なので、とりあえず昭和生まれには馴染みやすい、スローガンとか考えてみるかと思い、自動化をより具現化してみようと、
『One action makes more effects.』
としました。
英語にはまったく自信がなかったので、サーブコープの秘書様にチェックしてもらい、「カッコいいと思います！」と言われていい気になって、LOGASTERでロゴを作りました。

設立から2年経っても、未だにミッション・ビジョン・バリューを「これだ！」という言葉に出来てないのですが、こういうのは常に考え続けるのが良いのだと思います。