かざいむ日誌

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

Dropbox、Google Docs、GitHubの比較

アプリを作りたいという人がいたので、Gitを覚えて、GitHubを使うといいよという話をしたのだけど、Dropbox、Google Docsと何が違うのと聞かれたのでまとめておく。GitHub（GitLab）はシステム開発ではよく聞くし、たまに出版業界でも使われるという話を聞く。

togetter.com

www.slideshare.net

 

Dropbox、Google Docs、GitHubの使い分けをざっくりまとめると、複数のファイルについて課題を管理しながら編集したい場合はGitHub、そうでなければDropboxかGoogle Docs。複数ファイルの場合はDropbox、1つのファイルの場合、または意見をやり取りしながら進めたい場合はGoogle Docsを利用するのがよさそうに思います。

 

表にするとこんな感じ。

  Dropbox Google Docs GitHub
目的 複数のファイルの共有＆同期 1つのファイルの共同編集 複数のファイルの共同編集・同期
管理するファイル 複数 1つ 複数
履歴 復元可能 復元可能 復元可能
課題管理 不可 不可 可能
導入難易度 易

易

難

 

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

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

 

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

 

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

 

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

私

・大学で語学を専攻

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

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

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

 

話し相手

・大学で文系の専攻

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

・現在、新卒3年目

 

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

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

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

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

 

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

 

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

 

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

 

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

 

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

１．分野・課題専門力

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

２．総合マネジメント力

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

３．問題発見・調査分析力

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

４．コミュニケーション力

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

５．援助関連知識・経験

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

６．地域関連知識・経験

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

partner.jica.go.jp

 

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

 

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

 

追記。

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

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

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

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

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

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

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

 

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

www.pmi-japan.org

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

 

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

 

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

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

 

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

brevis.exblog.jp

 

 

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

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

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

 

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

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

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

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

blogs.itmedia.co.jp

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

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

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