台帳とUIとDB

ある新規業務で認証を取り1年近く経ったが、そのとき出来ているはずの業務運用が回っていなかった。不思議である。新規業務を作ったのだから、運用されていなければおかしい。でも、1年後くらいのタイミングで覗いてみたら、ほとんど業務ぽい運用はなく、現場への台帳更新と活動計画のあらましだけがアナウンスされている状況であった。

少ない業務システムの経験から言えば、業務の一部または全てを機械化したものがITのシステムであるから、(ITの手段は何にしろ)業務はどうにかしてでも回すはずで、回っていなければおかしい。

おかしいから呼ばれたのかもしれないが。

業務を端的に表現すれば、台帳に情報を集め、その情報を維持するだけの話である。sの台帳のデザインが見た目からイケていない。

自分の感覚では、台帳などの帳票は、全画面で開いたときに全ての列が収まるようにしたいと考える。1画面に入らないと横スクロールが発生して操作が増え、不便極まりない。余計な操作を増やしたくない。

であるから、ヘッダの行の高さがやたらと高いとアレコレと言いたくなるがそこは些細なことなので言わず、台帳で何をしようとしているのかを尋ねる。

この質問で実は運用できていない理由の片鱗が垣間見えた。1項目ずつ何を入力するのか、選択肢の場合は候補は何かを聞くと、答えが曖昧なのである。よくよく聞くと、認証を取る際に、帳票の雛形を入手してそのまま使ったらしい。

つまり、導入する側が業務にインストールするツールである帳票を理解せずに、いきなり現場に落とし込んで『書いて』とやったらしい。

現場は協力して書いてくれたらしいのであるが、何を言われたかは想像に難くない。

システムに当てはめると、台帳の表題(ヘッダ)はGUIになる。つまり、UI。そして、表題以下の行はDBになる。その台帳の思想や更新の仕組みはDBMSそのものだ。

それらのUIやDBは業務で使う。

でも、UIの項目の意味も型も理解せず他所から持ってきて、『はい、使って』と言って業務が回るだろうか。

業務ならマネジメントシステムとして業務サイクルを回す。そこにイベントやマイルストーンが設定され、年次で処理を行う。

業務を理解していないのであるから、運用である年次処理まで頭が回るわけがない。

しなければならないのは業務の再設計である。

こうした業務の設計の危うさは、エンジニアの仕様書にも潜在的にある。excelなどの仕様書はその典型である。エンジニアのSI業務や維持管理業務で使う。使われない項目やとりあえず埋めるだけになっている項目など見かけたことがあるだろう。

たかだか、帳票を使った業務の設計でも、要件、機能仕様、実現仕様、コード設計などのスキルが役にたつ。

逆に言えば、帳票を作った人にはそうしたスキルはなかったのだろう。

 

 

 

 

 

 

 

 

1 on 1はエンジニアのキャリアを考えるぶつける場なのかもしれない

1 on 1の導入事例をスライド共有サイトで、そこそこ見かけるようになった。自分としては、1 on 1を習慣化するまで大分慣れが必要かなと感じた。1 on 1で話を聞きたい側のマネージャやエンジニアリングマネージャ自身の仕事の時間の確保との兼ね合いがあるからだ。

それでもやってみて思ったのは、いわゆる目標管理の中間フォローアップを小さなイベントにバラして、頻度を多くして、評価時期までズルズルと行って大きな失敗にならないようにしよう、と言う意図を理解できる。

自分の場合は、日常的な感じで気づいたことを話していたが、どちらかと言うとそれはマネージャ側の関心事ベースで話し掛ける。逆のメンバからは、そうそう問題が大きくなりそうだったり、実際、手がつけられなくなってからのケースがある。このあたりは、メンバの感覚で情報を教えてくれるメンバもいれば、自分の裁量で思うようにやっているメンバもおり、一人ひとりの仕事のスタイルの違いがあって興味深い。

小さなイベントにして、頻度を増やことは、ある意味とても過保護ではないだろうか。

組織的も組織の目標達成の使命があるから、それを積み上げるメンバの目標やOKRの達成に繋がった方がいい。実際、日頃から声がけして木になることを聞くのは、リスクの予兆なり芽の気配を感じて潰しに掛かっているで、意味合いとしては1 on 1のこちら側をインフォーマルな形でやっているだけに過ぎない。

違いは、1 on 1に同席するエンジニアのwillをカジュアルだがフォーマルに聞くことが出来ると言うことである。この点で言えば、メンバは受け身ではいられない。何を話すか、どうしたいかを自分のwillとして話さなければならないから、自分の仕事や目標を意識的に見直す必要がある。

以前にも書いたが、エンジニアの日常は全てそのエンジニアのキャリアであるから習慣的にどっちに進んでいきたいかを考えるのは、エンジニア自身のこととして、しなければならないと思う。

その意味では、キャリアの考えを経験の多い相手にぶつけてどっちにエンジニア自身のキャリアを飛ばすかの練習の場なのかもしれない。

 

ハーバードの自分を知る技術 悩めるエリートたちの人生戦略ロードマップ

ハーバードの自分を知る技術 悩めるエリートたちの人生戦略ロードマップ

 
行動経済学の基礎 (MyISBN - デザインエッグ社)

行動経済学の基礎 (MyISBN - デザインエッグ社)

 

 

 

 

『なんでも相談して』は相談して欲しい側から相談する

新しいメンバが入ったとき、困っていそうなメンバを認識したときにいうセリフが『なんでも相談してね』『なんでも聞いてね』だ。

もっと使いそうなシチュエーションは、朝会やスタンドアップミーティングで進捗が芳しくないメンバに、なんら裏の意図もなく、ただ自然に『困っていたら相談して』的な物言いをするケースである。

聞く方としては、同じチームのメンバだし、困っていたら本当に助けたいし、相談に乗れることは乗りたいと思って言っている。少なくとも、それは君の仕事だから、というドライな線引きでは言っていない。

では、それで実際に相談されることがあったか。

相談された内容はなんだったか。

着任したばかりのメンバだったら、質問するのは物理的に必要な情報で占められる。担当するタスクに必要だと思う情報、前の経緯がわかる資料、そう言ったもののありかや知っている人を教えてくれという。あとは手続き的なこと。これをして良いのか、あれはどうか。

共通しているのは、可視化されていない、察することができない情報を手にれる手段を知りたいだけである。

このようなケースは、相談をして欲しいと言っている側から見れば、本来想定している相談内容とは違う。

リーダのエンジニアやプロジェクトマネージャが言う『なんでも相談してね』はそのエンジニアが仕事を着手できるかどうかである。とにかく、仕事のスケジュールはこの瞬間も進んでいるので、すぐに立ち上がって欲しい。だから、立ち上がりで困っているなら聞いて欲しい。

ことが手遅れになる前に、進捗にインパクトを与える前に報告して欲しい、と言う意図で言っている。ただ、これは言っている側もそれを意識しては言っていない。まずは仕事が進められるように、のくらいのつもりで言っている。

その意図、観点で言えば、着任して仕事をできる状況が揃うまでは、意とする『なんでも相談してね』の条件が揃っていない。

タスクのチケットを渡すのか、取ってもらうのかはさて置き、

『タスクを始めるために必要な情報が揃っているかそれを判断できるか』

を尋ねる方が暗黙に心配している『なんでも相談して』よりは数倍いい。

 あと、『なんでも相談して』は言った側は待っていてはいけない。言った以上、こちらから、立ち上がるまでは声を掛ける。声を掛けるのも、言った側でこのくらいで何かしら情報を整理できるだろうの少し前くらいに仕掛ける。

トイレから戻るときとか、ランチに誘って注文が出てくる前くらいとか、無防備なところで聞き出してみる。ガードが下がっているところをわざと狙う。

それで、本心ぽいところから状況を聞き出して、リーダが対応できるならすぐ、その場で対応する。すぐ、がポイント。(相談をしていないが)体感として相談をすると助けてくれると言う経験を刷り込むのである。

なんでも、最初の体験が肝心。

 

 

実態のないペルソナには気を配るのにチームのメンバには分かってもらえると思い込むのはなぜか

立場的にメンバ間で困ったことが起きると相談を受ける。だいたい、誰か1人が問題を起こしたような形になり、周囲の関わるメンバや関係者から半ばクレームぽい物言いの聞き役になったり、ストレートに苦情ぽいことを聞かされる。

当事者のメンバは、相談にきたり、気がつかないままだったり、抱えていたりする。

様々なケースに出会ってきたが、共通するのは当事者のメンバのパフォーマンスである。周囲の期待に応えられない。それだけであればまだマシなケースもある。無垢な罪意識のない行為が周囲に顰蹙を買う。

時効だからいいだろう。以前、こんなケースがあった。当事者は主体的に自分で判断して、良かれと思ってステークホルダと連絡を取り、打ち合わせをしようとしていた。もちろん、以前からそのステークホルダとミーティングをしていたから、当人にとっては何もきにすることもなかった。

その以前とは体制が変わっていて、全体のプロジェクトリーダが置かれ、全体の筋書きを書き、進めようとしていた。対外的なコミュニケーションラインを一本化、つまりフォーカルポイントを集約しようとしたわけだ。

全体を把握する、一枚岩になる。そう言う意味合いで妥当な策である。

そこを以前からいたメンバは自律的に、でも、新任のプロジェクトリーダから見れば、自分から伝えたことを守らない、勝手に対外的なコミュニケーションを取ろうとするメンバがいるように見えるわけだ。

エンジニアは不思議な生き物である。ものづくりでは実態のないペルソナを作り、UIやUXで最大限の体験価値を与えようとする。事細かく想定する人物の属性を盛り込み、ストーリを考える。

でも、同じところで働いているとしても、目の前にいるメンバには、自分が関わろうとするとき、最大限の体験価値を与えようなんて一切微塵のかけらもないようにしか思えない。もちろん、関わるメンバがどんな人物で、どのような考え、価値観を持っているなんて考えようなんて思っていないようだ。

自分としては、期待マネジメントの延長戦のように見えるが、実はもっと手近な、それでいてタチの悪いことなのではないかと、頭をよぎったのである。

  • いいことだと思ってやっているんだから。
  • 自分から自主的にやっているのだから。
  • 全体を成功させるのだから。
  • 役割は説明したのだから。

全部、甘え。

コミュニケーションコストを中途半端にしか負担せず、分かってくれるだろうと一方的に思い込む。

全部、甘えでしかない。

そう思い至ったとき、全てがわかった気がした(気がしただけ)。手戻りがないようにToDoになるように説明したり、段取りを具体的に説明したり、タスクを小さくしたり、マメに声をかけているのは、全て自分を使って働きかける。

自分のタスクを終わらせるために、全体を進捗させるために。そう言う意図があるからである。だから、コストを払う。

逆に言えば、コストを支払わなければ上手くいくイメージを持てない。両手放しで上手く行くなんて想像もつかない。

当事者も、周囲のメンバも、どちらも、しなければならないことは、しなければならない。

 

 

 

 

終身雇用の怪しいこれからのエンジニアの生き方

豊田社長の発言は自動車関連の税負担が高過ぎ車が売れなくなると雇用を維持できない意図を都合よく捉えているようである。

www.fnn.jp

 

ITの業界なんてたかだか70年しかない。だから、旧来の雇用制度など気にするもないのではないか。見方を変えれば、50歳、60歳になったとき、自分の技術は何で、どうやって自分の価値を売っていくか、くらいでないとやっていけないのではないか。

大手ベンダから人材を放出してくる時代に入ったように見えるが、外資であれば元々業績評価の低い一定の割合はfireする人事制度であるから実は目新しくない。また、そうした人事制度の中でキャリアを積んでいるエンジニアは自分がそうなることの可能性を理解している。理解すると言うことは、そうなったときに自分から出ていく選択肢を持っていると言うことにもなる(もちろん、しがみつくつもりの人もいる)。

今、サービサーやWeb系のIT企業は超人材難でオファリングがすごい。そうした企業は即戦力を必要としているし、そうで無ければリソース不足で成長が止まってしまう危機感を持っている。そういった企業間でのエンジニアの流動性はとても高い。やりたいことをやってすぐに次に移る。

そうした企業も事業サイズが大きくなると上場したりする。では、組織が出来上がっているかと言うと、実はそれほどでもない。場合によっては、組織の程をなんとか保っているぐらいのところもある。人の流動性が高いから制度が出来上がらないのである。

そういった組織の環境をエンジニア中心の組織を作るのはさぞかし楽しいことだろうと思う。元々組織づくりは楽しいと感じる属性を持っているからかもしれないが。

組織を作ると言うことは意思決定を文化的に醸成するプロセスを育てることである。

そうした文化を制度から補強するのが規程などである。組織の文化の良い点を失わないように、より強くする制度を規程で作り、運用を軌道に乗せる。

自分の専門的なIT技術でテックリードするのもありだし、それがメインストリームだろう。でも、必要な人材は全方面でオファリングしていることを知っておこう。

ただし、今の所は。

そうした場に移らなければならないとき、なにで食べていくか軸を持っておこう。それは、今日から意識して仕事をしなければならない。

いざという時になってからでは遅い。

 

図解CIOハンドブック 改訂5版

図解CIOハンドブック 改訂5版

 

 

 

 

キャリアの選択肢としてのプロマネ

エンジニアとして所蔵する組織で、目標設定やOKRのToBeの設定で、将来の自分像を考えさせる組織は、考えさせない組織より断然いい。少なくとも、エンジニア本人に自分はどうしたいのか、どうなりたいのかを考える機会を与えているからだ。

あなたは将来、何ができるエンジニアになりたいのだろうか。

来月はこのプロジェクト、それが終わったら次のプロジェクト…毎月給与が振り込まれ、どう決まったかも分からずに貰う賞与。理由も分からず上がったり変わらなかったりする昇給と昇格。流石にこんな組織はないと思うが、エンジニア本人に、あなたは将来どんなエンジニアになりたいかを考えさせる組織は、キャリアはエンジニア本人のものであると自覚させようとしている点で良い。

あなたは将来、何ができるエンジニアになろうとしているのだろうか。

数年、その年数はエンジニアの経験や能力によって違いがあるが、一人前に仕事を回せるようになれば、いつの間にか若手エンジニアの育成を任されたり、小さなプロジェクトを経験させられたり、プロジェクトチームの中のブロックを任されるようになる。

嫌が応にも、エンジニアはチームの中で仕事をして、チームの中でリード役を負う。

さて、あなたは将来、どのようなキャリアを選ぶのだろうか。

プロジェクトマネージャと言っても、プロジェクトに様々な案件があるように、プロジェクトマネージャも多種多様である。ひどいプロマネもいれば、エンジニアが働きやすい環境を作ってくれるプロマネもいる。あたりのプロマネでは自分のパフォーマンスが驚くほど高い。残念なプロマネのときは、どう頑張ってもやる気も絞り出せない。

ブロックリーダや小さな案件を経験すると、エンジニアとして、1人の人間として、今まで体感することがなかった成長を得られるものだ。情報が多く入るようになり、そうした情報を整理しながら意思決定するのは骨の折れる経験だが、やってみると面白いものだ。

2-3人のチームと呼ぶには小さなチームでも、パフォーマンスを期待通りに出して貰うのは至難の技だ。間に入って悩み、色々とネットで調べたり、本を読んだりして、実際に試してみる。プロマネといっても、実質は、プレイングマネージャで半分エンジニア兼業だったりする。

タスクの分担は、メンバの持っているスキルを最大限に活用したくなるが、エンジニアが挑戦したいと言う意思があれば、少しだけフォローを考えながらやってもらえるとエンジニアの成長をサポートできる。これもプロマネの裁量があってできることだ。

2-3人くらいから精々5-8人くらいのメンバでやるプロジェクトが一番楽しい。目が届き、顔色がわかる。誰かが渦中そうだったらすぐに気配がわかるし、助ける手を伸ばしやすい。

プロジェクトマネジメントでの数字との格闘は面倒臭く、数字で評価されるところは出来ればやりたくない。でも、その仕事をすることでメンバの事業への貢献を後押しできる。

あなたのキャリアの進む選択肢にプロジェクトマネージャはどうだろう。

 

 

 

なれる!SE 4 誰でもできる?プロジェクト管理 (電撃文庫 な)
 
カワイイ後輩の育て方1: スカウト編

カワイイ後輩の育て方1: スカウト編

 

 

 

捨てられるエンジニア

ある教育コンサルタントと会話しているときに、昨今の終身雇用に対する経営者のギブアップの先の話になった。

 

headlines.yahoo.co.jp

 

人月商売のSIerの経営者は、採用難でビジネスの頭打ちに危機感を覚えているのだという。

『何を言っているのだ』とつい言ってしまった。元々のビジネスが人売りなのだから、売るエンジニアが売り切れてしまったら、それ以上のビジネスなんてないことは誰にだってわかる話である。

その流れで、コンサルタントから『エンジニアは人材供給不足なのは本当か』という質問を受けた。少なくとも自分の担当範囲では欲しい人材は足りない。

ただ、自分がエンジニアになった何十年も前から人材供給不足は言われ続けていることである。

不足しているのはその時代で売りたい技術を担うエンジニアであって、売りたい技術がビジネス的にバズらなければそのマーケットは消えてしまうだけである。

前述の人月商売のSIerの経営者は、抱えているエンジニアの技術が古くて従事していたプロジェクトや維持管理が終わって戻ってきたとき、売り先がないとぼやくのだと言う。

こうして、エンジニアは捨てられていくのである。

こうしてとはどう言うことか。

所属するSIerの中で、技術を、キャリアを会社任せにしているエンジニアは、その技術でエンジニアを売れなくなった(=価値がなくなった)とき、SIerの不良在庫になるのである。

今は、間接部門にそうした強風が強く打ち付けられ始めている。NやFの48歳云々がそれだ。

キャリアを会社任せにしているエンジニアはお荷物になり、捨てられる。

 

苫米地英人の金持ち脳? ~捨てることから幸せは始まる~

苫米地英人の金持ち脳? ~捨てることから幸せは始まる~