【知見】リーダーシップ白熱教室（第１回）でリーダーシップの見方が180度変わった
リーダーシップ白熱教室で学んだことをまとめてみた。
要は自分に刺さったポイント。
リーダーシップと権威（権力）を混合してはいけない
基本原則
人々は他人に信頼を行い、権限委譲を行う。
たとえば、自動車の修理は修理工場にやってもらうように依頼する。かわりに、権限を得た人間は依頼者にサービスを返す。これが、すべての基本原則。ゴリラの特性・リーダー像について
シルバーバックの例。ゴリラのシルバーは年配になるときの特徴。年配とは経験を積んでいるとされる。しかも、強い固体でオスのみが成ることができる。集団で動く際には、シルバーバックは他の個体に指示を出す。調査用の固体が敵を見つけると、シルバーバックに伝える。シルバーバックは判断し、全体が守れるように調整する。
言われてみれば、そうなのかもねーと思う。今まで会社組織にいて、リーダーシップは権威がある人（＝上司）が行うものと思っていたけれど、そうではないんだと学ぶ。確かに一見、権威があると部下にサービスを提供しやすいから、そう見えるけど、それだけでは駄目なんだと学ぶ。そういえば、最近偉くなった超PMは権力が無かった時代から、人脈（お客様、社員に対する影響力）はすごかったように思う。権威は後からついてくるのかも。
委譲した信頼は裏切られることがある
ユダヤ人の例
信用するようにされるか。教育が根幹にある場合がある。ユダヤ人はアメリカ当局を信用してはならないと、何世代も言われ続けている。たとえ、同じ人種であっても。信じるな、信じるときは慎重に。公式な権威、非公式な権威
ヒトを呼びつけたり、解雇したり。しかしながら、重要なのは非公式な権威。それは個人に期待し、信頼し、相談するあるいは、相談される。周りは自分らが期待する内容に答えられると信頼されている人物。しかしながら、リーダーシップはこれらと待った区別であるリーダーシップは権威とは別である
子供が遊ぶ際、1日の内、何分注意を払っているか？支配力の大きい人に対する注意の方が長いはず。親や兄弟など。なぜか、支配力が大きい人物のほうが多くのサービスを提供してもらえるからだ。しかしながら、権力を伴わないリーダーシップは人の目にとどまりにくい。期待にこたえられないと、自社のリーダーはリーダーシップがかけていると思われる
組織において、権力を持っている人間がリーダーシップが欠けていると不満を言う。これは権威とリーダーシップの混同によって発生する。権力に対するサービスが何か。必ずしも良いものとは限らない。ルールや制限が発生する場合があるからだ。
人々の期待するサービスを提供できないかもしれない。
人々の本質的な期待をこなすためには、一時的に期待にそぐわない施策を行わなければならないということもある。政治でよくあるのはこのパターン。
会社を良くするために最大公約数となる箇所を改善する施策を打つわけだから、社員全員が満足する対応はできない。全員に対して最大の満足度にできないかわりに、全員に対して最大にがっかりさせてないための施策が提供できるかが、リーダーシップのポイントのようである。
その最大公約数となるものを見つけ、サービスとして提供できるか、が難しいところだなぁと思う。
ではまた。
【考察】なんだかんだでノミニケーションは有効だと思う今日この頃
仕事のプロジェクトチームの飲み会に参加。
今回は自分が統括するチームの飲み会というわけで、現場情報を収集する目的だった。
ノミニケーションに参加してみてわかったこと
ピラミッド型開発により、コミュニケーションコストを効率化しているため、普段は協力会社のメンバー10人のうち、3人としか会話しない。しかしながら、飲み会では全員と会話することができる。会話するこで、チーム全体の状態を確認することができる。
具体的にわかったこと例
今回わかったことをまとめてみた。
- 協力会社のリーダーは一足飛びで出世したばかりで、超忙しい（※負担へらさないとなー）
- 昨日から参加したサブリーダーは同じお客様の別プロジェクトにいた。（※お客様の特徴を伝える手間が省けそう）
- サブリーダーはトラブル等で当分、参加は難しいので、段階的に移行する予定
- 中間搾取の企業がマジうざい。（※コレは改善の余地有り）
- 先月入った新規メンバーはプログラムを伸び盛りで楽しいらしい（※そのまま伸ばすといいかもしれない）
- 新規メンバーは最近、東京に来た
- 元サブリーダーは子供が生まれる。来年2月予定。何か準備しないトナー。
- 職場のディスプレイが小さい（※コレはなんとかしないとなー）
※はこれからの役立つ情報かなと思ったので、感想
ノミニケーション抜きで調べることもできる情報だが、たぶん、飲み会の方が効率的に本音の情報が聞けるような気がする。なんか、日本の職場には上下関係みたいな空気が漂っているから。
ではまた。
【考察】ごみ屋敷
家がごみだらけ。
いや、掃除する暇がなかっただけなんだけど、片づけがおろそかになっている。
なんで、片付けられないか
と考えてみたら、いたって普通の原因で、「出して片付けない」ということなんだと振り返る。
この「出して片付けない」というのが曲者で、どうやら少し片付けないと、後でまとめて片付ければいいやという心理が働き、加速度的にごみがたまっていくことがわかった。
散らかしたブツについて
ごみは何かという以下のとおり。俗に言うごみじゃないんだよな。
- 服（山盛り）
- 本（積み重なったやる）
- ペットボトル（二本）
- ネクタイ
- 広告
- 新しい服が入った紙袋。そして、新しい紙袋のタグ等
片付けの施策を考えてみた
たぶん、片付けのカテゴリがばらばらだから、散在してしまうのだと思う。
というわけで、困ったらまとめてポイできる箱を準備しようかと思う。
これで、見た目がごみごみしているからといった雰囲気に呑まれて、片付かない状態が加速度的に伸びるのを防ぐことができるはずだ。実験してみよう。結果はまた後日。
ではまた。
【反省】新業務・現行踏襲のアプリケーション開発の１つの失敗例
序盤。
本文とは何も関係ないが、自分のBlogが読みづらい。
読んでいて、まじむかつく。
なので他の読みやすいBlogを参考に分析した。
結果として、①事実→②分析→③自分の意見となる傾向があることが判明
自分も真似しようと思う。
だって、どうせ書くなら読みやすいほうがいいもんね（自己満足）。
現場の経験から
新業務の要件定義を担当している。
企業のシステム開発活動であり、使い手も企業内の人間なので、ユーザー部と企業の業務フローとともに議論を行っている。
しかしながら、設計も後数日といったところで、ユーザから要件追加があった。まぁベンダーとしては追加工数でウハウハなんだけど、そもそも論で言うと、要件定義に不備があったってことなんだよなぁと反省。
要件定義の漏れの原因
原因は何だったかというと業務フローを詳細まで抑えていなかったこと。
言い換えると、ユーザが既存の画面について熟知していることを前提としていたこと。
そのため、既存業務フローの踏襲として修正対象外としていた機能、実は一部が新業務フローにかわることが判明し、仕様を変更せざるおえなかった。
要件定義の粒度について
今までユーザが業務フローを書いて終わりだったのだが、たぶん、きっと、システム開発者も業務フローの粒度をシステム使用レベルで抑えるべきなんだなと思った。いわゆる、ユースケースだったり、シーケンス図だったりするんだと思うんだが、この辺の知見を時間不足や工数不足でサボったのが本質的な原因だったのだと思う。ついでにいうと、担当したプロジェクトは要件定義の期間が短かった。
というわけで、要件定義のフレームワークは重たいものであるということをクライアントのシステム部と共有する必要があるのだと感じた。しかしながら、システム部は要件定義を甘く見ている傾向があるため、それを如何に伝えるか、リードしていくかが課題である。
余談
うーん、事実、分析、解放と端的に書いてみたが、読んでみて面白くないな。コレは何故だろう。やっぱ、文章力とボケの力が不足しているのか。
くやすぃ。。。。
ではまた。
【考察】キャリアに行き詰まったときは伝記を読もう
というのが、さっきわかったのでメモ。
伝記つっても、100年前の大昔じゃなくて、自社の20～30年前の人（今の偉い人）のキャリア履歴を見てみることね。
ちょうど数年前から1時間前まで、自分のキャリアモデルがなくて、暗中模索状態で、倦怠と絶望の淵に立たされていたんだけど、ある資料を見たとたんに、もう一度がんばってみようと奮起し始めるに至った。そんな経緯もあって、これは有益なアプローチなんじゃぁ・・・なんて期待して投稿。
で、そのモチベーションをあげるに至った資料というのが、自社の偉くなっちゃった人のキャリアモデル。自分の目標を達成していそうな人、かつ、今の自分でもなんとかそのキャリアモデルのルートに乗れそうな、いい感じのラインの人がいると理想。
ちなみに、そんないい感じの人が見つかる確立は万に一つだと思うので、私は運がよかったのだと思う。
私の願望
幼少時より人から賞賛されることに快感をおぼえ、他人に良く見られたい・チヤホヤされたい一心で日々努力を重ねて・・・とかいう、どこかのアニメみたいなことに酷似するほどに、なんとなくだが、えらくなりたいと思っていた。
みんなにすごいって言われたい。お金もほしい。とりわけ、会社に依存せずに戦える存在になりたい。たとえば書籍や講演でフィーをもらって定年後も安心、みたいになりたい。
とかね。でも、これって、みんな思っているのかなと思っていたり。違う？
とにかく、まぁ俺はそう思うわけだ。
死に至る病、それは絶望。
とおっしゃったのは有名なキルケゴール先生ではありますが、結構、真理なんじゃないかと思っていたりします。
んで、自分としては絶望から希望に変えようと模索していたアプローチとしては、
- 仕事で有名になる、あるいは、ブログで有名になる（exちきりん氏）
- 本とか講演ができるようになる
とか、もやっとした夢。うーん、ま、具体的じゃない。
そう、アプローチが具体的じゃないのだ。
「これ、本当にできるの？」って言われると、「いや・・・」ってなっちゃうような。
しかも自社でそんなことしている人をあまり見なかったので、「まず仕事で有名になるって自社じゃ無理なんだろうなー」とか思っちゃっていて、模索している感じだった。
そうすると、あら不思議。モチベーションが下がりまくった挙句、悶々としていたところから抜け出そうと、転職活動とかやっちゃって無駄な時間をすごしていたわけ。そういうときに限って、自社が不調だったりして、悪いところばかり見えてきたりするんですよねー。
ところがどっこい、転機が訪れた！
信じるものは救われる
神を信じれば救われます（信仰）。アーメン。
なんていうキルケゴール先生の解法についていけなかったのが昔の話。
なんだけど、自分の信じるものを信仰とするならば、現代版として言い換えると信頼されているという自信であり、自分の存在価値を肯定できる未来への希望なんじゃないかと思うのでス。
という夢を見ました。・・・じゃなくて、上記のイメージを前提に考えると、私は科学的なアプローチを信じることにしているので、掲題の心理に基づいて考えるアプローチを持っているのです。色々回りくどく語ったものの、先人たちのエリート街道が、自分でもアプローチ可能だと判断できている範疇においては、希望を持つことができるようです。
で、私はたまたま、社内のWEBでそういうキャリアパスの人を見つけられたからよかった。
これからがんばろう、おー。って感じ。
ちなみに、もし自社にいないという人がいたら、IPAあたりでもキャリアパスの事例が書かれているから、参考にするといいかも。ちなみに自社の超偉い人はPMの事例として載っていたり。
これとかこれとかこれ。
ってわけで、自社のエリートみたいになれるように、これからもがんばろうと思う。おー。
ではまた。
【考察】ベンダーとユーザー企業
昨日、月島にてSIのベンダー（他社）からユーザー企業に行った先輩方と飲む。
その中で、ベンダーとユーザの違いを感じたので、メモする。
ベンダーにいるときの特徴について（先輩のいた企業の場合）
- 開発主体の業務
- 国産企業の子会社SI企業はぬるい(-要因)
- 残業が多い（これはヒトによる）。逆に言うと、時間の自由度が高い。
- 一例としては、出社が11時でも誰も文句を言わない
ユーザ企業のシステム部の特徴
- 業務主体の業務
- どうやら、提案書や企画書を作るのが主体。開発能力は失われる
- 残業が少ない（時給制として考えると、ベンダーに比べて時給が上がる）
- 逆に言うと、出社、退社の時間が決まっており、残業できない。融通がきかない
- 遅刻厳禁。出世に響く。1ミスが命取り（これは銀行特有じゃないかと）
- 企業によってはスーツではない
- いろんなヒト（外資証券、コールセンターの変なヒト、ベンダーなど）が入り乱れる
私のいる会社（外資系SI）について
最近、嫌気が差していたけど、前向きに立ち向かう覚悟を決めると、色々融通が効いて、いい感じな住処であると感じたり。
- 開発主体
- 技術的にイノベーションとなる製品がたまに出る。
- うまくできると世界で最先端のものに触れられる
- 残業が多い（これはヒトによるが、比率は高い）。かわりに、出社は自由度が高い
- ぬるくないのが多い。部門によってはぬるい。
- 休みはそれなりにとれる（プロジェクトが順調な場合に限る）
見比べてみて
ヒトによって、行きたい会社は変わるんだろうな、と思う。
自分としては、残業が多いのは悩ましいけど、朝ゆっくり出社できるのはすごいメリットだなぁと思う。子供を保育園につれていけるしね。
あと、SNSとか、課外活動（OSSコミュニティ参画）が全社的に自由なのは大きい。これは、今後の自分の頑張り次第で芽が出るかもしれないしね。
ベンダーはデメリットも多いけど、まだまだ捨てたもんじゃないなぁと思う、今日この頃。
ではまた。
