IT、プライド、プロフェッショナル 〜 人間不在のデジタル論議 | タイム・コンサルタントの日誌から
あの奇妙な「半強制的自粛」の数ヶ月間も、ずっと職場で忙しくされていたと伺い、少し驚いています。たしかに現場を持っておられる立場ですから、やむを得ないとはいえ、まことにご苦労様です。 ところで今回、突然、新任の上役からTさんに降ってきた「DX化」の指示の事を伺い、失礼ながら思わず、昔読んだDilbertのマンガを思い出してしまいました。「Dilbert」とは、ハイテク企業のバカバカしさを風刺した、米国の新聞連載マンガです。 その中で、ずっと部長の秘書をしていた女の子（たしかティナとかいう名前でした）が、秘書業という仕事の報われなさに嫌気が差して、エンジニアに職種転換を希望しようとします。しかし、同じ職場のアリスという女性エンジニアが、忠告して言うのです。
設計とはどういう行為か、AIで設計を自動化できるか？ | タイム・コンサルタントの日誌から
2月の中旬、まだ大勢の人の集まる会合が可能だった頃（なんだか遠い昔のようだが）、「日本学術振興会 プロセスシステム工学第143委員会」（通称「PSE143委員会」）という場に招かれ、講演をさせていただいた。会合全体のテーマは「新しい設計手法・視点」で、わたしは『システム設計は果たして工学たりうるか？』と題するお話をした。 設計とは何か、という問題について、最近あれこれの角度から考えてみている。わたし自身はエンジニアリング会社でずっと働いており、とくに駆け出しの頃は、設計部門でキャリアを積んだ。今は設計の現場から離れてしまったが、今でも設計の良し悪しこそ、その後の仕事の質や利益を、大きく左右すると信じている。そして、プロジェクト・マネジメントの分野に設計論が欠けていることが問題だ、とは以前も書いたとおりだ。 では、ひるがえって、設計とはどういう行為なのか、設計の質とは何が決めるのか、そして昨
エンジニアリング・チェーンのマネジメントと、生産技術というボトルネック | タイム・コンサルタントの日誌から
個別的な業務を予見可能にするとは、どういう意味でしょうか。『個別性の罠』にとらわれないためには、ユニークな業務であっても、その行き先をある程度、予測できるようにすることが必要です。かつ、望ましい形に進むよう、計らう必要があります。 それは端的に、その業務がいつぐらいまでかかり、どれくらいの費用を要し、どんな工数を必要とするのかを、つかむことです。そのためには、業務のボリュームや作業の構成を考え、全体の工期・工数・コストなどを、見積もる能力をつける訳です。そして、それに応じた体制や予算、人のアサインなどを決めていきます。つまり、計画していくということです。業務を「計画可能にする」といってもいいでしょう。これによって、いわば野放しの「野獣」を、通常の仕事の体制や予算の中に、取り込めるようにしていきます。
システムズ・エンジニアリングとは何か | タイム・コンサルタントの日誌から
日本にはあまり知られていないが、欧米では確立され重視されている技術の分野がある。それは「システムズ・エンジニアリング」＝システム工学である。 ・・と書けば、“何を馬鹿な”と思われる方が大半であろう。日本にはシステム・エンジニア（SE）と呼ばれる職種の技術者が、少なく見積もっても十万人単位で存在する。それに、大学でもそれなりに教えているではないか。「システム工学」と名のつく学科だって、数十は存在する。それなのに、「あまり知られていない」などとは何ごとか！ そう憤慨される読者諸賢に、それでは、一つご質問したい。貴方が学校で学ばれた「システム工学」の、代表的な教科書をあげていただきたい。これ一つ読めば、システム工学の基礎が大体分かる、読んでいない奴はモグリだ、というような定番の教科書である。システムとは何を指すのか、システムはどのように設計すべきか、設計手法は何があるのか、システムの分析や評価は
エンジニアリングとは統合力（インテグレーション能力）である | タイム・コンサルタントの日誌から
「エンジニアリング」という言葉を聞くと、読者諸賢はどのような仕事を想起されるだろうか。都会的なオフィスで遂行する、理知的な設計とデザインの仕事？ それとも製図板と作業着とノギスをともなう、泥臭い仕事？ あるいは企画と要求仕様だけを与えて、どこか海の外でやってもらう設計の力仕事？ 『エンジニアリング会社』と呼ばれる職場で、もう30年以上も働いている。会社には、机と椅子とPCと、あとは人が並んでいるだけだ。自社の工場は持っていない。建設現場はあるが、建設労働者を雇っているわけでもない。資機材は世界中の製造業の会社に頼んで作ってもらい、物流業の会社に頼んで現場まで運んでもらう。据付け組立工事は、現地の工事業者にお願いしてやってもらう。 わたしの属するエンジニアリング業界には、国内で「専業」と呼ばれる大手が３社あるが、どこもほぼ同じような業態である。もっとも、国内には「エンジニアリング」と名前のつ
クリスマス・メッセージ：名前を持つ存在として | タイム・コンサルタントの日誌から
少し前のことだが、ある打合せで、システム利用者のマスタをどう設計するか、の議論になった。個人を特定するために、まず各人にユニークなキーとなるIDを振る。それから主要な属性を定義していく訳だ。当然最初に来るのは、『氏名』だろう。 ところで、氏名という属性を格納するために、最初出てきた案は、たしか「名字」と「名前」の２つのフィールドを用意し、それぞれに読み仮名のフィールドを付け加える、というものだった。まあ、普通の日本人が考えると、こうなるだろう。 しかし、ユーザの中には結構な数の外国人もいた。そこで、「ミドルネーム」のフィールドもいるんじゃないか、というコメントが出た。加えて、結婚したけれど旧姓表記のまま仕事を続けている女性もいるから、そうした人はミドルネームに旧姓を入れれば便利だろう。そうなると、ミドルネームにも、読み仮名のフィールドが別に必要かもしれない・・
IT、OT、ET、そしてマネジメント・テクノロジー | タイム・コンサルタントの日誌から
前々回、そして前回と続けて、本サイトのテーマである『マネジメント・テクノロジー』の領域について、あらためて考えてきた。 マネジメント・テクノロジーは、目に見えにくい領域における技術である。わたし達の文化は、目に見えるもの（五感で感じられるもの）に対しては細部にまで徹底してこだわるが、見えない物事や抽象的概念には、いたって無頓着、という傾向が強い。 たとえばカレー屋さんの場合、料理の味と、その材料やレシピには研究を怠らない。しかし客の注文をどうとってどういう順序でデリバリーするか、何をストックし作る量をどう予測するか、といった店を運営する過程や仕組みには、なりゆきで応対する。これが多くの店のあり方だろう。 カレーの料理法は「固有技術」で，店の運営の仕組みは「管理技術」（マネジメント・テクノロジー）に属する。もちろん固有技術（味）は、いわばビジネスのベースで、これが不味ければ商売は成り立たない
従業員番号のない会社、あるいは、わたし達の社会のアキレス腱について : タイム・コンサルタントの日誌から
その国には、住所というものがなかった。住所表記の仕組みがないので、場所を伝える時は、X市場の前とか、XXホテルの東隣3軒目というしかない。誰かに郵便を出すには、市の名前を書いて、あとは私書箱（PO Box）の番号をつける。だから誰もが、郵便を自分で取りに行くことになる。 その国の名前を、サウジアラビアという。初めて行った時には、ずいぶん奇妙に思えた。だが、毎日の生活は、普通に行われている。最近は、いくつかの市では通りの名前と番号による、欧米式の表記もされているようだ。だが、全国的ではない。カーナビがどうなっているのか、わたしは知らない。 そんなのはごく特殊で例外的な事例だ、と思われるかもしれない。のんびりしたアラブの途上国の、それも国土の大半が砂漠である国の特殊事情だろう、と。多くの日本人は、そんな風に思うかもしれない（現実のサウジはG20のメンバーで大国だが）。
設計思想（Design Philosophy）とは何か | タイム・コンサルタントの日誌から
Kさん、久しぶりにメールありがとうございました。お元気とのこと、何よりです。ご活躍中の様子が、行間からあふれていました。生産管理の現業をかかえた上に、新規システム導入プロジェクトのメンバーの一員としてアサインされたとは、たしかに大変だろうとお察ししますが、それだけKさんが周囲から期待され一目置かれていることの証左だと思います。 ところで、Kさんからメールをいただくたびに、難しい宿題を投げられたように感じるのですが、今回は格別です。『設計思想に関して』のご質問とは！ なるほど、たしかに新しい基幹業務システムを考える出発点として、“その設計思想はどうあるべきか”を問うのは、とてもオーソドックスかつ当然の発想と思います。自分達が製品を設計開発するときも、成功した製品には明確な設計思想があった。だから、プロジェクトを成功させたければ、当然システムにも設計思想がなくてはならないはずではないか。－－設
見えない非効率 ー 今、動いているんだからいいじゃないか | タイム・コンサルタントの日誌から
新任の取締役が、あるとき担当する事業部の支社を見に行った。一通り見学し、支社長らと懇談した後、かえろうとしたら、ある部署だけ灯りがついているのを見つけた。現場仕事はもう終業しているのに、管理部門の1セクションだけ、忙しそうに机にむかって仕事している。 「何をしているの？」と彼がたずねたところ、「本社に送る書類を作成しているんですよ。毎月、数字をまとめて送らなけりゃいけないんで、残業になるんです。」との答えだ。資料を見て、さらにたずねる。「本社は、この統計資料を見てどう役立てるんだろう？」「・・存じません。本社にたずねてください。」 その取締役は本社に戻ると、早速、送付先の企画部門にいって、その書類のことをきいてみる。すると、「ああ、その書類ですか。工場が毎月送ってくるんでね、ファイルして保管しているだけです」という。「でも、なんで工場はその書類を送ってくるのかな？」「さあ・・。」 いろいろ
生産システムとは、どういう仕組みだろうか | タイム・コンサルタントの日誌から
法政大学の西岡教授といえば、現在、「つながる工場」のための緩やかな標準づくりで、日本版インダストリー4.0として注目を集めるコンソーシアム"Industrial Valuechain Initiative”（IVI）https://www.iv-i.org/を率いている方だ。その西岡教授は、日本機械学会の研究分科会報告の中で、世の中にあるシステムは、二種類に大別できる、という興味深いことを書いておられる。 「自動車や携帯電話など、人がその外側にいるシステムを第一種のシステムと呼び、人がシステムの内部にいて、その構成要素となっているものを第二種のシステムと呼ぶことにしましょう。はたらく作業者である“私”にとって、私は生産システムの一部であり、システムの内側にいます。これまで工学の世界では、第一種のシステムを多く手掛けてきました。その反面、第二種のシステムは、挙動が自然法則のみに依存せず、なか
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
『なぜ』からはじめよう － 仕事の目的を設定する | タイム・コンサルタントの日誌から
たしか林達夫の西洋史に関する論考だったと思うのだが、「古代ギリシャは豊かなイメージがあるが、社会的な生産性はじつはかなり低かった。ギリシャ社会を支えていたのが、奴隷労働だったからだ」という説明を読んだことがある。林達夫はわたしの尊敬する思想家で、平凡社の『世界大百科事典』の編集長をやった博学の人だ。 人を動かすということが、技術リーダーとして面白い仕事をする必要条件だと、前回書いた。では、具体的に、人は何で動くのだろうか？ 一番すぐに思いつくのは、給料などのお金だろう。お金という報酬で、人を動かす。会社というのは、そうなっている。業務上の命令通りに働けば、給料がもらえる。上司の覚えも良くなる。そむけば、叱責されて給料が下がったり、首になったりするかもしれない。つまりアメ（給料・昇進）と、ムチ（罰則・失職）で動かす訳だ。 ここで人を動かすために使われているのは、「強制力」（権力）である。強制
在庫のデータ構造を考える | タイム・コンサルタントの日誌から
「わたし」は新米のエンジニアである。最近、先輩からオフィス備品類の在庫管理を手伝うようにいわれた。ペンだとかノートだとかフォルダとかいった文具類が中心である。これまである意味、ルーズな管理だったが、経費節減の折、きちんと在庫数量を管理した方がいい、と部長が方針を出したとのことだ。今まで、各人が勝手にネットからモノを注文して取り寄せ、請求伝票だけが部の庶務係に回される。これをやめて、部で必要数量を考え、集中的に購入し、部のキャビネに保管しておく。そして各人が必要時に庶務係に申請して受け取る、という管理方式にかえることになった。その、キャビネの在庫管理の仕組み作りが、「わたし」の仕事だ。 在庫管理の仕事ははじめてだ。だからいきなり部の仕組みを作り始める前に、たとえば自分の家のモノを在庫管理するとしたらどうするかを考えてみることにした。題材は何でも良いが、出入りの多い食べ物にしてみよう。 在庫管
パーソナル時間管理のベーシック : タイム・コンサルタントの日誌から
いま、目の前にA4で30ページの英文の仕様書があるとしよう。中身はまだ、まったく見ていない。さて、これを読んでレビューするのに、どれくらい時間がかかるだろうか？ わたしの場合、答えは簡単だ。集中できる時間で、ほぼ2時間かかるだろう、と予測できる。なぜかって？ わたしの仕事のパフォーマンス値によれば、英文の文書をきちんとレビューするのに、1ページ平均約4分間かかるからだ。30×4＝120分で、ちょうど2時間になる計算だ。 ただしこれは、正味作業時間（Net working time）である。現実には、しずかに集中できる時間を、2時間も連続して確保するのはむずかしい。電話や上司の呼び出しやメール・打合せなどによる割込がある。だから、着手から完了までのグロスの時間（Elapse time）はもっと長くなるだろう。それでも、半日で終わる仕事なのか、3日かかる仕事なのかは明らかである。1ページ4分間
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
マイルストーンは中点で測れ | タイム・コンサルタントの日誌から
プロジェクト・スケジューリング立案作業の第一歩は、いうまでもなくＷＢＳ（Work Breakdown Structure）の作成である。成果物スコープとプロジェクト・スコープを、もれなく・重複なくカバーするタスク（アクティビティ）をすべて拾い上げる。それらを階層的に構成し、整理番号をつけたものがＷＢＳだ。スケジューリングは、ＷＢＳを構成するアクティビティの所要期間を見積り、また、それらアクティビティ間の論理的な着手順序や依存関係を決定して、ロジック・ネットワークに落とし込む（ここは何らかのソフトウェア・ツールを利用することが多い）。その上で、クリティカル・パスを求めると、それがプロジェクト全体の工期となる、という訳である。 通常はさらに、クリティカル・パス上の主要な達成点に、「マイルストーン」を設置する。これは後の進捗管理を分かりやすくするための工夫だ。ここまでは教科書的な常識の話で、誰も
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
敗北から何を学ぶか 〜 その1・学ばないための5つの方法 | タイム・コンサルタントの日誌から
進捗率を何で測るか？ −−情報処理技術者試験の問題より | タイム・コンサルタントの日誌から
設計の「なぜ」を考える | タイム・コンサルタントの日誌から