非機能要件を軽視する人が多すぎる
今日はITのお話です。というかぼやきです。
いつもと違う趣向の内容で、長いし写真もありません。
興味があればご一読ください。
でも本職の人じゃないと面白くないだろうなぁ。
ITの専門用語に非機能要件というものがあります。
ITの用語の割には全部漢字って珍しいかもしれません。
英語ではNon-functional requirement とか NFR とか表現しますが、国内では上記の漢字五文字が主流です。
個人的にはこの名前の付け方はダメだなと思います。
「機能に非ず」
なんとなくその他のどーでもよいものという印象を与えてないか？
機能要件は重視されるのに非機能要件は軽視されてしまうのです。
「非機能要件」のリンクも載せておきます。
読まなくてもいいです。いきなり読んでもわからんと思います。
非機能要件を一言で言うと
なかなか一言で言うのは難しい。
的確にこれ！と指し示しづらいものなのです。いろんな要素があるから。
それでも無理やり一言で言うと、「ITシステムを永続的に安全に堅牢に快適に維持すること」です。
おれは非機能要件を最重視します。
なぜかというと、おれの職務は「ITシステムを永続的に安全に堅牢に快適に維持すること」だから。
おれはプロジェクトの序盤かもしくは途中から入って、システムが止まるまで担当することが多いです。途中で抜けることは・・・まぁ、たまにはあります。
そうすると嫌でもシステムがちゃんと動くようにしないといけないんです。
もちろん機能要件も大事なんですけど、そっちは誰の目にも見えるので、必ず誰かがやるんです。やらないとお客さんから突っ込みが入るんです。
ある意味わかりやすい。
リンゴ買ってきてと頼まれて、みかん買ってきたら おいこら！ってなるよね。わかりやすいから間違えにくいと思います。
そしてリンゴを買った人は、「おれは間違いなくリンゴを買ったぜ！」って思うことでしょう。（いちいち思わねーだろ）
でも、依頼主のほんとの要求は、「おいしくて、栄養があって、長持ちして、大きなリンゴを毎日届けてもらうこと」なんです。
リンゴを買った人にはここまで思ってほしい。
これで安けりゃ言うことなしですが、コストの話はちょっと別の要素も含みます。
どこまで良質なリンゴにするかは事前の取り決めと合意に基づくから。
うーん、ちょっと変な例えになってしまったかもしれない。
非機能要件を軽視する人が多すぎる
非機能要件は短期的にはやらなくても誰も困らない。誰も気づかない。
しばらくするとボディブローのように効いてきて、気づいた頃には何をやるにも手間がかかる、追加投資しないとできない。だから止めよう。みたいなことになる。
もしくは突発的な事故がおきたときに、どうにもならない顛末が待っていたりします。
これだけだとなんのことかわかんないですよね。
いくつかピックアップしますと、だいたいこんなことです。
・異常を検知できること
・壊れても復旧できること
・安定した性能を維持すること
・改修がしやすいこと
・安全であること
これらは最初のうちは達成できていなくても表面化しないものが多い。
どれも永続的に気にしないといけないものなんです。
文字だけ読めば業界に関係なく「そりゃそうだよね」って思いますよね。
ところがどっこい、これらを気にしない奴らが多すぎる。
多分、推定・・・8割ぐらいの人は気にしません。（個人の見解です）
非機能要件をちゃんと達成するには、実はシステムの全容を理解しておかないといけないんです。
〇〇という言語が使えるとか
WEBアプリ組めるぜ！とか
SQL書けるぜ！とか
AIのライブラリが使えるぜ！とか
単発のスキルでは成り立たんのです。
ダメな例
今日、とある人から相談をうけたダメな例を書いてみたいと思います。
専門的な話題なのでわかりづらいと思いますが、1個1個注釈付けるわけにもいかんので流してくだせぇ。本人が読んでたらまずいなぁ。ごめんね～。
相談内容はこちら。
「データベースのとあるテーブルがでかくなりすぎてバックアップが遅くなったから、古いレコードを削除したんだけど、再編成するのに時間がかかかると苦情がでるから、テーブルとインデックスを別々に再編成しようと思ってるんだけどどうかな？」
この手の話題はよくあります。
忘れた頃に問題が発覚して対処しようにも対象がでかすぎて何をやるにも支障がでてきてしまいます。
早めに気づけば大した苦労なく対処できるのですが、時間が経つと対応が困難になります。
ダイエットするなら太りすぎないうちにやるのが楽なのと同じですなぁ。
システムの誤認
さて、この相談には大きな誤認があります。
テーブルとインデックスを別々に再編成することはできません。
インデックスを単体で再編成することはできます。
なぜか？
テーブルというのは実データです。特定のアドレスに特定のデータが格納されています。
インデックスはそれを指し示すデータです。
テーブルだけキレイにしたって、インデックスが追従するわけなかろーもん。
おれは「そんなことできんよ」と伝えたのだが納得していない様子でした。
例えて言うなら、Aさんがスマホ＆キャリアを替えたけど、Bさんの電話帳に登録した電話番号は元のままの状態です。
これじゃ電話したってつながらないでしょ。
（いまどきはMNPがあるからつながるんですけど）
逆に電話帳だけ作り直すことはできますよね。
新しく買ってきて、五十音順に書き直せばよいのです。
（いまどき紙の電話帳はないかもしれんけども）
当然ながら新しい電話帳でもちゃんと相手につながります。
これと同じで実際のデータベースの活動を想像すればわかることでもある。おれはデータベース（正確にはDBMS）を作る技量はありませんが、少なくともデータがどんな風に保管されているかのイメージは持ってるので想像することはできます。（別にすごいことではない）
しょせん人間が作ったモノなので、人知を超えるようなミラクルな動作はしないんです。
たまに良い意味でびっくりするようなことはありますよ。
そういうときは、おれも歳だなぁと悲しくなります。
逆に悪い意味でびっくりすることもたまにあります。
作りがしょぼすぎて常識の範囲を超えた挙動をすると予測しようがない。
ちょっとだけ話を戻します。
システムがどうやって動いてるのかを気にしない人が多すぎるんです。
気にしないから、できるはずのないことをやろうと思いついたりする。
気にしないから、ありもしない心配をすることもある。
コンピュータは道具なので、道具は仕事をすればよいだけとも言えます。
良い仕事をさせたいのであれば、その特性と原理をある程度理解しないと使いこなせないはずなのよ。
もうちょっと話を戻します。
この人の心配は、再編成の処理時間が長いとシステムが止まって苦情がでることでした。
でも、よくよく話を聞くと、更新系を止めることはお客さんと合意されてて、参照系を停めたくないんだってさ。
ここにも一つ誤認がありました。
参照するだけなら再編成はできるんです。（ダメなケースはあるけども）
でも、それは嫌なんだってさ。
当人曰く、再編成中に参照するとデータが正しく参照できないという情報を得ていたらしい。
そんなこと、あるわけなかろーもん。
データベースシステムが正しいデータを提供しなかったら何の役にも立ちません。データベースシステムはデータを保全するために何重もの仕組みを備えています。どこのベンダーもこの部分に心血を注いでDBMSを作ってます。
少なくとも更新が発生しなければ、何回参照したって同じ結果になるんだよ。(Order byを指定しないと順番がかわることはある)
話を聞いてて、なんだか疲れてきた。
さらに話を戻します。
そもそもの要求はなんなのかというところに立ち戻る。
相談の範囲内では「バックアップ処理時間を短縮すること」なんですね。
DBの無駄領域を縮小するという判断は間違ってはいないんですが、これで十分なのかというとまったく足りていません。
ここは必ず疑いの目をもって確認する必要があります。
そもそも、なんでバックアップが遅いのか？
これはいろんな要因がある。
ほんとにバックアップサイズがでかいせいなの？
今までよりはでかいかもしれないが絶対量としてでかいのか？
バックアップそのものを適切な場所でやってんの？
ネットワークは遠いの？ほかに重たい処理が動いてない？
期待する転送速度はでてるの？
などなど。
そこらへんを聞いてみたけど、担当外でよくわからんみたいでした。
これがまずい。かなりまずい。
表面的に見えてる問題の根本的な原因はぜんぜん違うところにあるのかもしれないのに、当人には知る術がなかったり、そもそも思いつかなかったりすると適切な対応方法にたどり着くことは絶対にない。
上記はインフラ全般での考慮点です。詳しい情報が得られないので飛ばしました。得られたとしても当人には手がでない領域のようでした。
次にDBサーバー内の判断です。
DBサーバーにとって大事なのはディスク性能です。十分な性能を出すには一工夫が必要です。でもこれも情報を得られませんでした。
DB内にはテーブルスペースがあり、その中にテーブルやインデックスがあります。テーブルスペースは「物理情報と論理情報の境界線」です。
テーブルスペースはサーバー本体やOSと密接な関係があります。
テーブルは論理的な情報として扱われます。つまり実データの物理配置を気にする必要がありません。
テーブルスペースとテーブルをどう関連付けるかがとても大事なのです。
多くのアプリケーションの開発者はテーブルスペース以下の層とテーブルとの関連付けのことを気にしません。
もう、あきれるほど気にしません。というか知らない。
アプリケーション開発者がテーブル設計をやってるのにテーブルスペースを無視するんです。そりゃあかんでしょ。無視してもデフォ値で動くからちゃんと動いてるかのように見えます。でもデフォ値は最適ではないのです。
インデックスを知らない人もいます。知っててもどうやって決定すればよいかわからない人もいます。
テーブルを定義するときにテーブルとインデックスを別のテーブルスペースを割り当てることができます。これの目的や効果はいろいろあるのですが、
このDBMSの場合は、バックアップ時にテーブルスペース別に並列処理が行われます。
ということはね・・・このでかいテーブルとインデックスの割り当てを変えるだけでも処理時間の問題は解消するのかもしれないってことです。
他にもDBMS特有のフィーチャーがあります。バックアップ時の圧縮やテーブルの圧縮など。テーブルレイアウトそのものに無駄なものがあるかもしれない。
これらの話をしたところ、相談してきた人はめんどくさそうになっていました。当人の作業範囲を超えてるみたいで、そんなこと言われてもと思ってるようです。その後、どんな対応するのかちょっとだけ興味はあるけど、ここはあえてほったらかそう。やる気があるならまた連絡が来るでしょう。
終わりに
長々書いたけど、これら１つ１つの配慮が、ぜーーーーーーーーーーんぶ非機能要件にはねてきます。
この例では主に性能や可用性に影響します。
システム開発において何をやるにも、常に非機能要件を気にし続けないとちゃんとしたシステムにはならないんです。
それは困難なことなのでたまに抜け落ちてしまいます。
抜け落ちる理由の根底にあるのはこれ。
そもそもシステムの動作原理を理解してないと、何を気にしないといけないのかもわかるはずがない。
端から端まで理解してる人なんてそうそういません。
だから非機能要件の達成は難しいのです。
と、長々と語りましたが、おれもゆるいところはゆるかったりします。
一人で全部面倒見れるわけねーよ。もうおっさんだし。一介のITエンジニアですから～。
だからこその組織活動だったりします。
もっとコンピューティングが進化すれば、あまり気にしなくてもいい時代が来るかもしれません。
でもやっぱり作り手としては、自分の道具がどうやって動いてるのかをしっかり把握しておいて欲しいところです。
さぁ寝るか～。
この記事が気に入ったらサポートをしてみませんか？