今更、Windows RT機種を買いました。 元々気にはなっていたのです。フツーのWindows互換機と思いきや、わざわざARMで作り直して、しかもそのせいでソフトが少ない。ゲーム機でいえばwii Uみたいなもんでしょうか。
勤務先最寄りのビックカメラでもフツーに新品は売ってるのですが「フレッツ光付き」だったので辞めました。間に合ってますというか、賃貸アパートですらインターネット付き（多分ケーブルテレビとか？）ですから、改めて新規契約付ける意味がない。 wimaxならアリかな。
で、中古というかリファービッシュを買いました。前述フレッツ付きと同価格帯ですが、光要らないんで。
機種は ASUS Vivo Tab RT です。 TF600-GY32
あれマニュアル付いてないのか。オフィシャルサイトでPDF版を落とせるご時世なのであまり困りませんが。http://www.asus.com/support/Manual/28/5/ASUS_VivoTab_RT/
アカウントは最初は、起動時の案内を真に受けて、microsoftネットワークにgmailアカウントで登録しましたが、それがどうこうって言うよりは、スクリーンロックしたときに「microsoftネットワークパスワード」を要求されて弱りました。 スクリーンキーボードはシフトが長押しで効くので、まあまあの使い勝手ですが、ランダム文字列パスワードを入れるにはギリギリです。
ネットワーク認証？って奴になってしまって不便だったので、「ローカルアカウント」に変換しました。
Windowsストアでラインナップを確認しましたが、噂どおりの「少なさ」ですね。Android 黎明期（4年ぐらい前？のandroid market)を見るようですが、今から4年後には増えますとかは考えにくいでしょう。大概の「判ってる」ユーザは、Windows RT Pro機を買うでしょうから。
Skypeは、microsoftアカウントと勝手に統合しやがりますね。
とはいえ、流石のオフィシャル、軽量Windows互換機(?)で、EXCELビューア兼編集機として使う分にはなかなか優秀です。
「スタートメニュー」のExcel等を選ぶと、懐かしいXPっぽいデスクトップに戻ります。ちゃんと「（インターネットの付かない方の)エクスプローラ」があるので、それでファイルを探してタップすれば、Excelで開きます。
ちょっと驚いたのですが、libreoffice/openofficeのods形式がそのままシレっと開いたことですね。
http://ja.wikipedia.org/wiki/OpenDocument
これはWindows Office 2013が全体的にそうなのかな？
ゲーム類は、「いかにもunity http://japan.unity3d.com/ で作りました！ http://japan.unity3d.com/gallery/made-with-unity/game-list 」っていう感じのものが殆どですね。評価数も二桁が多いので、Windows RTのユーザの少なさを想像させます。まあこの手の「他人の評価をしてもらう系」はサバを読んだり盛ったりするわけにもいかんのだが。
それにしても microsoftは売り方間違えてると思う。
大多数の日本企業は、「XPサポート切れ」でリプレースに困ってます。が、Excelが使えれば大概やっていけるでしょうから、Windows RTでも問題ないのではないでしょうか。 しかもWindows 8「では無い」ので、ロクでもないソフトしか入手できない。法人の「IT推進部」としては管理コストが省けるんじゃないでしょうか。
まあmicrosoftの誇りが許さないかもしれないけどね。
2013年11月2日土曜日
2013年2月25日月曜日
「エクセルでガントチャート」アナタの目的は「作成」じゃなくて「管理」ですよね？
当ブログの統計を見たら「EXCEL ガントチャート」がいらっしゃる。と言ってもただの1件ですが、実際試すと、引っかかるほとんどが「作成方法」。アンチの小生のページによくぞ来たなと思います。
前にも書きましたが、目的と手段を取り違えるのが、日本人のかなり強い特徴です。
アナタの目的は「エクセルでガントチャートを作成する」ことではないはずです。
ひょっとしたら、上司命令で「報告書としてガントチャート」を描かされてるかも知れませんが。
「ガントチャートで工程管理をする」のが目的のはずです。
何が違うのかって？
仮に、紙の方眼紙にガントチャートを描いたとして、それを「管理している」とは思わない筈です。だって紙だから。でも「エクセルを使った」ら「管理してる」と思い込んでしまう。イヤイヤ「エクセルで方眼紙」をやったら、紙の方眼紙を使うのと大差ないでしょ？ 管理してるはあくまでアナタ、エクセルは清書を手伝ってるだけ。アナタの仕事は減ってない。
とはいえ、前述のキーで検索するような人は、まだ見どころがあるということでしょうか。何かオカシイと思ってるのでしょうから。
工程管理の本質は、作業量÷人数＝期間 を出すことですが、もちろん話はそんなに簡単じゃない。複数人で回せば、優先順位やら依存関係やらの話が出てきて、しかも場合によっては作業者を入れ替えたりして対応しなければならないはず。それをエクセルでガントチャートで、やれるものならやってみろと。それが大変だと言ってるわけです。もちろん気づいてますよね？
小生は否定派だし、必要ならスクリプトでも何でも書きますが、オイオイそこまで言うなら解決方法を言えよ！とか思うでしょう。もちろんありますよ。
http://hondaalfa.blogspot.jp/2011/11/blog-post_25.html
エクセルで頑張るなら
http://www.moongift.jp/2009/02/gantt_chart_for_openoffice_calc/
http://q.hatena.ne.jp/1098241302
http://d.hatena.ne.jp/bs_n/20110924/1316870700
前にも書きましたが、目的と手段を取り違えるのが、日本人のかなり強い特徴です。
アナタの目的は「エクセルでガントチャートを作成する」ことではないはずです。
ひょっとしたら、上司命令で「報告書としてガントチャート」を描かされてるかも知れませんが。
「ガントチャートで工程管理をする」のが目的のはずです。
何が違うのかって？
仮に、紙の方眼紙にガントチャートを描いたとして、それを「管理している」とは思わない筈です。だって紙だから。でも「エクセルを使った」ら「管理してる」と思い込んでしまう。イヤイヤ「エクセルで方眼紙」をやったら、紙の方眼紙を使うのと大差ないでしょ？ 管理してるはあくまでアナタ、エクセルは清書を手伝ってるだけ。アナタの仕事は減ってない。
とはいえ、前述のキーで検索するような人は、まだ見どころがあるということでしょうか。何かオカシイと思ってるのでしょうから。
工程管理の本質は、作業量÷人数＝期間 を出すことですが、もちろん話はそんなに簡単じゃない。複数人で回せば、優先順位やら依存関係やらの話が出てきて、しかも場合によっては作業者を入れ替えたりして対応しなければならないはず。それをエクセルでガントチャートで、やれるものならやってみろと。それが大変だと言ってるわけです。もちろん気づいてますよね？
小生は否定派だし、必要ならスクリプトでも何でも書きますが、オイオイそこまで言うなら解決方法を言えよ！とか思うでしょう。もちろんありますよ。
http://hondaalfa.blogspot.jp/2011/11/blog-post_25.html
エクセルで頑張るなら
http://www.moongift.jp/2009/02/gantt_chart_for_openoffice_calc/
http://q.hatena.ne.jp/1098241302
http://d.hatena.ne.jp/bs_n/20110924/1316870700
2012年3月19日月曜日
日本人の「EXCEL好き」は異常
文句です。代替案については別記事で書いてます。
プログラマ業界でも、「EXCEL仕様書」で悩んでる人は多いと思います。
仕様書を書くのはプログラマでも、それを受け取る人は「非プログラマ」なので、
アウトプットとして「EXCELで見る」方法を選ぼうとします。
何ででしょうね。正直小生には判らない世界です。
これがSI/IT業界を泣かせたり泣かせなかったりします。
具体的には小生は泣かされたりした方で、あげくゲーム業界に出稼ぎに出てたりますが
それはまた別の話。
ちょっと検索してみると、2006年辺りから予見はしていたっぽい。
http://www.atmarkit.co.jp/news/200611/02/hitachisys.html
EXCEL好きは、「日本人」の「帳票文化」即ち「罫線好き」が原因だと思います。
「綺麗な帳票で出力する」そのためのフォーマットとしてEXCELを要求するのは、日本人の特徴ですね。小生は認めたくはないですが。
http://news.mynavi.jp/articles/2009/11/04/form2/index.html
そしてこれは、外国人(本稿では敬意を込めてこう言いますが)は全員驚いてます。
http://slashdot.jp/story/11/09/30/040224/%E6%97%A5%E6%9C%AC%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%8C-Hacker-News-%E3%81%A7%E8%A9%B1%E9%A1%8C%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F
小生がする筈だった反論は、全て前述のURLで述べられてると言ってよいでしょう。
SI/IT業界での「顧客要望」は大抵この通りです。
http://slashdot.jp/comments.pl?sid=546769&cid=2027351
笑い話にしかなりませんが、笑えません。
これを踏まえて、「VBAホスティング」などというサービスもあります。
http://jp.fujitsu.com/platform/server/primergy/pccluster/excel-hpc/
笑い話にしかなりませんが、笑えません。
言うまでもないことですが、あえて言いましょう。「表形式でないデータ」を、「表計算ソフト」に入れることは異常です。
彼らにとって大事なのは、「業務を効率的に遂行する」ことではありません。「罫線を綺麗に引いて」「罫線の中に綺麗に文章を流し込むこと」です。とここまで書いて、MS-DOSの時代から続いている文化のような気がしてきました。
そしてそれらの書類は、最終的には印刷して、課長にハンコを貰います。綺麗に書けるし、書き直しも楽だし一石二鳥。これ以上のソリューションはありません。俺ってアッタマイイ！
電子データのまま活用しようとか、検索しようとか、そんな発想は、逆さまに吊るしても出てきません。そしてその書類を受け取った人は、それをまた別のExcelシートに手打ちで番号を振ったりします。これが最善です。
目的はあくまで、「罫線「以外」」の筈です。それを罫線を最優先でツール選択をしています。ここに日本人の本質的な異常性があります。目的と手段を入れ替えるのです。そしてその為に派生した業務を無駄と思いません。故に「EXCEL作業より効率的になる」という主張は彼らには届きません。「EXCEL作業」が最善だからです。
こんな事を書いている小生も日本人で、EXCEL嫌いですが、世界広しといえど、ここまで「EXCEL好き」な人種も珍しいでしょう。故に、「日本人のEXCEL好き」は耐えがたい事実です。
帳票だったらまだ良いですが、ガントチャートだったら最悪です。土日をまたいでその分の長さを手動で直すとかあり得ません。いいマクロがあるよって？そんな話はしてません。
以上を踏まえて、小生は「EXCEL好き」を「目的と手段を入れ替える人」と判断します。
プログラマ業界でも、「EXCEL仕様書」で悩んでる人は多いと思います。
仕様書を書くのはプログラマでも、それを受け取る人は「非プログラマ」なので、
アウトプットとして「EXCELで見る」方法を選ぼうとします。
何ででしょうね。正直小生には判らない世界です。
これがSI/IT業界を泣かせたり泣かせなかったりします。
具体的には小生は泣かされたりした方で、あげくゲーム業界に出稼ぎに出てたりますが
それはまた別の話。
ちょっと検索してみると、2006年辺りから予見はしていたっぽい。
http://www.atmarkit.co.jp/news/200611/02/hitachisys.html
EXCEL好きは、「日本人」の「帳票文化」即ち「罫線好き」が原因だと思います。
「綺麗な帳票で出力する」そのためのフォーマットとしてEXCELを要求するのは、日本人の特徴ですね。小生は認めたくはないですが。
http://news.mynavi.jp/articles/2009/11/04/form2/index.html
そしてこれは、外国人(本稿では敬意を込めてこう言いますが)は全員驚いてます。
http://slashdot.jp/story/11/09/30/040224/%E6%97%A5%E6%9C%AC%E4%BA%BA%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E8%A8%98%E4%BA%8B%E3%81%8C-Hacker-News-%E3%81%A7%E8%A9%B1%E9%A1%8C%E3%81%AB%E3%81%AA%E3%81%A3%E3%81%9F
小生がする筈だった反論は、全て前述のURLで述べられてると言ってよいでしょう。
SI/IT業界での「顧客要望」は大抵この通りです。
http://slashdot.jp/comments.pl?sid=546769&cid=2027351
笑い話にしかなりませんが、笑えません。
これを踏まえて、「VBAホスティング」などというサービスもあります。
http://jp.fujitsu.com/platform/server/primergy/pccluster/excel-hpc/
笑い話にしかなりませんが、笑えません。
言うまでもないことですが、あえて言いましょう。「表形式でないデータ」を、「表計算ソフト」に入れることは異常です。
彼らにとって大事なのは、「業務を効率的に遂行する」ことではありません。「罫線を綺麗に引いて」「罫線の中に綺麗に文章を流し込むこと」です。とここまで書いて、MS-DOSの時代から続いている文化のような気がしてきました。
そしてそれらの書類は、最終的には印刷して、課長にハンコを貰います。綺麗に書けるし、書き直しも楽だし一石二鳥。これ以上のソリューションはありません。俺ってアッタマイイ！
電子データのまま活用しようとか、検索しようとか、そんな発想は、逆さまに吊るしても出てきません。そしてその書類を受け取った人は、それをまた別のExcelシートに手打ちで番号を振ったりします。これが最善です。
目的はあくまで、「罫線「以外」」の筈です。それを罫線を最優先でツール選択をしています。ここに日本人の本質的な異常性があります。目的と手段を入れ替えるのです。そしてその為に派生した業務を無駄と思いません。故に「EXCEL作業より効率的になる」という主張は彼らには届きません。「EXCEL作業」が最善だからです。
こんな事を書いている小生も日本人で、EXCEL嫌いですが、世界広しといえど、ここまで「EXCEL好き」な人種も珍しいでしょう。故に、「日本人のEXCEL好き」は耐えがたい事実です。
帳票だったらまだ良いですが、ガントチャートだったら最悪です。土日をまたいでその分の長さを手動で直すとかあり得ません。いいマクロがあるよって？そんな話はしてません。
以上を踏まえて、小生は「EXCEL好き」を「目的と手段を入れ替える人」と判断します。
2012年3月14日水曜日
「Excel仕様書」の代替案を幾つか
Excelを辞めろというのは簡単です。
#と言って辞めるなら世話ありませんが。
代替案を出すのがデキるプログラマってもんでしょう。
とりあえず「仕様書」としての代替を幾つか見繕ってみました。
アウトラインプロセッサ等の利用
中でもNanaTreeはなかなか良いです。ubuntu/wineでもアッサリモッサリ動きます。
http://yourcolor.seesaa.net/article/134778238.html
ファイルフォーマットnnaは、XML+RTFなので、バージョン管理と非常に相性が良い。
マージできる可能性すらあります。
(wineではうまく動きませんでしたが)「仕様書」としてfix|提出する必要がある場合はrtfエクスポートで済みそうです。
より簡易な用途にはNamiで良いでしょう。
http://www.vector.co.jp/magazine/softnews/030723/n0307232.html
ファイルフォーマットnm2は、幾つか特殊な制御コードが挟まってますが、
ほぼSJISプレインテキストであると言ってよさそうです。gvimで開いて中身が読み取れるぐらいなので。これもバージョン管理と相性が良さそうです。
有名どころではSol4ってのが有るらしいのですが
http://homepage1.nifty.com/knowledge-osmo/
ファイルフォーマット不明
何某かの図が必要な場合。
「○○フロー」を描く場合Dynamic Drawが良さげ。
http://www.dynamicdraw.com/jp/dd/index.html
試してません。
何某かのアルゴリズム表現には、同氏の公開しているThought Tickler
http://www.dynamicdraw.com/jp/hr/index.html
http://www.vector.co.jp/magazine/softnews/060511/n0605111.html
がヤバ素晴しい感じです。
試してません。
#と言って辞めるなら世話ありませんが。
代替案を出すのがデキるプログラマってもんでしょう。
とりあえず「仕様書」としての代替を幾つか見繕ってみました。
アウトラインプロセッサ等の利用
中でもNanaTreeはなかなか良いです。ubuntu/wineでもアッサリモッサリ動きます。
http://yourcolor.seesaa.net/article/134778238.html
ファイルフォーマットnnaは、XML+RTFなので、バージョン管理と非常に相性が良い。
マージできる可能性すらあります。
(wineではうまく動きませんでしたが)「仕様書」としてfix|提出する必要がある場合はrtfエクスポートで済みそうです。
より簡易な用途にはNamiで良いでしょう。
http://www.vector.co.jp/magazine/softnews/030723/n0307232.html
ファイルフォーマットnm2は、幾つか特殊な制御コードが挟まってますが、
ほぼSJISプレインテキストであると言ってよさそうです。gvimで開いて中身が読み取れるぐらいなので。これもバージョン管理と相性が良さそうです。
有名どころではSol4ってのが有るらしいのですが
http://homepage1.nifty.com/knowledge-osmo/
ファイルフォーマット不明
何某かの図が必要な場合。
「○○フロー」を描く場合Dynamic Drawが良さげ。
http://www.dynamicdraw.com/jp/dd/index.html
試してません。
何某かのアルゴリズム表現には、同氏の公開しているThought Tickler
http://www.dynamicdraw.com/jp/hr/index.html
http://www.vector.co.jp/magazine/softnews/060511/n0605111.html
がヤバ素晴しい感じです。
試してません。
2011年11月27日日曜日
subversion時代のロック機能って、要らなくね？
出稼ぎ先でsvnを辞めさせてmercurialに移行を推進するときに
反論のうち一つが、次のようなものでした。
svnのファイルロック機能が使えなくなる。
これっておかしくね？
目的と手段を完全に履き違えてます。
ファイルロックってなぜ必要？
↓
バイナリファイルを管理しなきゃならないから。
マージできないからコンフリクトした時に面倒だから。
↓
差分管理の出来ないファイルをバージョン管理って、意味なくね？
↓
EXCEL仕様書を追放しましょう。
と言うのは極論だとしても。
わざわざ「ロックを取得」とかやるのは、CVS以前に逆戻りですよ。
筆者の考え方は真逆です。ファイルロックは要りません。
ある担当者がその作業を完了するまで、他の作業者の作業を止めるのは本質的ではありません。同じ「EXCEL仕様書」の別シートであっても、ファイル全体がコンフリクトします。これはEXCELとsvnの問題であり、作業者がそれに付き合って、作業の直列化をするべきではありません。
何でもいいから作業進捗はcommitするべき。そして作業を続けるべき。
それを「ローカルリポジトリ」という切り口で解決したのが、分散バージョン管理です。ファイルロックは要らないのです。
もちろんcommitしたのが「EXCEL仕様書」であれば、手動マージの手間は残ってるのですが、それを先送りにして作業を続けられるのをメリットとすべきでしょう。最後にまとめて出来ることは、先送りにしても良いはずです。
ちなみに、既に出稼ぎ先ではmercurialの導入が済んでますが、前述の反論はしてません。反論してきた彼を説得するのは、本質的ではないので省きました。
反論のうち一つが、次のようなものでした。
svnのファイルロック機能が使えなくなる。
これっておかしくね？
目的と手段を完全に履き違えてます。
ファイルロックってなぜ必要？
↓
バイナリファイルを管理しなきゃならないから。
マージできないからコンフリクトした時に面倒だから。
↓
差分管理の出来ないファイルをバージョン管理って、意味なくね？
↓
EXCEL仕様書を追放しましょう。
と言うのは極論だとしても。
わざわざ「ロックを取得」とかやるのは、CVS以前に逆戻りですよ。
筆者の考え方は真逆です。ファイルロックは要りません。
ある担当者がその作業を完了するまで、他の作業者の作業を止めるのは本質的ではありません。同じ「EXCEL仕様書」の別シートであっても、ファイル全体がコンフリクトします。これはEXCELとsvnの問題であり、作業者がそれに付き合って、作業の直列化をするべきではありません。
何でもいいから作業進捗はcommitするべき。そして作業を続けるべき。
それを「ローカルリポジトリ」という切り口で解決したのが、分散バージョン管理です。ファイルロックは要らないのです。
もちろんcommitしたのが「EXCEL仕様書」であれば、手動マージの手間は残ってるのですが、それを先送りにして作業を続けられるのをメリットとすべきでしょう。最後にまとめて出来ることは、先送りにしても良いはずです。
ちなみに、既に出稼ぎ先ではmercurialの導入が済んでますが、前述の反論はしてません。反論してきた彼を説得するのは、本質的ではないので省きました。
2011年11月25日金曜日
踊るプロジェクトと、踊らないエクセルガントチャート
筆者は40過ぎても現役プログラマなのですが、そんな事も言ってられないので、
プロジェクト管理の一端に首を突っ込まされることも多々あります。
具体的にはガントチャートですね。
検索でいらした方には解説は要らないでしょう。
問題はそれをメンテナンスするコストです。
日本人は、EXCELが大好き過ぎる人が多く、ガントチャートをEXCELで作ってしまうケースは多いと思われます。簡単なのなら良いですが、因果関係や、担当アサインを念頭に置いて、作業分解していくと、大変な項目数になる筈です。
進捗を「線画」で書いてしまうのはとりあえずは善しとしましょう。
ALTを押しながらだとセルにピッタリ合わせて作図できるらしい。知りませんでした。ただし、土日を手動で跨がなければなりません。これだけでも筆者からするとあり得ない手間ですが。
本質的な問題は、作業順序管理と、アサイン管理は、管理の軸が違うので、同じエクセルの「行」で管理できないことです。どうするか？と言うと、作業順序管理でまず「線画」で引いて、その線画をコピーして、それを担当者の行に持っていって、パズルしてると思います。後者の微調整が終わっても、前者に反映する訳ではありません。EXCELの線画はそういう風には出来てませんしね。この手間も正直ありえません。
で、さらにあり得ないのが、これを課長が一人で頑張ってるならともかく、たまたま休んだりして、このEXCELのシートの修正が、筆者ら現場まで降りてくることです。プログラマ層にEXCELの達人は少ないと思います。というか、前述の作業を手動で全部やってるとしたら、それはプログラマじゃないです。せめてマクロを書こうと思ってください。筆者はどっちも思いませんが。
商業製品としてはもちろんMicrosoft Projectが存在してますし、これを使ってる現場も多いはずですが、存在すら知らない人もまず居るでしょうね。
もちろんカウンタープロジェクトであるオープンソース類似品もいくつか存在します。筆者が試したのは次の2件です。
OpenProj http://sourceforge.net/projects/openproj/
http://gigazine.net/news/20090107_openproj/
GantProjectz
http://www.ganttproject.biz/
いずれもチャートそのものの作成は全く不満がありません。作業を次々を入力していって、因果関係を設定する時は、線画の一方から他方にドラッグすると、線を引いて、しかも日付の調整までしてくれます。当たり前。こんなの人間が手動でやる作業じゃないです。ここまでの作業は、GantProjectzの方が洗練してるように思いました。
ただし、担当者アサインは、いずれも作業を右クリックしてプロパティ。とかで、複数件の重複アサインが出来ちゃいますね。EXCELで管理してる人たちは、基本的に一人1作業で管理しているでしょう。また「右クリック」とかさせるのもアレで、チャートを握ってグリングリン動かしたい筈です。日本の課長連中に使ってもらうには、この辺りまで簡素化しないと普及しないかなと思います。
ということは作れば天下を取れるか？
プロジェクト管理の一端に首を突っ込まされることも多々あります。
具体的にはガントチャートですね。
検索でいらした方には解説は要らないでしょう。
問題はそれをメンテナンスするコストです。
日本人は、EXCELが大好き過ぎる人が多く、ガントチャートをEXCELで作ってしまうケースは多いと思われます。簡単なのなら良いですが、因果関係や、担当アサインを念頭に置いて、作業分解していくと、大変な項目数になる筈です。
進捗を「線画」で書いてしまうのはとりあえずは善しとしましょう。
ALTを押しながらだとセルにピッタリ合わせて作図できるらしい。知りませんでした。ただし、土日を手動で跨がなければなりません。これだけでも筆者からするとあり得ない手間ですが。
本質的な問題は、作業順序管理と、アサイン管理は、管理の軸が違うので、同じエクセルの「行」で管理できないことです。どうするか？と言うと、作業順序管理でまず「線画」で引いて、その線画をコピーして、それを担当者の行に持っていって、パズルしてると思います。後者の微調整が終わっても、前者に反映する訳ではありません。EXCELの線画はそういう風には出来てませんしね。この手間も正直ありえません。
で、さらにあり得ないのが、これを課長が一人で頑張ってるならともかく、たまたま休んだりして、このEXCELのシートの修正が、筆者ら現場まで降りてくることです。プログラマ層にEXCELの達人は少ないと思います。というか、前述の作業を手動で全部やってるとしたら、それはプログラマじゃないです。せめてマクロを書こうと思ってください。筆者はどっちも思いませんが。
商業製品としてはもちろんMicrosoft Projectが存在してますし、これを使ってる現場も多いはずですが、存在すら知らない人もまず居るでしょうね。
もちろんカウンタープロジェクトであるオープンソース類似品もいくつか存在します。筆者が試したのは次の2件です。
OpenProj http://sourceforge.net/projects/openproj/
http://gigazine.net/news/20090107_openproj/
GantProjectz
http://www.ganttproject.biz/
いずれもチャートそのものの作成は全く不満がありません。作業を次々を入力していって、因果関係を設定する時は、線画の一方から他方にドラッグすると、線を引いて、しかも日付の調整までしてくれます。当たり前。こんなの人間が手動でやる作業じゃないです。ここまでの作業は、GantProjectzの方が洗練してるように思いました。
ただし、担当者アサインは、いずれも作業を右クリックしてプロパティ。とかで、複数件の重複アサインが出来ちゃいますね。EXCELで管理してる人たちは、基本的に一人1作業で管理しているでしょう。また「右クリック」とかさせるのもアレで、チャートを握ってグリングリン動かしたい筈です。日本の課長連中に使ってもらうには、この辺りまで簡素化しないと普及しないかなと思います。
ということは作れば天下を取れるか？
2010年4月13日火曜日
清書ツール
マイクロソフトオフィスを愛用しちゃってる人は、
日本中にかなりの数に登ると思います。
買ってきたPCの中に入ってりゃ、そりゃ使うでしょうよ。
会社のPCに入ってなけりゃ、
そりゃ家から持ってきて入れるでしょうよ。
#筆者はやったことはありませんが。
それはマイクロソフトが望んだことでしょう？
プロダクトアクティベーションとか今更何をやってるやら。
しかし現実問題、ワードもパワーポイントも、
「画材」としてしか使ってない人が殆どでしょう。
従来まで「紙」でやっていたことを、
そのままワードやらパワーポイントやらで続けようとします。
日本人の場合は「帳票」って奴があるらしく、
キレイに罫線を引いてレイアウトした「帳票」に
ギチギチに文字を書き入れるのが美徳です。
上司の承認印をもらう欄も忘れちゃいけません。
電子化しようとしても、「帳票」からどうしても離れられません。
ワードでは罫線でのレイアウトがやりにくいので、
エクセルを使う人はかなり多いです。
しかしエクセルは、ページの概念が希薄なので、
「ページ」の代わりに「シート」に分けて書きます。
めくるのが面倒くさいんですけど。
それに文字を入れるときは「罫線を避けて」書かなきゃならない。
正直、MS-DOSの「ワープロ」に戻った心境です。
皆さん、よく平気な顔してやってるなと思います。
おっとイケネエ。はみ出しちまった。フォントサイズを縮めて、っと。
これで入った。
貴方が資料を作るために、パワーポイントと向かい合ってる時間の殆どは、
レイアウト調整に明け暮れてることでしょう。
手書き時代より、キレイに仕上がる。それだけです。
手間は、下手すると増えてるかもしれませんね。
強調しておきます。
「資料を作る」のは手段であって、目的ではないはずです。
あくまで、打ち合わせなり、顧客への説明のため、のはず。
でもパワーポイントに向かい合ってるウチに、
ページ数を増やさなきゃいけない気になってくる。
綺麗に作りたくなってくる。
目的脱線、と呼ぶことにしたい。
帳票にこだわってる事自体も、業が深くてアレですが、
清書ツールとして、エクセルやらワードやらを選択するのも間違いです。
ワードは文章を書くためのもの。
例示するなら、小説を書くためのもの、
と言い換えてもいいかもしれません。
小説に罫線は使いません。
故に罫線が使いにくくてあたりまえです。
エクセルは表計算のために使うものです。
セルには、数字あるいは品名を入れるものです。
そこに文章を入れる日本人が悪いのです。
結論として、「清書」ただそれだけのために、
不適切なツールを使って、苦労を増やしている。
手段(書類作成)のための手段(清書ツール)ですからね。あくまで。
仕事を増やす仕事に絶望した！
納品物件としての、設計書類
受注開発稼業、
納品はプログラムだけじゃなくて文書も必要です。
「ドキュメント」という単語は一般名詞ですが、
この業界で言えば、設計書類の事を指す。らしいです。
20年ぐらい前までは、ドキュメントの厚さで、
受注金額が決まるという良く判らない風潮がありました。
作った方からすれば、ある程度の達成感がありますが、
受け取った側はそれを使うかって言ったら使わないです。
ウォーターフォール型の、古典的開発スタイルは、
最初の設計書類と、後期のプログラム実装とでは、必ず乖離があります。
なぜって、修正が面倒臭いから。
故に、納品後で、「別人」が修正しなければならない場合はままあります。
納品はプログラムだけじゃなくて文書も必要です。
「ドキュメント」という単語は一般名詞ですが、
この業界で言えば、設計書類の事を指す。らしいです。
20年ぐらい前までは、ドキュメントの厚さで、
受注金額が決まるという良く判らない風潮がありました。
作った方からすれば、ある程度の達成感がありますが、
受け取った側はそれを使うかって言ったら使わないです。
ウォーターフォール型の、古典的開発スタイルは、
最初の設計書類と、後期のプログラム実装とでは、必ず乖離があります。
なぜって、修正が面倒臭いから。
故に、納品後で、「別人」が修正しなければならない場合はままあります。
契約方法にもよりますが、ソース付きで納品してしまったら、
それは納品先でも修正できてしまうので、
わざわざ発注するより、自前でやっちまえ、というのは正しいです。
その場合でも、プログラムに付いてきたであろうドキュメントは使いません。
そもそも、大量のドキュメントを受け取っても途方に暮れるだけです。
実際、途方に暮れました(実体験)
そもそも、大量のドキュメントを受け取っても途方に暮れるだけです。
実際、途方に暮れました(実体験)
仮に読んだとしても何のこっちゃ判りません。
4.5次元の「仕様」を、2次元未満の文書に落とす訳ですから
4.5次元の「仕様」を、2次元未満の文書に落とす訳ですから
自分の期待している「次元」でなければ、推理小説読むようなもんです。
有る程度の熟練者なら、プログラムを読んでしまった方が早い。
そして、その別人の修正によって、
さらにドキュメントとプログラムでの乖離が大きくなります。
なぜそんな事が起こるのか？
理由は簡単です。
ドキュメントに細かい事まで書きすぎたからです。。
変数名とかの話をせざるを得なくなる。乖離の危険が大幅アップ。
そもそもフローチャートを書こうというのは、
プログラムの修正コストが、非常に高価だった時代の名残り。
そして、その別人の修正によって、
さらにドキュメントとプログラムでの乖離が大きくなります。
なぜそんな事が起こるのか？
理由は簡単です。
ドキュメントに細かい事まで書きすぎたからです。。
関数名とか引数の意味ぐらいまでなら、まだ良いのですが、
関数内部のフローチャートとか描いちゃったらもうダメです。変数名とかの話をせざるを得なくなる。乖離の危険が大幅アップ。
そもそもフローチャートを書こうというのは、
プログラムの修正コストが、非常に高価だった時代の名残り。
ディスプレイもキーボードも無かった時代。
ところが21世紀になってみたら
物件自体が、小規模化＆短期化＆低予算化してますので、
ドキュメントを書く時間すら惜しかったりします。
- パンチカードだの、
- 紙に書いてパンチャーに渡すだの。
- 順番待ちだの。
黙って待ってる訳にもいかないので、紙と脳みそでデバッグするしか無かったのです。
昔話です。筆者は伝説でしか知りません。
フローチャートが全面的に要らない。とは言いません。
製作者が、思考を整理するためには非常に有効です。
ただし、納品物件としては、要らないんじゃね？と思う。
昔話です。筆者は伝説でしか知りません。
フローチャートが全面的に要らない。とは言いません。
製作者が、思考を整理するためには非常に有効です。
ただし、納品物件としては、要らないんじゃね？と思う。
20年前ぐらいまではまだ良かった。予算はあったので。
ところが21世紀になってみたら
物件自体が、小規模化＆短期化＆低予算化してますので、
ドキュメントを書く時間すら惜しかったりします。
本当に細かい話は、ソースを読んでしまった方が確実です。
そして、納品物件としてのドキュメントは、
オヤクソクではなく、目的を考えるなら、
ソースを「補間するモノ」でなければなりません。
要件定義だけはすり合わせる必要がありますが、
クライアントの想像力が豊富でないと、大抵何の話か通じません。
結局、修正せざるを得なくなります。
じゃあもう作ったの見せちゃった方が早くね？
結局、修正せざるを得なくなります。
じゃあもう作ったの見せちゃった方が早くね？
それでも依然として、「COBOLで慣らした」感じの方々は
エクセルで罫線を作り込んだフォーマットを持ってきて
そこに文章を入れたくて仕方ないらしい。
「帳票」って奴ですね。
エクセルやらワードやらを、
結局「清書ツール」としか使ってないので
運用は、「紙文書」を逸脱して居ません。
ということに気づいているのか居ないのか？
それはそれで問題があるのですが、それは別の機会に。
登録:
投稿 (Atom)