エンジニアの子どもの就活では何をどう伝えれば良いか

エンジニアで子持ちの親御さんはお子さんにどのような就活のアドバイスをしているのだろう。自分のことは自分で選び、決める年齢はとうにすぎているのだから、あまり関わることをするのは過保護であると思う方もいるかもしれない。

これは実際に子を持つことができ、その年齢に達しなければ考えもしないことである。ましてや、自分の子どもではあるが、就活の当事者は子どもだし、親があれこれ言っても親が就活するのではないのだから余計な口は挟まない方が良さそうだということだけはわかる。

ところで、何人もの新人エンジニアを受け入れて来たが特に自分の子どもが学生になったときの新人エンジニアを見ると、それまでより一層、自分の子どももあと数年もすれば同じようにどこかの企業なり団体なりで、もしかしたら院進などするのかもしれないと思いめぐらしていたりするのだ。

見たこと、知っている中で選ぶ

親である自分自身がそうだったし、新人エンジニアと会話しているとわかることだが、人は見たこと、知ったことの中でしか選べない。見たこと、知っていることはどれだけ外界との接触や外に関心を寄せて眺めるという行為をするかで変わってくる。多くは、無意識に流してしまうから、やはり人生の経験の少ない20代は圧倒的に情報不足であることは歪めない。

言い換えれば、見たことがなかったり、知る機会がなければ就活も院進も選択肢が狭まってしまうということだ。

どこまで関与するか

 これまでもそうだったが、子どもが選んだことには口は出さない。口を出したら責任が伴う。明らかに間違いであったとしても、それは判断する前に間違えないアドバイスをするかもしれないが、人生において明らかに間違いな選択はそうそうないのも事実だ。一見、間違いのように思えても本人がどうにかしてまうこともあるし、正しいと思っていたことでたくさんの失敗もまた存在する。

親としては求められたら情報を適度に提供するくらいが精一杯かもしれない。

話の中で、就活はどのように進むのかと聞かれたので、従来のESからグループ面接、(圧迫)面接が多いが、やりたいこと、やってみたいことがあるなら、学生のうちに実際何かを作ってポートフォリオとして公開した方が、これをやりたいと示すことができるのでより選ぶ側としては選びやすいかも知れない、と。他にはインターンや、OBOGと繋がるアプリもあるらしいよ、と知っていることをいくつか摘んで返す。 

選択肢を示す

 前に子どもと割と長い時間歩くことがあった。学校の授業こと、関心があることと話を振ってみた。何かに関心を持っているということがわかれば、そこから仕事について振りやすい。

 蛙の子は蛙になるのか、それとも別の仕事を選ぶのか。

少し前に大学の講師をされている方から、いまWebサービス系でとても人気のあるブランドがあり、学生が多く集まっているがエンジニア希望で実際にエンジニア配属される学生は10%もなく、エンジニア配属以外の残り90%は不人気な職種に回されていると聞いたことがあったのを思い出した。

選択肢を示す狙いでその話をする。

企業で働くならその企業の事業が何であるかがわかると、多くの新卒をどのように配置するかは、企業の事業を知れば少しは察しがつくかも知れない、と。

企業や団体の仕事は主とする事業ばかりではなく、様々な職種で構成していることや例えば、エンジニアもエンジニアが提供するIT技術はそれを提供する側と買って使う側の2つの関わり方があり、どちらも選択肢であることを伝える。

さらに、選択する企業や団体は国内ばかりではなく、海外、それもアジア圏だってあるよと。

これだけ一度に話をすると情報過多になってしまい、逆に選べなくなってしまうものだが、これも来春近くなれば必ず経験することなので、今のうちに接触することはある意味ワクチン摂取のようなものなのだ。

 

そこまで話をして伝えたかったことは「選択肢がたくさんあることを知っておこう」ということだ、と。

また少ししたらその時には何に関心を持っているかを聞いてみよう。

 

 

 

 

あの凄腕のエンジニアの技術習得や解決方法に至る考え方を聴きなさい

どこにもお手本になるような凄腕のエンジニアはいるものだ。少なくとも一定の技術レベルに到達するまでは憧れた凄腕のエンジニアがいたのではないか。いなかったとすると自分で目標を設定でき、孤高に自分を高みに向かって伸ばすことができたか、感性がアーティスティックの方に振れていたか、然もなくば、凡庸なエンジニアなのだろう。

 凄腕のエンジニアを知れば知るほど、その人にはなれないがその凄腕のエンジニアのようになってみたいと思うことはよくあることだ。それが憧れるということなのだから。

 

成長途中のエンジニアはついついそうした凄腕のエンジニアに技術習得のコツや抱えている問題の解決方法を聞いてくるものだ。目の前の課題と認識していることを解決するのが本人にとってプライオリティが最優先になっているからだ。

そうした凄腕のエンジニアと所蔵する組織が同じだとか、親密であれば度々教えてもらう機会が作れるだろう。しかし、面識もそれほどなかったり、社外の著名なエンジニアだとそうはいかない。話しかけられ、時間をもらうことができればラッキーな方だ。

技術習得や解決方法を聞いてはいけない

 確かにそれらはプライオリティが高いイシューだから、ここぞとばかり聴きたくなる気持ちはよくわかる。それにそうしたことを尋ねれば、凄腕のエンジニアも親身になって聞いてくれるし、(凄腕エンジニアなら)どうするかを教えてくれるだろう。

でも、解決方法は聞いてはいけない。

凄腕エンジニアにはなれないが、凄腕エンジニアが凄腕エンジニアであるイズムを取り込むことはできる。技術取得や解決方法を聞いてしまうと具体的な解決手段として得られるため、それを再利用できるように自分の中で経験知から形式知に変換するプロセスを経なければならない。

そして、多くのエンジニアはそれをしない。

技術習得や解決方法に至る考え方を聞く

聞かなければいけないのは、プライオリティの高い課題を解決する場合にどうした点を気にして、何を根拠に判断するか、その凄腕エンジニアが解決策に至る考え方、つまり、思考プロセスを聞くのだ。

もちろん、それを聞くために聴き方も工夫がいるだろう。必要そうな情報を箇条的に提示することで、追加情報を要求されたらそれもその凄腕エンジニアにとって確認したい情報としての重要性が隠れているかも知れないからだ。

こうした聴き方に変えることで、経験知から形式知への汎用化へ近づくため再利用する角度が高まるし、身につきやすい。

 

 

 

資料の切り口の角度の見つけ方

まあ、脈略もなくエントリを書いていると、もう少し体系的に整理した上でコンテンツを書いた方が良いに越したことがないのだが、ついつい習慣で書きたいネタを探してその日のエントリを拵えてしまう。

拵えるという言葉は美術の先生がよく使っていた。一度自宅に遊びに行ったことがあって、乾燥させて砕いた餅を揚げ餅にして出してくれたのが印象に残っている。今思えば、あの間取りはアトリエも兼ねていたんだと思い出す。

大型連休はのんびりとリフレッシュすることもなく、日々の習慣のことを続ける一方、連休明けのスライドづくりも休み初日から手をつける。なんでも形にしていく確実な方法は、やろうと決めた最初の日に手をつけ、実績を1ページでも残すことが肝要だ。これをしておくだけで、随分と気が楽になる。初日に手を付けないと翌日から自分にストレスを感じるだけだ。

切り口を変えて見せる

資料を作るとき、よく言われることに切り口を考えた方がいいとか別の切り口で見せたらどうかという物言いがある。

これ、言われる人はどうしたらいいかわかって聞いているのだろうか。多分、わかっていないのに「そうですね」 と相槌を打っているのではないか。

わかっているなら目の前にある資料には仕上がっていないはずだからだ。その状態で適当に相槌を打っているとまたそれを繰り返すのは確定事項である。

知っていることを並べる

 いきなり切り口を考えようとしても上手くいかないだろう。材料に対する持った包丁の角度をどう付けたら、どんな塩梅で分かれるか想像がつかないのだから。

まず最初に知っていることを書き出してみよう。ここでもオススメするのはノートやA4の紙に手描きで書くことだ。モレスキンがいいらしいが厚くて重いので試しに無印あたりのノートに書き出してみよう。

描くペンは、フリクションがいい。色は、青系がオススメだが、好みでいい。

つべこべ言わす、まず、知っていることを描き込む。ところでなぜ書き込むではなく描き込むかというと文字ばかりではなく、イラストを多く描くからだ。キーワードには囲みを入れたり、矢印で繋げたりするように。

時系列

 不思議なことに描き始めると時系列に情報を並べて描いているはずだ。もし、このことに気づかないでいきなり資料を作っていたら、やっぱり時系列に沿って作っていただろう。

このことからも、切り口が通り一遍になってしまうことがわかる。

一部だけ詳細

特に自分が担当したところだけが妙に詳細で具体的に描いていることに気づくだろう。全体を描くはずが、知っていることだけしか描けないということにここで気づく。全体から見れば、無駄に詳しいページもあるがさらっとした情報しかないページもあり、これを通しで読まされるのは正直しんどい。

切り口の角度

材料が出揃ったところで、どの角度で材料を切るかを考えなければならない。どんな切り口の角度を付ければ良いか。

それほど難しくない。至極当たり前なことだが、こんなことから考えてみよう。

  • 会議の目的
  • 資料発表する側の目的

 会議の目的とは、会議の主旨である。そこに集められる目的を軸にする。システム開発の事例発表であれば、教訓、プラクティスを軸にする。プラクティスにたどり着きたければ、課題、問題、トラブルを出発点にする。そうすると時系列な情報はあっても1ページで十分になる。プロジェクトの概要も1ページで十分だ。ノートに描き出した情報を軸に沿って拾い出し、アウトラインに嵌めていけばいい。

資料発表する側の目的とは、資料を作るあなたがどうしてそれを知って欲しいかを軸にする。野心めいたものであれば別のもっともらしい大義でラップしたほうがいいかもしれない。承認要求の充足も同じだ。聴講者が聞くことで得られるメリットを前面にしないと誰も聞いてくれない。そんな安っぽい動機はすぐにバレてしまうものだ。

数日前のエントリで目次について書いたが、このコンテンツはその目次への辿り着き方である。このやり方がいいのは軸を作って進めているので、資料を見直した方がいいとコメントがついたら、軸を確認すれば変更がしやすし、知っていることを描き出しているので再構成しやすいという点だ。

 

 

 

 

 

 

 

DevOpsが文化を持ち出す理由 ー20年前の大規模システム開発でのDevOpsー

DevOpsDays tokyo2018は興味があったけれど結局は予定がみっちりで行けず、いくつかの公開資料を眺めながら20年前に参画していた大規模システム開発での開発からリリースするまでのプロセスを思い出す。

slide.meguro.ryuzee.com

これまで経験してきたシステム開発とプロダクトのデプロイが幾つだったか数えていない。つまり、エンジニアは無意識に、いや、当たり前にプロダクトの開発とデプロイを、今風に言うならDevOpsに関わっているのである。

ただ、それがDevOpsの概念的に一致しているかどうかはわからないが。

契約としてのDevとOps

20年前の大規模プロジェクトではっきりと意識したのが契約としてのDevとOpsの違いだ。Devは開発、SI、システム開発である。Opsは維持管理、保守、SOである。前者は準委任契約若しくは請負契約で契約を締結する。Opsは人工契約で締結される。

絶賛設計中や絶賛開発中であればシステム開発オンリーだから、Devしかないし、それ以外意識しないものだ。ただ、UAT工程の準備が始まると工程推進の作業主体は顧客に戻るのでプロダクトの管理も顧客に移転される。

このタイミングで維持管理が発生する。こうしたことを理解できるようになると、契約が2本発生する理由も理解できる。 

これが契約面でのDevOpsを意識したキッカケである。

リリースとしてのDevとOps

UAT工程に入るとプロダクトの管理主体は顧客に移ると上述した。これによりプロジェクト推進で大きな転換点を迎える。

それは何かというと、Dev都合でコードの変更ができなくなる。プロダクトが顧客に移転されたからだ。それまで、Devサイドのテストまではバグがあれば手続きはするとしても比較的気軽にコードのリプレースができた。エンジニアもまた、バグは修正すればいいんでしょ、くらいな気持ちでいたものだ。

ところが顧客にプロダクトが移転されるとどんなバグであっても容易に置き換えることはできなくなる。顧客に申し出て承認を得なければならなくなる。承認をもらうために変更に伴う影響調査、設計変更、何段階ものテスト。それらのレビューと証跡を記録し、顧客のレビューを超えられたものだけがデプロイされる。

それがエンジニアの手続きを経て行われていた。

緊急リリースとしてのDevとOps

 稀に致命的な不具合が見つかる。多くは考慮漏れである。それだけ複雑な要件が起因で、エンジニアの考慮をすり抜けていた業務ロジックが存在したということだ。

致命的な不具合で業務上の影響が甚大な場合、顧客の手続きも行われるが緊急事態であることから最優先の特急で手続きが進められる。

これはとても象徴的である。

リリース案件が1件であれば大規模システムでのプロダクトのリリースも数時間で可能ということだ。システムの特性上、必ずリリースには人的判断が伴うとしてもそれ以外では数時間で可能ということを証明している。

ただ、リリースに関係する処理全てを人海で対応しなければならなかったのかと言えば、それは違う。当時は、テストまでのプロセスを人手に頼らなければならなかったのだ。今は、それをシステムで対応できるまで技術が追いついたのだ。

見方を変えれば、20年前の大規模なシステム開発のDevOpsと今のDevOpsに違いはない。人海かシステム対応かだけの話だ。

こういうことからもこれからエンジニアはどこの技術にフォーカスすれば良いのかある程度推測できるだろう。今の技術の延長でいつまで飯が食えるか。

そんなことを考えているエンジニアの方が稀有なのかもしれないが。

変わったのは顧客だったのではないか。20年前なら技術的に不可能だという言い訳に仕方がないと諦めることができた。今はそれは諦められなくなった。それが最大の理由だろう。

 

https://slidehub.azureedge.net/images/34d9f4c3f0ac9f7d8a6f7478c96d3038/slide-28.jpg

引用 Effective DevOps | Ryuzee.com

 

DevOpsの定義は諸説あるようだが、文化が持ち出されるところが腑に落ちなかった。スライドを見つつ、これまで目の前を過ぎ去っていったシステム開発での知見から導き出されたのはこれだった。

テクノロジーのパラダイムシフトにエンジニアが転換するためのクッションとして文化を引っ張り出しているのではないか

と思い至った。結局、エンジニアが変われということをソフトに示唆しているだけなのだろう。

 

 

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

 

 

 

ビジネスの主役をメンバに移したらメンバが考え動き始めた

マネジメントは実はとても楽なオペレーションである。なぜか。それはマネージャが計画を作り、メンバが納得するかどうかに関わらず、人的リソースを割り当て、進捗を計測し、計画どおりに進捗していなければPDCAのCAをメンバに指示し、またPDCAを回せば良いのだ。その上、結果に応じた評価を行えば良い。

マネージャに課せられるロールに紐付けされるアカウンタビリティはこれで果たせる。

さて、どうだろう。

指示しない宣言

 メンバが自らチームに課せられたミッションを理解し、達成が必要だと考える目標を認識し、計画を考え、一つひとつ行動に移す。

この域に達するようになったチームは理想的ではないか。そうしたチームにようやくなり始めたと感じた経験をしたことがある。

前に書いたかもしれないが、前年まではあれこれと割と口を出していたのを年度明けからやめる宣言をしたことがあった。

もう、あれこれ言わない。

チームの目標は立て、君たちに数回に渡って説明した。ここからは君たちが全てを回すのだ。そう言った。

それまで、メンバは最後にはあれこれとアドバイスをもらえるというパターンで仕事をしていたはずだ。それが窮屈だったと思っていたメンバもいたかもしれなし、最後にディレクションをもらってからそのディレクションに合わせればいいと思っていたかもしれない。

それをやめる宣言をした。

脇役に回る

 では何をしたか。

新規事業の企画を1つのテーマにしていた。ネタ的に毎年あるものだが、その年はちょっとしたマイルストンがあり、それより前に形にしないと機を逸することになるだろうと見ていた。

新規事業企画でアイデアがあるのはわかっていたが一向に進む気配がなかったので、概況からちょっと誘い水を投げてみた。

君たちにはある企画をやりたいと言っている。だが、もうそのリミットは視界に入ってきている。本当にそれを実現したいなら今が最後のチャンスだと思うがどうか。

やりたいのなら応援する。役員にも掛け合う。手伝って欲しいことを言ってくれ。

その裏で、部門責任者の時間をもらう機会を作っておいた。

これは組織の動向を話してもらう体で、最後の5分にメンバが企画プレゼンをしてはどうかとメンバに提案していたからだ。

部門責任者はそのプレゼンをきき、組織の内情を話、メンバにその企画を進めることを判断した。

そう、マネージャはメンバの脇役であったほうがいい。主役はエンジニアに任したほうが良いのだ。メンバは自分で考え動く。

 

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

 

 

マニュアルを目次から作るということの意味がわからくてリジェクトされた話

もう20年くらい前だったか、大規模プロジェクトにアサイメントされた。担当は、プロジェクト内で使用するエンジニアが使用する情報共有システムだった。サーバのセットアップ(聞いてなかった)から、パッケージの導入をさせられて(製品担当のエンジニアのオンサイトサポートがあったかもしれない)、あとはプロジェクトに合わせてカスタマイズするというやつだ。

当時のカウンタのリーダが部長級の人で、プロジェクトの中で使わせるのでマニュアルを作れという。じゃあと、作ってみたら速攻でリジェクトされた。もう一度トライしたらこれも速攻でリジェクト。

そのとき、優しく言われたのが

 

「目次からね。作って」

 

ああそうなんですね、くらいしか思いもしなかった。言われたことの意味が理解できていなかったのだ。

だからだろう、3回目もリジェクト。

f:id:fumisan:20180426074046p:plain

わかってないので解決策が突破できずに悩むこと一日。今から思えば悠長なことだ。今だったら、すぐに相談してよ、と言うだろう。

構成を考える機会

 エンジニアであれば、文書を作成する機会は多いはずだ。仕様を説明する資料、設計書など書くことが仕事だからだ。

ただ、文書を作ると言っても、テンプレートを使って書くことが多い。テンプレート自体や、そのテンプレートを部品とした、文書全体の目次構成を考え、チームに展開する機会はほとんどないだろう。特に最近は、ドキュメント自体をUMLなどのツールで書いてしまったり、コードからリバースするところもあるから、ツールのデータをリポジトリに格納したらおしまい、的なプロジェクトもある。

ただ、そうしたツールで○○図やチャートを作成していても、プロジェクトで作成するドキュメントはコードを書く上で必要なものの構成は考えなければならない。それを考慮した上で、どの図表や文書が必要かを決めなければ、コードを書く際に情報が足らず、手戻りが発生してしまう。

結局、誰かが文書の構成を考える必要が出てくるが、誰かが考えれば良いのでその他大勢のエンジニアにそうした文書構成を考える機会は訪れない。

何が困るか

文書の構成を考える機会が得られないと何が起きるか。エンジニアが自分で一から作る文書の内容が破茶滅茶になるのだ。

wordでもpowerpointでも良いが、文書を作らせるとエンジニアが書きたいこと、書けることから書き始めてしまう。

普段から目次構成を考えることがなく、パーツばかりを作っているから文書の目次を考えると言う発想に辿り着かない。

何が起きるかと言えば、上述のようなことが起きるのだ。

何を伝えたいか

 文書であるから、結局、対象読者に対して文書に記載することを伝えたい、となるはずだ。ウォーターフォール型のシステム開発であれば、局面の文書は、次工程のインプットになる。V字モデルであれば対向するテストフェーズのインプットになる。将来の自分かもしれないエンジニアに対してその工程での成果を伝えるために作成するのだ。

f:id:fumisan:20180426080832p:plain

成果発表であれば、伝えたい成果を最大限伝えなければ成果を評価してもらえない。過大にではなく事実としての成果を伝えなければならない。

そうした伝えたいことを伝えられる文書になるかどうかは、目次構成に全てが掛かっている。

構成を考えるには

付箋紙かA4の紙に標題、こんなことを書くと言うイメージのコメントを書き出し、壁に貼ったり、テーブルに並べて全体を眺める。

これが一番である。

その際に、伝えたいことは何か、を書き出しておくと良いだろう。順番に悩んだり、構成に入れるか、削除するかの基準となるからだ。

間違ってもいきなりWordやPowerpointで作り始めてはいけない。綺麗に仕上がるので構成を作ることより、実際に書き始めてしまうからだ。

ここは注意されたい。

 

 

 

アウトプットの遅いエンジニアの仕事をちょっとだけ早くする

グループに投稿された話題に、

一人のエンジニアがずっとアレコレと仕様を悩んでいてコードをなかなか手をつけないのだがどうしたらいいか(要約)

 というのがあった。コードに限らず資料作りでも同じようなエンジニアは見かけるし、逆に何も考えていないじゃないかと思うくらいに、いきなりスライドを書き始めて構成が支離滅裂になるエンジニアもよく見かけるのでどっちもどっちだな、と思う。

冒頭の仕様に悩んでなかなかコードを書かないエンジニアを観察している立場のリーダやコーチの立場で見れば、これはこれで焦れったいものだ。ついつい、自分ならこう進めてしまうのに、とコードを書くエンジニアを自分に置き換えて、自分がコードを書くならああすればいいとかこうすればいいとかと段取りを組み立て、それと比較をしてしまうからだ。

違う頭を持っていることを認識する

リーダやコーチ役こそ、悩んでいるエンジニアと自分が違う頭を持っていることを最初に気づかなければならない。

自分のやり方を押し付けてはいけない。やるのは悩んでいるエンジニアの仕事だからだ。それを奪ってしまってはいけない。奪われてしまったらそのエンジニアは自信をなくすだろうし、チームでの存在意義も失ってしまう。

リーダやコーチは、メンバのパフォーマンスを最大限に引き出すのも仕事の一つだ。

違う頭を持っていることを認識する行為は、悩んでいるエンジニアの存在を認めるということだ。

ここが解決のスタートポイントである。

世界観を教えてもらう

仕様で悩んでいるエンジニアは、多分、いや確実に、リーダやコーチより多くの不安を感じ取ってリーダやコーチ役よりより広い範囲でこれから書くコードの仕様についてどう決定すればいいかをあぐね居ているのだ。

 それに比べ、リーダやコーチ役は仕様の界面をスパッと決めているはずだ。だから、次々と段取りが思いつくのだ。

だったら、悩んでいるエンジニアがどんな世界観で悩んでいるのかを教えてもらおう。

この際、リーダやコーチは聞き役に徹しなければならない。使っていい言葉は2つだ。

 

 

  • なるほどねー
  • こっちはどうなっているの

 

 

同意すること。関心を持っていること。この2つを示しながら聞けばいい。とにかく、頭で考えていることを図式化することだ。

界面を引かせる

次にすることは、悩んでいるエンジニアに仕様の界面を引かせることだ。言い換えれば、インタフェースを決めるわけだ。

書き出された図の中に悩んでいる仕様の範囲がどこまでが入るかをぐるっと線引させる。

もし、全部を線で囲ったとして、その図式が妥当な仕様だとすれば、デザインは頭の中でできていたということだ。ただ、具体化していないなかったから、頭の中で整理できずに決めきれていなかっただけだ。そうであれば、それでいいと背中を後押しすればいい。

線引が仕様の機能を超えていたら、別の機能仕様を引き合いに出してどちらが機能を実装したら良いか、アーキテクチャとして見直したらいい。実は悩んでいるエンジニアのアイデアの方が正しかった、ということもないではないのだから。

ちょっとだけ早くするには

悩み始めたら、ホワイトボードに描くことをチームのルールにしよう。全員でやるのだ。

利点は2つ。

1つは悩んでいるエンジニアの頭の中を図式で可視化し、それをリーダやコーチが気づける。

2つ目は、全員でやることで学習することができないエンジニアのアーキテクチャのデザインスキルを共有できることだ。ホワイトボードに描くことでそれが視界に入る他のエンジニアがなぜ、どうして、と思えればこれで十分なのである。

 

プジョー ソルトミル ナンシー 12cm 900812/SME

プジョー ソルトミル ナンシー 12cm 900812/SME