チームの善性は製品の善性に降り注ぐ

就職して1年。日々ソフトウエアの品質と闘っています。

品質というのは厄介で、一朝一夕には変わりません。開発者はいい仕事をして良い製品を作るべきであって、そのために何が必要なんだろう？何をしなければいけないのだろう？良い製品とは何だろう？という問いに、常々立ち戻らなくてはいけないようです。

ソフトウエアを製造するのは開発者です。今どきのソフトウエアは一人では作れないようなサイズなので、たいていチームで動くことになります。

チームというのは意外に脆い枠組みです。最近は開発者のチームと製造後のソフトウエアの運用を担うチームの距離感を縮めるのがトレンド（DevOpsといいます）ですが、これはチームの責任範囲を広げることでもあります。チームの目的が曖昧であればあるほど、個人の裁量と責任が大きくなります。

自由ソフトウエアと職業倫理

一般的な専門職と同様に、ソフトウエア開発者にも職業倫理があります。例えば、自他の資産に損害をもたらすようなソフトウエアは作れますが作りません。

職業倫理について厄介なのは、いくつもの流派があること、すべてが明文化されているわけではないこと、この倫理を知らなくても開発者にはなれるということです。

自由ソフトウエアという考え方があります。
自由ソフトウエアそのものについては、リンク先のWikipediaの記事を読んでいただくとして、ここではこの考え方に同調する開発者は自由であること（＝ソフトウエアが公開されていて、その全てを制御できる権利を持っていること）を大事にしていると理解してください。

この自由ソフトウエアというのは、資本主義の経済活動と非常に相性が悪いです。なぜなら自由ソフトウエアはふつう無料で公開されていて、知識がある人なら誰でも利用可能だからです。

自由ソフトウエアを売ってお金を稼ぐ商売は儲かりません。
結局、現実の経済活動上は、ソフトウエアの一部や全部が不自由であることを受け入れていることがほとんどです。

同じ理由で、自由ソフトウエアだけを作って生活できる開発者は多くありません。大部分の開発者は、たとえ自由の思想に共感していても、仕事として不自由なソフトウエアを作らなくてはいけないのです。
もちろん、私もその一人です。

技能と正しさ

できる仕事、やりたい仕事、やらなくてはいけない仕事がそれぞれズレていることはよく起こります。

ことソフトウエアについては、要求された製品を要求通り作れるかどうかは、実は本当に作ってみるまでわかりません。「それ、作れますよ」という約束は危険な口約束でしかないのです。
本当に作れるのか見極めるために完璧な見積もりを取ろうとすると、実際にその製品を作るのと同じだけのコストがかかるということです。

ただ技術者というのはものを作るのが好きで技術者をやっていますし、自分にはできないということをなかなか認められない生き物でもあります。つい、「作れますよ」と約束してしまうのです。

このこと自体は一概に悪いことではありません。技術者は自分の技能を超えた課題を解決するために試行錯誤を繰り返すことで成長するからです。

問題はそれで出来上がった製品の方です。頑張って作った、ちょっと出来は悪いけど一応は動いている製品が他者の手に渡ること。
果たしてその製品は正しく動くのでしょうか？

存在しないことの証明

ソフトウエアにバグがあることを証明するのは簡単です。実際にそのバグを引き起こして見せればいいのです（業界では「再現する」といいます）。

逆に、あるソフトウエアにバグがないことを証明するのは不可能であることが知られています。なんのアプリにしろ、そこにあるのは、バグがあるかもしれないソフトウエアなのです。

正しさ

では、仮にバグがまったくないソフトウエアを実現できたとして、それは正しく動くソフトウエアでしょうか？

ソフトウエアの正しさは、その挙動が使用者の期待通りかどうかで決まることがほとんどです。ソフトウエアはコピーされてたくさんの使用者に実行されるので、その期待は一通りに定まりません。

特に機能が枝葉になればなるほど、期待の輪郭がぼやけてきます。

この記事をお読みの方は、LINEアプリにメッセージが送れることを期待しているでしょう。通話ができることも期待していると思います。
では、FX取引やポイントカード管理を期待されている方は、どのくらいおられるでしょうか？
LINEのFX取引は、他のFXアプリと比べてどのような特徴を備えているべきでしょうか？

ソフトウエアが成熟していくと、どうすれば開発者の手によって世界をより良くできるのか、という質問に答えるのが難しくなります。

善性

大きなチーム、大きな責任。不自由なソフトウエア、曖昧な期待。
しかし製品は売り上げをあげなくてはいけず、我々も日銭を稼がなければいけません。

悪く言えば、何かと理由をつけてソフトウエアを書き換え続けなければ、開発者はご飯にありつけなくなるということです。
どんな理由に依るかについて考えることは別の機会に譲るとして、ここではどのように書き換えるかに注目します。

われわれは資本主義社会にいて、この書き換えはソフトウエアの資産価値を増やす方向に行われなければなりません。つまりソフトウエアの挙動をより正しくすること、 すなわち使用者の期待通りに近づけること、です。

期待は表現できない

使用者は、まだ見たことがない製品を正しく表現できない。このことは開発者よりも実業家に有名な話です。
馬車社会では、速く走る馬が欲しい人はいても、自動車が欲しい人はいない（実際には自動車の方が提供できる価値が大きいのに）、という例えでよく説明されます。

使用者の期待に沿うものを開発するのが開発者の使命ですが、同時に、言われたものをそのまま作っていてはいけないのです。
使用者の期待の表象をよく見極めて、うまく表現されていなかったが本当に必要だったものを作る、それがソフトウエアエンジニアリングの醍醐味です。

正しさを探す

使用者の真の期待＝正しさを使用者自身が表現できないなら、開発者が観察をもって想像していくしかありません。
ソフトウエアエンジニアというといつもコードを書いているように思われがちですが、私の場合はほとんど（体感8割くらい）の時間を正しさと向き合うために使っています。

小さなソフトウエア、あるいは強力なオーナーシップによって開発されるソフトウエアであれば、この正しさは開発者の正義によってもたらされます。
お客さんはこの機能が必要に違いない、必ず売れる、というやつです。

大きなソフトウエアになって分業が進み、使用者からの期待が曖昧になると、正しさは開発者の善性によってもたらされるようになります。
正義の力が届かなくなり、設計者の善性と、開発者の善性が手を取り合って製品の正しさを作ります。開発に関わるメンバーが、その製品がどうあるべきかを理解している状態です。

決してどちらかが優れているわけではありません。ソフトウエアのサイズを大小に分けるのは軽率で、実際は状況が入り混じります。製品のサイズにチームが追いつけず、あべこべになっていることも多々あります。

チームの善性

大きなソフトウエアの正しさを守る善性をどう育めばいいか、これが今の私の抱えている課題です。誰か一人が正義を発揮して全ての方向性を決めるのは難しくないですが、それではチームは成長しないのです。個人の裁量と責任が大きなチームであることを認めなくてはならないのですから。

善性と正義の違いについても触れておきましょう。善性は人（ここではチームも）が持っている善なる性質を、正義は規範（＝正しさ）の遵守を、それぞれ指しています。正義には強制力がありますが、善そのものは実現すべき目標であり、善性を持つこと・それを発揮することは強制されるものではありません。

（私は哲学をちゃんとやっているわけではないので、大間違いがあったら教えてください）

善性を持つことが強制されないことは、マネジメント上の問題になりえます。抱いている期待が違うように、それぞれが持っている善性が違い、そんなメンバーを組み合わせて正しさを追求するのです。この問いは組織計画でよく触れられるので、ここであえて取り立てて扱うことはしません。

製品の善性

もう一つの問題は、チームの善性が製品を正しい方向へ導けるかどうかです。

チームの善性、いわゆる開発方針は、正しさとお互いに影響を及ぼします。製品が実現するべき正しさは、社会規範の正しさよりもずっと早く移り変わるので、メンバーの善性、チームの善性が、正しさと同じ方向を向いているかどうか、常に確認し続けなくてはいけません。

この作業を怠って、善性と正しさがズレてくると、いいものを作っているはずなのに受け入れられないという悲しい状況になります。これはよくある状況でもあります。

この正しさが法律や規定によって強制されるものであれば話が早いのですが、そうはいかない場合も多くあります。

開発者はよく「いいものを作れば売れる」という幻想に囚われています。この幻想がチームを支配していて、善性が正しさを含めていないとき、どんなに頑張っても前にも後ろにも進めないという状況になります。

正しさを包む善性が製品の善性です。誰か一人によって規定されるものではありません（あるいは、規定されこそすれ全てが網羅されることはありません）。顧客と開発者の間の関係性によって、製品の善性はかたち作られます。

チームと製品の関係性

foolproof という考え方があります。顧客は開発者が想定していないように製品を使うので、製品はどんな想定外にも対応できるようにしておかなければならない、という考え方です。

想定外を許すことは、長く使われる拡張可能な製品の特性です。正しさからはみ出すような想定外の用法をされた時、チームはそのことに気付けるかどうか。

そして、新しい正しさに基づいて善性を書き換えることができるかどうか。
それができるチームをどうやって作っていくか。

相互の関係性を見極めつつ、正しさと善性を比較して書き換えていく。

形がないソフトウエアを作っているからこそ、形がないままに向き合っていかなくてはいけない難しさ。

毎日のように悩んでこそいますが、これが、ソフトウエア屋として働く楽しさだったりもします。