システムをつくるということ
私自身が、新卒一年目・チームの一人のメンバーで権力がなかった頃から、10年以上経過して一事業における開発の責任者をしている今に至るまで、一貫して自分の仕事をどう捉えているか、という話を書きます。仕事をはじめて教育を受けてから、ずっと一貫して思っていることです。最初からこのような言語化をしたかということはともかく、解像度は同じでした。
これは、以下の2つの資料に触発されて書いていますが、これらの資料は読まなくても単独で読めます。
システムをつくるとは、他人の振る舞いを規定すること
私はプロとして働き始めてから6年ほど、いくつかのWebアプリによる業務システムを開発しました。（今も業務システム的なものを開発していますが、ただtoCの要素もあるのでいわゆる「業務」に限らず、またWebアプリだけでもなくて、その後は単に「システム」を作っているというのが正しいと思っています。）
業務システムをつくるにあたって、まず要件定義というものを行っていましたが、この中でユースケースや業務フローというものを作ります。これは、そのシステムにおいて、誰が何を目的としてどのようなことをするのか、ということの定義です。つまり、そのシステムにおいて、誰が何をすることが業務として期待されているのか、ということを規定します。これは、少し強い言い方をすると「人様の仕事を規定する」ということであり、少し弱い言い方をすると「人様の仕事道具を作る」ということです。
「仕事道具」のメンタルモデルから「仕事を規定する」メンタルモデルへ
仕事道具を具体的なモノでイメージすると、飲食店で使われる包丁や鍋、農家で使われる農具、鳶職人のハーネス。もう少し複雑なものであれば、電子レンジ、コンバイン、電動器具。あるいは、高度な医療器具などもそうですね。ただし、実際の仕事道具というのはもう少し抽象的な場合もあります。リモートで講義をするとなれば、zoomのようなものは一種の仕事道具ですが、上記で挙げたような具体的な形のあるものとは若干違いがあります。
zoomはソフトウェアであり、かつリアルタイムで使うので道具というイメージを持ちやすいですが、もっと抽象的、かつ本質が電子的でないようなものもあったりします。より抽象的なものには、例えば住所の管理業務に伴う「転居届」というものがあります。どこに誰が住んでいるか、ということは自治体が管理しています。この管理は一つの仕事ですが、もし転居があれば転居を管理しないといけません。その転居の管理という仕事をする中で必要となるものが、転居届です。転居する人が、自治体に転居届を提出する必要があり、この転居届を受け取った自治体は住民票を書き換えるなどして適切な管理をします。
転居届は自治体が定義しているものであって、広義ではそれ自体が 自治体（など）の定義した仕事の道具 といえます。ただ、この「道具」は時間差で処理されるので、一般的な道具とは若干ニュアンスが異なっているでしょう。
システムをつくるというのは、この例でいえば「転居したときの管理の一連の仕組みをつくる」ということと同じです。あるいは、転居に限らず、「住所管理一連の仕組みをつくる」という方がより正しいかもしれませんが、とにかく「転居届」のみをつくるということではなくて、「転居届を含む転居管理一連の仕組み」こそがシステムである、ということです。
転居の管理の仕組みは、自治体において細かい違いはあるにしても、原則は日本の国の中で同じなので、この根本的なシステムをつくることの影響者は非常に多いです。これぐらい影響者が大きなシステムはどちらかというと少数派で、場合によってはその影響者が一人ということもあるでしょうが、人数によらず、（業務）システムをつくるということの本質は「仕事道具」および「仕事道具を含めた仕事の仕方」＝「仕事をする人の振る舞い方」の規定ということになります。
同じようなことを少し別の角度から話すと、業務システムにおいて、
- （転居届のような帳票も含む）UIの規定はより道具に近い側面で
- 転居届の処理の方法や期日なども含む制度や処理規定はより仕組みに近い側面で
それぞれ仕事を規定する要素になる、とも言えます。この仕事の規定というのは、つまりシステムを通して 他人の振る舞いを規定する ということになります。それは例えば、 業務フローに書いた通りに他人が動く ということなのです。
業務システムの場合には仕事ですが、一般のシステムの場合は「業務」や「仕事」という言い方は必ずしも実態に即していないでしょう。この場合は単に 他人の振る舞いを規定する ということになるかと思います。システムをつくるとは、具体的なUIから仕組み・制度的な部分まで含めて、様々なことで 他人の振る舞いを規定する ことなのです。[1]
目的はまた別である
ここで注意しておきたいのは、他人の振る舞いを規定するというのはあくまでもシステムやそれを構成するソフトウェアの性質であって、システムをつくる目的は必ずしもそこにあるとは限らない、ということです。例えば住所の管理であれば、公共サービスの提供、都市計画の改善、治安の向上、税収の安定といったことが目的であり、システムを通してどう振る舞うかを規定すること自体は必ずしも目的ではありません。
厳密・完璧に規定するわけではない
また、規定には常に範囲や幅があって、厳密・完璧な規定をするわけではない、ということにも注意が必要です。包丁には色々な使い方がありますし、zoomを様々な用途で使えるのと同じように、システムにおいてもそのシステムの許す幅があります。この幅の広さを設計することも、システムをつくるうえで重要なことです。特に、汎用性の高いシステムをつくるためには、意図的に許容する範囲を広く設計するといったことが必要になります。[2]
システムをつくることの影響
他人の振る舞いを規定するということは、つまりシステムを使用する、あるいはシステムに巻き込まれる人全てに対してシステムが影響を与えるということです。そのような一人ひとりへの影響は、時に大きなものとなり得ます。これはtoBの業務システムであっても、toCの消費者向けのシステムであっても、いずれにしてもそうです。システムをつくりそれを運用するということは、システムをつくる人と、それに巻き込まれる人とのある種の対話であり、コミュニケーション なのです。そのような見方をすると、システムをつくるということは本質的に以下のような性質があります。
- システムをつくる人から、そのシステムに巻き込まれる人へのセカンドライン以上のマネジメントに似ている
- 例えばKPIを改善するためにUIを調整するのは、UIを通して利用者をマネジメントしている
- UIに留まらず、ルールや仕組みを変えることも利用者のマネジメントにあたる
- システムをつくることの影響は一方向的、または間接的である
- 開発者との間に直接的な権力勾配はなく、実装者個人は権力がないかもしれないが、それでも行為を一方的に規定する
- 利用者からのフィードバックが可能な場合もあるが、作った人はその時にはすでに居ないかもしれない
システムアーキテクチャの選択は、権力構造的に解釈できる部分も一部にはありますが、実際にはもっと複雑です。例えば、発注者による要件定義がふわっとしていて結果的にイケてないUIのシステムを開発者が作ってしまったときを考えてみます。発注者はある種の権力を持っていますが、実際に実装をするという意味での開発能力はありません。システムの開発者は、実際に開発をする（具体的な実装の詳細を選択する）という意味での「権力」があるかもしれませんが、イケてない実装を意図的に選択したわけではなく、単により良い手段を知らないからそうなってしまうということもあります。このような場合、発注者にも開発者にも本質的な権力はなく、一方で利用者にはもっと権力はありませんが、ただ一連の行為の結果としてイケてないUIが生まれます。
つまり、「偶然そうなってしまう」ことで、結果的に利用者に対して悪い影響を与えてしまうことがあり得る、というような構造があります。もっとわかりやすいのは、システム障害でしょうか。普通は障害が起こりやすい構造を意図的に選ぶことは少ないでしょうが、それでも障害が起こりやすい構造は知識の不足などによって選ばれます。[3]知識がなく、実質的に各人において選択肢がなかった状態であったとしても、問題が発生してしまうということです。[4]
隠れた選択肢を自覚して、事前になるべく知識を拾い、失敗を改善する
では、一開発者として悪影響を与えないようにする、あるいは良い影響を与えるためには、どうすればよいのか。一つは、こうした構造を理解したうえで、自分の行動には常に隠れた他の選択肢がある、ということをまず理解することでしょう。つまり、大前提として、自分はその場でベストと思われる判断をなるべくするが、しかしそれがベストではない可能性を常に考慮するということです。そのためには、まず判断に際してできる限りの知識をつけることが必要です。例えば世間のベストプラクティスを知ることであったり、実際の利用者について対話や観察を通じて深く知ることであったり。
さらに並んで重要なことは、失敗したらそれを改善する、ということです。一度限りのフローであれば別かもしれませんが、システムは一般的に繰り返し利用されます。もし失敗UIや失敗制度を設計してしまったら、それを直せば次の利用からは問題がなくなるということです。もちろん修正が難しい場合もあるのですが、システムをつくるための基本的かつすごく重要なことです。ただ、そうはいっても、知識をみにつけるとか失敗したら改善するとかは、きわめて当たり前のことを言っているかもしれません。ここで一番重要なことは、「隠れた選択肢がそこに存在していて、自分は無自覚にそれを選んでいる可能性が常にある」 ということを自覚することだと思います。これは、自分自身がある種のシステム、あるいはアーキテクチャの中で生きているということを自覚する、という言い方もできます。そりゃあシステムを作っているのですから、当たり前ですよね。[5]
影響を自覚して、そこに至るまでをなるべく手足や箸のように動かす
自分が及ぼしうる影響や、隠れた選択肢の存在を理解したうえで、より重要なことは、その影響に至るまでの要素を 「コントロールまではしなくても手足のように動かす」 ということです。つまり、自分がシステムをつくることを通じて、その利用者に対して影響を与えるとき、間の「変数」がどう動けばどう変わるか。自分が直接的に指示をできる対象が限られているとしても、何かしら自分が力を加えることによって、ピタゴラ装置を操作するように 遠隔的に変えたい結果を変えられないか。それを、より手足や箸を動かすことに近いかたちでできないか。
手足には筋肉があり、電気信号を通じて直接的に動かすことができます。（ただし、十分な練習をしないと、思ったとおりに体を動かすことはできません。）
箸は自分の体ではなく、筋肉もなくて、電気信号を与えることはできません。手の筋肉を通じてある意味で間接的に操作することになりますが、しかし箸を十分に練習した人にとっては、それが間接的であるという感覚にはならないでしょう。
それと同じことを、システムをつくるときに与える影響についてもやる、ということです。具体的にどう動くかという仕組みをイメージして、理想に近い動きをさせようとする。結果的になんらかの動作をするので、それをフィードバックとして改善する。それを繰り返して、システムとして理想的な姿に近づけると同時に、自分自身も影響を操作する能力を身につける。 システムをつくることを仕事にするとは、そういうことです。
むすび
いかがでしたか？
開発者（実装者）や、開発者を経て管理者になった人が書いているシステム開発周辺領域の記事を読むと、しばしば違和感がありました。その違和感がなにかがようやく言語化できて、ソフトウェアを作っているがシステムを作っていないように感じる、ということなのだと思っています。システムを作ることは、他人の振る舞いを規定することであり、それを意図せずやってしまうことに敏感になるのが当たり前で、かつシステム作りを繰り返すならばセカンドライン・サードラインからの「コミュニケーション」も当たり前なのでは、みたいなことでした。[6]そのバランスや前提となる認知が、私の感覚と大きくずれていて、それで今までの違和感があったんだなと納得しています。
この考え方については、その人の能力というよりは、単純に意識しているかしていないかの差の方が大きいと思います。この考えを踏まえてどこまで自責的に動くか（自分が変えられる運命だと思って動くか）、というのは人によるでしょうが、単純にこのような考えの存在を知らなくて、いわゆる視座が上がらないということもあるのかなと思って、この記事をまとめました。
この記事に興味を持っていただけた方には、以下の記事もおすすめです：
-
zoomの場合は、それが何を規定しているのか？と思うかもしれません。zoomはより道具に近い側面が多いですが、それでも例えば、もしzoomに資料を表示する方法がなければユーザーの行動は制限を受けますし、実際にはzoomには資料を表示する方法がありますが、それはzoomのUIに従って為されます。リモートミーティングの場合には一部独特の流儀、例えば冒頭の音声チェック等があると思いますが、それもzoomに伴って規定されてしまっていることの一つと言えるでしょう。絶対にそうしなければならない、という事ではないですが、結果的に誘導されているということです。 ↩︎
-
システムが定める用途の中においては具体的に、システムが定めない用途においては限定をしないように、設計されていることが望ましいと思います。実際に、狭義の道具の場合には、その道具が保証している範囲の外においては一切の限定がありません。 ↩︎
-
システム開発以外の文脈で有名なものでは、フロンによるオゾン層破壊などがあります。フロン自体は、もともと安定で優秀な冷媒としてもてはやされ、冷蔵庫の冷媒による事故を大きく減らしたという実績がありましたが、想定外の上空で大きな問題を引き起こしてしまいました。これは知識の欠如によって発生したことですが、一方で人類が事前に予期することはできなかったでしょう。 ↩︎
-
ちなみに、この状態の「責任」が誰にあるか、ということは非常に難しい話だと思っています。発注者には自身の事業としてそれをやる責任が確実にありますが、とはいえ開発の具体的なノウハウは開発者が保持しているべきです。単純に水準が低いことが問題で、それを改善することが本質だとは思いますが、ではどうすれば改善が行われるようになるのか。私にはまだ答えがありません。 ↩︎
-
広く一般的に、必ずしも直接システムを作る仕事をしていないとしても、仕事をするというのはそういうことだと思います。つまり、世の中というシステムにおいて、その一部として動き、また時にそのシステムを部分的に再設計して、他者に影響を与えて生きるということが、働くということです。 ↩︎
-
うまくできるとは言っていないし、現実の開発者においてそれが当たり前だとも言っていない ↩︎
Discussion