ソフトバンクさんが、「Half & Twice」という社内スローガンを出されています。
時代の変化が求めるワークスタイルとは〜ソフトバンク流「働き方改革」の事例～ - ITをもっと身近に。ソフトバンクニュース
これは、”半分の時間で生産性を2倍にしよう”という考え方です。 不勉強で申し訳ありませんが、私はこのスローガンは、先日のAnsible Automatesで初めて知りました。
一見無茶に見えますが、個人的には割とドMなので、こういうのを出されると燃えるタイプです。
あんまり話はつながっていませんが、色々と考えを整理するために、効率化に関する自分の考えを書いてみます。
効率化の定義
私の考える「効率化」の定義は、以下の通りです。
- ものごとを現在よりも短時間で実施する
- 同じ時間をかけても、より品質の高いものを提供できるようにする
決して、「新しいものを作り出す」とか「すべてを同じ方法で実現する」とかではないのがポイントだと思っています。
効率化＝自動化？
これは、明確にNoだと思っています。
自動化は、効率よくものごとを行うための一つの手段でしかないと考えています。
例えば、「手動でファイルサーバのデータを整理した」「業務フローを整理し、書類にまとめた」というのは、自動化ではありませんが、これは「効率化」の手段としては正しいアプローチです。
ファイルを探すのに散らばっていてどこにあるかわからず時間がかかる。 誰が知っているかわからないから、手当たり次第に相談する。 こういった課題を解決することで、「無駄を減らす」という形で効率化を実現しているからです。
利益＝売価 - 原価
この商売の原則と同じです。利益を出すには、原価を下げるか、売価を上げるか。
原価は、同じ方法を継続していても下がりません。なので、大量購入だったりもっと安い仕入れ先を探す、などの手法で原価を下げることを検討します。
単純に売価を上げても、それを喜ぶ人はいません。なので、大量に売れるために広告をうったり、付加価値をつけることで、より商品価値を高める必要があります。
まあ、こんな話はいまさら言われるまでもないことだと思いますが。
売り上げ論に関してはど素人なので、原価を下げる方法の話になるのですが、ITの現場でこれを考える場合、「無駄を減らす」というのがまずは考えるべきだと思っています。
Ansibleを例に挙げて考えてみる
私が最近お熱なAnsibleですが、これはRedHatさんの「自動化2.0」の中心に位置するプロダクトです。
- 「導入効果で実作業時間が1/30になった」
- 「フロントエンドと連動させて運用に手がかからないようになった」
上記のように、非常に効果が高いと思える導入事例が多いです。
ただ、
- 「Playbookでいろいろな仕組み実現しようとすると無理やり感が出てつらい」
- 「コーディング規約をまもってくれない」
- 「Playbook化する前に標準化が必要だった」
とかの、つらみ寄りの言葉も目にします。
Playbookは可読性が高い。冪等性があると良い。これは本当のことだと思います。
TowerやAWXを入れると、ワークフローで最小限のPlaybookの組み合わせで行けるから部品化しやすい。
これも本当だと思います。
ただ、それらが求められる現場や環境だけではないはずです。
単純に、「作業時間を短くしたい」「かかる人手を最小限にしたい」ということがやりたかっただけなはずなのに、「自動化」することが目的になっている。
その「自動化」の手法に合わせるために、結構な努力をする。
結果、なんか当初考えてたのとは違う結果になってきて、ぐぬぬ・・・となる。
割とよくある話ではないでしょうか。
手段に盲目にならずに、自分が本当に必要としているものを見極める必要があると思っています。
私としては、基本的に「無駄を減らす」ということを効率化の一丁目一番地で考えていて、それと照らし合わせて適切な場所で、適切な方法を取れればそれでいいと思っている人です。
「自動化2.0」のサイロをなくすというような考え方とは反することになりますが、検討の結果が、ある場所ではAnsibleなどになり、それ以外では別のアプローチになる。それでいいと思っています。
こんなことを言っている背景
Ansibleなどの自動化ツールで実現できるのは、以下の点だと思っています。
- 作業トリガーの自動化
- 作業の標準化
- 処理の自動化
これらを実現できるのは素晴らしいことです。
ある作業の処理待ちで次の自身の作業まで3時間待つ。これをトリガーの自動化でだれでもできるようにして無駄を減らす。
非常に素晴らしいです。
作業手段が標準化され、統一されることにより、引継ぎにかかるコストが大幅に削減された。
これも素晴らしいです。
実際の作業が省力化され、作業をITに任せて他のことができるようになった。また人手でやりよりもはるかに確実で効率的に実施できるようになった。
本当に素晴らしいです。
でも、そこにたどり着くまでに、いろいろな学習をしたり。準備にものすごく時間をかけたり。意識改革までしたり。
あれ、それがやりたかったんだろうか。と疑問に思ったことはないでしょうか。
もちろん、エンジニアにとって前に進むことは求められますし、新しいことを学んでいくことはとても重要なことです。これは「環境や時代に合わせて適応していく」という、「変化」なのだと思っています。
ただ、そのような「変化」ができない人や環境でも、効率化は求められるんです。 私の周りにも、そんな人たちはそこかしこに居ます。
そこに対して、「時代遅れだ」とか「勉強しない奴はこれだから」とマウントを取ることはできると思いますが、変化しないものは変化しないんです。
であれば、やりかたが間違っている、と考えることもできるはずです。この時点で「あいつらには無理だ」とあきらめるのはまだ早いです。
「無駄」とはどういうことか？
ツールを変更することで手順を変化させる。 これは、受け入れのコストがものすごくかかります。
上記のような、新しいやり方ができない場合でも効率化が求められます。
そういった場合には、徹底的に「無駄」を排除することが最も効果的だと思っています。
「無駄」というのはそこかしこにありますが、例えばある特定の作業を行うときを考えてみましょう。
- 手順書を目で追っていき、工程ごとにチェックを入れる
- 手順書に従い、画面の操作を行う
- 手順書に記載されたとおりに、コマンドを手動やコピペで入力する
- 入力された内容を複数人のダブルチェックで目視確認する。
- 手順書に記載された形の結果になるか確認する。異常があればエスカレーションする。
大体の場合、最後の判定の部分が最もコードを長くにしてしまうものだと思います。 いわゆる、「エラーチェック」の部分だと思います。
決して「エラーチェック」の重要性を軽んじているわけではありませんが、それって本当に自動化しなきゃいけないんでしょうか？
判定基準が明確なら、別に目視でもいいんじゃないでしょうか？
人手による運用のリスキーな点は、「オペミス」だと思ってます。 オペミスは、手順や判定基準がしっかりしていない場合に発生することが多いです。
文字が読みにくかったり、絶妙にTypoっていたり。 それを目視で確認して手動で入力したり、慎重に1行1行コピーして貼り付ける。
私も、CiscoのACLをコンソールでいじる時なんかはすごい慎重になったものです。
私が考える最も「無駄」なポイントは、この「入力行為」です。
入力は、人間がやるのよりも、機械がやるほうが確実です。
入力を誤るオペミスは、機械がやっても間違えるならそれは手順が悪いんです。
なので、確実に手順通りに実施する機械があるのであれば、あとは手順の精度の問題です。
であれば、その仕組みを作ってやればいい、と考えて、実際に作ったことがあります。
前の部門で類似のオペレーションを何度もやるようなシーンがあって、そこに適合するなと思ったのがキッカケです。
でも、メンバーは「変化」には敏感なメンバーでした。なので、それは中身を知らないといけないような仕組みにはせず、手順の精度を上げればいい、かつ見た目は変わらない、入力だけをやってくれる、という実装にしました。 （ちなみに、中身も大したことはないです。）
止まる部分には特定の文字（手順書上不自然でない文言）を手順に入れるだけで、止まってくれるようにしました。ここで目視で判定をするようにしました。
メンバーの教育は5分で終わりました。今ではなんの気兼ねもせずにその仕組みを使ってくれています。
結果、一回の作業の時間は1/3になりました。
Ansibleの話よりも効果は低いようにも思えます。でも、本当にそうでしょうか？
効果がすぐに出る。ある程度網羅性に目をつぶれば、どんなものにでも応用できる。メンバーの教育もほとんど要らない。 冪等性なんて求めてない。
教育そのものが無駄とは言いませんが、結構なコストです。抵抗もあります。
こんなふうに、部分的に形は変えずに無駄な部分だけを省く。こんな形の効率化があっても良いよな、と思います。
もちろん、そこで止まるか、踏み台として先に進むかはそれぞれです。
それでも、一足飛びにやるよりも、確実な一歩を踏み出す。 その結果生み出された時間でもう一歩目を踏み出す。 そんな形のステップもあっていいと思います。
前に進む材料は一つではないはずです。 読んでいただける方は少ないと思いますが、みなさんも盲目にならないようにご注意ください。
