関西と首都圏の大学ランクとか比較難しい
自分が関西育ちで、大学も関西圏。
東京転勤後、子供たちは首都圏で育って、いざ、大学を見渡すと、知らないところばかり。
もちろん、名前は知っているが、なじみがない。生活感なし、実感なし。
関西といえば、
- 国公立は、京大、阪大、神大、市大、府大、みたいな感じで並んでいて、京都府大や兵庫県立大、滋賀大、和歌山大など、近県国公立大学がある。
- 私立は、（最近はわからんけど）関関同立で、あとは京産とか近大とか龍谷とか。その他、女子大とかも結構あった気がする。
一方首都圏は、
- 国公立は、東大の後に続く、総合大学がない。総合だと、千葉とか、首都大学東京とかになるのかなあ。（首都大を総合とみるとして） でも、ランキング的には、一橋、東京外大、東京医科歯科、東工大などが続く。良く聞く、横国とかも総合ではないし。特徴的なのは、首都圏ど真ん中にお茶の水女子、東京芸大か。
- 私立は把握できないくらいあるが、言わずと知れた、早慶が頂点にあり、上智が続くらしい。あとは、MARCHと呼ばれる大学群。明治、青山、立教、中央、法政。これに学習院が加わることもあるらしい。が、理系では、東京理科大がある。このあたり混とんとしていて、よくわからない。
比較するわけじゃないけど、関西出身で今、首都圏にいる立場でなんとなくだけど、
関西は、国公立が順番に並んでいて（ランクもそうだし、総合大学としても）、国公立系を目指す受験生にとっては、選びやすい。ランク差はつけられるが、まあ、センターの得点状況次第のところもあるので、それよりも、国公立に入ることができる点でいいな、と思う。一方、首都圏は、国公立が選びにくいために、平行して私立を視野に入れないといけないが、その私立が個々に対策をしないとなかなか通らないときているから大変。
私立に目をやると、関西にないのは、早慶なので、早慶至上主義的な雰囲気は、感じる。 全国区の名前だし、学部ともかく、早稲田です、慶應です、と言える点が重視されている感じがある。実際は、内部進学が多いので、学生の質はどうなのだろうか、とも思うところがある。（大学受験勉強をしたかしていないかという意味で、推薦なんかも同じ意味）でも、大学名を言えば、それでどこでも歩けるみたいな、承認欲を満たすブランドとしては成立している感じ。なので、早慶以外の私立は、なんとなくね、って感じを受けやすい。 一方、関西の関関同立は、同じブランド力を関西に限っては持っているよう。 だが、関西圏内では、関西経済圏でのブランドがあるので、他の大学もそれなりに並んでいる感じをうける。
個人的な印象を控えめに見ても、早慶ブランドは、異常な感じがする。決して、同じ比較をできない（つまり、学部傾向も違うし、医学部の有無もあるし、スポーツなんとかとかもあるし、なんでこの芸能人が、的なところもあるし、これは余計か）。
まとめにならんけど、首都圏の国公立が少ないのに対して、私立が乱立するのと、早慶ブランドを押し上げている気がする。その結果、バランスを欠いている気がする。
そう、首都圏はバランスを欠いている。（超全国区だってところも特徴的だけど）
千葉大学が、浦安市にあったり、せいぜい船橋くらいにあったらどうだろう。それよりも、中央と法政が、国立大学化するってのもあってもいいかもしれない。*1
そして、MARCH-Gから、早慶上智明治青山立教あたりが私立６強でもいいのかな。
教育方針や受験制度のことをどうのこうのいうよりも、こういったアンバランスな受験事情をかんがみて、予算を投じていくのが重要かと。
あ、中央と法政が、国立大学化したら、どんな名前になるんだろうなあ。
ロジクール M235 再接続
備忘録として残す。
新しくM325を買って、ついでにキーボードも購入。（K360)
で、これらをUnifyingレシーバーで接続してよしよし、と思って、それまで別のノートで使っていたM235も接続してみた。
全部繋がってよかったよかったなのだけど、さあ、もとに戻そうとしたら、M235が元々付属のレシーバーと繋がらない。
元々のは、Unifyingではないので、なんかこりゃぶっ壊れたかな？とか思いつつ、余ったUnifyingレシーバーでつなげたりしてごまかそうかな、なんて思っていたけど、
検索して助かった。
M.A.D WORKS
というところで、同様のことが書いてあった。
結局、Logitech Supportにつなげて、ソフトをダウンロードしてOKになるわけだけど、このページ、通常のサイトからはわからないようだ。
Articlesとかなっているし。
いずれにしても、少々冷や汗もの。
よかったよかった。
他にもいろいろあったかもしれないけど、Unifyingじゃないやつがもうあまりサポート真剣じゃないってことで危うく落とし穴に入るところ。
助かったので、自分モ記録しようっと。
プロジェクトエンジニアリングを調べたら
プロジェクトエンジニアリング（PE）ってのを聞いて、こりゃなんだっけか？ と思って軽くぐぐったりしていると、すこし興味深い記事に。
最終回 なぜエンジニアリング会社は優秀なPMを育てられるのか | 日経 xTECH（クロステック）
ちょっと前の記事でもあり、何気に見過ごしていたのだろう。
でも、エンジニアリング業界ってのがこの世にはあって・・・（そうそうプラントとかやるところらしいけど・・・・）、そこでは、プロジェクトマネージャを中心とした体制を引いているよう。しかもチームとしてだけどね。
プロジェクトエンジニアって職種があるのもちょっと新鮮。（新鮮って、本来逆で、先達のことを知らずこのIT業界にいて、単に知識がないだけなので、あっちにしたら迷惑ね）
で、何に興味を引かれたかというと、プロジェクトの体制を組むときに、プロジェクトマネジメントチームってのが独立して、存在するってところかな。普通、IT業界のSI型だと、PM（×１）、サブPM（×３）、リーダ（×６）とか・・って感じでしょ。でも、根本的に違うのは、サブPMとかって、下手すると設計担当と兼務していたりするわけで、設計チームの代表でもありながら、プロジェクトマネージをするってところかと。
プロジェクトマネジメントチームを独立して編成し、PM、PE、PMOみたいな形で、実際の設計や製造、テストなどを実施するチームと、相対する形で存在させる。
開発チーム（たとえば、ソフトウエアエンジニアリングチーム）は、設計リーダや製造リーダ、QAリーダ、テストリーダ等がいて、メンバを持つ。開発を統括する人をこれまでは、PMといっていたが、SWEチームの統括者として定義する。で、各リーダーに対してPMチームが張り付く、二人三脚で実施する。進捗や課題解決、問題調整など。
たとえば、設計そのものに責任を持つ人と、設計上の問題をプロジェクトとして可視化し報告する人、全体の情報をフィードバックしたりする。
そんな人を増やしてどうするの？とかいうけど、実際そうなっているでしょ。サブPMだか、サブシステムLの下には、本当に実施上のLがいたりして。ええ、じゃあ、単価の高い人を一杯育てるの？とか思うかもしれないけど、実装をする人たちではないので、そんな無茶な人数にはならんだろう。
マネジメントチームがあらゆるプロジェクト上の問題を把握し解決する。その間にも、設計者や開発者は自分の役割にある程度は集中できる。
コストを別にしてというか、やりくりの部分をとりあえず棚に上げて、実際どういうフォーメーションが正しいのか、それを考えたほうがいいとおもう。
今、ここまで書いて思ったのは、そういうマネジメントチームがうまくできれば、発注側に生息するPMOと言う名のコンサルとかを減らすことできるんじゃね？って。役割を何重にも兼務出来る人ってそれほどいるわけじゃないので、その人たちがボトルネックにならないように（ここでは、いろんなものを背負ってしまうサブPM＝設計L＝テストL）のような人。
要員のボトルネックを解消するだけでプロジェクトはかなり機能すると思ったりするなあ。
理想的なこと言いすぎかなあ。
アジャイルでもウォーターフォールでもなく・・・
なぜか http://www.amazon.co.jp/dp/4822281108/ が読まれているように、システム開発の特に人にまつわる問題は相変わらず変らないように思える。
品質や生産性に関する議論も、60年代あたりの調査や考え方から大きく変っていないようにも思える。（すべてのコードを、同じ言語で語るとか、フレームワークやＤＢを考慮していない生産性など）
そんな中、アジャイル開発のアジャイル宣言やプラクティス、Ｓｃｒｕｍのようなプロセスやマネジメント、などは、それそのものの主張や啓蒙という以外に、いまだ大きく変っていない人の問題や品質などの問題を抱えているシステム開発の現状に提言をしているという側面があると思っている。
でも、現状を語るときに、ＷＦ（ウォーターフォール）を引き合いにだし、すべての問題が、そこから生まれるかのごとく説明し、今のシステム開発の悪いところは、ＷＦ型開発にあるといわんばかりの話は、まったく、どうかと思ってしまう。ＷＦって単にプロセスの話じゃないかと。
自分は、10年以上前にＲＵＰ（ラショナル統一プロセス）に近い、アーキテクチャ中心の開発技法を定めたり、最近では、アジャイルやスクラムの話をすこし現状の開発現場にあわせるように、リリース駆動型軽量プロセス技法を定めたりしてきて、ある意味メソドロジストとしての仕事もあるのだが、最近の、アジャイル vs WF の比較とか、とても無意味な話に思えてしまう。
実は、アジャイル推進派というか、スクラムとかやっている人は、もうそういう比較や論争にかかわらず、どんどん次のステップ−つまり、やりたい開発に注力しているのが現実かと思っている。
どちらかというと、そういう話を取り出してくるのは、今頃になって、そういう動きが気になってきた人たち （これまで、さして、開発の仕方に疑問を感じず、ちゃんとやればうまくいって当たり前で、うまくいかないのは個人の能力か、顧客が悪いぐらいにしか思ってない人） が、なんか、世の中そういうのあるんなら、どういうものか定義して、標準化しようとか、知財化しようとか、要するに何かネタを探しているところに出てくる話のようにも思う。
そのせいか、盛んにアジャイルを学ぼうという、いわゆる盲目的な勉強家たちが増えてきて、アジャイルでは、こういったやり方をすべし、とか、スクラムではこういうやり方でやるべき、みたいな教育ビジネス的な流れにつかまっている。
（おいおいまたかよ、ＰＭＢＯＫ、ＣＭＭＩ、ＩＴＩＬ、、、いろんなフレームワークやナレッジベースと、なんか一緒になってしまっているじゃねーか、、、で、資格取得者数 何名が、組織目標になり、意味不明な育成プランが走り、数字だけを追っかけるやり方が横行する流れ）
本質的でないものを追っかけて、表面的な成果指標に取り上げられ、無意味な組織目標に力を注ぐことを、組織にいる人間としては、否定はしないが、あまりにこういった話に終始すると、いやになってくる。
アジャイルとウォーターフォールは比較するものでもなく、それはどういう観点から、システム開発を捉えているか、他にもいろんなチーム生成や個人の力、組織論などいろいろあるんだからそういうものをしっかり追っかけてみていきたいとおもうんだよなあ。
選択と集中ってこと（独善的解釈）
選択と集中では、事業領域を絞りこむ。
よくある勘違いは、
これからは、（たとえば、ICT、クラウド）に集中する、といった発言から、
あたかも、クラウド事業を選択し、集中するというふうに思っていること。
でも、
選択するとは、＜やらないことを＞選択するのであって、
やることを選ぶのではない、
集中するとは、何かを選択するってことでもなく、資源を投下することでもなく、
その事業で勝ち抜く方法を考えるということ。
組織をつくり、人を移動させ、量を増やすことことではない。
やらなくなったことの利益や売上を、どうカバーし、勝ち抜くか。
勝負に集中する、といったことでもいいかもしれない。
つまり、
これまで、10戦、６勝４敗なら、３０戦して、18勝12敗ってことではない。
10戦中、８勝以上していく策を考えること。
これが集中するということ。
プリンシプルその３ 相手の言葉を使うこと
結構、気を使って、ワークショップの間やっているのがこのプリンシプル。
当たり前のようで、結構大事なのだよね。
これはコンサル経験があるとわかるかもしれないんだけど、コンサルはだいたいワークショップに限らず、場をリードするために、新たな切り口やキーワードを与えていくことがある。
（というよりもそれが重要と考えているコンサルも多い、ちょっと近くで聞いてみなよ、切り口とかいっているから・・・）
ま、そうすることで、それまである問題に対して違った見方ができるようにもなり、解決に近づいていくような効果がある。
実際、コンサルティングを受ける顧客もこういった新鮮な入り方を期待しており、整理できてくる感触を得てくる。
しかしながら、最終的にワークショップを終了した段階において、自社事情にあった施策や方向性を見出し、次のステップに向かうためには、いわゆる、｢腹落ち感｣、｢納得感｣が重要となる。
この腹落ち感とか納得感だけど、一般論的な視点を絡めて問題を整理してきた結果、最終的にどう解決策として落とし込むか、そこなんだけど、そのときには、自社自身の言葉を使う必要がある。
（要するに、相手の文化に入り込めるかどうかなんだけどね）
そこで、私がワークショップで心がけていることは、最初は、全ての事実がわからないが、イメージしたり、論理的に整理したりする中で、相手（顧客）の言葉で語り始めるようになることである。
ワークショップを進めていく中では、まず、自分が、相手（顧客）の言葉で問題を理解し、相手の課題に入り込んでいくということが重要だからで、できるだけ相手の文化や思考に近づけて、、ま、かっこよくいえば、顧客視点での問題が見えてきて、顧客と一体感を醸成することになる。
本当にすばらしいのは、、そういったプロセスや時間を共有していく中でようやく問題解決に向けての、本当の言葉選びや切り口の設定ができてくる点である。
最初に一般的な切り口を提示するけども、自社課題に転写していく中では、自社の通常の言葉（ビジネス用語というかそういう感じのもの）使いつつ、問題をさらに整理していくと、ようやく本当に自社としてフィットする言葉が生み出される（よく世間で聞く言葉でもいいんです、自社へのフィット感というかなじみ感ってのがあるので）
そして、その瞬間こそ自社の課題にフィットさせた最終的なゴールとなる。
プリンシプルその２ 論理に基づくこと
その１の｢イメージする｣で、一種のヒアリング効果があるといったんだけど、実際は大変だよ、とも伝えたかった。それは、効果を発揮するには、陥りがちな罠があり、それにはまらないように気をつけないといけないから。
それが、論理に基づくこと、。
顧客から全ての事実を得られていないので一所懸命イメージすることで、相手の方の考えを引き出すことができるのだけど、陥りがちな罠ってのは、そのイメージを自分勝手な理解にしてしまい、本当はまだまだ意外な展開や事実があるかもしれないのに、自分でストーリーを描いてしまうこと。
｢たぶんこの事情ならこうだ、他の事例もそうだから、こうなのだ。今回もこういうパターンか、｣みたいに思い込んでしまって、検討範囲やヒアリングの範囲を狭めてしまうことがある。、これが一見、論理的に進み、正しいように思えるから面倒。うまく収束できているのならいいのだけど、ちょっとわかった気になって対象から外してしまうと、あとで大変なことがある。
状況がわからないから意識的にイメージするんだけど、イメージが見えてきたからといって決めつめるのは危険ということ。
そのためには、おそらく自分の判断はあっていると思いつつも、それまで聞いた事実を積み上げて、そこから導出可能なことのみで展開すること、これが論理に基づくことである。
が、ここまでは普通のコンサルでも当たり前だろうけど、本当の効果、狙いはここからなのです、
事実に立脚し、論理的に展開することによって、何を狙うか？
実は、丹念に事実を積み上げていくと、事実と事実の間にある、不整合を知ることができ、実際に、その不整合は、なぜ現実として成立しているのか？がわかってくる。それを顧客と共有すること。
ようするに、不整合があるにもかかわらず、なんとなく進んできているということは、何かが矛盾しているようでも、どこかで是正されながら、実際成立しているということを確認するわけである。結構、現実って複雑だな、ってところか。
実際、複雑な事情は、不整合や非論理的なことで、現実が成立している。なので、（おそらく普段は見てみぬ不利するか優先度が低いかで）顧客は意識していないことだろうと思うけど、これを顧客が自ら気づくように仕向けるのが、論理に基づく、ということの本質であり、効果である。
なので、イメージアップを繰り返しながら、事実を積み上げ、論理的に組みなおすことが必要である。ワークショップを重ねていく中では、さまざまな事実が明らかになってくる。それが不整合であったりすることもある。
それに対して、なんとなくゴールが見えたからといって、一気に結論に走り、飛躍しないように、論理的に再構成することを並行して実施することが重要である。
もしこの手順を省いたら、後で隠された事実が明らかになったり、現実の不整合を無視したりすることになり、再び同じ状況に陥ることは間違いない。論理に基づく整理が常に必要である。
