#161 「使い勝手」悲喜こもごも
センスではなく思想
こんばんは。こんにちは。
今日は月に一度の株式会社こども会議（仮）二子玉川事業所のリアル会議でした。協賛企業と今後の方向性の打ち合わせで、いくつか課題は出たものの概ね合意に至り、一番大きな課題は想定通り、私のDTMがやりきれるかどうか、ということになりそうです。
この土日で、ココナラにてDTM初心者向けコンサルを2件受け、弩素人がなんとかスタートラインにやっと立てるかな、というところになっております。これから足りない機材を調達するわけですが、肝はやはりDAWというソフトウェア。どれを選ぶかでなんとなく運命が決まりそうな気がしております。一番オーソドックスな老舗ソフトウェアだとYouTubeでも沢山チュートリアルが上がっているのですが、どうやらちょっと重いし遅そうで、老舗ならではの面倒くささもありそうです。もう一つ気になっているのが新進気鋭のソフトウェアで、海外のHipHopシーンから流行り始めたのですが、日本ではあまりメジャーではなく、サポートが不安。しかし他と比較して感覚的に使えそうなところが気になっています。
ともあれ、最後はもうエイヤで決めるしかないので、あと1週間ほど悩んでから決めようと思います。それにしても、編曲の世界、めちゃくちゃ面白そうです。
#ただ今は不安しかない
私は長らくソフトウェアサービスを売る側の立場だったので、こうして真剣に選ぶ側の立場になるのは楽しい経験です。といってもC向け製品は人から営業されるわけではないので、詳しい人のご意見や自分でスペック比較した結果が選択基準の全てになるわけですが、なんとなく最後は「使い勝手」になってしまうところが、自分でも苦笑してしまいます。
ソフトウェアの「使い勝手」をよくすることについて、私は有意義な経験がありません。ソフトウェアなんてすぐに直せるっしょ、と思われがちなのですが、作っているチーム構造や作っているフレームワークやアーキテクチャ、使っている環境によって、使い勝手はおろかちょっとした修正すら難しくなります。私はソフトウェア開発における最上流工程の要求定義しかできないので、後工程の構造の悪さを見つけて改善を提案することができず、本当に歯がゆかったのを思い出します。なので、使い勝手を上回る（というかそこに目が向かないぐらいの）ベネフィットで訴求する能力が異様に高くなったと自負しており、ビジョン実現や組織ガバナンス、費用対効果の定量化で契約を取るということをしておりました。
#良いのか悪いのか
「使い勝手」というのはある意味、慣れる部分がとても大きいです。最初は違和感があっても手技で覚えてしまえばなんてことなかったりするのですが、本当に何度やっても必ず間違えたり先に進めないようなシステムにたまに出会うとげんなりします。
最近、某ネットスーパーのサイトがリニューアルしたのですが、えらくレスポンスが悪くなってしまい、おまけにレスポンスが悪いのが、クリックできていないのかがわからないというだいぶ初歩的な作りになっていて、大いに「使い勝手」が悪くなりました。大手なのでそのうち改善されると思いますが、すぐにレスポンスが返ってくることが当たり前のサービスに慣れているユーザにとっては、オペミスするしかないだろうなと想像し、過多発注が多いんじゃないかな…とぞっとしました。
というわけで、オペレーション数（操作数）の多くなる作業ほど、使い勝手はとても大事です。使い勝手のよいソフトウェアとは、設計者のセンスの有無というより設計マナーの基本だと思っています。ソフトウェア開発が当たり前で、「猫も杓子も開発できる」時代になってきたからこそ、設計思想の基本に忠実になる必要があるんじゃないかなと思ったりしています。多分そんなに難しい話じゃないと思うんですが、そこをおろそかにしてしまうと、後になればなるほど改良するのってすごくすごく大変になるんですよね。私は大変な組織しか見たことがないので、たまに洗練されたソフトウェアを見ると、中を覗いてみたくなります。多分、技術力もさることながら、ソフトウェア開発の哲学が首尾一貫してるんじゃないかなぁと想像しています。
というわけで、今回のDTMにおいては、目的も明確だし期限も決まっていることから、長期目線でメリットが多いもので決めるというよりは、短期目線で使い勝手がしっくりくるもので決めようと思っております。
本ニュースレターのバックナンバーはこちらからご覧いただけます。
🐦 Twitter：@ayakoPizumi
🎧 無限塔の秘密：Spotify / Apple / Google / Amazon
☕️ 活動Link：https://linktr.ee/jediaya