課題解決のためのUI/UX

プログラミング言語の変遷に見る開発体験の変化

綾塚祐二 2019年02月07日 07時00分

  • このエントリーをはてなブックマークに追加
  • 印刷

 最近のニュースで、古くからあるプログラミング言語の「COBOL」が話題になった。また、2020年から小学校でプログラミング教育が実施されるという話題もある。計算機(=コンピュータ)をどう動かすかを決めるのが「プログラム」であり、それを作るのが「プログラミング」の役割だ。当然、そこにもさまざまなユーザーエクスペリエンス(UX)が生じる。

 今回はそれについて幾つか考えてみたい。プログラミングにはとても多くの要素が絡み合うため、ここで言及できるのはそのうちの一部であることをあらかじめお断りしておく(機会があればまた他の要素も取り上げたい)。

プログラミング言語

 人類初のコンピュータプログラマーといわれる19世紀のAda Lovelaceの時代から、1940年前後の電子計算機が開発された当初までは、計算機が直接実行できる「命令語」(機械語)を記述・入力していた。計算機以外でも、自動織り機であるジャガード織り機のパターンの指定やオルゴールの楽譜など、時間を追って機械の動作を一対一で記述するものは、ある種のプログラムといえる。それらも同様である。

 これらは、機械の種類ごとに命令語の内容やその入力の仕方がまちまちなので機械ごとに特化したプログラムが必要になる。また、命令語の内容は主に機械の都合に合わせたものにならざるを得ないので、人間にとっては「計算させたいこと」を命令語の並びで表したり、命令語の並びで何が計算されるかを理解したりするのは容易ではなかった。

 つまり、計算機にとって直接的であり、人間にとっては直接的ではなく(複雑な翻訳が必要である)ということである。

 1950年代後半ごろから、「高級言語」あるいは「高水準言語」と呼ばれる、計算機の命令語から離れ、人間に分かりやすく記述できるようにしたプログラミング言語が各種開発された(人間にとって翻訳の苦労や手間を減らすという、UXの改善でもある)。

 前出のCOBOLをはじめとして、「FORTRAN」や「LISP」など現代まで連なる言語がこの時代に多数登場している。COBOLやFORTRANは、命令語を直接記述するときのように、基本的に計算機に実行させたいことを順番に記述するという「手続き型言語」というタイプのプログラミング言語である。

 他のタイプとしてLISPのような「関数型言語」や、1970年代に登場する「Prolog」のような「論理型言語」などもあるが、ここではそれらについて割愛する。

ライブラリ、開発環境

 高級言語を用いても、毎回、一から全て書くのは煩雑だし、何より無駄である。そこで、ライブラリやフレームワークなどの形で、さまざまな機能を持つモジュールが用意される。計算機の進歩により扱えるデータの種類や大きさ、複雑さが増えるにつれて、用意される機能の粒度も大きくなってきている。また、オプション機能だったものがどんどん標準機能として使えるようになってきている。

 例えば、昔は何らかのフォーマットの画像ファイルを読み込んで画面に表示しようと思ったとき、そのフォーマット用のライブラリを用意してファイルを読み込み、それを実行環境に合わせた表示フォーマットで出力するプログラムを作って表示させる、ということが必要だった。

 しかし、現代普及しているプログラミング言語や環境では、ほぼ標準で多くのフォーマットに対応しており、フォーマットを気にせずに画像ファイルを読み込み、実行環境を気にせず表示するということをそれぞれ簡単な機能の呼び出しで行える。

 同じプログラムを繰り返し実行するためモジュール化を考えるというのは、プログラミング時に求められる基本的な思考法だし、プログラムのミス(バグ)を減らすためにも有効である。もちろん、作りたいプログラムの本質以外の部分をなるべく簡略化して作成できるようにするのは、UXの改善にも大きく寄与する。

ビジュアルプログラミング言語

 高級言語の登場以来、現在でも(少なくともちょっと規模の大きなシステム開発の)主流で使われているのは文字を使ってプログラムを記述するプログラミング言語である。これを、図形や矢印などを使って記述しようとするのが、「ビジュアルプログラミング言語」(ビジュアル言語とも呼ばれる)である。

 分岐または合流するような処理の流れやデータの流れを表すには、線図の表現が向いているし、また人間が流れを理解するのにも向いている。モジュールを一つの「かたまり」として図的に扱うのも、特に初心者には分かりやすいだろう。

 文字が主体のプログラミングだと(統合開発環境ではいろいろと補助があるとはいえ)機能を名称で覚えておく必要があるが、ビジュアルプログラミング言語の場合は、必要な機能のモジュールをパレットのような形で用意しておけば、ドラッグ&ドロップでそれらを配置するだけで使いこなせる。これも、初心者にとってのハードルを下げる要素である。

 子どもの教育向けなどとして人気のある「Scratch」などでは、各種の命令や手続き型言語の制御構造(ループや条件分岐など)をブロックという形で表現している。ブロックはテンプレートとして機能し、自由自在に組み合わせたり、パラメータをブロック上に入力させたりすることでプログラムを構築していく。

 コードの打ち間違えや括弧のつけ間違えによる制御構造の設計ミスなどを防げるので、これも作りたいプログラムの本質以外に気を取られることを避けるのに役立つ。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

SpecialPR

連載

CIO
月刊 Windows 10移行の心・技・体
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
セキュリティインシデント対応の現場
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]