隣に座っているエンジニアが『当事者意識』を持てない理由

つい最近、チームの運営で嬉しいことがあったのでそれを書こうかと思っていたところで『当事者意識』というキーワードを見つけた。

 

「当事者意識を持て」という言葉は、現段階のメンバーの思考を否定するニュアンスを含んでいると感じています。今のあなたではなく、もっと意識を引き上げろ、もっと高みを目指せ、今のあなたよりもっとできるはずだ、というニュアンスですね。

引用 マネジメントにおける「当事者意識を持て」という言葉の死 | クラウドワークス社長 吉田 浩一郎のブログ

 

ここ最近感じていることの1つに『当事者意識』は、あまり良い表現ではないと思い始めている。それは、その人が自分の仕事を手につける前でも視界に入っていたが、仕事に手をつけるときになって初めてその視界に入っていたことを認知するのではないかと思わざるを得ない事象をよく見かけるからだ。

もう少し、情景を補足すると、チームで他のメンバがやっている仕事は『今は自分の仕事に直接影響を受けることがないと判断すると、詳細に踏み込んで傾聴し、影響の有無を確かめる』ことはしない。ところが、自分がそのメンバの仕事の成果がどうやら影響をするとか、関係を及ぼすと認知するようになるとそれまでは気にならなかったのに猛烈に聞き耳をたて、自分に影響がないように振る舞うようになるというものだ。

こうした行動の変化について確信を持てたことの1つに、とあるワークショップでの発表を聞いていたときの会話があった。要点だけを伝えると、会話の中で自分が思っていることを伝えようとするとき、思っていること全てを伝えるとは限らない、という行動をする人がいた。なぜ、そうした行動をするのか、意思決定の背景をなぜを繰り返し尋ねた。結局、損得の感情が壁を作り、伝えるコストを掛けることを止める判断しているのではないかと推測し、そうではないかと本質を抉るような問いかけをしたところ、そうだと答えてくれた。

仕事においても、感情に支配されて行動を意思決定する人はよく見かけるし、メンバにも何人かいる。それは否定されるものではないし、するものでもない。そうした行動を取るということを知っていることは、知っている方のコミュニケーションコストを下げる効果をもたらすと思っている。

まとめる必要性はわからないが、まとめると、

  • 人は自分の利害を認識して初めて外部からの影響を認知する。
  • 人は感情で損得を判断する。

というところではないか。

では、認知していない人にどのようにして認知することを促せば良いのだろうか。少なくとも、自分は『当事者意識を持て』とは言わない。言うとしたら、

 

『これはあなたの仕事に影響すると思っている。先送りすると手戻りになるから今から把握したらどうか』

 

と言うニュアンスで伝える、かもしれない。

 

 

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

バリュー・プロポジション・デザイン 顧客が欲しがる製品やサービスを創る

 

 

 

あなたの開発現場は大丈夫?

次の会話の中から適切ではない箇所を指摘しなさい。なお、A社とB社には請負契約を締結している前提とする。

A社PM『bさん、設計工程が押してしまいましたが、開発工程は納期を変えずに期間を短縮して対応してください。それで、機能Xはcさん、機能Yはdさんでお願いします』

B社b氏『厳しですが頑張ります。担当の件は了解しました』

続きを読む

物理と人系が絡むところにイノベーションは潜んでいる

ザクっと読んでの第一印象は、物理と人系が絡むと必然と泥臭い、地味な調整を伴うのだということである。

あと、現場と物理で離れている場合は、監視(モニタリング)は必須である。

 

codezine.jp

 

全く新規の建屋にIoTのデバイスを据付しようとしても、工事の段取りや設計上の構造物に制約を受けるので、勝手な前提はおけない。

業務が絡めば、その業務にフィットしていないとズレて使えないと言われる。最悪は、撤収になってしまう。

 

こうしたことは、その現場で調整したエンジニアに蓄積されるので必然と属人化される。それを属人化しないようにするために労力とコストを使いナレッジを集めようとしても、現場や業務は現場や個社ごとに違うので期待するほど再利用されない。

 

AIやIoTにそうしたことは限らない。セキュリティも同じである。

なぜか。

それは、運用が現場に残るからである。言い換えれば、現物が現場に据付されるもの、運用が現場の判断で行われるものについては、現場から離れたサイトからは知ることもできないし、上がってくる情報も何十分の1にしかならない。

現場に対しセキュリティの往査をすると、ルールどおりに運用されていないケースに遭遇するだろう。それは、ガチガチにツールで縛っていたとしても、運用するユーザはやりたいことを工夫して実現してしまうためである。

言い方を変えれば、そんな使い方は想定していなかった、というケースを現場で実証してしまう。

それを検知するためにモニタリングを必要とするのである。

 

例えば、デバイスが起動するたびにその回数を記録しておくことで、その数値を確認して異常な再起動回数があることを確認できれば、電力の供給不足を疑うなど、類推する材料とすることができる。データが多ければ多いほど、多角的な予測につなげられるのである。

 引用 同上

 

エンジニアになりたての頃に携わったシステムがよく落ちるのでソフトウェアが疑われた。ソフトウェアが疑われたというよりは、自分が作ったからバグがあるのだろうと疑われたのかもしれない。当時の自分が作ったソフトウェアなら疑われてもやむなしではある。

一緒に仕事をしていたメーカの担当者やHWの担当者は知らないところで色々と調査をしてくれたのだろう。結論は、プロダクトを据え付けた現場でブレーカが落ちていたことを突き止めた(多分にヒヤリングして気づいたのではないか)というか、そういう結論になった。

それ以来、ソフトウェアを疑われることはなくなったので、そういうことで落ち着いたのだろう。

こうした、物理と人系が絡むと必然と泥臭い、地味な調整を伴う作業は地味にリソースを占有するし、安定するまで時間を必要とする。それに、案件毎の結構なコストをしめる。そこがネックとなり、成長のスピードを抑制する。

まあ、そこにまたイノベーションが生まれる機会があるのだが。

 

 

 

 

Kindle Paperwhite、電子書籍リーダー、防水機能搭載、Wi-Fi 、32GB(Newモデル)

ホワイトが欲しいよ!

 

 

書き続ける技術

要点は、3つ。

  • 毎日同じ時間帯に書く。
  • 書いたものは忘れる
  • 書けないときこそ、書き始める

以上。

 

毎日同じ時間帯に書く

この短い文の中で、大事なことをいくつか含めている。1つは、『毎日』書くということ。2つ目は『同じ時間に』ということ。3つ目は、『時間帯』と区切りをつけていること。

『毎日』は文字どおり『まいにち』である。欠かさず、日課として書く。書くことが見当たらない、書く意味がわからないなど頭をよぎっても、書く。

『同じ時間』とは、毎朝か毎夜のどちらでも良いが、書き始める時刻を決めておくということ。夜の時間は、急な用事(飲み会とか、残業とか)が入りやすいので必然と朝になるかもしれない。朝夜はどちらでもよく、書き始める時間を手探りで探し、書き始めやすい時刻を見つける。

『時間帯』は、時間の枠である。書くための枠、タイムボックスを設けると捉えて良い。30分で書くのか、1時間掛けて書くのか。それを決める。 

書いたものは忘れる

 書くと気になるのはアクセス数や感想である。果たしてそれを期待して書いているのか。それを自分自身に問う。期待している自分があるのであれば、アクセス数やコメントを期待できる内容を書けばいい。

そうでなければ、書いた後の書きものは忘れる方が良い。書き終わってしまったものを考えることに意味はない。

ましてや自分でコントロールできないアクセス数なんぞ、ヤキモキするだけ無駄である。

得てして、雑に書いた方がホッテントリになることもある。

書き手であれば、書いた後は手離れしなければならない。それが精神衛生上もよい。

書けないときこそ、書き始める

 まあ、書きなれなければ、書きなれていないからこそ、書けなくなる。最初はあれを書きたい、これを書きたいと思いついたかもしれない。でもそうした思いつきは忘れてしまい、二度と思い出せない。

また、書き始められても途中で書くペースがダウンしてしまうこともある。そしてピタッと止まる。それからネットを眺めて時間アップである。

そうならないために、書き始める。そういうときこそ書くのである。書いた後は気にしないのだから、書いてみる。

それで良い。

自分の言葉で書けば、次が考えられる。悶々と書けないと唸っているのはサボりである。

書き始めるのである。

 

荒木飛呂彦の漫画術 (集英社新書)

荒木飛呂彦の漫画術 (集英社新書)

 

 

 

 

自分のためのPDCAは衰退を引き起こしている

エンジニアの仕事は業務であるから、決められた業務の進め方の枠があり、その枠の中で手順を踏むことになる。そうしなければ、業務を主管する部門が効率よく処理できないためである。さらに言えば、業務部門は外部の制約、例えば法規などで決められたとおりに手続きする必要を求められ、それに準ずるための結果的に、現場のエンジニアに同じような手順を踏むように求めることになる。

こうした手順は、最適であることはないため、定期的に見直したり、手順に不具合を見つければ、改善する。こうした改善の取り組みを定期的に行えば自然とPDCAが周りそうに思えるが、実際にはそんなことは起きないため、ISO9001やQCなどの手法をとりいれ、より、効率化的に業務の手続きを進められるように取り組む。

ただ、実態は、業務の不具合である事象の運用でカバーしているような対応を直すことをせず、PDCAを回せと指示されて、PDCAを回すことを目的に業務を変更しようとするから結果は改悪され、手続きが逆に増えてしまっているのが現状ではないだろうか。

 

news.yahoo.co.jp

 

業務の手続きもそうだし、組織で開発するサービスでも当てはまるが、そうした改善は本来、利用者に対価を支払ってでも使いたいと思わせるトレードオフを引き起こさなければ成り立たない。

新しいサービスが生まれてそれが使われるのは、従来、手作業で行なっていたことをサービス側で代行したり、手作業を省略してしまうことで利便性を得られるからである。

あとは、単純に視覚的に好き、だからである。

 

「機能性だけなく見た感じ」、「製品がもつストーリー性」、「個別機能よりも製品群全体での調和」、「論理ではなく共感」、「まじめさだけではなく遊び心」、「モノよりもモノをもつことの意義」といったコンセプトから「デザイン思考」は成り立っていると言われる。

引用 日本が世界から劣後する一因が「PDCA」のやり過ぎ 世界は「デザイン思考」にシフト(井上久男) - 個人 - Yahoo!ニュース

 

これは何も今になって、ではない。昔から、である。ただ、今より少し前までは、そうした考え方でものづくりをやっていたかと言えば、それは限定された範囲で行われただろう。

 

 世界のビジネスマンは、MBAロジカルシンキングなどを学んできたが、これはある程度「正解」が見えている領域で最適解を見出す分析的アプローチ。「PDCAサイクル思考」も同様のことが言える。これに対して「デザイン思考」とは決まった課題を解くのではなく、解くべき解を探す力を養うことに重点を置くものだ。時代の変化が速く、何が売れるかも分からない時代は、「潜在的なニーズ」を探し出すことの方が重要だろう。

 

技術がコモデティ化され、誰もが新しいサービスをみてすぐにコピーできるようになってしまった。従来の開発者側の発想である、機能を増やす、軽量化する、小さくすることは2番手を走っていれば真似ればいいだけになってしまった。

つまり、PDCAを回す必要は無くなってしまったようにも見える。実際には、2番手でコピーするだけなら、PDCAは不要そうだが、1番手の次のリリースをウォッチして、似て非なるサービスを出すためにサイクルを回していれば、実態はPDCAをまわしているようなものと捉えることもできる。

ただ、それでは限界があるわけだ。昭和の頃はマネ下と呼ばれた企業があった。

いずれにしろ、そのようなサービスを提供する際の視点はサービス提供者側からの視点でしかなく、それに基づいてPDCAを作っているからどうにも独りよがりになるのである。

そうしたやり方が溢れれば殲滅戦を引き起こし、消えていくだけである。そうした消耗だけのやり方を変えるのが視点を反対の利用者側に移して擬似的に利用者側が選ぶまでの仮説を立てて企画するようになっただけなのではないか、と思うのだが。

 

 

 

けっきょく、よはく。 余白を活かしたデザインレイアウトの本

けっきょく、よはく。 余白を活かしたデザインレイアウトの本

 

 

カイゼンをKAIZENする『かいぜん』の提案について

エンジニアであれば誰でも知っているだろう言葉に『カイゼン』がある。言葉としては、日本語由来で海外でも通用するもので、由来はTMSやTPSだという人もいる。

カイゼンで検索すると、経営工学のページに行き当たる。

 

(社)日本経営工学会編の「生産管理用語辞典」の「改善」の項をみると、改善 KAIZEN, continuous inprovement 「少人数のグループまたは個人で、経営システム全体又はその部分を常に見直し、能力その他の諸量の向上を図る活動」

 引用 http://www.jitps.com/article/13912154.html

 

カイゼンが改善と区別される意味合いには、継続しているかどうかを重視する。要は、PDCAになっていなければカイゼンにはならないという事らしい。

さて、ここでフォーカスしたいのは、継続的にPDCAを回す対象はプロセスであるという事である。

まあ、ものづくりの現場で行われるのであるから、その対象を製造する手続きを見直すことで製造するモノをより簡単に、よりコストを掛けず、目指す品質を確保できるやり方を手に入れたい。それを実現するのがカイゼンである。

物理的にモノがある製造の現場ではそのモノ自体に縛られることもあるが、視覚的に目標を設定できることから目標を設定しやすいという面を持っている。

一方、ソフトウェアは無形資産であるから、視覚的にモノを見ることはできない。それにより、モノに縛られることもないが、モノに対する様々な性質を把握することもできない。

これらのことから導き出されることは、現場のエンジニアやエンジニアを動かす仕組みの良し悪しにモノの出来具合は左右されるということである。

これはいくらソフトウェア開発の現場でカイゼンを行っても形のないものを作る現場では、一つパラメータが足りないということを気づかされる。

足らないパラメータとは、現場のエンジニアである。

それを含めたカイゼンの改良版を『かいぜん』と呼ぶことを提案する。

 

 

 

 

トヨタ生産方式――脱規模の経営をめざして

トヨタ生産方式――脱規模の経営をめざして

 
トヨタ式「改善」の進め方―最強の現場をつくり上げる! (PHPビジネス新書)

トヨタ式「改善」の進め方―最強の現場をつくり上げる! (PHPビジネス新書)

 
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで