第001回_ご挨拶

» 2017/01/23

エンジニアライフの読者の皆さんはじめまして
ハンドルネーム：0/1相転移炉 です。

第1回目のコラムということで、いくつか自分語りをしていきます。
技術的な内容は3回目以降に書きますので、興味がなければ第1回目/2回目は飛ばしてください。

Q&A方式で書いていきます。

自己紹介Q&A

Q.なぜコラムを書こうと思ったのか？（動機）
A.第1に、私の現在のライフワークで研究している内容について世の中に発信し、多くの人の意見を参考にしたいと考えています。
第2に、エンジニアライフで技術紹介の記事がないなと感じたからです。コラムと技術記事は違うよ、と言われたらその通りかもしれませんが、コラムで技術記事を書いたって良いと思ったのです。

Q.筆者のライフワークとは？
A.私は、「システムエンジニアの仕事を改善する」をライフワークにしています。

Q.なぜそんなことを研究しているのか?
A.開発工程はここ２０年ほどまともな変化が起きていないように思います。そのブレイクスルーができないのかなぁと悶々と考えて眠れなくなるので研究を始めました。それが理由です。

Q.コラムに原稿料はないって知ってる？
A.知っています。そのため、コラムに載せる記事は私の研究の序章部分に留めます。このコラムで全容を公開する予定はありません。
このコラムで連載する内容は中途半端なものになることをあらかじめご了承ください。

Q.システムエンジニアの仕事を改善するって具体的には？
A.定量的な目標としては、次の5つを考えています。

• 目標1: コーディングの効率性を向上させ、製造フェーズのコーディング量を10kstep/月になるよう目指す。
• 目標2: ドキュメントに記載するべき内容・目次をテンプレート化する。(記載漏れやドキュメントのわかりにくさを解消し、トラブルを回避する)
• 目標3: 単体テストの設計・製作・実行を自動化する(単体テスト期間を100%削減する)
• 目標4: 結合テストの設計・製作・実行を自動化する(結合テスト期間を50%削減する)
• 目標5: システムテストの設計・製作・実行を自動化する(システムテスト期間を10%削減する)

目標は随時更新しています。

Q.なぜ@ITで公開しようと思ったの？（場所の選定）
A.第1の理由は、自分が@ITをよく利用しているからです。第2の理由は、公開しようとしている序章の内容は@ITの"やさしく読む「XML 1.0勧告」" の記事を参考にさせていただいているからです。

Q.どのような内容の記事？（要旨）
A.オブジェクト指向の構文解析器に関する開発を実践的な内容で紹介します。題材として自作のXMLパーサを構文解析ができるレベルで実装します。

Q.構文解析器を理解することでどの目標が達成されるの？（先ほどの目標に関連して）
A.最終的に、効率性向上(目標1)　と　テストの自動化(目標3,4,5)　を達成するものを自分でつくるための道具(ツール)が手に入ります。

ここからはQ&A方式を止めて、Q&Aのその他の情報について書きます。

その他情報

■対象読者について

　対象とする読者はJavaの文法が判り、初歩のプログラムが書ける人とします。

■紹介する技術

　このコラムを読むことで獲得できる技術は次の4つになります。

　1.字句解析器・構文解析器のオブジェクト指向言語による実装に関する技術

本コラムの目指すところは、Java言語でオブジェクト指向の設計を使ってXMLの字句解析器・構文解析器を作成することです。また、その具体例を紹介することも目指しています。本コラムに書かれた設計が最適とは言いません。ただし、具体的に動作するプログラムを紹介するので存分に検討していただきたいと思います。

　2.XMLの仕様に関する知識

字句解析器・構文解析器を作成する過程で、副次的に、XMLの仕様についてもいくつか解説します。本コラムでどこまでを公開するかは未定ですが、意味解析まで到達する場合は、XMLの仕様の詳細を検討します。

　3.仕様に対するW3Cの勧告を読む技術

研究開発系の仕事場ではRFCやW3C勧告を読むことが多くあります。もしかしたらRFCを書く人もいるかもしれません。XMLは概念的な理論ではなく単なるファイルの仕様なので、W3C勧告も入門編です。よって、W3C勧告やRFCを読んだことがない人には適当な題材だと思います。

　4.仕様の拡張に対応できるクラス設計

本コラムは、多くのクラスがVisitorパターンを使っていますが、デザインパターンの中で最も利用方法の説明が少ないのがVisitorパターンであると筆者は感じています。
そんな不遇なVisitorパターンですが、強力なデザインパターンだと筆者は思っています。Visitorパターンを使った機能拡張の実践例を通し、読者のクラス設計力の幅が広がることを期待しています。

本コラムの書式・お約束

本コラムの文章は「能動的に書く」ように心がけています。

文章を能動的に書くと言われてピンと来ない場合は"文章から受動態の表現を取り除く"と考えてみてください。

理由について思いつく限り、メモしておきます。論理的な根拠や統計的なデータがあるわけではなく、単なる私見です。

• 理由1:受動態の「される」という表現が尊敬語や謙譲語とかぶり、曖昧になる可能性を持つためそのような表現を極力避けています。仕様書の場合、個人的には「である」調で一旦書いてから、必要な場合だけ丁寧語に書き直します。

• 理由2:プログラムの関数・メソッド・プロシージャの命名方法は基本的に(能動的な)動詞を使うことが多いと思います。よって、仕様書も能動的に書いておいた方が解釈し直す手間を省けます。

• 理由3:単なるクセです。

連載の立ち位置

Q&Aで少しだけ触れましたが、最後に本コラムの連載の立ち位置について述べます。
この連載の立ち位置は技術書の元原稿ないし序章部分をインターネット上で発信することにより、興味を持っていただくこと、多くの議論をしていただくことを期待して公開いたします。