「変わるもの」と「変わらないもの」にどう立ち向かうかのヒントを見つけよう

まず、変わるってどういう意味かを確認しましょう。

一面的にしかものを見る癖がついてしまうと、辞書を引く前から一方的なものの見方、解釈の仕方しかできなくなってしまうので日頃から360度のビューワをぐるぐると回すように、ものを見るポジションを次々と変えられるように繰り返し試しておきましょう。

特に、エンジニアではない、別の役割、例えばマネージャ、顧客などの立場なら世界がどう見えているかを感情的な部分を切り離して意識を切り替えられることは日常の業務で有効なスキルになります。

それで、変わる＝変化という言葉の意味を確認しましょう。 

へん‐か〔‐クワ〕【変化】の意味
［名］(スル)
１ ある状態や性質などが他の状態や性質に変わること。「時代の変化についていけない」「変化に富む生活」「気温が急激に変化する」

２ 文法で、単語の語形が人称・数・格などに応じて変わること。「動詞の語尾が変化する」

引用　変化（へんか）の意味 - goo国語辞書

 どうして、役割を意識した視点の持ち方に触れたかというと、変化するということには、良い悪いという捉え方は間違いで、状態が変わるという捉え方をしなければ判断自体を誤ってしまうということがあるためです。

よくやってしまうのは、変化したときに基準を持たないで良し悪しを印象だけで考えようとしてしまうことで、その前には、変化することを評価するということが目的となっているかどうかで評価するしないをしなければならないということです。

言い換えれば、変化すること自体を意識して見る必要があるかどうかということなのです。

登場人物を揃える

エンジニアビューから見たときに状態が変わっていくものを登場人物として書き出してみましょう。

人物系（状態）

• エンジニア自身
• チームメンバ
• チーム
• 組織
• 顧客

人物以外（質）

• 経験（習熟度）
• 能力（できること、できるレベル）
• 技術（高度化）
• 価値観（判断基準・開発スピードなど）

ざっくりと思いつくままに書き出すとこんな感じでしょうか。 

さて、エンジニアを取り巻く要素全てがそれぞれで登場人物（状態）や人物以外（質）が変化する要素を持っていることに気づいたと思います。

これは仮にエンジニア自身が変わらないとしても、エンジニアと普段から接する登場人物が変化していくし、エンジニアが使う道具も質が変化していくのです。これでエンジニアが何も影響を受けないでいられるでしょうか。

こうしてエンジニアを取り巻く登場人物を取り揃えてみると、もはや変わらないという考え方自体が間違っているような気がしてきます。

「変わる」源泉は何か

 では何が源泉となってエンジニアを取り巻く状態や質が変わっていくのでしょうか。

それは時間の経過とともに経験知を積み重ねていくためだ、と思うのです。つまり、エンジニアとして生きていく以上、変わることが必然であり、状態や質を変えないということは、逆行する考え方である、というものの見方です。

「変わる」「変わらない」を取り違えている

状態や質を変えないという行為は、実はシステム開発ではよく行っていることです。

例えば、品質は、要求される品質へ到達している状態を維持しようとします。例えば、チームは作業で期待する成果を一定のレベルで得られるように活動をします。

これは普段変わらないと思っていることは、実は変わっているということであり、変わったと印象を持つことは、変化のスピードが体感できるほど状態や質が変質したということなのです。

更に言えば、変わらないということは状態や質を維持するために、刻々と変化している状態や質をリソースをかけて維持しているということになるのです。

これは、放っておいても無意識で変化するというということに対する、エンジニアが実現したいことをどう定義するかにかかっているということです。

チーズはどこへ消えた？ (扶桑社ＢＯＯＫＳ)

あなたの技術料はおいくらですか

このエントリを読みつつ思い浮かべていたのは、エンジニアで自分の技術料をどのくらいで売りたいかとか、それより以前の話で値付けをできる人がほとんどいないのではないかと思うのですがそんなことはないでしょうかね。

↓の無償、有償の話とは違う、エンジニアの値付けの話なのですので。

note103.hatenablog.com

エンジニアの労務単価も　JIS 単価 労務 - Google 検索　と同じように決まりがあれば誰も悩みはしないのですが、端的に言えばそれがないのでエンジニアが持っている技術料の価格設定をエンジニア自身は知らないし、知ろうともしないし、値付けをした経験もないわけです。

多くのエンジニアは良くも悪くもエンジニアの技術料を売るのは営業で、職種で販売と供給を分離していることがエンジニア自身の技術料をエンジニア自身が知らないし、売る技術料の価値の評価方法を誰も知らないから人月という拘束時間で人売りが生じるわけです。人月商売の話を今回はするつもりはないので、それは過去のエントリを検索してもらうかまた次の機会に。

あなたの技術料を教えてください

と言われたら何をいくらと答えますか。

ほとんどのエンジニアは回答に窮するのではないかなぁと思うのですが。答えらるエンジニアは転職の経験があって転職エージェントが年収いくらといったから、とか、提案で自社の人月単価を知っているからくらいなのではと思うのです。

なので、技術料でいくら、という値付けは答えられない、と。

これがサービスを提供している個人事業主のエンジニアになると提供するサービスに値付けをしているからこのサービスならいくら、とすぐに答えることができます。

やはり、売るものを持っていると提供する技術料の値付けを自分でやっているからある意味強いです。

安く値付けてしまう

 事業として売り物を持っていると売るまでや売った後のかかるコストを知っているのでそのコストに利益を乗せて売ればいいという理屈を知っていますし、実際にかかるコストが雑多でそのぶんを確実に回収しないとビジネスとして回らないので回収できる値付けをしてきます。

こうした技術料を提示するまでに必要となるコスト構造を知っているか知らないかでトンチンカンな値付けをしてしまったり、売ってはいけない価格で受注してしまうことが起きているわけです。

市場価値・コスト・提供する技術

市場価値についてもなんとはなく、買い手の希望である、－そりゃそうです、いくら売り手が値段をつけても買い手がいなければ商売は成立しないで－、と思っているのでそういう値段であることだと理解した上で、いくらくらいで自分が売れるのかというのは知っておく方がいいです。

ただ、そうした市場価値は年収というざっくりしたものですから技術料にするならまた別の価格設定の考え方が必要となります。

市場価値でも技術料でもコストを賄えなければ売る意味がないのでコストにどれだけかかるかを理解しておかないと手に入れられるはずの利益が飛んでしまうのでこうしたコスト構造を知っておく必要があります。提供する技術料に直接かかる費用については視界に入り安いので意識されますが、社会保障制度の費用や税金は間接的にかかる費用なのですが確実に持っていかれるので忘れてはいけない課目です。

提供する技術は、まあ専門家としてこれが専門技術だと言えればいいです。ただ、売りたい技術に買い手がつくと思っていたら痛い目にあいますよ。それに技術がコモデティ化すると技術料が沈下していくし、競合が勝手に価格競争を始めるので何を売るかは考えながら売らないといけないし、当たり前ですが独占し続けられなければ技術更新は欠かせないです。それもまたコストがかかのでる。

価格の値付けを知るための副業

 色々とエンジニアの副業は取り上げられていますが、副業とはせずに、税務上、雑所得として申告することを本業とは別にすることをオススメします。

書籍の執筆もそうですし、アプリを作ってリリースするのもそうです。びっくりするくらい増刷やダンロードされれば別な話ですが、そんなことはまずないので心配せずに、エンジニアとして作る技術料の値付けを実践するためにやりましょう。

やってみるとわかりますがコスト構造を知っていて、それに見合う対価を確保することを考えるようになると安く売ることがどれだけ何も考えずに取引しているか、楽をして商売をすることでその先のエンジニアの首を絞めていくかがよくわかりますし、エンジニア自身が技術の更新をしないと欲しい価格が得られずコストも賄えないことが身を以て経験できるのです。

さて、あなたの技術料はおいくらですか。

作業の中心にエンジニアを置くための情報と技術のあり方

人は起きて欲しくないことが起きるまでは、たとえそれが起きた時にどうなるか類似の経験をしていても見向きもしないし、どちらかと言えば思い出したくもないような経験であればあるほど自分の視界からそれを遠ざけるものです。

システム開発でのそれはトラブルがそれにあたります。

情報の流れ

ウォーターフォール型のシステム開発を採用している場合、システム開発に必要な情報は、チームの組織構造の上位層から下位層に流れます。

トップマネジメント層からプロジェクトマネージャへ、顧客からプロジェクトマネージャへ、プロジェクトマネージャからアーキテクトへ、プロジェクトマネージャからSEリーダへ。SEリーダからエンジニアへ。

プロジェクトの継続を左右する重要なことであればそうした情報の流れは強固になります。

作業の担い手 

ところでプロジェクトチームでシステム開発の作業プロセスの担い手は誰でしょう。

誰もが間違いなく答えられるとおり、プロジェクトチームでの作業プロセスの担い手はエンジニアです。トップ層であるトップマネジメントでもプロジェクトマネージャでもありません。

プロジェクトチームのエンジニアが作業を遅滞なく進めなければプロジェクトは緩やかにブレーキを踏んだ状態でアクセルを踏むことになり、知らず識らずのうちに取り戻せない負債を抱え込むことになります。

担い手と情報

 では、エンジニアの作業を滞らせることは何か。

それは、システム開発上で要件を実現するために要件を具体化するために必要な情報です。

エンジニアは無形の要件を情報の加工、つまり、情報の詳細化を繰り返し行うことでコードに変換できるサイズまで分解し、コードに組み替えて今度は、無形のシステムとして再構成を行います。

作業の担い手であるエンジニアは、情報がなければ何も作り出すことはできません。

共有のあり方

 冒頭のように、システム開発でトラブルが起きてから情報共有をエンジニア全員にし始めることが多いのは、作業の担い手と情報を誰が必要としているかという組織における情報を必要とする処理プロセスを理解できていないと見ることができます。

これは、階層型組織構造を取る組織においても同じことです。

トラぶれば、朝会や全体ミーティングを頻繁に開き、エンジニアの作業時間を奪ってまでプロジェクトチーム全体を巻き込んで情報共有をし始めます。

これは何のために行なっているのか。

作業の担い手に、必要な情報を確実に共有するために行なっているのです。

フラット化とロール

 組織をフラットにするという考え方があります。これは中間管理層を減らすことで情報共有と意思決定の速度を上げるというものです。

これと同じようにプロジェクトチームの中でも情報についてはチームの中でフラット化をすることが平時からの情報共有を確実にオペレーションするために必要な組織構造のあり方となるのです。

つまり、プロジェクトチーム内のロールは階層を示すものではなく、これまでの過去のエントリでも繰り返し述べて来たとおり、ロールは担う役割の識別子でしかないとう考え方を実現しなければならないということです。

平時の共有

 プロジェクトチーム内の情報のフラット化による共有は、全体で共有する仕組みを作り、継続して共有を続けなければどうしようもありません。

プロジェクトの中での方向性や今後の計画については集合形式の情報共有による1:Nの拡散で実現できるテーマもありますが、技術の共有についてはそれは成り立ちません。

聞いているだけでは技術は身につきません。

そこで出てくるのがモブプログラミングです。チーム全員でそれを行うことで技術の共有を一度に行うことができる多分ただ一つの方法です。

情報を平時からフラット化したチームの組織構造の中で共有し、作業の担い手であるエンジニアがシステム化するための適用技術をモブプログラミングにより技術情報の共有を図ることを実現できるからこそ、ここ1年でモブプログラミングが脚光を浴びつつあるのです。

エクストリームプログラミング

組織パターン (Object Oriented SELECTION)

プログラムマネジメントとプロダクトマネジメントは双子の兄弟か

とある夜の会合で某氏が

「プロダクトマネジメントはプログラムマネジメントではないか」

と言い置いて席を離れた後、そうかねぇとツラツラとそれが成り立つかを頭の中で考えようとしたけれどなんだかよくわからない。

わからないときにはわからない頭の中でこねくり回しても時間の無駄なので言葉の意味合い、定義から調べなおすのが兎に角一歩進めるのでそうする。

「製品、製品ライン、あるいは製品ポートフォリオのレベルでのビジネスマネジメント」

引用　

プロダクトマネジメントとは / PMstyleコラム

うーん、わかったような、わかっていたような。つまりだ、モノコトのビジネス・ライフサイクルをマネジメントする、という意味であると理解することにした。

標準書全体の文脈を含めて読み取ると、米国ではプログラム＝「巨大なプロジェクト」というとらえ方が強いが、日欧では「事業を創出する諸活動」との文脈でとらえる傾向がある

引用　プログラム・マネジメントは本当にプロジェクト・マネジメントの上位概念なのか : タイム・コンサルタントの日誌から

なるほど。局によって意味合いが少し違うけれど、日欧では事業＝ビジネスの諸活動の意味合いで使われると。

いいとこ取りしている感じの日本の定義を見ると、欧米の両方を包含した定義になっているのでますます曖昧になる。

日本PM協会: 新版P2M標準ガイドブック (2007)
使命（ミッション）を実現するために、複数のプロジェクトが有機的に結合された事業。　- 「大規模システム型プログラム」と「戦略型プログラム」（創出・変革型）とに分類される（定常業務はサービスプロジェクトとして位置づけられている）。

 引用　同上

特に、有機的に結合された事業とは、ビジネスオーナが担当事業の範囲でマネジメントしていればリソースやビジネスの判断は配下のビジネスの事情を考慮してジャッジするのでとても有機的である。

プロダクトマネジメントはモノコトのライフサイクルマネジメントだとするとプログラムマネジメントの事業を創出する諸活動が当てはまらなくもない、というか当てはまると言い切っても間違いではなさそうだ。

ところで、これまでプロダクトマネジメントに関わるまでは、プログラムマネジメントとは、プロジェクトマネジメントを束ねたマネジメントスタイルがプログラムマネジメントだと思っていた口である。

古いPMBOKをベースの知識として、あとは実施に経験して補完した限り、それで間違いはないと思うし、実は今でもそうだと思いっている。

なぜかというと、ビジネスにおいてサービスの創出や世代更新からマーケティングやセリングに携わっているとモノコトのライフサイクルマネジメントを複数並行して見ていたからだ。

そのときはプロダクトマネジメントという呼び方はしていなかったけれど、実務的にそれをやっていたのである。経験はとても強い知識の関連性を産むものなので、今のプロダクトマネジメントについては経験の目線から入るから、ああ知っているよ、という反応になるのだ。

多分、プログラムマネジメントとプロダクトマネジメントは違うもので差分があると思う方のプログラムマネジメントが対象とするライフサイクルの範囲が違うのだ。それは、プロジェクトの実行段階である設計からテスト完了までか、その両サイドにある企画からモノコトのサンセットまでを視野にいれているかの差で、これ自体が正解や間違いという判断するものではなく、経験の差があるだけの話だ。

プロダクトマネジャーの教科書

世界で闘うプロダクトマネジャーになるための本 ~トップIT企業のPMとして就職する方法~

改訂3版 P2Mプログラム&プロジェクトマネジメント標準ガイドブック

OKRと目標管理に実装されていなければならないこと

組織によってはあとひと月ちょっとで年度末を迎えるところもあるだろうし、多くは来年3月が年度末のところが多いのでしょう。だいぶ、web系の会社も増えたり、再編があったりすると決算月がいわゆる年度末の3月ではない組織が増えているような気がしますが。

年度末といえば、業績評定です。まあまあ、そんな嫌な顔をしないで。この1年何をやってきたか、自分と向き合うには良いじゃないですか。

 業績評定をするには元となる目標設定が必要で、評定をするためには元の目標設定の大切さについてはこれまでなんどかエントリを書いています。

ここのところ、グーグルのOKR（Objective and Key Result　目標と主な結果）というキーワードを見かけるようになったのですが、それに当たる記事を読んでみてもよくわからないのですよ。

目標管理での目標設定

過去のエントリで書いてるのですが、目標をどう設定するかでその年の目標設定で達成したいコトがほぼ決まってしまうのです。

どういうことかというと、曖昧な目標設定をするとエンジニアに限らず人は自分に甘いので結果的に目標を達成しないというものです。

ですから、目標管理での目標は、

• 定量的な目標を
• 具体的に達成したイメージを持って

設定できるかどうかにかかっていると言い切っても問題はありません。ただ、ほぼ8割方のエンジニアは定量的で達成したときのイメージを目標設定することができないのが実態です。

目標管理でのKPI

 一般的に目標管理のエンジニアレベルの目標を上に辿っていけば、組織の年度の事業計画のKPIに遡れるはずです。いや、遡れなければおかしいです。

なぜなら、組織の事業計画を達成するのが組織に属するエンジニアだからです。そのエンジニアの1年の活動が組織のKPIに結びついていないならエンジニアの活動は評価されないというのと同じです。組織の評価をKPIでするのですから。

そうした考え方を踏まえるなら、エンジニアの目標設定はKPIの一部分を担う定量的な目標になっていなければ辻褄が合いません。

そうした背景もあって、エンジニアの目標管理の目標は、定量的である必要があるし、目標達成時のイメージが具体的である必要がるのです。まあ、後者については、エンジニアが年度の初めで1年後に実際にどうなっているかは別にして、到達したいイメージを作っておかないと最初の一歩が踏み出せないという事情もあるのですが。

OKR

ところでOKRですが、

企業のチームメンバーそれぞれの目標と期待されている結果を明確にし、組織のオペレーションとコミュニケーションを効率化するためのシステム

引用　

KPIはもう古い！ Googleも採用する『OKR』が目標達成に効く理由。 | コラム

だそうです。考え方は良いですよね。期待を明確にして、オペとコミュを効率化しよう、ですから。

目標自体は、エンジニア一人ひとりに設定するものです。一人ひとりのエンジニアの活動結果が集約して組織の事業計画の達成につながるので。

さて、目標を設定するときに、目標は組織の期待だけなのか。いいえ、違いますよね。これも過去のエントリに何度か書いてきましたが、組織の期待とエンジニアの希望のすり合わせの結果の合意がエンジニア一個人の目標にならなければおかしいです。

一方的な期待では、主体性が欠如するので。

引用の中で、

ひとつの目標を階層ごとに細分化、数値化し続けていくことで、チーム内で「何をすべきか、目標は何のためにあるのか」がわかりやすくなります。

とあります。あれ、上述してきた目標管理の目標設定と同じですね。わざわざOKRと言い換える必要があるのかしら。

ただ、こういう言い方は良いなと思います。

しかしたいていの場合、このような目標設定の仕方ではうまく行かない場合が多いもの。なぜならば「結局どうしたいのか」というビジョンをつい忘れがちになってしまうからです。

達成したい目標の達成時のイメージを持っていないと目の前の数字を達成することが目的となってしまうのというところ。よく言われる、目的と手段が擦り変わるというやつですね。

目標を個人に活かす

 結局、組織としてはリソースたるエンジニアに事業計画の達成を担って欲しいのです。それだけ。指揮命令して間違いないくオペレーションする必要のある業務もあるのでしょうが、エンジニア個人の属人的な知識に頼っているシステム開発では、それでうまくいくなら良いけれど、実際はそうならないのは考え、行動するエンジニアに依存しているからです。

だから建前上は、主体的に活動して欲しいわけです。でも強制しても期待する結果は得られないから、エンジニアが気持ちよく働けるように落とし所を模索しているのです。

エンジニアも、組織がそうしようとしていることは見え見えなので、上手に乗ったふりをして、やりたいこと、試してみたいことがあるなら事業計画を担っているように見せかけて目標を設定すれば良いのです。

大体は、儲かる目標になっていれば文句はつきませんから。

そこで必要になるのは、エンジニア自身がこれから1年何をしたいか、どうなっていたいかと事業計画のKPIが落ちてきたときの紐付けと貢献の表現力です。

でもね、儲かるなら（コンプラは当然として）嘘はないわけです。単に、手段まで言っていなかっただけの話です。

だって、目標を達成できれば評価されるのであって、手段を評価するのはお門違いです。それこそ、目的と手段が入れ替わってしまうのですから。

HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント

ワーク・ルールズ！―君の生き方とリーダーシップを変える

How Google Works (ハウ・グーグル・ワークス) ―私たちの働き方とマネジメント

勝つKPI管理導入９つのステップ: 何故この不況下にあの会社は勝ち続けるのか (KPI Trust)

エンジニアが得意でない考え方を共有することのメリット

TLに流れてきたモノゴトの候補群から採用する際のロジックを作る（＝ルールと表現しても良い）という考え方がとてもしっくりしてというか、わたし自身の考え方と似ていて好感を持ったことがありまして。

エンジニアのお仕事って最終的に判断するのは顧客だったり、チームの中ではプロジェクトマネージャだったり、アーキテクトとロールとして権限＝最終責任を負える役割の人がするのだけれど、そこに行く過程で多くの判断の積み重ねを繰り返していて、そのほとんどがチームの一人ひとりのエンジニアが担っているという事実をエンジニアはもう一度、理解し直すべきだと思うのです。

ときどきどうしたものかなーと思うのは、ただただリーダ役や顧客に判断を仰ぐエンジニアを見かけるときなんですよ。あれ、本人は仕事を進めたいからというか、仕事が進捗しないと責められると思っているので必死なのかもしれないですけれど、システムの専門家としてはどうかなぁ、と。

例えば、システムの仕様について判断を得たいとすると、その仕様には様々な解決手段があるわけです。適用する技術が存在するだけ。実際には、想定している前提事項や外部からの制約条件で絞り込みされて、それでもまだいくつかの選択しか残る。

じゃあ、それを選べと言われた顧客が選べるかといえば、それは専門家でないのだから、技術的な観点での判断を要求するのは無理強いなことをしているだけなのです。そりゃ決められなくてずるずると進捗がスリップするわね。

エンジニアも仕様などを考えるときに、多くの情報を揃えて色々と考えて仮説を立てて仕様の合意に至ると思っているのですが、－さすがに思いついたポッと出のアイデアをそのまま仕様にしたりしていないですよね－、その過程では、それを考えるタイミングで確保できる情報をベースに制約条件と前提条件などや機能の振る舞いとしての事前事後条件を含めて仕様のあり方を図式化と言語化していると思うんですよね。

で、このケースは良いだとかこっちのケースは要件が実現できなくてダメだから、と判断のステップを踏んでいるのだと思うわけです。

それを明示化して共有したらどうなんでしょうか。

所詮、隠すことは何一つないのですよ。お金は顧客にもらっているのだし。まあ、1から10まで洗いざらい晒されても顧客はどうして良いか困りますけどね。

でも、仕様の考え方、ロジック（と言っても仕様の中身ではなくモノゴトの決め方）を説明してその上で、相談相手に期待する役割をしてもらえば良いのですよ。

そのロジックは日頃ブログで書いているトップダウンで考えようというのに結びつきます。概念から説明して行くとそれの判断を求められる方も情報が大局から掴めるので追いついていけるんですよね。それがボトムアップでしたら積み上げようとすると仔細な仕様だと詰めきれていないことが多くてそこにアラが出てあら探しになってしまうので。

調達 iPhoneX bluetoothレシーバー

イヤフォンをiPhoneXに繋ぐケーブルがとっても貧弱で、実際、朝夕の通勤で使うにはすぐに断線しそうで不安になるくらい。

buletoothのカナル型イヤフォンでも買おうかと思ってネットで探していたら、buletoothレシーバーで繋いでいる人がいてソニーの最新型のそれを見つけたので買いに。

SONY ソニー ワイヤレスステレオヘッドセット SBH24 : カナル型 Bluetooth対応リモコン・マイク付き 2017年モデル ブラック Black [並行輸入品]

ヨドバシに行って現物のありかを教えてもらったときに、音質を聞いて見たら「値段なりですよ」と言われたので、じゃあ、いい感じのはどれと聞いたらこれをオススメされたので勢いで買ってきた。

オーディオテクニカ Bluetooth対応ポータブル・ヘッドホンアンプaudio-technica AT-PHA55BT

出たばかりで、店頭在庫はないよと張り紙があったけど、店員さんにあったら買うのにと言ったらその場で在庫を調べてくれて、在庫補充完了してましたと。

何事もダメ元で聞いて見ることは大事だなー。