これは電通総研 アドベントカレンダー 2024の6日目の記事です。
はじめに
みなさんこんにちは。電通総研 金融ソリューション事業部 エンジニアリングオフィスの水野です。
今回は、システム開発において使用される不思議な言葉たちをご紹介します。
もしかしたら弊社固有ワーディングかもしれませんが、「そんなのあるんだ」と緩く捉えていただければ幸いです。
造語／隠語／謎用語とは？
同音異義語や、世間一般での使われ方とは大きく異なる単語、言い回したちです。
意味が分かりにくいのもそうですが、設計・実装作業に支障をきたすレベルの認識齟齬を生むこともあり、相当に侮れません。私はその手の用語が出てきたらまず疑ってかかり、詳細を聞き出すことを心がけています。
実物たち
早速実物たちを紹介します。
あくまで使われることがあるというだけで、普段のコミュニケーションで日常的に使用している訳ではないことをお伝えしておきます。
ライトなもの
ワード自体短く、説明も軽量なグループです。
注意が必要な用語は ブランク ですが、昨今聞くことは減ってきたのでまず大丈夫だと思われます。
ガッチャンコ
大抵は集合演算の結合です。つまりJOIN。理由は不明ですが、内部結合を指すことが大半です。
「ガッチャンコする」という動詞で使うことが多いです。
グレーアウト
UI部品を非活性にするという意味です。
Webページの場合はCSSを適用するなど実装方法はいくつかありますが、disabledにするということですね。
例えばボタンだったら、クリックやSubmitなどのアクションを受け付けなくしつつ、見た目も灰色など、反応しなそうなUIに変えることです。
認知負荷は高くなく、認識違いも発生しにくいですが、是非普通に「非活性化」と言っていただきたいです。
尚、活性化をホワイトインとは言いません（少なくとも私の周辺では）。
ブランク
Nullと文字列型における空文字を区別しない使い方で、是非ともやめていただきたいです。
口語でもブランクブランク連呼されることがありますが、大体は入力値無しのことを言っています。
「要件定義や基本設計では意識しないで良いのでは？」という話はあるのですが、であれば「値無し」で良いです。
汎用機時代バリバリの方は、スペースや半角スペースと言うこともあります。固定長時代の名残り？
昔、設計書にスペースと書いてあったのでvarchar型のDBカラムにスペースを設定したら、バグって且つ設計した人に怒られました。
穴をあける
閉じたネットワークで、特定のプロトコル／エンドポイント（IPアドレス or ドメイン、ポート番号） だけインバウンドを許容するという意味です。特定の宛先だけアウトバウンド通信を許容する際にも使用され、穴あけという名詞形もあります。
パブリッククラウド上のアプリケーションでは頻繁に使われる印象です。
打鍵
テストケースをただひたすらに実施することです。
モンキー試験と呼ばれる、とにかく何でもかんでも入力する体を張ったケース消化の意で使う流派もありますが、私の周辺では粛々とケースをこなす意味で使っています。
語源としては、タイプライターの鍵盤を叩くであったり、銀行業務の打鍵（システムに諸々入力する）であったりと諸説あるそうですが、何にせよテストケース実施にそれっぽい単語を割り当てただけです。
暗号化
ハッシュ関数を適用してハッシュ値を得ているケースの誤用です。頻出ではなく、本当に稀です。
新規に作る場合はアーキテクトの裁量で処理方式を決めれば良いのですが、既存システムで実装済みの場合には注意を要します。
「パスワードを暗号化している」と聞いたものの、実際はパスワードから得たハッシュ値を突き合わせていただけだったというのは、過去数回ありました。
～感
いろいろな名詞と組み合わせて使います。スケジュール感や費用感、コスト感（費用感と同じ）、期限感などです。
これはかなり分かりやすいメッセージで、「この内容で合意したわけではないです。後で変わることもありえますし、責任は負えません」と言う意味が込められています。実際、決裁権も裁量もないのかもしれません。
であれば、仮スケジュールや想定スケジュール、概算費用で良いのではないでしょうか。～感を付けるのは、更に確度が低く自信がない、なんらかの不安めいた気持ちのアピールなのかもしれません。
「大まかに捉えたいのです」と言うなら、やはり想定スケジュールが適しているでしょう。もっと粗い粒度で知りたいのだ等ありそうですが、そのあたりを汲み取るための労力が無意味なので、想定スケジュールで良いです。
スケジュール、工数で会話したいです。感と言われても……感です。
ちなみに、スケジュールかんについては、スケジュール観が正しい漢字かもしれません。数回見たことがあります。
感・・・・感。
道なり
「道なりのスケジュールで」という使い方が多いです。 「道なりに進む」とは、曲がったりせずまっすぐ進むと言う意味なので、想像通り何も条件を変更せずに真っすぐ進んだ場合という意味です。
オンデマンドの割り込みが無い前提、且つ稼働を増やさずに今までの生産性を保った場合のスケジュールが近しい表現でしょうか。とは言え、具体的な期日や従前のスケジュールと一切変更がないかは確認すべきです。
道なりと言うと、アントニオ猪木氏の引退スピーチである、
「この道を行けばどうなるものか、（中略）迷わず行けよ。行けばわかるさ。」
が思い出されます。このように、
「不安はあるが新しい一歩を踏み出そう。迷わず行こう、行けばスケジュールが分かるよ。」
的な意味合いなのかもしれません。
ちなみに、上記の猪木氏の言葉は商標登録（文字商標）されています。
行って来い
金融業界では普通に使われます。売りと買いで相殺して、差引で金額の差が出ないことです。
例えば、「影響調査漏れで工数増ですが、類似機能の実装を効率化したので、行って来いで同じ工数です」のような使い方をします。
正式用語だが注意を要するもの
マイクロサービス
本来のマイクロサービスアーキテクチャでないケースがあります。これは、私の狭い観測範囲だけかもしれません。
APIエンドポイントを持つコンテナは複数ありつつ、RDBが中央に一つというパターンが多いです。
例えば以下のような構成で、これはテーブル変更が発生すると全てのサービスが止まるし、データベースがSPOFになります。マイクロサービスの良さを殺し、デメリットを強調していると言っても過言ではないでしょう。
API毎にトランザクション境界があると、結果整合性なり補償トランザクションなりが必要になってきますが、このケースは大体最後に呼ぶAPIだけでトランザクションが完結しているので、表立って問題にはならないです（それもおかしい）。
無理矢理コンテナ分けてみました系が多く、モジュラーモノリスでAPIエンドポイントを複数持たせる方が良いことも多いです。
サービスベースアーキテクチャが最も近いので、そのように呼んで欲しいです。
手順・ガイド
マイクロサービスと同じように一般的な用語なのですが、どこまで求められているか が人によってバラバラなのが手ごわいポイントです。そのドキュメントを見て手順に従えば、誰でもモノが作れる レベルが期待されることもあります。
手順通りにやれば、プログラミングスキルがなくても実装できるというのなら、自動生成など別のアプローチを選択すべきです。
フレームワークやライブラリの使い方では、GitHubや公式ページに記載されている内容を求められるケースもあり、マニュアルを読んでくださいという気持ちになります。ガイド提供側とされる側には大きな前提知識の差があるので、最初Draftを作って粒度を確認した方が良いでしょう。
書き過ぎても実装のアップデートに追従していくのは大変だし、そのうちドキュメントとの乖離が発生するので、コンセプトや設計指針など、なるべく普遍的な部分に留めたさがあります。
しかし、「ガイドが無い（あるいは薄い）から実装効率が悪かった」と言われることもあり、バランスが難しいです。
初見殺し
難度が高く、初見では意味不明なグループです。
暗黙のアーキテクチャ特性が潜んでいたり、非機能要件のリスクが隠れていたりと、注意を要するのもポイントです。
ミステリアスアンニュイワーディングに慣れ親しんだ歴戦の猛者であっても、うっかり足元をすくわれかねない危険性の高さを孕んでいます。
入れポン出しポン
意味するところは 「データの更新も選択も単純で簡単、UIも簡便」 です。
暗黙的に、難易度が低くて工数がかからず、リスクも低いというメッセージがあります。画面とテーブルが1対1で紐づいている、マスターメンテナンス画面などでよく使われる印象です。
仮に上述の画面であれば正確に表現すべきで、例えば
この顧客メンテナンス画面は、テーブルと1対1且つ画面項目とテーブル項目が完全に紐づいており、型や属性も同じです。 更に、月に1回程度しか使わない上に、例えバグで止まっても手動投入でシステム運用が回るワークアラウンドがあります。 SQLも単一テーブルへの挿入・更新・削除のみ、選択は1テーブルからで、述語は2, 3項目のフィルタ条件があるのみです。 データ量は最大100件程度、既存システムからのデータ移行もありません。
など、具体的に言う方が良いです。蓋を開けてみたら、選択時は他のテーブル含め非常に複雑なクエリが要る、データ量が大量などあるかもしれません。ある一項目だけ、取得時に超難儀な計算をやっていて、それは共通コンポーネントが無いと実装出来ないなどあるかもしれません。または、1画面1テーブルで超単純だが、秒間 20,000ユーザのリクエストを100ミリ秒以内に捌く必要があるかもしれません。
「かもしれない」 のですが、入れポン出しポンという用語で真実が分からないのは誰も幸せでは無いです。プロジェクトの近しいメンバーと、公式でない緩いトークで共通認識の下で使うのは良いですが、公式の説明の場では避けるのが賢明です。
ガサーっと持ってくる
専らデータベースからデータを選択する際に用いられます。
「ガサっと」や「バサっと」など変形バージョンもあり、なかなかにバリエーションは多彩です。
意味は、「大量のデータを複雑な述語を伴わずに抽出する」 という表現が近しいです。
RDBを用いている場合、SQLが単純だとしても、大量のデータを選択するのでパフォーマンスやアプリケーションサーバのコンピューティングリソースが問題になることがあります。
特にパフォーマンスが顕著で、具体的な集合演算は何か、1レコードのサイズはどのくらいか、実際何行くらいを抽出するのかを具体的に確認することを推奨します。「ガサーっと持ってくるだけ」 と言いつつ、述語に関数を使っていたり、実は結合をしていたり、重い集合演算のケースもあります。
うっかり放置していると後で痛い目に合うので、この表現が出たときには一歩踏み込んで内容を確認しましょう。
無理矢理突っ込む
これも亜流や派生形はありますが、「ビジネスロジックでデータを加工して永続化する（大抵は挿入）」 という意味です。
無理矢理を付ける意味は大抵無いのですが、業務ロジックを強引に適用する（数値を丸めないといけなかったり、デコードが必要だったり、演算が必要だったり）みたいなニュアンスの時に付与すると理解しています。
「突っ込む」もレベルは高いのですが、これはSQLのINSERT文など、データストアへの追記決め打ちでOKです。
謎の強調
これはIT業界固有ではないかもしれません。同じ言葉を重ねて意味を強調しているグループです。
いまいま
「いまいま」単体だとjust nowというだけなのですが、他の言葉を修飾しているケースで問題が顕在化します。
「いまいま必要ない」と言った場合、例えば以下の意味のどれかを、コンテキストや背景から判断しないといけません。
- 必要だと思うが、今は作る計画はない。且つ、いつ頃作るかも不明
- 言ってはみたものの未来永劫必要ない、きっと
- 次の基盤更改のタイミング （3年や5年）までは必要ない
- 向こう数年は必要ない
- 向こう1年は必要ない
- 向こう数か月は必要ない
あたりです。
「それが何なのですか？」という話ですが、5か6なら近い将来を見越してアーキテクチャやデータモデルに拡張性を持たせるべきかもしれません。
1.は突っ込んだヒアリングが必要かもしれません。「この瞬間は不要」という意味なのですが、であれば判明している期限やタイミングの把握に努めましょう。決まっていないなら、決まっていないことが分かれば良いです。
3.であれば、数年後の飯のタネになる仕込みや、別ソリューションの提案が可能かもしれません。
うっかり口癖で「いまいま～」はお控えいただきたいです。
ほぼほぼ
「ほぼ」が仮に8割方みたいな確率だとすると、「ほぼほぼ」は9割9分9厘くらいの確率なのでしょうか。
「可能性としてはまず有り得ないが、システムに絶対はないので、超微少な確率を表現した。ただし、リスクは皆無なのでバッファは不要」 みたいなケースで使えそうです。
ただ、そこまで分かっているなら、普通に言語化したほうがきっと良いです。
フルフル
「フルフルでアサインしています」などで聞きます。
Full (=100%) なのですが、これが120%になっているとかでしょうか？
つまり、残業を見込んでいるということで、稼働時間は2割増しみたいな話かもしれません。
フルと同じ意味で「フルフルで稼働」 というなら、普通に「フル稼働」で良いのではと思います。
すぐすぐ
ASAPみたいな意味と捉えており、「一刻も早く」の最上位形です。
「すぐなんです！！ 本当にすぐ、今すぐ！！！」みたいな、何らかの気合い的なやつを込めた魂の叫びを表したいのだろうと思っています。
終わりに
今回は様々な摩訶不思議な用語の紹介でした。
これらの用語を組み合わせた応用バージョンもあり、例えば
「こちらは入れポン出しポンなので、エースのA君を高難度の本機能にフルフルでアテンドすれば、行って来いで道なりのスケジュール感です」
などの合体奥義です。
全ての表現に対し、厳密な解釈を可能にさせることは過剰です。その塩梅は、それこそ空気を読む世界です。
「どこまで厳密な表現を使うか」は一様の基準を持ち得ないので、「どの用語や言い回しを使ってはならないか」というDeny Listを作る方が有効だと思います。設計書など、一定の記述レベルが求められる際にご検討ください。
ここまでお読みいただき本当にありがとうございました。
執筆：@mizuno.kazuhiro、レビュー：@handa.kenta
（Shodoで執筆されました）
