小説・エッセイからイメージをつかむ

先輩の経験をエッセイから学ぶことについて書いたので、小説から他の業界のイメージをつかむと題して書こう。

経済小説は業界についてのイメージを作るのに役立つ、と思っている。

小説なので真剣に信じると恥ずかしい思いをするのかもしれないが、「こんな仕事をしているんだ」「こんたタイプの人間が多いんだ」と業界に対して空っぽの状態から何かある状態にはなると思う。

別の業界の知人や初対面の人に、「小説にこんな感じに書かれていたんだけど本当にそうなの？」と会話の種になるし、その知識が間違っていたとしても正しい生の情報を新しく得られし。

また、人間の脳に残りやすいのはストーリーのある知識であるので、ただの年表の羅列や教科書的な記述よりも、人の経験や体験を介した知識の方が頭に残りやすい。人間、学習するときは、大枠から学習するはず。大枠を学習した後に細部を学習する方が効率的なので、その大枠の部分はストーリーのある話で学習したらいいんじゃないですかと考えています。

ということで、経済小説は割と好きです。

鉄の骨 (講談社文庫)

マグマ (角川文庫)

ハゲタカ(上) (講談社文庫)

本のまとめだけじゃなく感想文も書いていこうと思います。

歴史学習の重要性

前回の記事で歴史を学んだと書いたが、歴史学習って大切だなと感じたのでブログに書こう。

暗黒のシステムインテグレーション―コンピュータ文化の夜明けのために―

本の筆者が1990‐から実際に経験した案件の技術の問題・人間の問題・会社の問題が書かれている。「昔はこんなやり方をしていたのか」「この技術はこの時からあったのか」「この仕事はこんな風にすすめるのか」「いつの時代も大変なのは人間なんだな」など筆者の体験を擬似的に体験できる。筆者の体験した歴史を見ることができる。

筆者が今の自分と同じような感想を抱いているのを見ると安心できるし、今と変わった部分・変わらない部分を確認することで廃れるもの・廃れないもののを知ることができる。

昔は飲み会の席で先輩から後輩への仕事の仕方が伝わったという説があるが、この本に書いてあるような体験談を先輩から後輩へ話すことで仕事の仕方が伝わったのではないか。

でも今の飲み会の席を思い返してみると、先輩が後輩に対して体験談を語るような場にあまり出くわしたことがない。私は変わっているので先輩の浮いた話や武勇伝よりも過去の仕事の体験談の方が楽しく聴けるのだが、いかんせんあまりその話題にはならない。（特に30代の先輩。40代‐50代は話してくれる。）

過去の仕事を活き活きと話せるほど良い思い出がないのだろうか。

過去の経験として話せる内容を持っていないのだろうか。

これ以上考えてもわからないし、結論として自分の大好きな世代論に落としそうになるのでここで終わり。

歴史というか先輩の経験談が重要だという話になってしまった。。。

ほかにも参考になったエッセイや小説を。

SEのフシギな生態―失敗談から学ぶ成功のための30ヶ条 (幻冬舎文庫)

SEのフシギな職場 ダメ上司とダメ部下の陥りがちな罠28ヶ条

「システム管理者の眠れない夜」　?ほんとうに価値のあるシステムを求めて (ITブッククラシックス)

なれる!SE―2週間でわかる?SE入門 (電撃文庫)

IT業界の歴史

今日は研修だった。

研修の中で業界の歴史について説明を受けた時、自分の今後の身の振り方を考えるヒントになったのでブログに残そうと思った。

80年代‐90年代前半：汎用機＋COBOL言語で業務システム構築の時代の全盛期

⇒手作業で行っていた業務をシステム化する事が目的のため比較的要件が明確だった

⇒汎用機の値段が高いため、各工程に多くの時間を使い、プロジェクト期間が長かった

⇒技術の範囲が狭く、一人の人が全体知識を追うことができた

⇒長いプロジェクト期間中に業務について学ぶこともできた

90年代後半‐00年代：C/S、WEBシステムでシステム構築

⇒ハードウェアが汎用機からオープン化・マルチプラットフォーム化

⇒オープン化することで価格が下がり、システム構築案件が増える

⇒オープン技術を使用して安く・早い構築が求められる

BUT：オープン化により技術の選択と組み合わせを考慮する必要がでてきた

⇒各技術が専門領域化してきた

⇒技術の領域が広がりかつ専門化も深まったため一人で全体を追うことが不可能に

結果として、各技術はパートナー会社や下請け会社の人にお願いし、ベンダはその人たちを管理するプロジェクトマネジメント業務に特化した人材の育成に努めた。

この時期に、技術を外出しし管理能力ばかりを重視したため、ベンダ内の技術力低下を招いたとも言われている。近年では技術力の復活を目指し方向転換しているが、PM重視時代に教育を受けて育った人はどうなるんだろう。。。（経営層がPM人材必要だと方向付けをしたのに。。）

PM人材重視はまだ根強く残っている風でもある。

N社さんは1年目から海外アウトソーサを管理する立場に立たなければいけないらしい

ITエンジニアの生態がわかる! SEの歩き方 (1年生クリエイター成長日記)

1年目から海外プロマネの例ではないが、若い人がリーダーしている例があった

自分の知らない技術に関して、チームリーダとなり顧客の矢面に立って仕事するのは大変そうだと感じる。

00年代‐10年代：アプライアンス製品、クラウド

◆アプライアンス製品

オープン化・マルチプラットフォームは選択肢が増えたが、技術が各領域に分散しすぎていて、問題が発生した時の対応が難しく、顧客に対するワンストップのサービス提供がしずらい。そのデメリットを克服するため、ハードウェア、OS、ミドルウェアをもつベンダが自社の製品のみを使って製品・サービスを提供する例が増えている。

OracleはSunを買収することでハードとOSを手に入れた。もともと持っているDBと組み合わせ、全て自社製品のハード＋OS＋DBの組み合わせを協力に推し進めるようになっている。（例：EXADATA）SAPのHANAもしかり。

◆クラウド化

顧客が自社でITを持つのではなく、ITを利用するという流れが強くなってきた。

ハードやOS、DB、NWを扱うインフラSEはクラウドサービスを組み合わせて仮想的なインフラ環境を構築するクラウドインフラSEに変化する必要があるのか。

以上、最後は駆け足になったが、昔からの流れを理解することで今自分が置かれている環境が分かり、将来の見通しが少し良くなった気がする。

数年単位の小さな流れに乗ると、環境の変化により（経営層の心境の変化）投げ出されるかもしれない。10年‐20年単位の大きな流れを見て、どのような身の振り方をしておいたほうがいいのかを考えながら勉強していきたい。

デザインのためのデザインその4

デザインのためのデザイン

5章　良いデザインモデルとは

・デザインの要件を段階的に発見でき、進化させることが出来る

・視覚化が容易で、チームメンバが理解しやすい

・人間の罪を排除出来る

共進化モデル➡問題の明確化と解の決定を相互に繰り返す

バザールモデル➡オープンソース的開発

スパイラルモデル➡筆者一押し

6章　デザインの共同作業

エンジニアリングデザインは個人の仕事からチームの仕事に変わった。これは、

①技術の高度化

②素早い市場投入の要求

が原因である。

しかし、デザインに関しては人数が多ければ多いほど良いというものではない。

むしろ、人数が多いとマイナスになる事の方が多い。

仕事を分割するコスト、多数の人が仕事を学習するコストが余計にかかるからである。

さらに「デザインコンセプトを統一する」という重要な命題を難しくするというコストがある。大勢の人が集まって会議でコンセプトを決定するとなると、まさに「委員会によるデザイン」となり、無用な機能の塊が生まれてしまう。

デザインコンセプトはただ一人のアーキテクトが決定し、統一感を持たせる必要がある。

7章　遠隔共同作業

技術の進歩により離れた相手とも共同で作業することが可能となった。しかし、遠隔地の人と共同作業する場合でも対面の時間を持つことは重要である。

◆理由

顔が見えるビデオ会議でさえも、直接会う事に比べると伝達される情報が減る。

また、直接会って人となりを知る事がその後のコミュニケーションの円滑化を助ける。

◆感想

ビデオ会議：シスコのビデオ会議システムを使用して海外の人とミーティングをしたことがあるが、最近の会議システムはすごいと感じた。画像の解像度も綺麗だし、会議に参加している人全体の顔も見える。直接会う時間がない時は十分代用できると感じた。

対面の時間：海外プロジェクトを成功させるポイントとして、プロジェクトの早期の段階で関係者でフェイストゥフェイスのミーティングを行うことの重要性を説いていた。

文化や習慣の違う海外の人とのプロジェクトだけでなく、文化と共にする国内人とのプロジェクトでも注意すべき点だと感じた。（特にマルチベンダの場合）

デザインのためのデザインその3

デザインのためのデザイン

4章

 

委員会での意思決定

 

巨大プロジェクトの成果物が無用な機能の塊になってしまう理由は、委員会で決定するからである。それぞれの部門の代表者は自部門の要求事項リストを認めさせることばかり考え、全体的に整合性のとれたデザインはできない。

 

成功するプロジェクトはプロジェクト責任者が最も重要な要求事項を満たす事に集中した上で、プロジェクトの決定事項を単独で決める時である。

 

契約

 

1．クライアントに欲がなく、発注業者に成果にみあった正当な報酬を喜んで与える。

2．発注業者はクライアントの要望に答えるべく最大限の努力をし、要望を答えるだけの技術や能力がある。

 

このような前提条件の場合は、固定費でプロジェクトを契約するのではなく、コストプラス方式で発注業者にお金を支払い、スパイラルモデルでプロジェクトを実施するのが最良の方法である。

しかしそれが一般的には不可能だ。

なぜなら、人間は欲があるし、嘘を尽くし、自分の有利になるように相手を騙そうとするから。

クライアントは契約をする時に、作業が増えても損にならないように固定費で契約したがるし、発注業者側では追加で作業要求されないように、契約書に作業内容のスコープを初期の段階で固定しようとする。

 

人間の罪がプロジェクトを固定的なものにするのだ。

 

○感想

大学時代に契約理論を学習したことを思い出した。

相手にうまく働いてもらうために契約をどのようにデザインするべきか、また、状況に応じて契約をどのようにデザインするべきかを学習していたきがする。。

また復習したくなった。

デザインのためのデザイン その2

デザインのためのデザイン

3章

合理的デザインプロセスに対する批判の章

ウォーターフォールモデルやPIMBOKモデルはデザインプロセスの正しい進み方を示しているように見えるが、実際のプロジェクトはそのようには進まない。

理由

1．要件、ニーズはプロジェクト最初の段階ではすべて洗い出すことができないから。顧客は自分が何を求めているのか完全には理解できておらず、仕様が固まるに連れて自分がなにを求めていたのかが明確になってくる

2．プロジェクトが進行し、形が見えてくると、最終的な成果がよりはっきりと理解されるようになり、その理解の結果、自分たちが本当に欲していた成果がわかるようになるから

3．目的・目標を制限する制約条件が変化するから。プロジェクトの初期では制約によりできないと切り捨てたものでも、プロジェクト進行中に変化が起こり可能となっていることがある

では、合理的プロセスが不必要かというとそうではない。

1．合理的プロセス＝モデルがメンバ間の共通認識となり、コミュニケーションの触媒となる

2．初心者が横道にそれないように、デザインに取り組む出発点となる

合理的プロセスモデルがあることが問題なのではない。

合理的プロセスモデルを唯一絶対的なものとして、強制されることが問題である。

PMBOKによる標準化、ISOによる標準化は合理的プロセスを信奉しすぎていないか。

デザインは滝が流れるように一直線に進むのではなく、新しいアイデアや状況の変化に柔軟に対応できるよう、螺旋上に進むものだと理解するべきである。

デザインのためのデザイン

デザインのためのデザイン

デザイン＝設計

製品のデザイン、建築物のデザイン、機械のデザイン、ソフトウェアのデザインはどのプロセスも類似する部分が多くある。つまりデザインプロセスとして抽出でき、デザインの科学として定式化できる。本書はデザインプロセスのあり方、つまりデザインをデザインする方法を述べている。

1章　デザインの課題

・異なるメディアのデザイナ達は互いの経験や見識を比較し合うことで自分自身の分野について新しい事柄を学ぶことができる。

・デザインとは「計画や構想を整える、あとで実行するために頭の中で用意すること」と定義される。

・デザインは「アイデア」とも表現される。

・デザインコンセプトに対して、それに関わるもの全員が共通の認識を持つことは難しい。創造物のデザインコンセプトはイデアであり、各人が実装しようとしている成果物はイデアの影となる。実装の前にメンバ間で認識のすり合わせ、イデアの共通化を図る必要がある。

2章　デザインプロセスの合理的モデル

・目標、要件、効用関数、制約事項、リソース配分、決定木の流れ

・PMBOKの５プロセスやウォーターフォールモデルをイメージすれば良い

・デザインプロセスをとばし、とりあえず実装するという無計画な状態からの脱皮

・チーム内のコミュニケーションや目標、要件の明確化、無駄な努力の回避などメリットが多数ある

⇒ではなぜ、ウォーターフォールモデルモデルは時代遅れといわれ、実装を重視するアジャイルが最近の流行のなのか

本日はここまで