今回の記事は「閑話」だ。
軽い気持ちで呼んで欲しい。
三回シリーズにします。
業務担当者にとってExcelはもはや無くてはならないツールだと思う。
しかしシステム開発者のプログラマーにとってはある意味もっとも嫌われているソフトウェアでもある。
なぜプログラマーにExcelが嫌われるか
設計書作成ツールのExcel
SIer業界で作成される設計書や仕様書は殆どがExcelかWordで作成される。経験的に9割がExcelだ。
Excelが多用される理由として、業務システムの仕様書は扱う項目が多い点がある。会計システムなら多数の勘定科目、製造業なら原材料名や部品名、小売りなら商品名という様に多数の項目を扱わなければならない。
この膨大な項目を仕様書に反映するだけでも大変な作業だ。たとえロジックが単純であっても項目が多いだけで仕様書作成は大きな作業になる。
このような沢山の項目を編集するのにとても便利なのがExcelなのだ。
業務系システム開発の現場では設計前の段階からExcelによって項目を整理して試行錯誤する。
開発前に簡単な計算式やビジネスロジックを試すことが出来るのも良い。
これが組み込み系やWebやゲームなどの開発ならばExcelの出番は多くないと思う。
しかし業務系開発の設計にExcelは必須である。
プログラムの組めないSEほどExcel好き
SIer業界には「プログラムの組めないSE」という人種が居る。
元々、元請けが開発工程の一部を下請けに外注していたのが、やがて開発を全部外注するようになり、十数年経って社内の若手情技師(ITエンジニア)が設計しか出来なくなったITベンダーが存在する。
全てのSIerが開発出来なくなっている訳では無いが大手ほどその傾向が強い。
大手の中には開発どころか設計まで丸投げにしてしまう会社もある。
このような多重請負の生態系の中では「プログラムの組めないSE」というものが存在することが出来る。
歴史は浅く20年前には存在しなかったので、長期的には存在を維持できないと私は思う。
個人的にはデフレ経済の産物だと思うのでデフレの終了とともに時間遅れで消滅に向かうと思う。
「プログラムの組めないSE」が主に使う設計ツールがExcelである。
Excelしか使わないと言っても過言では無いかもしれない。
多少はRDBやSQLも使う者は居る。
「プログラムの組めないSE」はプログラマーには嫌われる。
設計に間違いが多く、さらに間違いを理解できない者も少なくない。
私も何度も「プログラムの組めないSE」の書いた間違いだらけの設計書を正しく書き直して開発を行ってきた。
私は「プログラムの組めない人間に設計は出来ない」と考えている。今までプログラムの出来ない人間でマトモに設計出来る人間を見たことが無い。
ただ、システム開発は設計と開発だけではない。
相談・提案・企画といった仕事には必ずしもシステムを作る能力(設計・開発)を必要としない。
相談・提案・企画といった仕事と、設計・開発は完全に別の仕事であり必要とされる能力も、仕事の進め方も、働く場所も違う。
相談・提案・企画は業務を考える工程なのでシステム開発プロジェクトではない。
業務改革プロジェクトである。
業務改革プロジェクトの結果としてシステムが必要だという結論になったら、新たにシステム開発プロジェクトを作るのだ。
両者に直線的繋がりは無い。
元請けが相談・提案・企画を担当し、下請けが設計・開発をするのならば、明確な役割分担が出来ているので間違っていない。
相談・提案・企画といった仕事はITコンサルタントがやるべき仕事であり、受託開発業者の仕事ではない。
両方提供する業者もいるが、ITコンサルタントと受託開発業者の役割の区別は明確にすべきだ。
現在のSIerには受託開発業者は営業目的に無料で提案を行い、ITコンサルタントの価値を無効にしてしまっている業者が多い。
設計だけ自社で行い開発を外注するという不自然なやり方をするのも、ゆがんだ役割分担を行った結果として生じていると考えている。
正常なやり方に変えるべきだろう。
ITコンサルタントと受託開発業者は違うのだから。
ITコンサルタントが顧客に提案し企画を立て要件定義書を作成して、受託開発業者がシステムを設計開発する。
この役割分担が正常な姿だと思うが、現状は
1次請けが営業し、2次請けが相談に乗り、3次請けが提案し、4次請け以下がそれ以外の全てをやる。
という感じになっている。
要するに無駄に多重請負な上に役割分担が不明瞭で面倒な作業は実質下請けに丸投げであり、顧客に指導するようなITコンサルタント業務はあまり行わず、提案は営業の一種になっている。
仕事が上手く整理されていない印象が強い。
「プログラムの組めないSE」という存在は仕事が上手く整理されていない結果として生じている役割なので、もし彼らが提案などの価値のある仕事をしているのならITコンサルタントになるべきだろう。
そして設計は受託開発業者に任せるべきだ。
プログラマーにとって「プログラムの組めないSE」の書いた設計書は存在自体が迷惑なものでしかなく、要件定義書を渡されて設計から開発まで任された方が仕事がし易いのだ。
嫌われているのはExcelではなく「プログラムの組めないSEの書いた設計書」である。
設計書はExcelで書くべきでは無い
ただExcelは設計書を書くために作られたツールではなく表計算ソフトである。
設計書を書くには相応しくない特徴がある。
(1)履歴が残せない
設計書やソースコードは更新履歴を残す必要がある。手戻り作業で一部の機能を以前のバージョンに戻すことなど日常茶飯事だからだ。
最新版だけでは不十分なのだ。
ソースコードの場合はGitなどのバージョン管理ツールによって履歴を保存する。
マイクロソフトが買収したGitHUBはGitによって管理している文書やソースコードの履歴をクラウドによって世界で共有できるようにしたものだ。
Gitなどのバージョン管理ツールはテキストファイルでしか履歴を保存できない。Excelはバイナリファイルなので履歴を残すのが難しい。
バイナリファイルというのはテキストで表せないデータの事だ、画像ファイルや動画ファイルなどが良い例だ。
Excelのデータは複数のXML形式のファイルで構成され、それらのファイルをZIP形式で圧縮している。
もしXML形式を直接保存できれば履歴管理は容易になるが、現状ではそのように出来ていない。
ZIP形式で圧縮した方が持ち運び安いからだ。
バイナリファイルは履歴を残すことが出来ても、過去に更新したファイルを全て残すので効率が悪い。
(Dropboxのようにバイナリの差分を残す技術はあるがGitはそのような仕様にはなっていない)
効率の悪いやり方で残すのでストレージ不足になったりファイル転送が遅かったり、非常に不便になる。
テキストの場合は差分だけ残すので効率も良く速度も速い。
(2)設計書はソースコードと一緒にGitなどで管理すべき
設計書とソースコードは仕様変更や機能拡張、不具合対応などで変化し続ける。
設計書とソースコードの変更履歴は同期が取れていなければならない。
だから設計書とソースコードはファイルを管理する上で同一のデータベースやフォルダーで管理するべきなのだ。
理想は設計書もソースコードも同一のGit(バージョン管理ツール)で管理すべきだ。
現在は設計を行う会社と、開発を行う会社が別になっているので、設計書とソースコードが別々に管理されている。
これは歪んだ多重請負体制の都合なので、システム開発の都合ではない。
開発の都合に合わせるならば設計書とソースコードは同一管理すべきだ。
もし分けるならバージョンごとに分けるべき。設計書とソースコードを分ける道理は無い。
(3)Markdownなどが理想的
設計書とソースコードを同一管理し、履歴を残すのならば設計書はMarkdownなどのテキスト形式のツールで作成したほうが良い。
Gitで履歴を管理し易くなる。
(4)せめてWordを使うべき
それが出来ないとしてもせめて、単独で履歴を保存できるWordを使用した方が良い。
(5)業務担当者との文書交換はExcelが良い
非情技(非ITエンジニア)の業務担当者との文書交換はExcelやWordが良い。
どこの会社でも読めるからだ。
(6)Excelのジレンマに悩む情技師
悩んでいるのは私なのだが、設計書はExcelが良いかMarkdownが良いかという点で私自身迷う。
Excelは優れたソフトなので編集もし易く、表現力も多彩で、どこの会社でも読むことが出来る。
Markdownが扱える使える会社や人は少ない。
問題は「Excelは設計書を書くためのソフトでは無い」という点である。
何でも出来過ぎるExcel
自由レイアウト文書ツール
Excelは文書ツールとしては初めて「無限座標編集ツール」を実現したツールである。
しかもレイアウトも完全に自由で文書や図や表をどこににでも自由に配置できる。
これは試行錯誤をする為のツールとして非常に便利である。
設計書においても、フローチャートやER図やUMLのように無限座標を必要とする設計書を記載するのに昔は非常に重宝した。
今はもっと便利なツールがあるが、「どこでも読める」メリットは今でも最強である。
万能ドローソフト
Excelは絵を描くツールとしても優れている。
PowerPointとWordとExcelは同じ描画機能を共有している。
線分や円や矩形などオブジェクトを配置して変形することで絵を描くスタイルは扱い安く、誰でも短時間に簡単な図を書くことが出来る。
簡単な図であれば何でも書くことが出来るのである意味万能である。
これで絵画のような絵を描く人や、マンガのようなイラストを描く人も居るので、その性能はバカに出来ない。
万能画像アーカイブソフト
Excelは文書と図と画像(写真)を管理できるので、写真データなど画像ファイルをコピーペーストでExcelファイルに貼り付けて保存することが出来る。
これがまたシステム設計で便利なところでもある。
様々な写真資料や手書きの図などを一つの文書に纏めることが出来る。
重要な悩みどころである。
データベースクライアント
ExcelはODBCやOLEインターフェイスでSQL ServerやOracleなどのデータベース管理システムに接続し、データを閲覧保存することが出来る。
通常はデータベース管理システムのデータを閲覧するには専用のクライアントソフトが必要だが、システム発注元の端末など開発ツールの入っていない環境で緊急にデータを閲覧しなければならない時など役に立つ。
また簡単なデータ分析ツールとしても優秀だ。
簡易データベース
Excelはそれ自体を簡易的なデータベース管理システムとして使うこともできる。
先の例はフロントエンドをExcelで代行する話だが、これはバックエンドをExcelで代行する話だ。
フロントエンドをC#などで作成し、そのプログラムからExcelに格納されたデータを読む。
一人用の簡単な処理ならこれで済んでしまうこともある。
SIer案件でこんな仕事はしないが。
データベース内蔵の統合開発環境
もちろん、フロントエンドもバックエンドもExcelだけで全部やることも出来る。
むしろ、その方がインターフェイスの設計を考えなくて良いので簡単だ。
VBAなど開発環境や言語も充実している。
システム開発などでもエラーメッセージや課題の管理、不具合の管理などVBAで簡単なマクロを作成して管理業務を自動化したりする。
どこの職場でも必ず使える
何度も言ったがExcelは全てのオフィスで使用することが出来るので、Excelで作成したファイルはどこにでも送ることが出来る。
これは最強のメリットである。
Excelはどこへ向かっているのか、どこまでやるのか
Excelは文書も書ける。
絵も描ける。
グラフも描けて、画像も扱える。
外部データベースに接続できて、自身もデータベースになることも出来る。
業務システムを自身の中で作成することも出来る。
オフィスで必要なことは何でも出来てしまう。
Excelは表計算ソフトである
何でも出来るExcelだが多くの情技師が忘れている重要な機能がある。
それは「Excelは表計算ソフトである」ということだ。
それ以外の全ての機能は表計算機能のオマケにすぎ無いのだ。
我々の仕事はこのオマケに依存しているのである。
続く
