かざいむ日誌

IT関係で知ったことなどを記事としてあげていきます。内容に不備や質問などあればぜひコメントをよせてください。

就職して3年間の仕事って今の仕事に生きてますか?

とある会合の帰り、方面が一緒の人と話しながら帰ったのですが、仕事の話をしてる時にされたのがこの質問。

 

「就職して3年間の仕事って今の仕事に生きてますか?」

 

聞かれたときはほろ酔いだったのもあって、役立ってますよ~、と答えましたが、後から振り返るとちゃんと答えないといけなかったやつですね。また話す機会があるかわからないので考えてみました。

 

この会話の登場人物はざっくりこんな感じです。

・大学で語学を専攻

・卒業後、システム開発会社に就職し、プログラマー、SEを経験

システム開発に従事して10年以上

・次は海外の業務改善のプロジェクトに従事

 

話し相手

・大学で文系の専攻

・卒業後、メーカー企業にて総合職(技術職ではない)

・現在、新卒3年目

 

この方が言っていてポイントかなと思ったのはこのあたりです。

・英語がそんなに得意じゃない(自己申告なので本当か分かりませんが)

・学生のころから国際協力に興味がある

・自分にスキルが身についていない気がする

 

ぼくの経験からお答えします。就職して3年間の仕事は今の仕事に役立っています。次のプロジェクトは外国の組織でITスキルの向上を通じた業務改善をテーマとしています。このプロジェクトを進めるためのスキル要素は基本的なITリテラシー、業務プロセスの設計・改善、業務上のコミュニケーション、プロジェクト管理だと思います。就職して3年間の仕事で今度の仕事に直結しているのは上の中では基本的なITリテラシー、顧客への説明・提案の経験、プロジェクト形式での仕事の経験の3つかと思います。就職して3年間の仕事ではプログラミングやExcelなどが一番割合が大きかったように思うので今回の仕事に生きるのは30%くらいでしょうか。ただし、残り70%も3年間の仕事を前提に役割が与えられ、得た知識・経験が結構あるので何とも言えない感じですが、、、。

 

この方のお仕事を聞くと、プロジェクト管理的な要素が強く、技術職の方とやり取りしてスケジュールを管理しているらしい。おそらく、カレンダーを眺めながらの調整が仕事で成長している手ごたえを感じず、技術職の方とやり取りする中で技術職の方と違って専門知識がない、もしかすると違った分野に進みたくなる時が来るかもしれない、といったときに今この仕事をやっていることが無駄になるんじゃないか、といった気持ちがあって「就職して3年間の仕事って今の仕事に生きてますか?」と質問したんじゃないかと思います。

 

ぼくが思ったのは、もし今の仕事が将来の仕事に生かせないかもと思うのであれば、今の職場でPMBOKを意識して仕事されるのはいいかなと思いました。PMBOKは Project Management Body of Knowledge の略で、プロジェクト管理のベストプラクティスについてまとめたものです。プロジェクト管理は経験、勘、度胸じゃなく、知識とスキルとして体系的に身に着けられるもので、ポータブルなスキルなので、今の職場でこれを実践できるのであればちゃんとしたスキルとして胸を張れるんじゃないかと思います。

 

もちろん、広報、システム開発、会計などやりたい職種があるならそれでよいと思います。もし、やりたい職種がないのであれば、興味のある業種で求められるスキルを身に着けるのを目標にするのもいいのかなと思っています。この方は国際協力に興味があるそうなので、仮に将来その方面に進むかもと考えるなら、国際協力で求められるスキルを意識して仕事をするだけでも違ってくるかなと思います。

 

国際協力分野だとJICAのHPに国際協力人材に求められる能力として6つの能力を挙げています。

1.分野・課題専門力

大学での専攻や、職種を通じて身に着けた知識・経験のこと

2.総合マネジメント力

プロジェクト管理や部門の業務を俯瞰的に理解・実施する能力、人材育成など

3.問題発見・調査分析力

リサーチを設計、実施、まとめたり、問題を分析して原因を突き止められる能力

4.コミュニケーション力

関係する人に働きかけて変化を促す能力、交渉できること

5.援助関連知識・経験

JICAのやっていること、開発援助で過去に起きた問題・それを解消するための最近の傾向など

6.地域関連知識・経験

援助を行う地域で使われる言語の能力、文化などの知識・経験

partner.jica.go.jp

 

ちなみに国際協力人材の場合、これらは全部がないとだめというわけではなく、開発援助のプロジェクトを行う場合にプロジェクトの中でその人に求められる役割によって重点が変わってきます。専門家は1.分野・課題専門力が多く求められ、プロジェクトマネージャーには2.総合マネジメント力、3.問題発見・調査分析力、4.コミュニケーション力が多く求められるのではないかと思います。

 

話をまとめると、スキルを考えるときに切り口としては職種と業種で考えるといいのかも、業種の切り口から考えるときは技術職でない場合、業種や会社ごとに求められるスキルセットが異なるから調べてそれを意識しながら仕事を通じてスキルを身に着けられるようにするのが良いのかも。

 

追記。

TEDでとても良い20代向けの話があった。

メグ・ジェイ: 30歳は昔の20歳ではありません | TED Talk

後輩SEとの勉強会(2019/01/09)設計思想と方向性、使えそうな知識体系、スキルと資質について

久しぶりに後輩SEと話す。

彼は今組み込み系のパッケージソフトを使う業務に参加しているとのこと。それで悩みなのが、パッケージのできること・できないことは開発ガイドを読んで一通り分かったものの、「こういうのできない?」と聞かれたときに「できる」、「できない」という返事以上に踏み込んだ話ができないとのこと。

どういうことか聞いてみると体系化や設計思想などが腑に落ちていないみたい。こういう設計思想のパッケージだからこういうことをしようとするとめんどくさくなるとか、そういった話ができるようになりたいらしい。これって、なにか良いショートカットないだろうか、、、。複数のパッケージを比較してそれぞれの製品が推している特長から設計思想が見えてくるのでは?とちょっと思った。これが横並びでの体系の把握とすれば、時系列での変遷というのがわかるとまた良いのかも。現場にベテランがいるらしいので、もしかするとパッケージ以前の開発についても話が聞けるかもしれない。そうすると、過去のどういう課題を解決するためにこのパッケージが出てきたかがわかる。

たとえばモジュール化することで疎結合な仕組みを実現した、ということであれば密結合な作りは望ましくないことが分かる。

 

次に、今の現場では1つに集中しすぎだと怒られることが多いとか。代わりに求められるのが大局的な視点。おそらく現在のチームでは大枠をだれも提示しないまま、役割を増やされていて、慣れることを求められている。これはちょっと効率が悪いように思う。もしかするとあるのかもしれないが、作業の関連が結びついていないのかも。PMBOKITILだとドキュメントや手順が決まってていいよ、という話をした。

www.pmi-japan.org

今思えば、業務プロセス設計について話をした方がピンときたかも。成果物から、業務と業務からのアウトプット・業務へのインプットとなるドキュメントをざっくりでも整頓すると全体像や前後関係が把握できるかも。

 

それで、ITILについて紹介。沢渡あまねさんがITILを業務改善に応用した本を出していてなかなかよさそうだったので。

 

新人ガール ITIL使って業務プロセス改善します!

新人ガール ITIL使って業務プロセス改善します!

 

あとは、PMBOKのちょっとした紹介と、PMBOKのブログで勇気づけられた話を紹介。プロジェクトマネージャーとかを個人の資質と考えてしまいがちだけど、知識+スキルと考えればある程度のレベルまでは資質がなくてもできるのではという話。ぼくがどちらかというと視野が狭く、まんべんなく調整できるタイプではないので、PMBOKを身に着ければある程度はプロジェクトの推進ができるという話を聞いて、勇気づけられたという話をしました。詳しい話はこのブログ参照。

brevis.exblog.jp

 

 

NPM汚染、Node.js脆弱性の話の覚え書き

来年のSECCONに出そうなトピックだなぁと思ってメモしておく。こんなツイートが流れてきた。

 文脈よく分からなくて、なんかあったっけ?と思ってNPM、汚染とかキーワードで調べたら2つほど話が出てきたから備忘録的に書いておく。新しい話としては、NPMのパッケージのメンテナが変わって、マルウェア版が仕込まれて配布されたという話。たしかにこれはなにも意識せずに取りこんじゃったりしそうで怖い。

 

もう1つは、Javascript特有のPrototypeの脆弱性を突いた攻撃がありそうだとのこと。ざっくり調べると、JavascriptではPrototypeというものがあって、全てのオブジェクトの祖としてPrototypeがいる。これを上書きすることによってオブジェクトの振る舞いが変わってしまって意図せぬ挙動となるらしい。ちょっと前にPrototypeの仕様をふーん、と読んだばかりだったのでびっくりした。

この辺りの記事が分かりやすい。

jovi0608.hatenablog.com

techblog.securesky-tech.com

DeNA QA Nightに行ってきました。 #dena_qa_night

最近テストとは?品質とは?と思っていたのでDeNA QA Nightに行ってきた。そこそこ面白かった。QAの人たちのためのイベントといった印象だったのでどんぴしゃじゃなかったものの取り組み方や前提の話などに触れられたのが良かった。イベントはデバッグ工学研究所の松尾谷さんとDeNA品質管理部の河野さんが登壇。

 

松尾谷さん「テストの広さと深さ、どっちが大事?」

この話はQAが何を誰に対して保証すべきかという話でとてもスケールの大きな話だった。ソフトウェアのOSS化に伴い、OSSの品質を誰が負担しているのか。Webサービスの隆盛とともに、品質保証の役割が変わり、伸び盛りのサービスを下支えするものであると同時に、人気を博しているサービスが急落するリスクを避ける、リスク対策としての品質保証であるとのこと。このような観点からすると旧来型の品質保証を標準化したり、プロセス定義を行うようなプラクティスからは脱却すべきではないかとのこと。話が壮大でなるほどー、という感じ。

私は松尾谷さんの過去の発表資料が参考になった。

 

あと、この辺りのツイートのトピックも面白かったです。

特に、有則、禁則、無則という分類は考える補助線になる良い表現だなと思った。一緒に行ったJSTQB認定テスト技術者試験に合格したプロジェクトメンバーは聞いたことがあると言っていたので、この試験のシラバスを読むのもいいかも。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf

 

河野さん「DeNA品質管理部の概説と改善事例」

河野さんはDeNAに移って1年ほどだそうで、これまでの取り組みの紹介。こちらは現場の取り組みということでとても面白く聞くことができました。移ってきた当初は品質管理はそれぞれのサービス担当のチームがそれぞれの観点でテストを行っていて、プロセスや言葉の定義なども統一されていなかったそう。そこで、河野さんはPFD(Process Flow Diagram)という記法で、各チームのテストの立ち上げ、設計、実施、とそれらから得られる成果物などをフロー図に起こして業務の見える化をしたとのこと。そして、チーム間で共通するものを標準として定め、それだけでは不足する場合は任意で追加可能、不要な場合は理由を挙げて省略できるなどのルールを定めたとのこと。そして、作成した標準のテスト業務のプロセス定義の作業、成果物などの名前を統一した。

これにより得られる効果として2つほど挙げていた。1つは、リリース後の不具合発生時にテストプロセスのどこに問題があったか改善することができるようになる。もう1つは、テスト観点のベースラインを作る、データ収集、改善、などの次の施策のベースになるとのこと。

このようなボトムアップでの業務の標準化はとてもいい手法だと思った。暗黙知形式知に出来るとともに、各チームが標準プロセスをお仕着せではなく、自分たちの標準として取り入れることができるし、標準で足りない部分や標準の要らない部分をはっきりと意識出来る。これは今後業務改善の取り組みをする際に使えるなと感じた。

プロセスフロー図のサンプルはこのサイトにありました。

blogs.itmedia.co.jp

久しぶりにNodeを動かしたらエラーが出た。バージョンアップした。

Vue.jsのオンラインコースに引き続き、テスティングのオンラインコースを受けてた。英語が嫌でなければこのサービストータルで30分くらいの動画のコースでまずはちょっと触ってみるのにはいいコースだと思う。Vue.js入門とか良い感じ。3,4個のコースが無料なのでちょっと手が空いた時に良いです。

vueschool.io

で、受けてて、最初のテスト書いたからグリーンにするぞと思ってテストコード流したらエラー。

lesson3.js:2
class User {
^^^^^


SyntaxError: Block-scoped declarations (let, co
nst, function, class) not yet supported outside
strict mode
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
at node.js:968:3

で、これはちょっとNodeが怪しいと思って、ググったらこのサイトを見つける。

tweeeety.hateblo.jp

あー、おんなじ感じ。手元のNode、npmのバージョンを確認してみた。

$ node --version
v4.4.7
$ npm --version
2.15.8

どうもバージョンが問題な気がする。このサイトではnodebrewを使ってバージョンアップ、他のサイトではnpmのnというのを使うというのを紹介していたりしていくつか試してみたけど、こんな感じのエラー。

Roaming\npm\node_modules\npm-windows-upgrade\node_modules\inquirer\lib\ui\prompt.js:3
var { defer, empty, from, of } = require('rxjs');
^

SyntaxError: Unexpected token {
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:373:25)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object.<anonymous> (C:\Users\XXXX\AppData\Roaming\npm\node_modules\npm-windows-upgrade\node_modules\inquirer\
lib\inquirer.js:19:11)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)

ということで、素直に公式サイトからNodeの最新版をダウンロードしてインストールして解決しましたとさ、めでたしめでたし。

後輩SEとの勉強会(2018/11/17)制約と誓約 #docker入門

後輩SEからDockerを分かるようになりたいので勉強会のトピックにさせてほしいと提案があり、今日のテーマはDocker。以前、Swiftの案件でDockerを入れたそうで最近またDockerを記事とかで目にして知りたくなったんだとか。今振り返ると、もう少し良い説明があった気がするので再現でなく、ポイントを絞って掘り下げます。

 

制約と誓約

漫画ハンター×ハンターを知っている人なら分かると思いますが、Dockerはまさにこれ。Dockerでは普通のサーバなら出来るようなファイルシステムへのアクセスや、プロセス間の連携はできません。これはまさにコンテナ、箱に閉じ込められたようなものです。これが制約です。そして、開発者はお作法に従った開発を行います。これが誓約。こういう不自由さがあるゆえに、形の決まった箱、コンテナであるがゆえに、箱を載せる載せるOSは中身が何かを意識する必要はありません。どこに持って行ってもDocker上で動くことが保証されています。これがDocker、コンテナ技術で得られるメリットです。

と言っても、全く意識しなくていいかというとそうでもないかもしれない。以前、航空会社の貨物部門で働いてる友人から、貨物は積載量に応じてどのように配置するか計算しないといけないという話を聞いたことがあります。

コンテナ技術というのはとてもうまい例えで、少し前にコンテナ物語という本がはやってましたが、規格化して中身を意識しなくてもよくなるというのはすごいことですよね。

コンテナ物語―世界を変えたのは「箱」の発明だった

コンテナ物語―世界を変えたのは「箱」の発明だった

 

 

演習 

今日はDockerを動かしてみるというのを目標にしていたので、Dockerをインストールして公式サイトのチュートリアルに従ってDockerでHello Worldをした。基本この手順でやると、ものの10分でDockerを動かしてみることができた。

Part 2:コンテナ — Docker-docs-ja 17.06.Beta ドキュメント

ただ、2か所ほどはまったのでメモ。

docker build でイメージを作る時にエラーが出る。

app.pyファイルに日本語のコメントがあるのだが、それがdocker buildでエラーになる。このコメント行を削除するとdocker buildは通るようになる。

localhost:4000でアクセスできない

これはどうも実行したDockerがIPをデフォルトでもっているらしく、そのIPにアクセスすると作ったページが表示される。このURL↓

http://192.168.99.100:4000

stackoverflow.com

 

話したこと

この資料の始めの方を見ながら話したけど、Dockerの必要性を理解するにはある程度企業やサービスでどうやってサーバを運用しているか知識が必要だと思った。

 

まずは4枚目の、物理サーバ、仮想サーバ、クラウドコンピューティングについていまいちそれぞれの特徴や、解決する課題が腑に落ちないとのこと。そこでまずは物理サーバから話を進めた。物理サーバは分かりやすい構成。
 次に、仮想サーバを企業で導入する理由について。1台に1サーバだと社内システムを複数立てている時に問題になることがある。例えば、勤退システムは帰る時に入力が多いからその時間帯のアクセス数に合わせてサーバのスペックを考える。でも、それ以外の時間はサーバはあまりアクセスがない。一方で、グループウェアのサーバーは朝一にスケジュールを確認するためにアクセスが集中する。でも、それ以外の時間はサーバはあまりアクセスがない。そうするとサーバを1つにまとめて、CPUやメモリを共有したら1+1=2じゃなくて、1.5くらいの予算で済むんじゃないかというのが導入する理由の1つ。あとは、モノが多くなれば壊れる確率が上がるけど、企業とかで導入する仮想サーバーだとそういった時に壊れた部分とは別の部分でサーバを立ち上げることですぐに復旧することができる。
 最後に、クラウドコンピューティング。この資料ではおそらく、AWSやAzureが提供する仮想マシンのサービスを想定している。コンシューマ向けのサービスを提供している場合、アクセスの増減に合わせて、仮想マシンを増やしたり、減らしたりする、はず。これをルーチンでできるようにサーバの構築をAnsible、Chefなどのツールで自動的に展開できるようにする。そうすることで、闇雲にサーバを用意してお金を払う必要がなくなるし、アクセスが急に増えてアクセスがさばけなくなることもない。
 このような話が前提にあったうえで、このクラウドコンピューティングの構成では、台数を増やしてもOSを立ち上げるのに時間がかかったり、OSに入っているライブラリのバージョンが違ってて動かないことがある。そこで、登場したのがDockerだ。
 

設計Nightに行ってきました。 #sekkei_n2018

先日設計Nightというトークイベントに行ってきました。これは元々、 @shinpei0213 さんがBuildersconで話した内容についてのスピンオフ企画。忘れてしまいそうなのでメモがてらアウトプット。まずは登壇者の方々の資料を貼る。

nekogata.hatenablog.com

YouTubeに講演動画上がってました。

 

@moznion さんの発表資料

speakerdeck.com

 

@magnolia_k_ は公開資料作成中らしいですが、確かにこの1枚に凝縮されてます。

 

 

追記。資料公開されたようなので貼っておきます。

speakerdeck.com

 

@sona さん

medium.com

 

@moznion さん『ソフトウェア開発における「設計」と「パフォーマンス」の相互作用』

パフォーマンスを上げるための取り組みを垂直、水平、その他という切り口で分けていて分かりやすかった。スライド中に何度か「ゼニや」というえげつない言葉が出てくるが、ビジネスを見ろと言う大事な指摘だと思う。技術的負債という言葉と同じで、パフォーマンスもコストという物差しがあることで、妥当なラインを判断できるということを学んだ。まずはコストに見合わない「早すぎる最適化」をせずに、素直に設計する。インプレッションやユーザ体験、サーバの有効活用の観点から必要に応じて、パフォーマンスを向上させる設計を行う。設計のきれいさやパフォーマンスといったそのままでは比較できないものを「ゼニ」で判断するというとても面白い発表だった。

 

@magnolia_k_ さん『ドメイン知識の暗黙知形式知にするためには』

仕事で業務システムを作っているので個人的には一番身近に感じたトピック。ドメイン知識がなぜ暗黙知になるのか、どうやったら形式知とできるのかについての発表。暗黙知を3つに分けてそれぞれになぜ形式知とならないかを説明されていた。事実は起きた時にいた人には当然のことになっているから明示的に共有しない。関係はある視点から見た時に浮き彫りになるものだから視点を持つことなしに明示化できない。原則はそもそも意識しない、例外は書ききれないから共有されない。これはとても納得感があった。関係を明示化する方法として、何かしらかのフレームワーク(例えばAs-Is、To-Beモデル)に当てはめてみることを提案されていてなるほどと思った。原則を形式知にする方法がちょっと記憶が飛んでる。

ここで思い出したのが、国際協力のファシリテーションの本。この本の考え方がヒントになるんじゃないかと思った。

途上国の人々との話し方―国際協力メタファシリテーションの手法

途上国の人々との話し方―国際協力メタファシリテーションの手法

 

『途上国の人々との話し方 国際協力メタファシリテーションの手法』
和田信明、中田豊一(2010年)
みずのわ出版

 

これは国際協力で、援助対象の地域の人に課題を聞き取る時のヒアリングについて書かれた本だ。いくつか引用やメモを紹介する。

「私」は、村人に「問題は何ですか」と、聞いてはいけなかったし、「原因はなぜですか」とも決して尋ねてはならなかった。  

現実を構成する3要素:事実、観念・考え・意見、感情・情緒・気持ち
すべての質問が次の3つのタイプに分けることが出来る
1.「朝ご飯は何が好きですか」→好み=感覚、感情
2.「朝ご飯はいつも何を食べますか」→思い込み、考え、意見
3.「朝ご飯は今日は何を食べましたか」→事実
WhyとHowを使った質問は現実を浮かび上がらせない
事実質問に徹するということは、「観念」「概念」を尋ねる質問は控えるということ。こちらは事実を知りたくて質問しているのに、相手は、こちらに合わせて自分の考えを交えて答えることになり、やり取りに食い違いが生じる、つまり現実認識を共有できない、あるいは、思い込みと事実を区別しないままに、「思い込み」のほうを答えてしまう、という混乱を避けるということであった。

 

本当の原因を知りたいのであれば、「なぜ?どうして?」と当人に聞かないほうがいい。卑近な例でいえば、「先生、お腹が痛いんです」と言う患者に対して、医者が「どうしてですか?」と聞くはずがないということことだ。患者の自己分析など尋ねないで、医者は、「いつからですか?」「今朝は何か食べましたか?」という具合に問診、すなわち事実質問を重ねていくことを私たちはよく知っているではないか。
課題分析を手助けするためには、問題そのものについても、こちらからは尋ねないのが対話型ファシリテーションの原則である。逆に、もし相手がこちらに聞いてほしい問題があるのであれば、必ず相手から語り始めるはずだ。だから、こちらは、何でもいいので、相手の周辺で目に付いた物の中から意味のありそうなものを選んで、「それは何ですか?」「何でできているのですか?」「いつ手に入れたのですか?」などと単純に聞き始めればよい、ということである。

ちょっとずれているかもしれないけど、、、。

 

@sona さん『マイクロサービスと設計原則 』

FiNCでのマイクロサービスの実践を設計原則に照らし合わせてどのようにマイクロサービスを構成するのが良いかについての発表。マイクロサービスやったことないので、こういう課題があるのかというのが、FiNCでの事例で具体的に分かってとても面白かった。基準の立て方で、方針や構成が変わるというのがとても面白い。「実装のDRY」ではなく「作業のDRY」を目指すというのが名言。

今気づいたけど(いまさら)、マイクロサービスこそDRYの理想の体現で、マイクロサービスで出てくるDRYにまつわる問題は、DRYの根本的な問題と言えると思う。発表では横断的な関心事をDRYでどう解決するか、視点によってDRYの切り口が変わるという問題をどう解決するかという本質的な話をされていた、と今さら気付いた。それぞれ、横断的な関心事は「実装のDRY」ではなく、「作業のDRY」を目指すことにより解決する、視点によってDRYの切り口が変わる場合は、それぞれを1つのビジネスとみなしてマイクロサービスを設計する。なるほど。

 

とても楽しいトークイベントでした。ありがとうございました!