第2回 中堅・中小企業の経営者はなぜ「IT嫌い」になるのか
多くの中堅・中小企業は、ソリューションプロバイダに不信を抱いている。システムの提案内容だけでなく経営者に不安を抱かせないようにする姿勢こそ、受注獲得の決め手になる。そのためにも、まずは相手の身の丈に合った最小限のIT化を提案すべきだろう。 筆者は経営とITのコンサルタントとして中堅・中小の特に製造業の経営者と話をする機会が多い。このとき、どの経営者も一口で言えばIT化に懐疑的である。「君、ITでは儲からんよ！」が口癖と言っても過言ではない。日頃、よく聞く話をまとめると図1のようになる。ほとんどは中堅・中小ユーザーとソリューションプロバイダのコミュニケーション不足に原因があるようだ。まずは実際の事例から、1つずつひも解いてみよう。 「システムでどうなるのかを聞いているのに…」 愛知県のG社（金属加工業）を訪問したとき、こんなケースに遭遇した。G社には、あるパッケージベンダーが生産管理システム
意図が伝わる設計書作成の心得【第6回】
仕様書は，複数のメンバーが共同で作成することが多い。したがって,コミュニケーションを怠れば,「仕様書間の不整合」や「保留事項の連絡不徹底による手戻り」などの問題を起こしやすい。こうしたリスクを避け, 効率的に仕様書を作成するには,どうすればよいだろうか。頻繁に起こる2タイプの実例を通して,その原因と対応策を考えていこう。 実質的な作業メンバーが1人というプロジェクトもあるだろうが，大半は複数のメンバーによる共同作業になるだろう。こうした現場では，仕様書の作成を複数人で分担して行う必要が生じ，プログラム間の仕様の調整に手間がかかる。 これは設計工程全般に言えることではあるが，特に仕様書の作成フェーズでは，基本設計とは異なるレベルでユーザーと仕様の調整を行う。このため，より一層，コミュニケーションに注意を払う必要が生じる。 それを怠ると，誰も気づかないうちに仕様書間の不整合が起きてしまい，後に
有能なプロジェクトマネージャを育てるには（1）
団塊の世代が定年を迎えようとしている。しかし、団塊の世代が持っているノウハウは若い世代に受け継がれているのだろうか。今回から3回にわたって、2007年問題ともいわれているノウハウ継承の問題について、特にプロジェクトマネジメント能力の育成に焦点を当てて考えていく。 団塊の世代が組織から去りつつある現在では、プロジェクトマネージャの量的不足・能力不足を懸念する企業が多い。システム開発のプロジェクトマネジメント能力の育成について、今回から3回にわたって考えてみる。 問題とその背景 団塊の世代が歩んできた道 団塊の世代を中心にその前後を形成する世代は、日本企業のIT化の進展とともに、その中で能力をはぐくんできた。この世代の人たちが社会で活躍を始めた1970年代は、日本企業が本格的に情報システム化に取り組みだした時期でもある。 オンライン化やデータベース化などにより、情報システムが業務の形態を抜本的
意図が伝わる設計書作成の心得【第4回】
「仕様書」は，設計者とプログラマをつなぐ重要なコミュニケーション・ツールだ。それゆえ，安易な書き方をすると問題を起こす。よく議論されるのは，「仕様書の内容はどこまで詳しく書くのが適当か？」という点だろう。過剰品質を避け，効率的に書きたいところだが，きちんと意図が伝わることが大前提である。二つの実例を通して，そのキー・ポイントを紹介する。 今回から，題材を「仕様書」に移して設計書作成の心得を紹介していこう。 前回までは，ユーザーからの要望聴取を基に作成する基本設計書を題材として，設計者とユーザーとのコミュニケーションを軸に展開してきた。これに対し，今回から取り上げる「仕様書」は，基本設計書を基にシステムを実装するプログラマやSEに対して，より具体的なシステムの詳細を伝える設計書である（図1）。 このような設計書は「詳細設計書」や「プログラム仕様書」など，様々な名前で呼ばれていることと思う。ま
【ワタミ】毎週火曜、本社で改善指導店長業務を4分の1に削減（後編）
簡単に「スピード」などを報告 業革会議は毎週、全国からマネジャーなど200人以上が集結し、東京都太田区の本社で開催される。まず午前7時から、渡邉社長などが司会を務める第1会議で幕を開ける。本部スタッフ、各業態・地域の営業本部長と部長、マネジャーが参加し、ワタミに寄せられたクレームの報告と分析を徹底して行う。 9時半になると、第2会議がスタート。「和民」や「わたみん家」など業態別に、業態トップの幹部社員とマネジャーが集まる。第1会議で議論した分析結果を基に、クレームへの具体的な対応策を作る。 11時には、業態別に本部長と部長、マネジャーが参加する第3会議に移行。第2会議で決議されたクレーム対応策の告知と、個々の店舗の課題について対策を話し合う。 実は、これだけ徹底的に議論を重ねる会議を毎週開催するから、店舗支援システムの入力項目が少なくて済み、入力時間を短くできた。店長は1日の業務の良しあし
意図が伝わる設計書作成の心得【第3回】
効率よく，ユーザーと必要十分な打ち合わせをしたつもりでも，基本設計書に大きな“抜け”が生じることがある。システムの目玉機能ばかりに目を奪われたり，設計者が補って考えるべきところで手を抜いたりするためだ。設計書の“抜け”がどうして生まれるのか，それを防ぐにはどうすればよいかを，よく起こりがちな二つの実例を通して考えてみたい。 いざ基本設計書をレビューしてみると，システムのある部分に関する重要事項がすっぽりと抜け落ちていた――。 このような話は，システム開発の現場でしばしば耳にするのではないだろうか。図1のように，システムの構築に欠かせない重要な事項が，なぜかユーザーからも設計者からも指摘されないことがあるのだ（あるいは指摘されながらも議論が不十分なことがある）。こうした状況で基本設計書を作成しても，その通りに作るとシステムは意図通りに動かない。 問題が表面化すると，基本設計書の“抜け”に対す
Part 2 失敗しないCMS導入ワークフロー：ヒアリング、プランニング | 成功するCMS導入の必須ノウハウ
失敗しないCMS導入ワークフロー 多数の導入経験で磨かれた手順と設計書 ページではなく“コンテンツ”を管理前置きはこのくらいにして、CMS導入に関する流れを説明しよう。スリーイントでは、CMS導入において以下のようなワークフローを使用している。これはCMS導入が“システム構築”という面を持つ一方で、システム系とはまったく関係ない“コンテンツ管理という”面を持っている非常に厄介な仕事だからだ。順序だててきちんと進めなければ、成功し得ないプロジェクトだといえるだろう。 CMSが単にウェブサイトを管理するものだと考えているならば、このプロセスは必要ないのかもしれない。なぜならば、現状のウェブサイトを管理しているのはウェブマスターであり、ウェブサイトについてはほぼすべてを熟知しているからだ。システムを構築するベンダーとウェブマスターとの間で設計をして構築すればいいだろう。しかし、これによって何が構
意図が伝わる設計書作成の心得【第2回】
設計者とユーザーの間では，システムの仕様を巡って「言った，言わない」の泥仕合をすることが少なくない。両者の思惑や認識がすれ違ったまま基本設計書を作ってしまった結果である。困ったことに，これは一見良好なコミュニケーションを確立したと思われる場合にも起こり得る。このテーマに基づき，二つの実例を通して設計書作成の心得を紹介する。 基本設計書は，ユーザーと円滑にコミュニケーションを行うためのツールであり，コミュニケーションの結果を書き留めたものである。 それ故，コミュニケーションがうまくいかないと，基本設計書に残された情報に思わぬ勘違いや間違いが埋め込まれ，これが後々，プロジェクトに大きな危険をもたらす可能性がある（図1）。恐ろしいことに，誤解の種はユーザーや設計者が発した，たった一言でも生じ得る。基本設計書の作成段階においては，とにかくユーザーとのコミュニケーションを重視し，お互いの考えやシステ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「うちの部下は自発的に仕事をしない」 この悩みに答える（後編）：NBonline(日経ビジネス オンライン)