『職人芸』。それは、その人にしかできない、または他より圧倒的な品質・精度・速度で仕事を遂行する技術力、というものが確かにあります。

そのような崇高な技術は、どこから来て、どこへ行くのか。そんな圧倒的ポエム回。

職人芸とは

言い方はなんでも良いのですが、組織には上級的なエンジニアが一定割合いて、おそらくその人にしかできない仕事や、手慣れていて効率的に済ませられる仕事を任せられていることでしょう。

そういうエンジニアはたいてい『職人芸』と呼べそうな技術を修得しています。例えば、高精度な設計・高難度な機能実装・的確なコードレビュー・精密な試験・堅牢な運用などなど。

システム提供を大雑把に工程で分類すると、企画・設計・構築・試験・運用 といったところでしょうか。ちょっと外すと研究などもアリですね。それぞれの工程において、集中的に従事して得る職人芸もあれば、多岐にわたる経験によって生まれる職人芸もあることでしょう。

では職人芸にまで昇華する前はというと？ 誰しも最初は勉強フェーズから始まり、軽い構築を経験し、お金に関わるような業務として実戦投入していきます。その中でも、システム構築への携わり方として、ゼロから生み出す・設計通りに組む・他者の面倒も見つつ・工程全体を見つつ、など様々です。

工程や役割といった色々な状況がある中で、いったいどこで職人芸がひねり出されるかというと、私見としては本番環境の経験と改善にあると考えています。一口に職人芸や本番環境といってもその幅は広いですが、大枠で捉えるならば、本番経験から発生する技術は全て尊い職人芸になりうる、ということです。

職人芸の発生

ンもの凄くシンプルな例をだしますが、開発初期にこんな機能が必要になったとします。

開発者はDBクエリを発行し、Viewに表示させました。

機能としては正しく動いていますが、このまま本番投入すると、将来的にどのような事象が起こると想定できるでしょうか。

• データ量が膨大になって重くなってきた
• SELECT COUNT(id) FROM products にしたら軽くならないかな
• SELECT id FROM products ORDER BY id DESC LIMIT 1 で auto increment の最大値を取れば
• いやいや SELECT MAX(id) FROM products の方が
• query cache ON にしたら効くかも
• データの取得条件を追加したいんだけど
• WHERE is_flag = false をつけたら重くなった
• それ以前にこれだと auto increment の最大値を使えなくね
• 結局 SELECT COUNT(*) FROM products WHERE is_flag = false にしたけど激重
• 結果をKVSにキャッシュするか……リアルタイムやめません？
• さらにデータ量が膨大になってストレージアクセス過多に
• DBメモリよりデータ容量の方が大きくなって、iowait が厳しい
• ストレージのIOPS上限に到達してにっちもさっちも
• 貧乏だからHDDで始めたけど… SSDにすぐ変えるなんて無理ぽ
• とりあえず商品数の表示なくしていいっスか

だいぶ雑ですが、こういう経験ができるだろうと予想できます。このような経験を、未経験かつ事例も知らない人材が取り組めば、本当に同じような轍を踏むでしょうが、経験済みの職人ならば、企画や機能を見た時点で、企画の変更を提案するなり、設計に工夫を仕込むなりして危険を回避するでしょう。

システムというのは構築するだけなら、簡単とは言わないまでも、そこまで難しいものではないです。システムという生き物に、本番のトラフィックやデータという血を循環させてこそ、その真価を見極めることができます。

また、昔は血の流れは穏やかだったのですが、徐々に血の流量が膨大になってきたり、リリース当初から爆発的に流し込まれたりと、より品質の善し悪しが結果に結びつきやすくなった。という時代的な変化もあり、職人芸の重要性は増しています。

これは別にSQLに限った話ではなく、コーディングの方向性や、開発者数の増加にヤバみを感じたり、色々です。変化する、あるモノの状態に対して、未来を想像してリスクを回避する判断力。または、危険に直面した際の解決力。それが職人芸であり、経験派生がゆえにその人にのみ蓄えられる、見えない技術力です。

人事とかで、何ができるか問われれば、●●言語やXaaS運用など回答できますが、職人芸はなかなかに伝えづらく、聞き取りづらい。一緒に働いてみないとわからない部分のひとつが、もしかしたらこれかもしれません。

職人芸の流動性

この心強い職人芸を持つエンジニアの存在は、もちろん貴重な戦力でありますが、組織の脆弱性にもなりえます。

職人芸が発揮されるその時、様々な思考の元に結論を導き出し、その改善案を反映する。ということが行われるのですが、その結果は目に見えたとしても、経過も残されて共有される、ということはよほど意識的に取り組まなければ成されないでしょう。

仮にそんな貴重なアウトプットを残そうとしても、それを逐一真剣に吸収しようとする人間がどれくらいいるのか、そもそも文書をインプットしても経験には遠く及ばないだろう、と考えると、アウトプットによるその効果が見込みづらく、やはりやらないか、長続きしないものです。

そんな中で職人が転属したり、転職したりすると、職人芸によって保たれていた部分の品質が、思いもよらず劣化することがあります。「このくらい」の『職人芸』が、このシステムには必要なんだけど。と具体的に説明できるものではないので、今・どこに・どのくらいの職人芸が割り振られているのか、を見失うシーンがあります。

引き継ぎが十分でないと、いや、引き継げるものではない部分もあるとしたら、新しく配属された人や残された人は、システムの過去起きた同じ問題に取り組んだり、なぜその部分がそういう風に実装されているのか、を考えて推測して理解しなくてはいけなく、余計なリソースを割く結果が待ち受けることになります。

もしそういう状況が続いたとしたら、組織として全くとは言わないまでも無駄なリソースを消費していて、より全体の技術力を向上させるための足枷になっている、とも考えることができます。

新卒研修だの、講習会だの、師弟制度だの、色々やって成長したとしても、転職します。運用の引き継ぎだけします。では、全体の底上げとは遠い状況であることは間違いありません。

IT業界は特に転職率が高いので、そもそも転職率を抑える施策も大事だと思いますが、私としては、転職して人材が入れ替わっても継続的に底上げできる環境を整備できないか、と感じている今日このごろです。

職人芸の記録

システムの機能構築や改善の成果は、アプリケーションだけじゃなく今だとインフラ関連も、ほぼ全てがコードにて表現されて残っていきます。

そのため、新規開発者はまずはコードを読む。教育として読ませる。という行為は手段の１つとしては正しいですが、運用中のコードはあくまでその時点での優良な成果であるため、経緯や改善の流れといったものは汲み取れるわけではなく、それだけでは不十分であると言えます。一見しただけでは、無駄に？余計な？処理や書き方をしているように感じるコードもあることでしょう。

そういうコードや設定値になった経緯には必ず、障壁や原因・改善理由・改善案、を経た魂が込められているはずで、コード（＋コメント）からそれを汲み取れる必要はないですが、それこそが継承して残していくべき技術であったりします。

私は、十数年間で社内用技術情報には、このブログの何倍も記述し続けていますが、それらの多くは設計・構築手順・運用手順といった結論が主になっています。開発中のボツ案や方針転換の思考、運用における改善案に至る細かい経緯など、を意識的にできるだけ全てを記述していくようになったのは、ここ数年内のことです。

それらを残すことの希望的観測としては、開発中の自身の思考が整理されて、より速く的確なゴールへ向かうことができること。そして他者が見た時に、なぜそのようになっているのか、どのような工夫が組み込まれているのか、などを本人がいなくとも伝わること。がありました。

前者は自身の感覚として、高い効果を得られたと感じていますが、後者はただ残しただけだと誰にどれくらい伝わっているかが不明なので、ちょっと期待する方向が違うかな、という感触でした。

そこで現在取り組んでいるのは、自身の持つ職人芸の適切な記録と、啓発活動です。私はインフラ・SREが役割なので、設計と構築・監視と改善を主に活動しており、SREについてはこのような記録を意識的に行っています。

• どの監視システムを使って
• 概要・URL・ログイン方法 を別途まとめておく
• どのサービスのどのデータを見て
• できればパーマリンク、なければキャプチャやテキスト
• データをどのように解釈して問題点と判断し
• 各データの概要 は別途まとめておく
• どのような改善案を提案し
• どういう手順で反映するか

のような大枠を元に、１つのタスクを１ページにまとめています。誰でもヤル気を出して読めば、経緯から結果まで理解できるだろう内容に仕上げる心積りで記述します。それを吸収してもらえれば、他の人もより課題発見と改善をできるようになったり、設計や構築時点での判断に役立つだろうことを期待するわけです。

こういうのって、ちゃんとしたデータセンターの運営とかだと、それはまぁキッチリした障害報告書を提出してくれたりするんですが、いちエンジニアの日常的なパフォーマンスチェックとかポストモーテムだと、普通はそこまで事細かく記録しないと思うのです。

それでも記録していくと、ちょいちょい汎用的にまとめられそうなテクニックが出てくるので、それは別途カテゴリ分けしてまとめ、それらを技術情報として社内で共有する。経緯と汎用技術の記録と報告、を淡々とし続ける、というのが今現在です。

記録媒体としては、ブログやチャットなど時系列で流れるものは、適していないように思います。なぜなら、長く継承していくつもりの情報だからです。ちょうど、クラウドやミドルウェアなどサイドバードキュメント形式が適していると思っていて、その中でも定期チェックやポストモーテムなどの時系列系をまとめる場所と、汎用的な技術をまとめる場所を分けています。

技術の継承や、全体の技術力底上げを目的とした時に、色んな手法はあると思うのですが、私の経験と性格上は、口頭系の手段は長い目でみると効果が非常に薄いと判断し、まずはテキストでしっかり残す、というところに立ち返ったというわけです。

職人芸の継承

ここまでも結構な労力ですが、これでようやく土台が整っただけです。この土台を元に、どのように職人芸の継承── もっと平たく表現すると、各種技術力の底上げを、効果的にできるのか、を考える必要があります。

少なくとも、確かな技術情報という土台を用意できたとしても、それだけでは自然発生的に目的の達成へ向かうことはほぼない、と考えてよいでしょう。

なのでまずは情報更新を報告する場、が必要です。これはグループチャットで十分です。理想は、そこで質疑応答や議論がカジュアルに発生するとよいですし、改善案に対して改善結果も当然のように報告されると、なおよしでしょう。

様々なジャンルの職人芸が継続的に集まり、空き時間に自然と目を通され、成果や応用が飛び交う── ような環境ができれば、土台整備と文化醸成としては成功したと言えそうです。

その環境に期待することはいくつかありますが── 最たる目的は、組織全体の技術力向上だとし、最もそれを効率的に実現できる方法はどのようなものか考えると、基本的な考え方としては能動的に吸収してもらうことでした。

理由の１つに、ネガティブ面からの脱却があるのですが、先にも述べたとおり私自身は口頭ベースの学習が嫌いなんですね。新人関連はまた別なのですが、それ以降では以下のようなデメリットがあると考えるからです。

• 教える側の人材と、その時間が必要である
• 教える側と教わる側、二人以上の時間を揃える必要がある
• 多人数相手だと、どのくらい効果があったか感じ取りづらい
• 多人数の中で、情報の要不要の濃度に差がでる（参加することに意義はある、とはいえ時間を無駄にはしてほしくない）
• 多人数の中で、能動／受動的かで効果に差がでる
• 教わる側が転職したら何も残らない
• 教える側が転職したら継続できない

それをテキストベースの情報と、チャットベースのコミュニケーションを主軸に置いた時、以下のようなメリットを期待できます。

• 誰も時間の制約を受けない
• 誰でもいつでも情報へのアクセスと編集ができる
• 誰でもいつでも質問と応答、議論ができる
• 学習手段と環境の集約・蓄積・保管ができる
• 能動的な学習を見込める（強制して受動的にはしない）

もちろん継続や整理が難しい、などのデメリットもあげられるんですが、ここで最も重要なのは、いつでも誰でも能動的に学習してもらう点にあります。なぜか。

あらゆる学習や練習において、能動的か受動的かによって、その効率や成果には何倍もの差がハッキリと表れるからです。スケジュールに入れられたから、とか、上長に言われたから、とかで学習しても全然楽しくないし、なかなか吸収もされません。

最低限の能力を身に着けてもらう──なら、それも手段として正しいかも知れませんが、高度な技術や、職人芸という他人の経験を吸収するという段階までくると、能動的な学習でしか、効率的──とか以前にそもそも一定ラインに到達できないだろうと断言できます。

なので乱暴な言い方をすると、身につける姿勢のない人には別に無理に取り組んでもらう必要はなくて、前向きな姿勢の人に能動的に吸収してもらったり質問や提案をしてもらう主体であることが、圧倒的に効率的なんじゃないかと考えます。

これは別に、できない人を切り捨てるという意味ではないです。役割分担として、開発・運用・研究などそれぞれメイン業務に取り組んでいる中で、忙しい・忙しい気がする・デスマなう・モチベが湧かない・やる気MAX！ORIX。いろんな立場や状況がある中で、できれば全員に底上げをしてもらいたいけど、その時点では取り組めない。そういう人がいても後からいくらでも追いつける環境であればよい、ということです。

新卒が伸び盛ってきたから、中途採用で入ったから、転属して業務が変わったから、忙しかったけど時間ができたから。いつでも、誰でも。おとなもこどもも、おねーさんも。

──そういう環境と文化を保ち続ける、ところが最も重要で最も難しいですが、理想なのかなと考えて取り組んでいる只中でありんす:-)