かざいむ日誌

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

母をタブレットデビューさせてみた。

母70代中盤の契約しているガラケーの更新時期を迎えていたのでもろもろ考えたうえでタブレットガラケーの2台持ちに移行してみた。

 

きっかけ。

母は現在遠方に住んでいて、姉、兄は車で20分くらいの場所に住んでいる。3月中旬から私が海外赴任となり、孫と会う機会がこれまで以上に減ると思われる。これまではガラケーを使っていたが動画は共有できず、写真もファイルサイズ制限があって時間があるときだけ母にリサイズした写真を送り、兄に動画を送って見てもらっていた。母が利用していたauのプランがこの3月末に契約終了を迎えることになり、スマホ使いこなせるか心配という連絡があり、1月頃から検討を始めた。なお、現在のガラケーは兄が使用料を払っている。

 

考えたポイント

  • パソコンやスマホなどに疎い
  • 細かい文字を見ると疲れやすい
  • 大きなスマホを持ち歩くのは大変
  • スマホを使った場合、Line、メール、電話が主な用途
  • 兄や姉が実家に寄った時にスマホの使い方を設定してくれる
  • 出費は抑えたい
  • 外出時に調べものなどはおそらくしない
  • うまくいかなくてもいいようにミニマムスタートにしたい
  • SIMの契約はオンラインで手続きしたい
  • 兄にも小さな子どもがいて同じやり方で写真などの共有をしたい

結果

以下のような運用を行うことにした。ガラケーはプランを変えて引き続き契約する。中古のSIMフリータブレットを購入、IIJ格安SIMを契約(月額900円程度の3GBのプラン)。外出時はガラケーを携帯し、家ではタブレットでLineをする。初期投資は中古タブレット代6000円、SIM事務手数料3000円で月額900円(税抜き)でスタートした。

 

タブレットの設定

母にタブレットを渡すにあたり以下の設定を行った。

  • 文字サイズを大きくする
  • Lineの文字サイズを大きくする
  • 画面のブルーライトカット設定
  • Google音声入力を利用(現在トレーニング中)

 

現状&反省

とりあえずLineのメッセージや送った動画は見れるようになった。反省としては音声入力ではなく、スタンプの送信を先に教えておくべきだった。音声入力はキーボードの設定、音声入力の状態の把握がちょっと難しかった。今回は兄の子どもの動画・写真の共有、母のITリテラシーがまだ発展段階などの条件を考えてスマホアプリの「みてね」の採用は見送った。写真のバックアップおよび妻の親への共有を考えると今後は「みてね」もありかもしれない。

Google Driveにアップしたファイルがダウンロードできない。

ファイル共有目的で自分のアカウントとは別にGoogleアカウントを作って、Google Driveを共有して他の人にファイルをアップロードしてもらった。ダウンロードしようとしたところ403エラーが出た。

f:id:name_untitled:20190209131541p:plain

doc-14-6g-docs.googleusercontent.com へのアクセスが拒否されました このページを表示する権限がありません。
HTTP ERROR 403

 

ググってみたところ、以下のサイトがヒット。解決策としては以下の2つが提案されていた。

1.すべてログアウトして、Google DriveのURLを開き、ログインする。

2.匿名モードでブラウザを開いてログインする。

 

2.を試したら無事解決した。

Dropbox、Google Docs、GitHubの比較

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

togetter.com

www.slideshare.net

 

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

 

表にするとこんな感じ。

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

 

就職して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