『技術の言葉』

本サイトの目的に沿って、技術であって特に情報関連技術に関する言葉の背景を説明しています。適宜改変することがあります。

技術の言葉の定義は、よく整備されている科学の言葉に比べ、各々の企業が製品や役務（サービス）を区別するため、斬新さや親しみ易さなどの印象を考慮し、商業的な観点も踏まえて作られることもありますが、伝統的には学術的に機能や構造を特定して定められているものが多くあります。しかし、特に情報関連技術においては商業がアジャイル手法を用い、学術に先行して技術を広める傾向が強く、体系的な理解が困難になっているので、このページを作りました。

技術の理解には、原則、頭の中だけで完結するものだけではなく、数式やデータなどを用いた量的な解釈や判断、また物理的な感覚などによる補足が必要であり、基礎的な体験を共有していない人と言葉だけで全ての情報を共有するのは困難かもしれません。

『技術と技能；アジャイル開発』

技術とは、このＷｅｂサイトでは、なんらかの目的を達成するための方法や、その過程で立ち現れた課題を解決するための方法であって、再現性がある程度高い方法のことです。科学に関する方法（科学技術）や、柔道・剣道など武道に関する方法（技）などと限定されて用いられるのが通常です。
技能は、知的財産の分野では「個人の熟練によって到達し得るものであって、知識として第三者に伝達できる客観性が欠如しているもの」（審査基準より引用）であり、文章による伝達が比較的容易な技術と区別されます。

しかしながら、社会的集団的観点から見ると、業者間でも別途の基礎となるべき知識を予め共有していないとその技術の習得（伝達）が困難であるのは同じであり、この点での技術と技能の違いは、予め共有しておくべき伝達に必要な基礎となる情報がコンテンツ（教材）として存在するか否かであると考えられます。つまり、技術にも技能と同様の問題が含まれていると思われます。

算術や論理を用いる科学的手段や自然現象などについての文書情報の演習や読込みを行ってきた者とそうでない者とでは基礎的な体験が異なっており、また、特定の目的や課題を包含する社会的現象に人文的手段などで取組んできた者とそうでない者とでも基礎的な体験が異なっており、またこれらの他にも有用な体験があります。
更に、外国語が用いられるなど言語の多様性もあります。
情報関連技術はこういった基礎の異なる者が関わる技術の分野であることを常々意識している必要があると考えています。

他方で、アジャイル開発には市場標準（デファクトスタンダード）を肯定する傾向が強くあり、速く行き過ぎると、多様な価値に配慮する余裕が少なくなり、大多数である第三者に伝達できる客観性が欠如することで技能的特性が強く現れ、秘匿化効果は強まるが、孤立し、行き詰まり、引継ぎも困難となるという問題も懸念されます。また、実験的な取り組みを仮想でない現実の社会で行うと、安定している現実の社会に不可逆的な損害を発生させ自己の信用や財産を失う可能性もあります。

そして、情報関連技術については、社会で複雑な問題を多人数で扱うことが多くなっていることから、アジャイル開発に並行して、コンテンツとして体系的に整備し必要なときに用いることができるようにしておくことが有用だと思います。またこれは職務の属人化への対策にも繋がると考えられます。

『アタリ・ショック』

—生成ＡＩとハルシネーション、またはアジャイル—

ソフトウェア市場について、過去に、需要がある産業に参入し、形だけを整えたコンテンツを大量に供給することで需要を消費してしまい、且つ、消費者からの信用と期待を損ない、市場を消滅させる事件があったそうです。

「酸っぱいレモン」市場と呼ばれる、取引において売り手と買い手との商品についての情報の非対称性が存在する状況がこのような事件の前提にあったと考えられているようです。

生産手段の効率化は、当初は新規参入を容易とし、多様なソフトウェアの大量の供給を可能としますが、消費者の受け取る価値に配慮しない商品が増え、その消費者にとって好ましい商品を市場で選択しにくい状態になると、比較的に早くその市場の魅力が損なわれる危険性があると考えられます。

他人に先駆けて新しい機能を提供していくことは有益だと考えますが、個別の消費者が求めている価値が何かを丁寧に特定していくことが、上述のような事件を避けるのに必要な作業の一つだと考えます。

『重要業績評価指標（ＫＰＩ）』

—得点（ポイント）—　（ＫＰＩ：キー・パフォーマンス・インジケーター）

組織（ｓｙｓｔｅｍ）や社会を管理するため、目的や目標を設定した後、例えば法律や契約ではルールを条項（ｃｏｄｅ）という箇条書きの文章で定性的に表現します。
また他方で、具体的に組織などの操作や変化の観察をすべく、定量的な評価を可能とする数値の表現（ｉｎｄｉｃａｔｏｒ）である、例えば重要業績評価指標（ＫＰＩ）などの得点（ポイント）を条項の中などで用いることがあります。

条項を解釈する際には、文章の論理の構造や語句の定義を理解する解釈方法である「文言解釈」を行って目的などを達成できるように管理を試みますが、その解釈が目的などの達成のために不足があったり矛盾を引き起こすなどで役に立たない場面では、目的などとの関係を考えて解釈を行う「趣旨解釈」を行います。

しかしながら重要業績評価指標は、その数値が独立して評価されることが多く、恣意的に抽出された対象から測定されることもあるなど、その達成のための手段の選択に裁量が与えられることと引き替えに、その数値が目的などに影響する効果を理解しようとする丁寧な評価が行われないことが多くあります。

目的を達成するには必然条件だけでなく、十分条件を満たすことも確認する必要があります。
重要業績評価指標などの得点を用いて評価を行う場合には、その得点の数え方や算出方法を知っているだけでなく、その得点がどういった条項などの文脈で設定されたのか、得点をその文脈で評価して期待する効果が生じているのか、事象は多面的に評価できているか、条項はＰＤＣＡで見直せているのか、などを評価しなければ目的の達成や維持に至ることは困難であると考えます。

『バグ（Bug）』

—正常系と異常系—

バグとは望まない挙動のことであり、その原因とされる物事には様々な種類があります。例えば、仕様を定める際に入り込んだものや、それをプログラミング言語で表現した際に入り込んだもの、表現したプログラムを実際に実行するハードウェアの仕様を考慮しきれていないことで入り込んだもの、などを容易に思いつきますが、これらの他にも、使用しているＯＳやミドルウェアまたはライブラリやこれらのアップデートに含まれるもの、プログラムを格納している記憶媒体やCPUなどのハードウェアの変更や破損で生じるもの、供給される電力や電磁波などの外乱により引き起こされるもの、意図的で人為的な行為により引き起こされるものなどがあります。

これらの原因の多くは、思考や手続きの抽象化に伴う、注意力の分断や分業化によって見逃されることで存在しているように思えます。

想定した手順を実行することで目的を達成しようとする設計は正常系と呼ばれ、比較的容易に作成することができますが、設計の際に意図せず入り込む上記のバグに備える異常系では、異常系のバグに備える必要もあることから、慎重に行う必要があり、多くの場合には正常系よりも複雑で実装には何倍も多くの労力を要することになります。