優れたツールが備える「ＢＤＴ特性」 - 設計者の発言
「パワーポイント」をはじめとした完成度の高いツールには「ＢＤＴ（"Baka Demo Tsukaeru"の略）特性」が備わっている。ＢＤＴ特性が不十分なツールは、出来が悪いか発展途上かのどちらかなので、それをあえて使う際には必要以上のコストを覚悟しなければならない。かといって、ＢＤＴ特性が十分であれば誰にとっても都合がよいということにはならない。理想的なＢＤＴ特性を備えるツールを使うユーザには、別の意味の覚悟が求められることがある。 ある種のソフトウエアには、それを使えることを公的に示すための資格があったりする。じつは、そのソフトウエアが「じゅうぶんに使いにくい」からこそ、その種の資格の価値が認められるというところがある。普及しながら改善されてゆく過程で、ソフトウエアは「ＢＤＴ特性」を獲得する。最終的に、そのソフトウエアを操作できることを示す資格は意味を失う。こういう資格はこれまでもあった
ビジネスリーダーに必要な「経営の３言語」 - 設計者の発言
ビジネスリーダーには「経営の３言語」が必要である――これは何年か前にビジネス雑誌で読んで強く印象に残った意見だったのだが、誰が書いていたのか覚えておかなかったのを悔やんでいた。最近それがコンサル会社の社長さんでもある会計士の山根節（やまねたかし）氏の意見であることがわかった。彼の言う「情報リテラシーとしての経営の３言語」とは、自然言語・コンピュータ言語・会計言語のことだ。これらはビジネスリーダーだけでなく、企業システムの開発者が身につけておくべき基本的素養でもある。 ◆１．自然言語 自然言語とは、一義的に母国語を指します。日本語がキチンと操れない人は、職人には向いても組織のリーダーには向きません。（「経営の大局をつかむ会計」山根節、光文社新書） 氏の言うように、母国語が洗練されていないようではリーダーは務まらない。リーダーは折に触れて所属メンバーにチームの方針や理念を語らねばならない。「黙
プログラマではなくテスターとして現場デビューする - 設計者の発言
筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない（今思い出しても冷や汗が出る）。「自分に代わってテストだけをやってくれる要員」がいてくれたらと本気で願っていた。 だから、１年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学
集中するためにオフライン環境へ - 設計者の発言
このエントリを考えていた矢先に、編集者と打合せをした。今度の本はレイアウトがややこしいので、直接会って話をしないとゲラを校正できなかったからだ。けっきょく喫茶店を３軒をハシゴして６時間かけて本文全ページのレイアウトを確定できた。電話もない、誰からも声をかけられない、ネットにもつながらない。仕事のための技術と意志を持つ人がそんな環境に置かれたなら、期待以上の密度で仕事は進むものだ。 広く知られているとおり、電話に出るとフロー（集中）状態が霧散してなかなか元に戻れない。まとまった集中時間を確保するために電話は大敵であるが、今は電子メールがぐんと普及したおかげで電話での妨害は減っている。 ところが現在の職場環境で、仕事への集中を阻むものとして無視できないのはその電子メール、それにブラウザである（あと会議ね）。ちょっと一息ついてメールをチェックしたり、探しものをするためにブラウザを立ち上げたりする
文章術：断言して根拠を示す - 設計者の発言
文章を書くことに苦手意識があったら、システム設計の仕事は務まらない。設計情報には図面だけでなく、相応量の文章が添えられるのがふつうだからだ。そして、キャリアの初期にまっとうな文章能力を身につけておいたほうがいい。設計の仕事をまかされてから文章力を磨こうというのではドロナワに過ぎる。 筆者はそれまでも文章を書くことが好きだったが、１０年前にある本を読んでからますます好きになった。それ以前は良くも悪くも「情緒優位な文章」を書いていたのだが、その本を読んでからは論理で畳み込んでゆくスタイルにすっかり変わってしまった。それほどにその読書体験は強烈だった。じっさい、筆者の最初の本（「データモデリング入門」）はその著者が書いた本の影響を強く受けている。文章書きのための参考書は山ほど出ているが、訊かれたときには筆者は今でも迷わずにその本を薦めている。 それが、小野田博一著「論理的に話す方法」（日本実業出
システム設計は「成果物を他人にジロジロ見られるハズカシイ仕事」 - 設計者の発言
◆設計図を見られたくない設計者たち 筆者もパネラーとして参加した「ＤＯＡ＋コンソーシアム第三分科会」の第１回会合「データモデリングって実際どうなの？(2005.2.15)」の議事録が公開された。読み物としてもなかなか面白いのでお勧めしたい（ただし閲覧するためにはＤＯＡ＋への会員登録が必要）。 とくに興味をそそられたのは、基調講演をしたテプコシステムズの國澤（くにさわ）氏のパネルディスカッションでの発言だ。社内での設計事例を集めたモデルライブラリーを作ろうとして挫折した理由として、彼は次のように語っている。 プロジェクトをやっている人自身が自分のつくったモデルを公開したがらないということがより大きな問題でした。自分が作成したモデルを公開して、周りから文句をつけられたくないというメンタリティが非常に強いようです。 ◆テクニカルレビューの困難 筆者も同じような経験をしたので彼の無念さがよくわかる
「押しかけ実況書記」のススメ - 設計者の発言
打合せの場で、頼まれもしないのにホワイトボードの前に立って書記役をやることがある。討議の内容をその場でボード上に図解したり、検討事項を文章として書き表すのである。「実況書記」とでも呼べそうな役割なのだが、ボードのコピー等を文書として残すためというより、討議の進行を導くための工夫として欠かせない。だから、誰もホワイトボードの前に出ないようなら筆者は進んでこの役を勤めるようにしている。 とりとめのない討議のことを「空中戦」と言うことがある。たとえば、誰かが何か重要なことを言ったのに、それに対して別の誰かがどうでもいいようなコメントを言って、そのどうでもいいようなコメントの一部にもとづいて話が展開するといった調子だ。結果的に最初に提示された重要な意見は無視されるし、論点も行き当たりばったりになる。「空中戦」という言い方は、いつまでたっても論点が空中をさまよって着地しない、カジュアルな言葉のやりと
業務マニュアルの作り方 - 設計者の発言
業務マニュアルをまとめるのは想像以上にやっかいな仕事である。とくに、コンピュータを用いて進める業務の場合、パネルや帳票（これらを合わせて入出力フォームと呼んでおく）の使い方を盛り込む必要があるのでややこしい。仕事の手順の軸、入出力フォームに関する説明の軸、および各手順における入出力フォームの使い方の軸とが複雑に交錯する。コンピュータ上の業務システムの仕様を巻き込んで周到に構造化しない限り、使いやすく保守しやすい業務マニュアルは生まれない。 ◆業務フローと業務マニュアル そもそも業務マニュアルとは何か。それはいわゆる「業務フロー」とはどう違うのか。まず、筆者が提唱する三要素分析法での、業務フローと業務マニュアルの位置づけを確認しておく。データフローダイアグラム（ＤＦＤ）で描かれた業務フローには、いくつかの「業務プロセス（個々の仕事の単位のこと）」が載っているが、それぞれの業務プロセスのあり方
家計における「資本勘定」とは（後編） - 設計者の発言
前回、簿記が次の「４象限」にもとづく残高構成の変化を捉える体系だと説明した。これらがさまざまな仕訳科目の最上位分類となる。 借方 貸方 ＢＳ 資産 資本・負債 ＰＬ 費用 収益 家計であってもこの分類は基本的に同じだが、「資本」がわかりにくい。家計は資本金がいくらなどといった経済主体ではないからだ。そこで資本を、決算時に資産から負債を差し引いて決まる勘定、すなわち「自己資産」とみなす。さらに費用と収益をそれぞれ「支出」と「収入」と表記してみると、「家計簿」っぽく見えてわかりやすい。 ＜借方＞ ＜貸方＞ ＢＳ 資産 負債 現預金 自己資産 １００万円 １００万円 ＰＬ 支出 収入 ――――――――――――――――――― 合計 １００万円 合計 １００万円 家計は元入れ（もといれ。元手の資金を資本金として事業を始めること）から始ま
家計における「資本勘定」とは（前編） - 設計者の発言
簿記システムでは、さまざまな取引が「仕訳」として入力され、帳簿組織に集計されるようになっている。仕訳毎の「貸方・借方」の金額が一致していることから、簿記は「貸方・借方」の二元論と思われがちであるが、この理解はまったく不正確である。 簿記は「貸方・借方」の次元と「ＢＳ（貸借対照表）・ＰＬ（損益計算書）」の次元とが交差する４象限を基礎とする、「四元論」とも言うべき体系である。それらの象限には以下のような呼び名がある。 借方 貸方 ＢＳ 資産 資本・負債 ＰＬ 費用 収益 というわけで簿記は、「収益」、「費用」、「資産」、「資本・負債」の４つの勘定グループ間の振替を記録したり、振替にもとづく残高（合計額）の変化を捉えるための体系である。 具体的に見てみよう。たとえば、現金１００万円を元手に会社を起業したなら、その時点で次のような取引が認識される。 ＜仕訳１＞ 現金１００万円／資本金１００万
システム要件を捉えるために必要な「疑り深さ」 - 設計者の発言
システム設計者には詐欺師に対するときのような「疑り深さ」が必要だ。そのような姿勢によってしか探り当てられないタイプの要件が存在するからだ。その種の要件はしばしば重大で、捉えそこなうと痛い目に会う。 ◆システム要件の分類学 システム要件は、ユーザによって自発的に語られる場合と語られない場合とがある。ユーザが独自にまとめた要件定義書などは「語られた要件」の代表的なものだ。第三者がまとめたとしても、ユーザに一方的に語らせただけのものであればこれと似たものになる。しかし、そこに書かれたことを漏れなく取り入れるだけですべての要件をまっとうできると設計者が考えているとしたら、あまりに純朴過ぎる。 システム要件には、「語られていないけれども無視できないもの」も「語られているけれども無視すべきもの」も存在する。つまり、システム要件には「語られたか、語られなかったか」と、これに直交する「無視すべきか、無視で
システム設計に求められる適性 - 設計者の発言
◆他の職業との比較が重要 以前、システム設計は専門職であるからには求められる適性があると指摘したが、そこらへんをもう少し具体的にしておきたい。 およそどんな職業向けであっても適性の議論になると、実務者にさえ「そんなスーパーマンってこの業界にいたっけなあ」と皮肉りたくなるような安直な理想像が描かれやすい。とくに論者が職業人として自信に満ち溢れている場合に、そのような議論になるのかもしれない。反対に、自分の職業生活にやけっぱちになっている論者だと「打たれづよさ」だの「何よりも体力」みたいな、わかりやすいが乱暴な議論になりそうだ。 重要なのは「他の職業と比べた場合に、とくにどんな素質が求められるか」、さらにその職業において「劣悪であることが致命的でない素質は何か」を示すことである。たとえば、しばしば耳にする「システム開発者にとってはコミュニケーション能力が重要である」という主張は却下される。なぜ
「As-is先行」か「To-be先行」か - 設計者の発言
前回、ＤＯＡとＯＯＡとの対立の話を書いたが、ＤＯＡとて一枚岩ではなく、いろいろな考え方をする人たちがいる。だから、筆者も参加している「ＤＯＡ＋コンソーシアム」の集まりは、椿正明博士や佐藤正美氏といった歴々の方法論者や、商売上競合しそうな営業担当者同士が呉越同舟で語り合うという、奇跡のような企画である。参加者の考え方の違いは想像以上で、「どうも偶然にも、我々は全員『ＤＯＡ＋コンソーシアム』という集まりに名を連ねているらしい。一致点が見つかってよかったなあ」なんて冗談が出るほどだ。それほどに違いを楽しめるというのも、本質的な部分が共通している余裕ゆえなのだろう。 ＤＯＡの中でも議論になりやすいのが、「現状分析と基本設計のどっちを先にやるべきか」という問題だ。その前後関係が分析・設計手法の前提をまったく変えてしまうからだ。まあ、けっきょくは「個別の案件毎に特性が違うから、どっちが正しいとはいえな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
