ソフトウェア開発にはウォーターフォールやアジャイルといった開発手法がありました。同様のものを SSE でも整備しておいた方が便利でしょう。
以降では開発手法を二点紹介したいですが、その前に、本章ではソフトスキル開発の典型的な流れと、そもそも「ソフトスキル開発」とはどういうことかを整理します。
まずソフトスキル開発とは何かを定義します。
第二章までで、以下三点を強調しました。
これを踏まえて定義しましょう。
ソフトスキル開発とは 概念をつくって、第三者にわかりやすく提出すること を指します。実は似た言葉があって、『知的生産の技術(1969)』の著者、梅棹は「知的生産」について次のように述べています。
かんたんにいえば、知的生産というのは、頭をはたらかせて、なにかあたらしいことがら――情報――を、ひとにわかるかたちで提出することなのだ。
私は知的生産と SSE は同義だと考えていますが、知的生産という言葉では今に至るまで整備されてきませんでした。50 年も前の話ですし、知的生産という言葉自体が広域すぎるので無理もありません。
話を戻して、ソフトスキル開発は次の三点をすべて満たす必要があります。
特に第三者向けの表現と提出が必須です。
SSE では第三者が理解できるほど言語化されていないものを 観念 と呼びます。いわゆる非言語情報はすべて観念となります。身振り手振りや表情、容姿や権力やその他ステータス、イラストなどに逃げては行けません。必ず言語で表現しなければなりません。言語で表現できて、はじめて概念と呼ぶことができるのです。
もう一つ、そうして表現した概念は提出しなければなりません。提出というと二者間の手渡しを思い浮かべるかもしれませんが、これに限りません。ファイルサーバーやクラウドストレージに置いて関係者がアクセスできるようにしたり、インターネット上に公開してアクセスできるようにしたりといったことも含みます。しかし 提出先が持続的に入手できる必要があります。具体的には、概念を記述したファイルやテキストを渡すか、あるいは公開していつでもアクセスできるようにするかの二択です。直接渡さないとか、ダウンロード不可能の公開物を 3 日で公開停止するといったことは提出とは言えません。
大胆に言えば、概念はオープンなものです。そもそも概念は抽象的か、具体的であっても秘密的ではありません。理想を言えば、インターネット上でフルオープンできるものであってほしいのです。このようにいつでも誰でもアクセスできるレベルで公開できる性質を 開放性 と呼びます。開放性を伴うことを開放的と呼びます。
以上を踏まえると、ソフトスキル開発は次のように言い直せます。
ソフトスキル開発とは概念を言語的に、かつ開放的に提出できるように表現すること である。
ちなみに開発対象としてソフトスキル・ツリーも含みますが、ツリーは必須ではありません。たとえば私は社員全員がいつでも誰でも誰とでも 1on1 できるあり方「Free 1on1」と開発しましたが、ここにツリーは含んでいません。別に含んでも良いです。たとえば以下のようなツリーを同梱してもいいでしょう。
ソフトスキル開発 ではないこと も取り上げておきましょう:
それぞれ運用また提出と呼びます。開発ではありません。あくまでも開発の段階では提出可能にしておく（できれば運用可能にもしておきたい）だけです。
そういう意味で、ソフトスキル開発の全体的な流れは 開発 → 提出 → 運用 となります。
例外的に、よほど秘密裏に進めたい場合は「開発 → 一時提出 → 運用」もありえますが、SSE では――少なく本書では想定しません。すでに述べたとおり、SSE において概念とはオープンなものです。
なぜ概念はオープンであるべきなのでしょうか。これは意図的です。SSE を整備した私が、意図的にそうしています。
理由はシンプルで、持続的に盛り上げたいからです。インターネットやオープンソースなど、オープンであることの価値は言うまでもありません。
また SSE では言語を書いて、言語を読むことで、人間が自ら動かねばなりません。読み書きの営みは避けられず、したがって読み書きに慣れてもらわねばなりません。そういう意味でも、開発した概念はなるべく広く流通させて、少しでも多くの人の目に触れるようにしたいのです。
古い話になりますが、2000 年代のインターネットはテキスト文化でした。SNS やスマホが登場する前の話です。ブログのトラックバックがそうであるように、誰かが書いたテキストをおもちゃにして、別の誰かがさらに書いていました。そうして思い思いに書いて公開することで盛り上がっていきました。読み書きは地味ですし、負担も高い行為ですので、実は モチベーションが非常に重要なのです。ここをカバーするには、色んな情報が溢れているというセレンディピティと、自分の情報が使われるという相互性の両方が必要です。この両方が起こるだけのポテンシャルを、SSE は備えなくてはならないのです。
と、小難しく書きましたが、インターネットやオープンソースをご存知の方は「そのパワーを使うためです」との一言で理解できるはずです。
ソフトスキル開発の定義をしました。また全体的な流れが「開発 → 提出 → 運用」であることも述べました。
次に、もう少し具体的な流れを述べたいです。
ABCD ウォーク と呼ばせてください。これはソフトスキルを開発、提出、運用するまでの一連の流れを、4 つのモードで整理したものです:
わかりやすく並び替えると、次のようになるでしょう:
開発者向けにたとえると、現状の理解は予備調査に相当します。問題の定義は要件定義に相当します。概念の収集は開発に相当します。新しくつくるだけでなく、既存のものを使ったり修正したりもします。開発でもライブラリを使いますよね。そして行動の実践とは開発以降の全作業を指します。
「開発 → 提出 → 運用」を紐づけるとしたら、次のようになります:
| ABCDウォーク | Dev-Sub-Ops |
|---|---|
| Breakdown | - |
| Definition | - |
| Collection | 開発 |
| Action | 開発、提出、運用 |
Collection が担うのは概念という部品を集めるところまでです。集めたあと、最終的にどう整備するかは次の Action の範疇になります。また Action は開発後の提出や運用もすべて含みます。そういう意味で、Action は非常に広域です。
なぜ広域かというと、Action の段階では純粋なソフトスキル・エンジニアリング以外の事情が大きく絡んでくるから です。早い話、その人その組織の文脈があるはずで、文脈に則って進めるためには相応の権力、政治、時には運が要求されます。SSE はそうした部分は扱いたくないのです。というより、その部分はすでに人類が開拓しているため、改めて扱う意義が薄い。
SSE のフォーカスは Action 以外のモードです。Breakdown、Definition、Collection ですね。つまり現状を理解して、問題を定義して、それを解くための概念を集めるところまでです。
ここまで述べてきたとおり、ソフトスキルのエンジニアリングは人を扱うものであり、従って本質的に正解がありません。重要なのはできる限りの創造性を動員して概念をつくり、わかりやすく使えるように整えることです。その先の Action は、できる人がやればいいし、すでに開拓されているように泥臭い営みにすぎません。
SSE が真に扱いたいのは、Action の前段階の、非常に創造的で難しい営みです。ここに再現性を持たせる――は言い過ぎですが、比較的誰でもこなせるよう、少しでも確率を上げられるよう整備したいのです。
最後に ABCD ウォークの「ウォーク」について説明しておきます。
これはランダムウォークのウォークと考えて差し支えありません。つまり A、B、C、D を自由に行き来する ことを指します。別の言い方をすると、サイクルやループではないということです。
ですのでウォーターフォールのように順に行うものではないですし、アジャイルのようにサイクルを回すものでもない。もっと自由で探索的なものです。
ソフトスキル開発:
ABCD ウォーク: