Month: April 2018

「Excelみたいに作ってくれ」という案件が失敗する理由

Excelは悪いソフトではないし、昔から使い込んできただけに、それなりに愛着がある。また、書籍もたくさん書かせてもらって一時はそれで食わせてもらっていたので感謝もしている。しかしながら、Excelの利用技術が結果的におかしな方向に行くのを目の当たりに見てきた。「ネ申エクセル問題」はその集約として非常に良いポイントを突いている。良し悪しを決めつけるのは簡単だが、問題はなぜそのようになり、なぜ是正できないかという分析だろう。「ネ申エクセル問題」としてまとめられた結果、ある領域についての理由と方向性がはっきりしたと言える。

業務システムの開発を請け負っていると、時々、「Excelみたいに作ってくれ」と言われる案件がある。要件がはっきりしていいのじゃないかと思うかもしれないが、これが大きな落とし穴になることもある。なるべく、そのような案件は断るようにしているが、作ってからメンテが大変だったりして、よくよく聞くと、Excelみたいに作ってもらいたかったと思っていたと言うこともあって、顕在化しない場合もある。

ある案件では、これまで、何十人レベルの人たちから毎月Excelのワークシートを提出していたものをWebアプリケーションにして欲しいと言われた。ちょっと複雑な経費精算である。Excelのテンプレートは、おそらく受け入れ側の都合を反映したもので、あまり分かりやすいとは言えないものと感じた。フィールドを全部埋めるのではなく、場合によっては埋まらないフィールドも多く、分類の違うフィールドがずらりと並び、状況によって入力したりしなかったりと言うことを入力者が決めるタイプだ。要するに、第一正規形を満たしていない。

それをそのままWebで作るとしたら、テキストフィールドがずらずら並ぶ。当然ながら、横幅は結構なものになる。状況に応じて必要なフィールドだけを出すようにすれば、スマホでも使えると考え、散々説得したが、「Excelみたいに作ってくれ」というところに常に落ち着く。仕方ないので、「Excelのように見えるだけで動作は違うけどいいでしょうか」と言って、それは納得してもらったはずなのである。

実際にExcelのように作ると言った時、その見かけを2次元セル的にやることと普通は思うかもしれないが、フタを開けると、「Excelのように」が指すポイントが人により異なることが判明した。つまり、これだけの文言では、要求定義にも、要件定義にもなっていない。単なる曖昧な表明にしかなっていないのである。

Webアプリでデータベースだから、レコードを作って入力すると言うのは、あまりに当たり前過ぎることなので、普通に実装したら、「画面を開いたら、最初からワークシートみたいになっているようにして欲しい」と来た。もちろん、そう言うライブラリもあるだろうし、レコードを複数作っておけば済むのだろうけど、ここで受け入れたら、本当にExcelそのものを作らされるのだろうと思って、それはできないと突っぱねた。最初からExcelと同一のものは作れないと言うことは明言し、データベースを利用して作ることも決まっていて、開発費用も決めたので、こちらの裁量がある。こちらとしても、要望が後から来たものは「費用の範囲に収まらない」と言う理由で断れる。そう言うわけで、当然ながら、「レコード追加ボタン」で対応した。

そこで引き下がっていたら、ドラッグしたらコピーするようにとか、式を入れられるようにみたいに要求が留まらないのではと危惧し、前記のような対応を取った。一応、システムは作成でき、想定外のことがあったもののメンテナンス開発でクリアし、今も使用しているようだ。しかしながら、「Excelみたいに〜は要件でもなければ要求でもない」というアンチパターンを実感したと言う意味で、悲喜交々な案件だった。それに、ワークシート的な見え方だと、多分、利用者は保存して添付する手間がないだけで、入力の手間はほとんど変わっていない。保存はないけど、ログインは必要になるので、面倒になったと思う人もいると思う。これは、つまりは今までワークシートを受け取っていた人だけが、集計が楽になるだけという非常に悪い設計の典型のようなシステムでもある。

「ネ申エクセル問題」での大きな教訓は、便利なソフトも使い方によって足かせになると言うことだ。よく、「紙での作業をそのままシステム化しても、効率が上がるわけではない」と言うことも言われる。まさに、ペーパーをExcelに置き換えても同じことが言えるし、それはExcelだけはないだろう。例えば、「LINEみたいなチャット機能もよろしく」みたいな要求は今だといろんな案件で出て来そうだ。しかし、そこで、思考を止めてはいけない。曖昧すぎて、本当に実現したいことが何なのかは、実はそれだけではコミュニケーションできないのである。馴染みのシステムを引き合いに出すのは、要求定義においてはきっかけに過ぎないことを常に意識すべきだろう。

開発の現場では「手法よりも問題解決」が現実

開発の現場で、「手法」を議論する機会が減ってきているように思う。もちろん、自分の身の回りのことが全てではないので、偶然かもしれないが、ブログ等での話題でも、あまり見られなくなっている気がする。以前だと、例えばMVCがどうとか言った話題が華やかだった記憶がある。そして、古くからのさまざまな手法のどれがいいのかと言った話題や、特定の手法をどのように理解すればいいのかといったことが議論された。サイエンス的に考えれば、原理原則があり、それに則った手法は、成功する確率が高くなるということから、以前は手法やアーキテクチャ中心的な考え方もあっただろうし、もちろん、今もそれはなくなってはいない。

現実はどうだろうか？ 色々な手法や原理原則は、１人１人がしっかり学習して現場適用するということも必要なことかもしれないが、「良い手法」はそのものが、すっかりパッケージ化されている。ソフトウェア開発で言えば、フレームワークやライブラリ、あるいは開発ツールで、そうした過去の蓄積が完全にパッケージされており、手法を深く理解しなくても開発を進める上ではあまり問題はない。ともかく、ある「やり方」を採用すれば、難しい原理原則はもちろん、手法の適用までができてしまうのである。Webのサーバーサイドフレームワークは典型的な例だろう。ほとんどのフレームワークはMVC（正確にはJavaEEでのMVC2パターン）であり、よほど変なことしない限りはMVCに基づく役割分担が自然に作り込まれるし、レイヤー化についても気がついたらそうなっているのが一般的だ。もちろん、実装の良し悪しはあるとしても、現場で働く側としては「○○フレームワークでよろしく」の一言で済んでしまう。

そうなると、現場でもっとも注目されるのは何だろうか？ システム開発の現場と、サービスアプリケーションでは色々違うとしても、結果的に、「問題点は何か」ということに注目することが常に行われているのではないだろうか。開発の枠組みは使用フレームワークをはじめとして、結果的に決まってしまうことが多い。要求工学では手段は後から決めるというのが基本ではあるが、現実にはそうでもない。そして、そこではどんな手法を採用するかも概ね決まっている。スタッフが持つ経験をベースに、進行の可能性を検討し、誰かが問題なく進められる部分は、特にフォーカスされない結果となる。一方、誰も作ったことがない仕組み、誰も経験したことがフレームワーク、ある領域で実現できそうにない非機能要求など、「できるかどうか分からない」所に開発タスクとしては目を向けることになる。

では、できないことを、原理原則からボトムアップして、手法を求めるかと言うと、そう言う側面が問題解決に集中しているときはあるかもしれないが、その結果、あるライブラリを使うことで十分に解決されるなら、「ライブラリを使います」と言うことで集約され、問題がさらに絞られる。「チーム全員で手法をまずは勉強します」という結果はかなりハードルが高い。結果的に、問題から始めて、パッケージ化された解決手段で概ね解決し、さらに違う問題にたどり着き、それを繰り返す。問題がほぼなくなれば、一定時間後に完成に進めるということだ。

問題点の解決が現場での主要な話題になり、系統的な手法が議論される素地はほぼない。もちろん、結局のところアジャイルということなのかもしれないが、小さなプロセスでも、大きなプロセスでも同様に言えることではないだろうか。良い悪いはあるとしても、そのように進んでいる。その中で、基本や原理を叫んでも、誰も耳を傾けない。問題を解決する糸口は、まさに原理原則に立ち返ることで手にできるとも言えるのだが、「良い素材はないだろうか」が糸口になってしまうのである。

普段は小規模な開発に関わる機会が多いので、仕様書が渡されないような発注は普通にある。もちろん、大きな会社の発注では仕様書があるものの、非常に高い割合で「仕様書書いている」と言う証拠のためだけの紙の塊でしかないようなことも感じる。設計に役に立たないわけではないが、中身が実装作業に遠いのである。わかり切ったことは簡単に書き、問題点を記述して共有すれば、仕様書はより役に立つのではないだろうか？ サイエンスなので、原理原則があって、それを踏まえた手法があるのは間違い無いのだが、いっそうのこと現実に合わせて「問題解決」にフォーカスした手法に目を向けるべきだと考える。とはいえ、そう言う「手法」を作っても意味はない。手法を否定する手法というのは存在に無理がある。その意味では、アジャイル宣言のように、どんなマインドで対峙すべきなのかをうまく表現しないといけないだろう。ということで、表題のように「手法よりも問題解決」と言ってみた次第だ。今やそういうやり方が一般的というスタンスで、メリットと注意点を検討すべきではないだろうか。

自動運転の実用化に違う方向性はないのだろうか？

次世代の自動運転技術に注目が集まっている。機械学習さらには人工知能の研究を強く牽引する期待が大きく、現実になればより安全な社会が実現するかもしれない。自動車業界は競争状態に入った自動運転技術を捨てるわけには行かないのかもしれないが、色々な業界がこぞって自動運転に目を向けている。一方で、新技術を危険視する向きもあり、自動運転で事故、あるいは死亡事故が発生すると、否定論が強まるなど、世論の関心も強く集めている。

技術そのものについて、「できない」と言ってしまうと、全く前に進めない。ところが「できる」とも言い切れないというのは、そこで「競争に負けた」と思われてしまうということもある。そして技術競争は熾烈になり、「あと何年で実用化」みたいな話はまことしやかに語られる。人工知能の世界でも、シンギュラリティという概念が既知のものであるのと同様、自動運転は近々実用化することになっているのが現在である。一方で、安全をどう確保するのかも大きな問題となっている。

自動運転の死亡事故をきっかけに一瞬、そうした議論が盛り上がったが、今回のアクシデントは偶発的なものと思いたい人たちと、ともかく「怖い」という漠然とした感覚から逃れられない人たちが大勢あることは改めて確認できたと思われる。事故が教訓になっていない漢字はちょっと怖いことでもある。どうすればいいという議論が進まないという点でもある意味怖い。この事故をきっかけに、何か安全性を高める方法はないだろうかと考えた。

自動運転の議論であまり出てこないと思うのが「社会インフラと連動した安全性の確保」だと以前より感じていた。現在、自動車をはじめとして色々な乗り物や人間が公道を安全に移動することができるには「信号」と言ったインフラがあるからだと考えられる。正確には、交通法規が根底にあるのだが、ともかく信号があるから安全でかつ、交通がスムーズに流れることは疑いの余地がない。自動運転にも、こうした社会インフラと連動したことができないだろうかと考えた結果、１つのアイデアが浮かんだ。それは、「舗装道路をスマート化」するということだ。

道路の舗装には、小石を含んだ砂利を利用していると思われるが、小石程度の大きさのIoTデバイスを開発し、一定の密度で舗装道路に含める。もちろん、様々なセンサーを持ち、結果は通行中のデバイスに送られる。熱に強いとか、すごく小さいとか、この『スマート砂利』には技術的な難しさは色々あるだろうが、自動運転よりはるかに容易だと想像できる。こうしたスマート砂利による舗装道路では、進路上に人間が歩いているなどのセンシングを、自動車の前の画像やセンサー等で見つける以上に正確にできることが期待できる。角を曲がった先の道路の状況が分かるかもしれない。

スマート砂利の道路は自動運転でより安全に走れるとしたら、自治体は極力スマート砂利を使った道路工事に切り替えるだろう。なんだか建築・土木系の利権を復活させるような雰囲気はちょっとげんなりするけども、自動運転について、自動車以外のことに目を向けてもいいのではないかとも思う。