ITシステムには目的がお役所的なモノからゲームまで様々あり、日頃から触れる中には扱いづらいとか体感が悪い、といったイマイチな品質の存在を感じることがあります。
これは常識的に考えてこうなってれば嬉しい、という最低限の品質を超えていれば良いとも言えるところで、その常識について軽く掘り下げてみる次第です。
目次
常識的な品質とは
テキストが読みづらい・データの入力や操作がしづらい・無駄に感じる作業や待機時間がある、といった不満はシステムのリリース初期によく見られるモノで、多くは徐々に改善されてまともなサービスになっていきます。こういった悪い品質のほとんどは端的に表すと『扱いづらさ』と表現できます。扱いづらさを感じつつも利用しているうちに、そのストレスが積み重なり、次第に利用する継続力が失われていくので、些細なポイントでも初期の感想や長い目で見た体感に大きな影響があるとして取り組むべきです。
ITシステムにおける『扱いやすさ』にはある程度の『常識』なツクリが確かに存在します。なにかしらでイマイチと感じた時に、「こうなってればいいのにな」と思いつつ進行する想いがソレであり、ソレは人の経験してきたモノによって・時代の移り変わりによって、それなりの幅で異なるものです。
使う人によって常識は異なるし、作る人の常識も異なるし、開発チーム内でも差がある中でも、「平均的に」「普通に考えて」こうなってた方がイィに決まってるでしょ。って感覚のバランスを誰かもしくは数人で取る必要があり、できなければ仕上がりが凸凹になって悪いパーツがそのままエンドユーザーにまで届くことになるでしょう。
品質の効果
さきほどのを逆にすると、テキストの装飾や行間調整によって読みやすい・直感で理解しやすい・複数データを一括操作できる・リクエストやデータ転送量に無駄がなくサクサク体感など。良くデキているシステムは１つ１つが良好もしくは最低限を満たしたモノの集合体となっています。システムを使うというエネルギーを消費する中でも、その多くの作業にストレスを感じづらいことでメインのコンテンツに集中することができるので、無駄なく効率的に利用できた／楽しめた、といった好感触に変換されることでしょう。
各パーツの仕上がり度合いを分類するとして、
- (優) よく仕上がってるね
- (良) 十分なデキだね
- (可) 少し改善の余地があるね
- (不可) そうはならんやろ
基本的な品質の差は＜作業回数＞＜消費時間＞＜利用頻度＞＜ユーザー数＞あたりを乗算する形であらわれるので、１つ１つの小さな差がユーザーの体感に影響し、そのユーザー合計は何万何億の回数／秒数の差となりシステム評価となって返ります。
システムにとても優れた仕組みがあればもちろん素晴らしいですが、システムの完成度という意味では突出した良さよりもまずは全てが十分なデキで穴がないことが肝要です。悪い部分がほぼ無いという仕上がりが「突出して良い」という１つの評価になると表現しても良いくらいで、昨今の複雑化したITシステムの全てにおいてそれを実現するのはなかなかに骨が折れるところです。
システムのセンスとは
じゃあシステムを常識レベル以上には仕上げたいよねってなった時、そのレベル感とはなんぞやって話になります。今の時代なら、デザインの基礎とかコーディングの基礎みたいな書籍類はいくらでもあるので、そういうのを共有・学習した上で、それを当たり前という常識にするのは良いかもしれません。ただ、ITシステムの成果物は、数学のように式があって数値の解がでる、ようなモノではなくて、自由な組み合わせと選択による『アート』な色合いも強いです。よって、知識として常識の概念を共有したとしても、そこから捻り出されるアウトプットには個別の『センス』が必要になります。視覚的な UI/UX から始まり、内部的なシステムのツクリまで全てが対象の話です。
日々、様々なITシステムを利用したり、業務としてシステムづくりをしていれば、少なくとも『常識的な品質のセンス』は育ちそうなものですが、意外とそうではなかったりします。それは、「機能を作る」ことと「扱いやすさを考慮する」ことは、そこそこ別な能力になるからです。
自身で「こういう機能を実装するか」または設計者により「こういう機能を実装してください」となった時、その機能が完成した時点で「達成」とする場面は少なくありません。そこから先の、「これは扱いやすいか」「より扱いやすくできないか」という考察と改善までを本来セットとするべきところを、初手の成果物をそのままに進行してしまうのは、『センス』が足りないからです。
この『センス』という表現はふんわりポエム感が強くてアレですが、ことIT業界におけるセンスは、芸術やスポーツといった少なからず競争要素のある分野と異なり、比較的に磨きやすさがあると考えます。システムの提供はビジネス視点では競争ではありますが、システムの制作における部分部分の品質は競争思考ではなく『こだわり』思考だからです。それがどうあるべきなのか、どうなれば喜ばれるのか、という視点が重要になります。
つまり、「作り手」が「使い手」のことを考えるだけでよい、というシンプルな意味になります。あらゆるシステムは必ず、自身を含む「誰か」のために作成されます。エンドユーザーのために UI/UX を良くすること、複数人でコーディングするために理解しやすく柔軟なコードにすること、インフラ環境を運用しやすく他環境でも使いまわしやすくすること、情報を不足なく読みやすく整理すること。
自身の目の前のアウトプットに対して常に、「使う人が扱いやすいか」「使い続けてもらえるか」を現在から未来の変化に対して考察して改善しようとする思考こそが、ITシステム制作における『センス』ではないかと思います。
センスを鍛える
使い手のことを考えるというのは、善行というよりは、どちらかというと「行動の読み」とか「先回り」的な行為の色が強いです。それを行うために最も重要なのは、「自身が利用者であること」で、目の前のシステムに対して『エアプ』はダメ。ゼッタイです。悪いセンスにはいくつも例がありますが、本ブログの読者層はITエンジニアなので、おそらく全共通になるだろう【ログ】をテーマに例示してみましょう。例えば、こういうログを見たことないでしょうか。
- グループチャットに通知されるログが JSON 型で成形なしの１行である
- 複数行のトレース含むエラーログが CloudWatch Logs に１行１イベントとして保存される
- ログレベルを環境変数や設定で管理できず、本番でも INFO 以上が記録される
どのような状況か想像できたでしょうか。これらは「見づらい」「要点を探しづらい」「不要な情報を含む」といった悪しきモノで、改善の方針としては、「必要な情報に絞る」「エラー管理サービスを利用する」を基準に、運用に入る前の構築時点で整理整頓できているべきモノであり私の『常識』です。
ログってやつは重要度が高いわりに、その状態にはおざなりに済ませてしまう場面が多いものです。確かに記録されないよりは記録された方がマシですが、「ログが記録される」という結果で止まってしまい、「有効活用し続けられるか」まで考察して改善されることは案外少なく、少し考えれば「記録された方がマシ」というだけの結論には絶対になりません。
ログに限らず全てにおいて、「扱いやすさ」が考慮されていない場合、
- 制作者がその結果の質に問題がないと判断するレベル感
- 成果を見た人も何も感じなかったか、感じても改善の指摘をしていない、できない環境
- 誰も常識的な品質基準を知らないのである
システムのどんな細かいあらゆる成果物も１つ１つを、まずは当人がそれがベストに近いかを疑い、他者もそれを疑い指摘できることが理想です。ある機能やあるアウトプットがデキたよやったね！で終わるのは全くの不十分で、じゃあそれは最も使いやすくなっているのか・条件変化や時間経過によって質が低下しないか、といったことを自問自答し続けることで優良なシステムにしていくのです。
それが続けば、初手で少しイマイチだった実力は、初手で十分な仕上げになり、さらに続けていれば初手で不満なく好評な仕上げをできるようになり、時には突出して高品質な結果を生み出せるようになります。そして、周囲にも当たり前のレベル感を引き上げる所作を求められ、それが出来る頃にはお賃金もまずまずな感じになっていることでしょう。
自身が構築したモノには甘美なところがあり、初手そのまま満足感と共に貫きたい気持ちが再考察を妨げることがありますが、この自由形のシステム作りにおいて多くの成果を初手ベストにできるわけもなく、常により良い調整・複数の選択肢・他の方針を疑った上で進む、という姿勢が『センス』を鍛える要因になると考えられます。
センス＝常識ではない
補足しておきたいところとしては、本件は「常識的に考えて在るべき以上の姿」を作るためには『センス』が必要という話であって、個々人の『センス』がイコール『常識』ではない、ということです。チームが組まれたり、人材が入れ替わったりすることで、『センス』には凸凹が必ず存在します。目的は良好なシステム提供であり、最低限の品質を保つことと、平均レベルを徐々に上げていくことにあるので、誰かのセンスを振りかざすことに意味はありません。「常識的に考えてこうあるべきだろう」というのはあくまで考察であって、態度ではないということです。
『センス』によって作成された成果物には少なからずプライドを含むので、他者の考察や成果物に対して評価・指摘するということは、他者のセンスを否定するという意味に近いものがあります。
指摘される側は悪く言えば傷つく・ストレスがかかることになるので、指摘する側は互いのセンスを衝突させに行く行為であると理解したコミュニケーションにすることが重要ですし、指摘される側も有用な事実だけを汲み取り無駄に傷つく要因にはフィルタリングするのが望ましいです。
時に ITエンジニアという人種は偏屈でマウント取りたがりな場合があるので、頭では「常識的に考えてこうだろう」と考えつつも、事実として状態がこうで効果がこうなので、こう変更するとこういう理由でこのくらい効果が良くなるだろう、という風に Before/After を整理して伝えられると良いかもしれません。
おわりに
ITシステムの制作においては、「こういう機能を」「こういう仕様・内容で」作りましょう、となった時に、それを「こういう品質で」作りましょうとまで指示することは難しいです。初手はある程度を個人技で仕上げ、そこから徐々にチーム内でそのシステムにあるべき品質へと磨かれていきます。最近なら、AI を利用することで見やすさや使いやすさを、それなりの結果へと導くことはできなくもないですが、60～70点を出させることはできても、その先に目指す 85～95点は人間のセンスで補わざるを得ないという現実は、なかなか変わるものではないはずです。
いつかは、多くのインプットと経験を積んだ人間よりも、AI の方が優秀になる可能性はあるとはいえ、入り組んだシステムの細かい部分１つ１つまでそれに頼ることができるのか、頼るべきかは予想できないところです。
なにより、最低限の品質維持だろうと、最高峰の品質開発だろうと、【神は細部に宿る】の精神はモノづくりにおける真髄の１つです。
『常識』という名の『センス』を磨くところから始まり、少しずつ高いレベルを目指すという楽しさ・達成感こそが本質的なところでもあるので、自他ともにそうであるための環境・文化づくりを大切にしていきたいと思う今日このごろです:-)
