PMノウハウとは何か？──組織的ノウハウ共有の事例から：有能プロジェクトマネージャ勉強会より（1）（2/2 ページ） メソドロジとは 一度、ここまでのまとめをします。メソドロジ（方法論）とは、ある目的や狙いを達成するために、それをうまくやるための「コンセプト（概念）」「メソッド（方法）」「プロセス（手順）」「ツール」の一連のシステム（関連する組み合わせ）、といえます。 「コンセプト」とは、目的・狙いに寄与する根本的な考えのことです。メソドロジの価値は、このコンセプトが優れたものであるかどうかで決まります。 「メソッド（方法）」とは、コンセプトを実現するための主要な技法や手法、技術などをいいます。 「プロセス（手順）」とは、コンセプトおよび方法から展開された仕事の進め方で、業務フローなどで表現されます。 「ツール」とは、手順の中で用いられる設備、運搬具、冶工具など現場で直接対象物を扱うものや

株式会社リアルナレッジ 代表取締役 秋池 治 横浜国立大学卒。メーカー系情報システム会社にてシステム企画とシステム開発に従事。その後、ユーザー系企業でデジタルビジネスの企画および社内改革に取り組む。2003年に数名の仲間とともに株式会社リアルナレッジを設立、業務プロセスの可視化やプロセスの最適化により、経験や勘に依存せず業務を遂行するためのパフォーマンスサポートを提供している。著書に『情報エキスパート』（アプライドナレッジ刊）がある。 さて、なぜいま「問題発見力」が重要なのでしょうか。従来のマネジメントというのは、例えば営業であればみんなが同じ行動をする中で、それを管理すること──すなわち「マネジメント＝管理」という意味合いで使われてきました。しかし、いまのビジネスは複数の高度な要素で成り立っていますから、マネージャがすべての面でスタッフより優れているとは限りません。つまり、組織は「多様な

ITアーキテクトという職種は、その職種をつくり上げてきた先人がいたからこそ、今日存在するものだといえる。ITアーキテクトをつくり上げ、現在第一線のITアーキテクトとして活躍しているエンジニアは、どのような道筋をたどってきたのか。また、今日のITアーキテクトの流行をどのように見ているのか。情報処理推進機構（IPA）ITアーキテクト委員会の主事を務める日本IBM サービス事業 ストラテジー＆コンピテンシー IBMディスティングイッシュド・エンジニア ITアーキテクト 榊原彰氏のインタビューをお送りする 私が入社したときには、実はITアーキテクトという職種は存在していませんでした。現在でいうプロジェクトマネージャもITアーキテクトもすべて「システムエンジニア」（SE）という1つの職種でくくられていたのです。システムエンジニアのほか、メインフレームマシンの保守を担当する「カスタマーエンジニア」、そ

前回までのあらすじ 前回、仙台支社から本社に転勤してきたばかりで張り切る初級シスアドの坂口啓二は、同僚で経費精算を担当する松下のためを思って経費精算ツールを作った。しかし、説明不足などの行き違いが原因となり、松下真樹との関係を悪化させてしまう。このままではツールが使われなくなるばかりか、新任早々同僚との溝を深めたまま仕事をしていかなければならない。果たして、坂口はどのような方法で解決を図るのか。 上級シスアドとの運命の出会い 坂口と松下が一戦交えた日の2日後の夜、坂口は椎名純平に誘われて新宿駅南口に程近い、甲州街道沿いの雑居ビルの地下にある居酒屋に入った。和風の落ち着いたたたずまいで、6人くらい入れるシンプルなボックス席が並び、どのテーブルにも一輪挿しの花が置いてある。 坂口　「なかなかしゃれた店ですね、ここ」 椎名　「テーブルごとに仕切られてるから、ゆっくり話がしやすいんだ」 椎名は、席

IT化の手段や方法はしばしば「ソリューション」と呼ばれる。経営や業務の問題・課題（プロブレム）に対する問題解決（ソリューション）という意味だ。問題解決をするうえ、さまざまなITの要素技術よりも重要なスキルがある。それが“問題発見力”だ 問題解決は、“真の問題”の発見がポイント 情報システムは、本来業務上の課題や問題、もしくは経営上の課題や問題を解決することを目的として開発・導入されるものです。結果としてそれはERPの導入であったりCRMシステムの開発であったりするかもしれませんが、その根本には必ず“課題や問題の解決”があるはずです。ところが実際にシステムを導入したり構築したりするIT部門やプロジェクトチームが、その目的を正しく理解できないとしたら、システムの導入が“課題や問題の解決”に結び付かなくなってしまいます。 システム開発における数々の問題は、開発の依頼者と開発側の問題認識のギャップ

Webアプリケーション開発案件の短納期化、高品質化、低コスト化要求に応えるために、ソースコード自動生成技術を活用する手法が注目されている。アイデア自体は昔から存在するものの、これまで大きく普及してこなかった自動生成という分野が、いまなぜ再び脚光を浴びつつあるのか。開発現場では顧客の高品質化要求や短納期要求により、もはや5％や10％の生産性向上策では負荷を吸収できずにいる。思い切って生産性を5倍、10倍へと上げるためには「できるだけコードを書かない」という発想の転換を行うしかないと気付き始めてきたことが大きい。ここではその技術進化の過程を追っていくとともに、ソースコード自動生成技術分野の最新状況と、これによるソフトウェア開発作業の現場への影響を紹介する。 自動生成技術の歴史 ソースコードを自動生成させるという考え方自体は古く、FortranやCOBOLが全盛の時代から今日に至るまで、さまざま

ユーザーから要求をヒアリングし、管理するのはコンサルタントやプロジェクトマネージャーの仕事だと思っていないだろうか。ユーザーからの要求は、システムのアーキテクチャを規定する大切な要素であり、要求の可視化や管理はITアーキテクトが率先して担当すべき分野といえる。現場のITアーキテクトは、あいまいで頻繁な変更が発生する「要求」をどのように可視化し、管理しているのか。 要求を管理し、統制する仕組みの重要性 IPAのITスキル標準センターのITアーキテクト委員会では、「ITアーキテクトは成果物に対し、以下の3点について責任を持つ」としている。 アーキテクチャの品質（機能性／信頼性／使用性／効率性／保守性／移植性） 経営戦略、戦略的情報企画で要求されている成果・効果 当該プロジェクトで要求される成果・効果 上記3点について責任を持つのはITアーキテクトだが、評価を下すのはユーザー側だ。つまりITアー

筆者は、妻と一緒にイタリアを巡る18日間の小旅行から戻ったばかりだ。今回の旅は研究に追われる日常の良い息抜きになったし、うるさく呼び掛けるコンピュータの前に座らずに考える時間を持つこともできた。 絵画、彫刻、建築の壮大な傑作を夫婦で見ていくうちに、筆者は何かいつも見慣れたものを見ている感じを抱くようになった。筆者は、約2000年前のベスビオ火山の噴火によって地中に埋没した古代の街の残骸の中をさまよいながら、構築物の高度な設計や実用性に畏敬の念を抱いた。そして、これらの過去の業績と今日の優れたソフトウェアシステム、すなわち複雑な問題に対するソリューションのスタイル、構造、そして簡潔な表現を尊敬せずにはいられない「傑作」との間に強力なつながりがあることを悟った。このようなシステムは誰でも目にしたことがある。中には、その開発に運良く何度か携わった方もいるだろう。 これらの作品と過去の巨匠を比較し

本連載は、メタボリックスの山田正樹氏が、仕事の合間に読む数冊の書籍に刺激を受けて思考した過程やその結果を記述したものである。参考にするのは必ずしもソフトウェア工学に関わる書籍ではないかもしれないが、いずれその思考の軌跡はソフトウェア工学的な輪郭を帯びることになる。（＠IT編集部） 生産性向上のメカニズム ソフトウェア開発における「生産性」とは何か。厳密に定義するのは難しい。生産性とは基本的には「あるアウトプットを得るのにどれだけのコストをかけたか」という尺度だ。さすがに「アウトプット」をソース・コード行数で測っても無駄だという認識は広まってきたと思うが、じゃあ代わりに何を使えばいいのかはいまだにはっきりしない。ユースケースやストーリーで測る考え方もある。そんなものは存在しないという意見すらある。 そういう場合には視点を1レベル上げて考えてみよう。つまり、ソフトウェア開発だけ考えているから分

企業の健康を診断する「業務分析」～IT技術者のための戦略・業務分析入門～：事例で学ぶビジネスモデリング（4）（1/3 ページ） 企業における健康志向 皆さんは、深夜のテレビCMを見て思わず健康器具を購入してしまったとか、効果が出るかどうか分からないサプリメントに何万円も費やしてしまった経験はないだろうか。実は、企業においてシステムを構築する場合にも、これと同じようなことが往々にして起きている。競合他社がERPを導入したので自社も導入を検討するとか、コンサル会社から成功事例を聞いて、CRMパッケージの導入を決断するといった話を聞くと、個人が健康器具やサプリメントを購入する話に似ていると思うことがある。本当にその企業の健康状態に合った健康法の導入が行われているといえるのだろうか（図1）。 企業と個人の違い?企業は多くの視点・価値観の集合である? 健康法を導入する場合、個人ならば自分の考えで何を

今年4月にJR西日本で痛ましい事故が起きた。この事故では、同社の利益優先体質を問題視する声が出ていたが、果たしてそういうことで解決する問題なのだろうか。今回は事故を題材として、組織とマネジメントの問題を考えてみる。 まえがき 最近、新しくマネージャになった人から、コミュニケーションのヒューマン・スキルなど人間関係に関する能力についての悩みを聞くことがある。この問題に対してのハウツーに関心を持つ人が多いが、マネジメントの問題には安直なハウツーなどはないと私は思っている。 「直面する課題の特性」や「自分の特性」と「相手の特性」という三者の組み合わせでやり方は変わる。他人のやり方をまねしても、必ずしもうまくいくものではないし、前回成功したやり方が、今回のメンバー相手でうまくいくという保証もない。自分の周囲で日々起こっている出来事を、問題の特性と人間の行動や組織の行動という観点からあれこれ考えてみ

標準プロセスやプロセス改善といったトピックに関しては、話題は尽きないのですが、本連載も要求管理、構成管理の連載同様、第3回をもって完了します。 第2回の「開発プロセスは継続的かつ段階的に改善すべし」では、組織と人、プロセス、技術（ツール）のバランスを取りながら、段階的、継続的に改善していくことでしか成長はあり得ない、ということをお伝えしました。これは、一度でも開発プロセスの定義と実践運用を経験した方であれば、身に染みてお分かりのことだと思います。 今回は、標準プロセス策定をする際には何から始めるか？ ということについてお伝えする予定でしたが、少し予定を変更して、どのようにしてこれらの活動を進めていくかについてお伝えしたいと思います。 何かを行う場合には、2つの大きな要素があります。それは、（1）心構え、考え方という“あり方”と（2）方法論、テクニックという“やり方”の2つです。以下、前半部

本連載の筆者は、京都府警に10年間勤務した後にシステムコンサルタントとして独立した経歴を持つ。昨今のビジネスでは、データマイニングなどの高度なITを活用したマーケティングリサーチや問題分析といった“捜査”に近い活動が頻繁に行われている。この連載では、ビジネスに捜査の技術を応用する手法を紹介する。 筆者は京都府警に10年間勤務し、コンピュータを使った犯罪捜査や防犯統計、交通事故分析などの業務に携わっていた。その後、システムコンサルタントとして独立し、ファーストリテイリングやソフトバンクといった企業に対する情報システムやマーケティングのサポートを行ってきた。 特に最近では、データマイニングや地理情報システムなど高度なITを活用したマーケティングリサーチや問題分析といった、まさに企業における捜査活動を支援する機会が増えてきている。この連載では、ビジネスに捜査の技術を応用し、さまざまな問題を解決す

PMの独り言 これらの説明をしたうえでPMの石出さんに感想を尋ねてみました。 石出さん　なるほど構成管理をきちんとやって、ビルドを管理すれば、ちょっとした「ムダ」を削減できそうだ。ツールを使っているので削減に掛ける工数も大したことはなさそうだ。確かにツールに慣れるまでは多少かかりそうだが、それは長い目で見れば必要なことだろう。 次回は、このビルドの際に得られる情報について説明し、その情報を利用してプロジェクトを管理する方法について説明する予定です。前回予告し、今回説明できなかったソースコードの評価方法も併せて説明します。 コラム：ムダの見つけ方（「祝 ランス・アームストロング ツール・ド・フランス総合7連覇」） 円津　石出くん、ツール・ド・フランスって知っているかい？ 石出　ええ、確かフランスの有名な自転車レースですよね。 円津　うん。ツール・ド・フランスは「フランス一周」という意味で、1

この連載では、架空の会社である株式会社エム・ゼットが、事業拡大を目指して、新たに新車販売事業を推進することになったというビジネスシナリオに沿ってモデリングを解説しています。前回（「利害関係者の目的を可視化するプロセス」）は、利害関係者を洗い出してその目的を可視化するプロセスについて解説しました。プロジェクトコンテキスト図と業務コンテキスト図、目的構造図の具体例を示しましたので、適宜、参照してください。 今回は、業務の目的を果たす手順を可視化するプロセスについて解説します。皆さんは、このシナリオの主人公である、アーキテクトの秋田さんになったつもりで、実際に手を動かしてモデルを作成しながら、モデリングのプロセスを仮想体験してください。 業務の概要を可視化 今回の会議には、プロジェクトメンバー全員が集まっています。プロジェクトメンバーは、プロジェクト管理者の田上さん、アーキテクトの秋田さん、業務

日々追われる作業、上司からの圧力、顧客との苦い折衝、理解できない既存システム、遅延するプロジェクト、追いつくのが精いっぱいの次々と登場する新技術、複雑な外注関係、理不尽な納期、完成直前まで変更が続く仕様、永遠に続くかのようなバグの発生と切り分け、長期にわたる徹夜作業、擦り切れた人間関係、明日の見えないキャリアパス……。筆者の20代のころの経験は、主にこうした「混沌とした」ものから構成されていたといっても過言ではない。こうした経験は、まじめに仕事をすればするほど、どんどん狭く深みにはまっていくものだ。そうした悩み深きプログラマの1つの解として近年脚光を浴びている「ITアーキテクト」という役割。この連載では、いまも現場でもがき続ける現役ITアーキテクトの1人として、悩ましい20代への「次のステップ」の手引となるものを残していきたいと考えている。 ITアーキテクトとは 「ITアーキテクト」とは、

ここまでの連載でも何回か触れていたのですが、プロジェクトの運営には、「より良く・より使える」方式への改善が重要です。今回は、さまざまな場面で改善を行うのに有効な、「ふりかえり」の実践です。最近メジャーになってきた感のあるKPT法の使い方、バリエーションについて主に説明していきます。 KPT法とは KPTは、それぞれKeep、Problem、Tryの頭文字で、それまでの活動を、それぞれ、良かったので次もやりたいこと（Keep）、問題だったので次はやめたいこと（Problem）、次にやってみたいこと（Try）の3つの軸で整理する方法です。 この方式の主な特徴は、 シンプルで分かりやすく、理解しやすいこと アナログ的で親しみやすく、参加しやすいこと 「見える化」されているので、外部の人でも状況が分かりやすいこと なところが挙げられます。そのせいか、参加者の「食いつき」が良いようで、次々と利用者が

この20年くらいを振り返ってみると、目先の利便性やコスト効率を追いかける傾向が強い。しかし、その結果をよく見てみると、この流れの中で失ったものも非常に大きい。今回は、IT化やデジタル化とともに失ってきたものを考えてみた。 何となくITの分野でも、マンネリと閉塞感を感じることが増えたような気がする。いままで馬車馬のように目隠しされて、ただ前進あるのみであったような気がしないでもない。企業30年説がはやるよりも随分前に、20世紀の技術は1万日で飽和するといった人がいた。チョッと立ち止まって振り返り、周りを見渡してみることが必要な時期なのかもしれない。 この10?20年を振り返って見た場合、デジタル化の流れの中で、ひたすら目先の利便性とコストや効率を追いかける傾向が強かった。しかし、その結果をよく見てみると、この流れの中で失ったものも、また非常に大きいことに気が付く。 最初のころは良いと思ってい

ソリッドアライアンスは7月25日、USB延長ケーブル「ケーブルga ナポリタン」を発表、同日より発売を開始した。価格は、なんと2万4800円（税込み）。 「ケーブルga ナポリタン」。価格はなんと2万4800円。フードサンプルを用いたおバカUSBメモリを多くリリースしてきた同社なので、いつかはやると思っていたが ケーブルga ナポリタンは、エビフライ、カニ爪、スシに続くフードサンプルを用いたUSB関連製品。「フードサンプル界の“ドン”」（同社K氏）なる、喫茶店ショーケースなどでおなじみのナポリタンをモチーフにした、たんなる“USB延長ケーブル”である。宙に浮いたフォークと巻き付く麺が忠実に再現されている。 たんなるUSB延長ケーブルのため、もちろん接続ポートも1基のみ。浮いた麺の部分にUSBポートが備わる。