Zenn
💡

ソフトウェアだけではなくワークウェア(Workware)もいかが？

2022/06/22に公開
#
働き方
#
役割
#
workware
#
ワークウェア
idea

サマリー

  • プログラミングでソフトウェアをつくるように、メタワーク（メタワーキング）でワークウェアをつくる
  • SREという新しい役割が生まれたように、ワークウェアをつくるメタワークエンジニアなる職業があっても良いと思う
  • メタワークとは
    • 仕事のための仕事
    • ここでは特にワークウェアをつくること
  • ワークウェアとは
    • 個人や組織の、仕事に関する何かを直接的・間接的に改善する概念や仕組み

メタワークとワークウェア

定義

仕事のための仕事を メタワーク(Metawork) と呼ぶことにする。

メタワークによってつくりだす各種概念や仕組みなどを ワークウェア(Workware) と呼ぶことにする。

ワークウェアの例

例は挙げるときりがないが、いくつか挙げる。

個人レベルでは、

チームレベルでは、

メタワークとは何か（+思い）

見ての通り、ワークウェアとは巷に溢れているものであり、わざわざ名前をつけるまでもないように見える。

問題はこれらワークウェアが 一部の研究者や役職者や有能なチーム、あるいはもの好きが趣味でつくるもの だとみなされている点である。言い方を変えると、「ワークウェアをつくる時間」を設けてつくる、という営為は無いに等しい。そういうことは基本的に許されない（仕事だとみなさない）し、したとしても「いや仕事しろよ」と一蹴されるだろう。チームというものは、基本的に与えられた仕事をこなすことだけに集中する兵隊であり、仕事のやり方をつくるという発想には至れない。あるいは奇跡的に至れたとしても「それは自分たちの仕事じゃない」「自分たちにできることじゃない」と考えて一蹴してしまう。

さて、メタワークとはワークウェアをつくることであり、 ワークウェアをつくることの民主化 を意味している。誰だってメタワークをつくってもいいし、チームにひとりワークウェアエンジニアなる役割と与えて専任させたっていい。VUCA で多様性でリモートな今の時代（余談だが筆者は VUCA + Remote + Diversity = VUCARD ブーカードと呼んでいる）、仕事のやり方なんて変えて当たり前だろう。にもかかわらず、バカ真面目に同じやり方を続けているのは辛くないだろうか。もちろん、だからといってバカみたいにポンポンやり方を変えまくるのも問題だが、それでも「全く変えません」「巷で流行っている "たしかなワークウェア" にしか手を出しません」では、あまりに柔軟性が無いというものだ。その間があってもいい。

筆者はメタワークに焦点が当たりづらい現状をずっと憂いていた。焦点を当てるためにはまず名前が必要、というわけでメタワーク、そしてワークウェアという言葉を整備することにした。

ワークウェアとソフトウェアの関係

ソフトウェアはワークウェアを実装したもの

ワークウェアを形にする方法はいくつかある。

  • 1: 言語化する（手順や解説などドキュメントでまとめるなど）
  • 2: アナログツール化する
  • 3: デジタルツール化する

このうち、ソフトウェアは 3: に相当する。

以下、KPT というワークウェアを例にして、上記3つを比較する。

1: の場合、「KPT はこういうものですよ」「この手順でやりますよ」といったことをドキュメントにする。別にザ・文書というほど形式張ったものである必要はなく、それこそ kpt.md のようなメモでもかまわない。そして、実際に KPT を使う人は、これを読んで（必要なら周囲を巻き込んで）行動する。つくるコストは最もかからないが、使うコストは高い傾向にある（人間が自分たちで運用しなければならないため）。

2: は、たとえばホワイトボードや付箋を使って貼り付けていくような道具が当てはまる。つくるコストと使うコストは両者の間くらい。

3: は CLI でもデスクトップアプリでも SaaS でも何でも良いが、デジタルなツールとして実装されたものが当てはまる。つくるコストは高いが、使うコストは低い（もちろんツールの作り方によってはかえって高くなることもある）。

ワークウェアで妥協する、あるいは試すということ

理想は何でもかんでもソフトウェア化してしまうことだが、つくるコストもあるため現実的ではない。かといってワークウェアを何も考えない、というのも極端である（現在はこれに陥っている・陥っていることに気付いていないチームが多い）。

さて、ワークウェアについて知ることができれば、ここに第三の選択肢を提示できる。

ワークウェアだけつくってみる ことだ。

  • 1: 何もしない
  • 2: ワークウェアだけつくる ★ここ
  • 3: ソフトウェアをつくる（＝ワークウェアもつくっている）

とはいえ、ワークウェアをつくって使うことには強烈な抵抗感がある。自分たちのような取るに足らない一般人がつくった概念を、わざわざ自分たちの手足を動かして使うことになるからだ（弁えと手間のダブルコンボ）。

しかし、恐れることはない。特に個人レベルでワークウェアをつくったり、コマンドラインツールをつくったりする人は珍しくないと思うが、ワークウェアをつくるのもそれらと同じようなものである。ただそれを「目の前の仕事やチーム全般」に当てはめてみるだけだ。抵抗はあるが、難しくはない。

ワークウェアは誰にでも行えるのか

まだわかっていないが、筆者の体感では、

  • 誰にでもできるものではなく、SREのように専用の役割をこしらえる必要はある
    • でも知識を身に付け、訓練をすれば割と誰でもできるようになるとは思う
  • 得意な人と苦手な人に分かれると思う
    • 実行（手を動かして結果を出す）が強い人と、考えることが強い人がいる
    • メタワークは後者の人が得意ではないか
  • 欧米は得意あるいは身近という印象がある
    • たとえば AWS のドキュメントにも「概念」というセクションが設けられていたりする
    • エリン・メイヤーの異文化理解力 曰く、イタリア・フランス・ロシア・スペインあたりが「原理優先」らしいが

まあこの件は、この先メタワークが盛り上がればわかってくるだろう。

ワークウェアの例

より理解を促すため、筆者が最近つくったワークウェアを少し紹介する。

説明と内容の分離

（設計ドキュメントを例にするが）あるドキュメントに「説明」と「設計内容」を混ぜて書くのではなく、「説明用」と「設計内容」とで分けて書くこと。

  • 背景
    • 仕事で AWS を用いたシステムの設計を行っている
    • 「設計書はこれで書け」というテンプレートが指定されている
  • 問題
    • そのテンプレには「アベイラビリティゾーンとは……」のような説明も書かれていた
  • 筆者のメタワーク
    • 「設計書には説明を書くべきではない」と考えた
    • 理由は、
      • AWS の用語は知っていることを前提にすればいいから
      • 説明内容までメンテ対象になるとメンテコストが鬱陶しいから
      • そもそも知りたいのは設計内容だけなので邪魔
    • しかし、うちは初心者（特に技術者・元技術者ではあるが AWS を知らない）が読むことも想定される
      • だったら知らない読者に読ませる用の説明用ドキュメントを別途つくればよい
    • この考え方を扱うために名前をつけよう
    • 設計と内容を分けること、だから「設計と内容の分離」でいいか
    • あ、あとこれを思い出したので、併せて提示すれば説得力が上がるだろう
      • Diátaxis
      • 技術文書フレームワークの一つで四象限で分けている

ミクスチャセパレーティング

前述の「説明と内容の分離」のように、2つの本質が混ざっている事柄を別々に分けること。

  • 背景
    • 2つの本質が混ざっていることが結構多い
    • この混ざっているものを分けること、はそれ自体が立派なワークウェアになる
    • 名付けよう
    • → Mixutre Separating としてみた

詳細は筆者のScrapboxを参照。 → ミクスチャセパレーティング - stakiran研究所

以下でも（聞けば「それ知ってる」という人も多いであろう）ものを少しだけ取り上げておく。

  • 印象と内容の分離
    • プレゼンと情報伝達は同時には取れないことが知られている
    • なのに両方を欲張る悪習がある
      • slide + document で「スライデュメント」と呼ばれる
      • （中々上手いワークウェアだと思う）
    • 訴求したいならプレゼンに徹するべきだし、情報を伝えたいならドキュメントに徹するべき
  • 内容と形式の分離
    • Word などリッチテキストは文書作成効率が悪い
    • なぜかというと、文書の中身と見せ方の両方を同時に相手にしているから
    • 本質は中身であり、見せ方はその後で良い
    • いわゆるマークアップ言語はこれである
      • Markdown もまさに
  • 蓄積と処理の分離
    • タスクを「目に入ったらすぐに」処理する人がいる
      • 言われたことをとにかくすぐに済ませようとするとか
      • 通知が目に入ったからとりあえず開くとか
    • しかし、それでは自分の集中が阻害されてしまう
    • タスクは間に合うタイミングでやりさえすればよく、目に入ったら今すぐにやる必要などない
    • より賢いやり方は色々あるが、たとえば以下
      • 「タスクはまず溜める」、そしてそれをきりのいいタイミングで「まとめて処理する」
    • これは「タスクを蓄積すること」と「蓄積したものの処理」を分けている
    • 例: メール（チャットでもいい）は1日3回、朝と昼と夕方だけ見る
      • もちろん人によってはこれでは回らないが

エキスプレイニング

自分の想定する説明の仕方と分量すべてを一方的に押し付けてくること。

  • Expart（熟練者、ベテラン、経験者、詳しい人 etc）が新人や参加者に対して行うことが多い
  • 名前は Expart + Explaining から来ている（マンスプレイニングも意識している）
  • 例: 質疑応答で質問者「Aとはなんですか？」と聞いてるのに、回答者が「Aは～～です。それから～～。ちなみに～～」のような過剰説明する
    • 「もういいです」という沈黙の合図を受け取らず、追加説明を入れてくる
    • 下手すると、ハッキリ断ったのに続けてくる人もいる

筆者はまだこの言葉を使ったことはないが、エキスプレイニングは決して小さな問題ではないと思っている。教えられる側や教えを請う側はどうしても立場が弱くなるが、だからといって相手の傲慢や無駄に長々と付き合い耐えていい理由にはならないのだ。この現状を変えるためには問題意識を持ってもらう必要があり、そのためには言葉が要る。というわけで、ひねりだしてみた。

※ ……というのは嘘で、本当は単にそういう人がムカつくから何とかしたいと昇華していただけである。昇華というと「うっぷんを創作にあてる」イメージがあるかもしれないが、筆者はメタワークにあてることが多い。プログラミングはしばしば不満（特に非効率や無駄を自動化したい等）から行われるものだが、メタワークも同様である。

Alnumark

アルファベットと数字と記号のこと。

  • 名前は Alphabet + Number + Mark から来ている
  • パスワードやランダム文字列生成などの文脈で「アルファベットと数字と記号」を示す言葉が欲しかったのでつくった
  • alphanumeric(alnum) という英単語がヒントになった
    • プログラミングや正規表現でも alnum という名前が出てくる（アルファベット+数字の意）

おわりに

ワークウェア（とそれをつくるメタワーク）について紹介した。

ワークウェアエンジニアという役割が生まれるほど盛り上がったらいいなと思う。あるいは願望かもしれない。筆者はせこせこ手を動かして結果を出すのが苦手で、エンジニアとしてはせいぜい平凡だから別の道を模索しており、メタワークならいけるのではないかと考えている。極めて私的な理由だが、最初はそんなものだろう。

メタワークには、私達をもう一段グレードアップさせるだけのポテンシャルがあると私は確信しているし、自ら証明したい。

GitHubで編集を提案

Discussion