もう4月で今更なのでこっそりと
なんやかんやあった
いろいろあって疲れた...
この記事は 子育てエンジニア Advent Calendar 2021 の13日めです。
以前書いたものはこちら
子育てソフトウェアエンジニアの継続的な学び方のエッセンス - ビットの海
子育てソフトウェアエンジニアのワークとライフ - ビットの海
こんちには、2児の父です。
子育てエンジニア Advent Calendar なので、小粋な子育てHackの話でも書きたかったのですが、先日の家庭内重大インシデントで疲弊してしまってそういう気分にはなれず、今年は掲題のような「Hackしないふつーの育児」にします。
端的にいうと、上の子の感染症（ブドウ球菌性熱傷様皮膚症候群）による入院です。
入院13日目にして、やっと退院することができました。当人は元気になったので、それは良かったのですが、共働きの親は疲労コンパイルです。
知育的なものだったり、時間の効率的なマネジメントであったり、育児Hackは多くあり、私もそういう話好きなんですけど、今回の入院を通して改めて考えたのはふつーの育児です。
必要最低限の育児、と言い換えても良いかもしれません。
育児のフリーペーパーかなにかで、インタビューに答えている人が言っていたのをぼんやり覚えているんですが、育児で大切な（必要最低限）のことって、「衣食住を整える」だと言っていて、いま非常に共感しています。
特にうちのような未就学児を抱える家庭が、それは一番に意識しないといけないこと（それ以外はある意味 Optional である）と言っても良いのではないでしょうか。
衣は、季節に合わせて、清潔で安全なものを用意しないといけないし。
食は、これも季節に合わせて、広く栄養を考えたものを用意しないといけないし。
住は、安全性に気をつけて、遊びができる環境を用意してあげないといけないですよね。
ともすれば、知育的な話題なんかにどうしても関心が行きがちです。
が、子供が入院というインシデントを経験して感じたのは、睡眠時間をちゃんと確保するとか、手洗いがちゃんとできているとか、衣食住がちゃんとしているか、テレビ見すぎないとか、絵本読み聞かせできてるか、etc..
基本的なところを時々見直して、そういうところを大事にしたほうが良いんじゃないかな〜という感覚でした。
こういう基本的なことが出てきてたら、自分たちの育児を自己肯定していって良いと思います！！！
私育児ちゃんとできてる！！！（自己肯定マシマシ）
（きっと来年はぜんぜん別のことを書いてると思います）
いちエンジニアといえども、時には何かしらの起案を自組織や上司に対して行うことがあると思います。
片手間でできるような仕事であれば、起案もへったくれも無いかもしれませんが、ン千万のお買い物なんかは、だいたいの組織では、それなりの説明が必要だと思います。
ちなみに、私が何かを起案する、という行為を初めて意識したのは、ン年前の新卒の頃、先輩が、社内に検証用の環境を作るために各種利害関係者の説得をしていたのを横から眺めていたときでした。
さて、今回の話は、以下の本に書いていることと自分の経験をかいつまんでいます。興味のある方は本を読んでいただくと良さそうです。
起案のための資料をいざ作ろうとすると根本的な問いが発生すると思います。
「なぜその支出が必要なのか」です。
それは、小さい会社であれば社長さんかもしれませんし、大きな会社であれば、多くの役職者に問われることかもしれません。
これが、例えば 「ECサイトにレコメンドシステムを追加して、売上を10%上げたいんです！分析結果から目処が立っています！」と言えると大変楽な話ですね。
ひねくれた人以外は反対しなさそうです（投資金額次第かもしれませんが）。
ただ、すべての支出がそういうわかりやすいものばかりではありません。
「開発に便利な SaaS を導入したい（が使うのは一部の人間だけだな）」かもしれませんし、「壊れそうで壊れないサーバをいい加減新しいのにしたい（が保守が残っている）」のようなものかもしれません。
こういった場合、利害関係者（主にお財布の紐を握っている人）がその必要性を両手をあげて賛成してくれることは、概ね稀であり、支出の為に説明なり、説得が発生すると思います。特に金額が大きくなればなるほど...ですね。
そういったとき、各々の経験から、「これを導入しないと若手が辞めますよ」とか、「このサーバー新しくしないと落ちた時にoo部から怒られますよ」みたいな言い方をするかもしれません。
それはそれでありなのですが、「ITに関して支出が伴うものはすべからくIT投資であり、そのIT投資の評価手法はいろいろある」ということを知っていると、資料を作ったり、人を説得したりする際の道具が増えることになり大変便利なので、いくつか紹介します。
まず、IT投資を大まかに分類してみます。
これは、「使っているデータベースの保守が切れたので更新する」みたいな投資と、「ECサイトの売上げアップの為に外部にコンサルタントを依頼したい」のような投資とでは、同じIT投資といっても性質がかなり異なるからです。
性質が異なるものを同列に扱うことは困難を極めます。
といっても、制度的、法的にスタンダードな分類があるわけではなく、実際は企業単位で何かしらの分類がされていることだと思います。
シンプルであれば
もう少し分けて、上述書籍（図解即戦力 IT投資の評価手法と効果がこれ1冊でしっかりわかる教科書）から引っ張ってくると...
所属企業に分類の定義がなければ、こういうのをとりあえず定義してみるのも良いかもしれません。
さて、やっと本題のIT投資の評価手法に入りたいと思います。
IT投資評価の難しい点は、いくつかありますが、制度的、法的に確立しした手法があまりないというが個人的には大きいと思っています。
例えば、エンジニア界隈で有名な「技術的負債」という例えがありますが、多くの経理担当者に理解される概念には至って居ないと思います。
とはいえ、現実は何かの手法がなければ困ってしまうので、いろんな人が知恵を出して考えたものがあります。
手法は、大きく分けて、財務的手法、非財務的手法に分かれると思います。
財務的指標は何らかの財務的な数字（売上とか利益とか）で、測れるもの。非財務的指標は、財務的指標以外のもので効果を測るものです（アンケートによるユーザ満足度、とか）。
さて、以下は上述書籍（図解即戦力 IT投資の評価手法と効果がこれ1冊でしっかりわかる教科書）に記載されている手法です。
| 手法 | 評価手法 | 内容 |
|---|---|---|
| 財務的手法 | ROI（投資利益率/投資回収率） | 投資額に対する回収額（利益）の割合 |
| 回収期間法 | 投資額をどれくらい早く回収できるか | |
| NPV法（正味現在価値法） | 割引キャッシュフローの総和 | |
| IRR法（内部収益率法） | NPVが0になるときの割引率 | |
| ABC/ABM | 業務コストの削減量 | |
| 非財務的手法 | 妥当性評価 | 世間相場、同業他社のベンチマークなど |
| ユーザー満足度評価 | 利用者のアンケート調査結果など | |
| SLA（サービスレベル合意） | システムのサービス水準 | |
| 情報セキュリティ投資評価 | リスクの大きさ | |
| IT-BSC | CSF、KPIの達成度 |
もちろん、これがすべてではありません。他に財務的、非財務的手法はたくさんあります。また、コンサルティング会社などは独自の非財務的手法で評価することも多いようです。
ここの手法について説明するのは手に余るので、それぞれの書籍等を読んで欲しいのですが、ここで伝えたいのは
です。
そして、先程のIT投資の分類と関わってくるのですが、IT投資の分類と評価手法は相性があります。
例えば、「新しいセキュリティソフトウェアを導入したい」という起案でROIを語ることは現実には難しいケースが多いかと思います。目的が、新しい脅威に対応する、ものであり、なにかそれが直接的な利益や売上につながるものでは無いからです。
その場合、何かしらの非財務的評価を用いることになると思います。
この、IT投資の分類と評価手法を適切に組み合わせることが、起案に対する納得を得る為に必要だと思います。
IT投資評価の話になると、ROI の話にどうしてもなりがちだと思います。
経営者は財務的な数字で物事を判断しているため、そのプロトコルに合わせようとすると、どうしても ROI の文脈で語りたくなります。
他方、IT投資は、利益や売上につながらないものの、事業の安定した継続性（セキュリティに対する投資などはそうでしょう）のための投資も多くあります。
現実には、個人の信頼から投資が通ることも多く、ooさんが言うなら大規模リファクタリングやりましょう、みたいな話も多いかと思います。それで成立するのであれば、それでも良いのかもしれません。
「技術的負債」のような概念が通じる組織であれば、それでも良いと思います。
自分は、アリストテレスの説得の三原則の話が好きで、説得には「エトス」「パトス」「ロゴス」が必要だとされています。
ロジカルに資料を作ったり、投資評価の計算をしたりするのは、エトス。
個人の信頼に基づいて動いてもらうのは、ロゴス。
そして、最終的には、実現したいというパッション（熱量）がなければ困難な問題ほど前に動かないと考えおり、自分がその対象に対してどれだけ真剣なのか、パトスを持って伝えるのが大事なのでは、と考えています。
加えて言うなら、提案を受ける側の態度もとても大切で、「エトス」「パトス」「ロゴス」を含む提案をきちんと（通す通さないは別として）受け止めるのが、良い組織なのでは？と思います。
以下はもう古いです。
新しい記事 : Mac で しゅっと Embulk 動かす (2022年5月版) - ビットの海
たまにしか触らないと、Java 8だったっけとか、dl.embulk.org 死んでるんだっけ、とか毎回忘れるわけですよ。 あと、 /usr/libexec/java_home -v の指定で、patch バージョン要らんとかも毎回忘れる。
brew install adoptopenjdk8
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
java -version
export EMBULK_VERSION="0.10.33"
curl --create-dirs -o ~/.embulk/bin/embulk -L "https://github.com/embulk/embulk/releases/download/v${EMBULK_VERSION}/embulk-${EMBULK_VERSION}.jar"
chmod +x ~/.embulk/bin/embulk
~/.embulk/bin/embulk --version
経営学のフィールド・リサーチ―「現場の達人」の実践的調査手法
随分前に買ったけど、本棚でホコリを被っていて、本棚整理で出てきたので何気なく手にとってみたら面白かった本。
概要としては「企業とその組織の実例（ケース）を研究するための方法論についてやさしく解説することを目的とした」（エピローグより）ということだそう。
内容としては上記のとおり、ケース・メソッドとケース・スタディをあわせた、フィールドリサーチをどうやってやっていくか、という実践的な内容です。
別に自分は研究者ではないけれど、特にSEをやっていたときに、既存の（システム運用などの）業務を改善せよ、みたいなことを仕事として渡され、何もわからずやっていた時期がちょっとだけあります。
SEを辞めて事業会社でソフトウェアエンジニアをするようになってから、アウトプットとしてのドキュメントを求められるような仕事はしなくなったものの、事業会社の中で、何かを改善せよ、みたいな話はポツポツ出てくるものです。
そのときに、自分が当事者として経験した業務ではない場合（たとえば、運用たことのないシステムなど）、コンサル風な感じで、現状把握をして、こうしたらいいんじゃない？みたいな（ときにはその改善自体を実践）することはよくあります。
自分は、人文系のフィールドワーク等の学問を学んだことや、コンサルの会社に居たわけでもないので、概ね我流でなんとかそういう場面を切り抜けてきたのですが、ふと、このアプローチってどうなんだろうと我に帰ることがあります（昔は フィールドワークコンサルティング というのも参考にしたりしていました）。
というわけで、多分この本をポチったと思うんですが、フィールドワーク関連の面白さはさることながら、経営学という学問のおもしろさも感じることができました。
特に以下のような記述は、多分に刺激的ではないでしょうか？個人的にはまさに！と思ったりしました。
第3章 部分と全体ーケーススタディをどう使うのか、より
ほとんどの企業にとって、唯一の目的は、利潤の最大化なのです。在庫コストの最小化はそのための一手段にすぎません。それを分解して、在庫問題というように切った瞬間から、もう最適化の基準としては在庫コストの最小化でやるしかなくなるわけです。
ところが、在庫コストを最小化するために、提示されたソリューションを実践すると、営業部門、他の工場、サプライヤーなど、いろいろなところに迷惑をかける結果になるわけです。これはなぜかというと小さく問題を切り出すために、企業のある一つの断面しか見られなくなってしまうからです。ところが、変数は一つの断面に収まりませんから、それを動かすとモデルの外で必ず影響が出てしまいます。そうなると企業全体にとっての最適化にはならないのです。
#!/bin/bash
START_DATE="20201224"
END_DATE="20210103"
DATE_CMD="gdate"
for (( DATE=${START_DATE} ; ${DATE} <= ${END_DATE} ; DATE=`${DATE_CMD} -d "${DATE} 1 day" '+%Y%m%d'` )) ; do
TARGET_DATE=`echo ${DATE:0:4}-${DATE:4:2}-${DATE:6:2}`
echo ${TARGET_DATE}
done
実行結果
2020-12-24 2020-12-25 2020-12-26 2020-12-27 2020-12-28 2020-12-29 2020-12-30 2020-12-31 2021-01-01 2021-01-02 2021-01-03
