そらとぶへび

仕事・プライベートを通しての気づき、JavaやPHP、データベースやサーバの話などこつこつと書いていきます

最良のパフォーマンスで臨めるように、何をすべきか

いま現在、来年度の転職に向けて活動を始めている。環境を変化させようという試みは、ワクワクする気持ちもある一方で不安な気持ちも溢れている。何かに悩みごとがあると、注意力が散漫になる。自分に意識が向いていると、話が頭の中に入ってこない。今回は後悔しない選択をしたい。全力で最良のパフォーマンスで臨めるように、何をすべきか。

部屋の掃除をする。

モノが溢れているとそちらに注意が行って気が散る。集中力を減らすものをなくして、自分と向き合う空間を創る。自分がどういった部分で落ち込みやすいのかを考えてみる。その部分を理解すること、それだけでも、気分の落ち込みを緩和させることができるはず。

感情的にならない。

怒りや悲しみにとらわれると、考え方が偏る。自分に意識が向いている状態になる。批判的な意見を言われても、相手は相手、自分は自分として、「考え方は人それぞれある」と心がけて、前向きな気持で会話をする。

目を見て話を聞く。

話し相手の目を見て話すというのは、周囲の雑音や気になる動きに気を取られることを軽減させる効果がある。
相手の視線を追いかけて集中するだけでも、話が聞きやすくなる。

確認をしっかりとる。

話を要約して相手に確認をする。多分こんな話だったと話をすすめない。ちょっとしつこいくらいに確認したほうがむしろビジネスの場面では信頼関係を保つためにも良い。

外で運動をする。

できるだけ軽い運動をする。深い深呼吸をする。太陽の光を浴びる。

三者の意見を聴くこと。

同じ悩みを持っている人と意見交換をする。コーチングをしてもらう。ただし、あくまで一意見として受け入れる。最後には自分の意見としてまとめる。

そして最後に。
頑張りすぎない。時には逃げも必要。
だたし、妥協のない選択をしよう。

PHP 参照渡しのキホン

参照渡しはアンパサンド「&」を代入元の変数の「$」の前に付ける。

$a = 'Red';
$b = $a; // 値渡し
$c = &$a; // 参照渡し
echo "代入直後 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL;
$b = 'Blue';

echo "変数b(値渡し)を変更 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL;
$c = 'Green';
echo "変数c(参照渡し)を変更 -> a(元の値):{$a},b(値渡し):{$b},c(参照渡し):{$c}" . PHP_EOL;

実行結果:

代入直後 -> a(元の値):Red,b(値渡し):Red,c(参照渡し):Red
変数b(値渡し)を変更 -> a(元の値):Red,b(値渡し):Blue,c(参照渡し):Red
変数c(参照渡し)を変更 -> a(元の値):Green,b(値渡し):Blue,c(参照渡し):Green

値渡しは、変数$bのみ変わるが、参照渡しの場合、$aが変われば$cも変わる。


参照渡しはforeachでも応用できるので、うまく使いこなせばかなりスマートなコードになる(かもしれない。)

foreach ($array as &$value){
  $value = (ここで代入した値が$arrayに反映される)
}

ちなみに、オブジェクトはデフォルトで参照渡しになる。オブジェクトで値渡しをしたい場合はcloneを使う。

$a = new stdclass(); // オブジェクトとして生成 
$a->test = 'Red'; 

$b = clone $a; //値渡し 
$c = $a; //参照渡し 
echo "代入直後 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL;

// 変数b(値渡し)を変更する 
$b->test = 'Blue'; 
echo "変数b(値渡し)を変更 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL;

// 変数c(参照渡し)を変更する 
$c->test = 'Green'; 
echo "変数c(参照渡し)を変更 -> a(元の値):{$a->test},b(値渡し):{$b->test},c(参照渡し):{$c->test}" . PHP_EOL;

実行結果:

代入直後             -> a(元の値):Red,b(値渡し):Red,c(参照渡し):Red
変数b(値渡し)を変更   -> a(元の値):Red,b(値渡し):Blue,c(参照渡し):Red 
変数c(参照渡し)を変更 -> a(元の値):Green,b(値渡し):Blue,c(参照渡し):Green

管理職≠マネジャー

マネジャーとは地位ではなく役割であるということを考えてみる。

管理職≠マネジャー

管理職≠マネジャーとして切り離して考える。古い組織環境で管理職とマネジメントが混同している場合、職場環境は上意下達の形になる。経営者の命令を、中間管理職が噛み砕いて部下に伝えるだけで、ほとんどメッセンジャーと変わらない。こういった環境では、上からの命令をどれだけ忠実に評価の対象になり、社内のことばかりを考えてエンドユーザを蔑ろにするような傾向になる。

どんな役割であるべきか

本業とは別にフリーでやっているプロジェクトにおいても作業を細分化して担当者に差配する人がいる。通常の会社組織では上司の仕事だが、この仕組においては、会社組織ではないので、上司ではない。純粋に地位ではなく役割としてマネジメントを行っている。当然、この人の意見が絶対ではなく、お互いに意見交換の上で物事を決めている。


1.現在の状態を明確にし、問題と課題を定義する
 目標・目的地を明確にしておくこと。そのうえで、何が問題・課題となっているのかを考える。何があれば解決するのかを絞る。

2.対策を講じる
 課題を特定した上での選択肢を複数だし、効果的な案を選択する。思いつきで着手すると徒労になることが多いので、できるだけ多くの手段を上げておくこと。

3.メンバーが成果を出すためのプロセス作る
 前回の作業結果から、出来たところ、出来なかったところを抽出して、次回どのようにすればより効率が上がるかを考える。「出来ないこと」はメンバーの問題ではなくプロセスにあることをまず考えて、改善策を出して次のアクションに結びつける。 定量的に数値で把握し可視化する。


マネジャーがもつ権限に給与や査定などの人事権のような権力まで握られると、マネジャーの人となりにより、意見交換が阻害されることもある。自由闊達な意見交換ができる環境で仕事ができればいいと思う。

それでは、優れたマネジャーの要件はなんだろうと考えていたところ、Google re:Work(リワーク)での記載が腑に落ちたので、引用させていただく。

rework.withgoogle.com

  1. 良いコーチである。
  2. チーム任せ、細かく管理しない。
  3. チームの仕事面の成果だけでなく、健康を含めた充足に配慮しインクルーシブ(包括的)なチーム環境を作る。
  4. 生産性が高く、結果を重視する。
  5. 効果的なコミニュケーションをする-人の話をよく聞き、情報を共有する。
  6. キャリア開発をサポートし、パフォーマンスについて話し合う。
  7. 明確なビジョンや戦略をもち、チームと共有する。
  8. チームにアドバイスできる専門知識がある。
  9. 部門の枠を越えて、コラボレーションをおこなう。
  10. 決断力がある。

Google re:Work(https://rework.withgoogle.com/jp/)のサイトには参考になりそうな記事が掲載されていたので年末年始あたりで熟読してみたい。

数打ちをする大切さ

今から6、7年前、長期休暇をとって夫婦で長崎旅行の際に、波佐見の地を訪れた。
義兄が営んでいる飲食店で使用している白磁の器を制作している工房が近くにあるので、いい機会だからと寄らしていただく事になっていた。

そもそも旅行の計画をたてても、いつもその場でコロコロ変えるような行き当たりばったりな旅行なので、何時にいけるという保証もなく、玄関先でちょっとご挨拶だけできればという気持ちでレンタカーを走らせて、工房へ向かった。しばらく走ること数時間、目的の看板を見つけた。が、思わず一回通過してしまう。「ほんとに伺って良いのかな?こんなぺーぺーの若輩の夫婦が時間の約束もなくふらりと訪れてもよいものか」と。実は訪問先の方は県に無形文化財として評価されるほどの方なので気後れした。
とはいえ、はるばるせっかく来たし、義兄から伺う連絡も入っていることだろうし、そう機会があるものではない。引き返し勇気を出して車を停める。

工房の庭で草むしりをしている方がいた。庭師の方だろうか?とおもいきや、御本人だった。
嫁が「兄がいつもお世話になっています」と挨拶すると、「あれ、○○さんの妹さん?!」とすぐに気づいていただいた。そしてにこやかに工房へ迎い入れてくれた。


工房ではいろいろな話を聞いた。肩書のことなど意にもかけない気さくな方だった。
都内でも個展や展示されていし、デパートで売られている値段は他の職人の器とは段違いの価格で販売されている。ところが、どこで展示されていようがいくらで売られているのか、当のご本人は興味が無いらしい。

また、バイヤーさんが大量に仕入れる後に毎回いくつも返品をしてくるらしいが、返品されることに対しても、器のどこが問題なのかなど気にしていない。

「我々は、芸術家とは違って数打ちの職人だからね」とおっしゃる。「芸術家は一点だけを残して他は割ってしまう。我々は、使ってもらうために作っているのでそんな事はしない。」と。
普段使いの器として使ってもらうために、数を打つ。陶器の知識も無い素人なので深いことはわからないが、素人目にみても、明らかに他の器とは違って飾り気がない。その分、素朴な美しさが際立ち触り心地が滑らかになっている。無駄のない造形は「数打ちの職人」でなければできない技術と思う。

帰り際、「だんなさん焼酎飲むの?」と聞かれたので、ハイと答えると、ご自宅の玄関の前まで付いてくるようにいわれ、ついていくと両手にすっぽりと収まるくらいの大きさの白磁の器を頂いた。絵付けのない丸い器だった。「この間バイヤーさんから返品されたものなんだけど、よかったら使ってよ」とのこと。何度見てもどこに問題があるのか検討もつかない。それどころか持った瞬間の手に馴染む感覚がとても気に入って、ありがたく頂いた。


翌年、一通の訃報があった。長いこと癌で療養しているとも伺っていたので心配していたが、訪れたときは草むしりをしていたし、工房では元気にたくさん話をしていたので、まだまだ大丈夫なんじゃないか、むしろそのまま病気を克服してしまって、またお会いできるんじゃないかと勝手に楽観してしまっていただけにショックだった。

真に一期一会の訪問だった。
 使い手のことを思って、ひたすらに数打ちすること。
 失敗にくよくよしないこと。
ほんの短い時間の中で、ものづくりのための大切なことを教わった。

あの時頂いた器は、我が家の家宝として、ただし棚に飾るようなことはせず、晩酌する際の器として今も大切に使わせていただいている。

一番厳しい人が、一番やさしい人だった

とあるプロジェクトにアサインされて4年の間、クライアントに毎日のように叱られていた時期があった。
月次会議の数日前からかなりのプレッシャーを感じながら仕事をしていた。確認モレのないよう重ねに重ねて見直しをしても、痛烈な指摘を食らう。

指摘される日々

やり方に無駄がある、対応の優先順がおかしい。原因究明の不足。ところどころを的確に詰められる。当時、PMOという複数プロジェクトを取りまとめるチームの一員として働いていた。数あるプロジェクト、部署、ベンダー、それぞれのシステム一つ一つにどのような業務があって、どう影響し合うのか、整理しきれずにいた。

クライアント組織の全システム案件が間断なく流れ込んでくるので、考える時間的な余裕はない。瞬時に優先度や連携先、共有先を判断して最善と思える体制を組み立てる。1件1件と、ひたすら数をこなす中に、重い案件が混ざっているにもかかわらず表面的に判断してしまい本来の原因を把握しきれずに、調整ミスが発生する。問題発生時の原因究明中も、別の案件対応を迫られるので、十分な調査・整理時間を確保できない。その結果、「ただこなしているからそうなる」「利用者のことを考えていない」と散々に指摘される。クライアントの指摘は筋は通っているため、言い返す余地がない。毎日間断なく案件が降ってきては忙殺され、毎月のように辛い思いをした会議だった。

吹っ切れたきっかけ

何度も心が折れそうになったが、それでも心が折れずにやってこれた要因は、痛烈な指摘の中に自分個人への攻撃は一切なかったことだと思う。問題はやり方にあるだけなんだ。そこに気がついてからは、なにがあっても吹っ切れるようになった。毎月烈火の如く叱られるのを恐れず、何度もトライできるようになった。徐々に仕事のパフォーマンスは上がってきて、以前より増えているにもかかわらず、案件を素早く的確に捌けるようになってきた。1年くらいした頃には、重要な案件や問題の兆しがありそうな案件など何かある度に事前に知らせをくれるようになった。本来の業務ではないにもかかわらず。おかげでよりパフォーマンスを発揮できるようになった。結果として組織全体が素早く動けるように対応することができるようになった。

徐々に、信頼を築くことを実感できた。それでもたまに油断すると以前のように烈火のごとく叱られることはあったが、理解のある指摘は気持ちがいい。ただただ辛かった月次会議も、いつしか会議の緊張感が楽しみになってくる。プロジェクトとしての期間を終え、クライアント組織を去るころ、その方は定年を過ぎて嘱託になっていた。挨拶に伺った時、今までにあった誰よりもやさしく朗らかで暖かかな態度で迎えて頂いたのが印象的だった。「誰かがいわなきゃいけない、そんなときに真っ先に指摘をする」自らの役目に徹底した人だった。

一番厳しい人が、一番やさしい人だった

今思えば、相手のことを一番考えていたのはその厳しい指摘をくれるクライアントの方だったかもしれない。どこまでも厳しく、それでいて人を叱る際に個人への攻撃は一切しない。今までで一番しんどい思いをした時期でもありながら、一番感謝を感じた時期でもあった。

こういった方に、これから何人出会えるだろう。

要求定義に用いるツールと技法

代表的な引き出し技法

ブレーンストーミング
・ 文書分析(既存文書のレビュー)
・ フォーカスグループ
・ インタフェース分析(外部インタフェース分析)
・ インタビュー
・ ジョブシャドーイング(観察)
・ プロトタイピング(モデリングとストーリーボード)
・ 構造化やオブジェクト指向の方法論を使用した要求ワークショップ ( JAD、引き出しワークショップ)
・ 調査(アンケート)

代表的なモデル化技法

・スコープモデル(コンテキスト・ダイアグラム、DMM)
プロセスモデル 業務フロー図、データフロー図
・ルールモデル デジションテーブル、デジジョンツリー
・データモデル ER図、クラス図

代表的な費用対効果分析法

 定性的技法
  費用効果比較法
  重み付けスコアリング法
 定量的技法(時間価値考慮なし)
  回収期間法
  費用効果比較法
 時間価値考慮あり(DCF法)
  NPV法
  IRR法

ビジネスモデル

事業戦略はビジネスモデルとして表現できるとわかりやすくなる。
ビジネスモデルをデザインするスキル 「ビジネスモデル・キャンバス」と「ピクト図解」を身につけろ | 「ピクト図解」考案者が語る ビジネスモデルのつくり方|DIAMOND ハーバード・ビジネス・レビュー

ビジネスモデル・キャンパスの9つの要素
(1) 顧客セグメント( Customer Segment )
企業が関わろうとする顧客グループについて定義する。
(2) 提供する価値( Value Proposition )
特定の顧客セグメントに向けて、価値を生み出す製品とサービスについて記述する。
(3) チャネル( Channel )
顧客セグメントとどのようにコミュニケーションし、価値を届けるかを記述する。
(4) 顧客との関係( Customer Relation )
企業が特定の顧客セグメントに対して、どのような関係を結ぶのかを記述する。
(5) 収入の流れ( Revenue Stream )
企業が顧客セグメントから生み出す現金の流れを表現する。
(6) 主なリソース( Key Resource )
ビジネスモデルの実行に必要な資産を記述する。
(7) 主な活動( Key Activity )
企業がビジネスモデルを実行する上で必ず行わなければならない活動を記述する。
(8) パートナー( Key Partner )
ビジネスモデルを構築するサプライヤーとパートナーのネットワークについて記述する。
(9) コスト( Cost Structure )
ビジネスモデルを運営するにあたって発生するすべてのコストを記述する。

表で、事業戦略案にCSF(重要成功要因)とKGI(Key Goal Indicator)を整理する。

CSF 事業戦略を達成するために、行わなければならない重要な事項
KGI 事業戦略が達成できたかどうかを判断する時の基準