Notes

メモ書き

はてなブログの記事(HTML)をQiitaにコピペしてみた

特に技術的な内容については、自分が会社でも見るつもりでブログに書いているのですが、新しい就業先がはてなブログをブロックしていらっしゃる!

Qiitaは見れたため、仕事で使えそうな内容はQiita側にも書くことにしました。

(Qiitaはもともと技術者向けのブログサービスだしね)

 

はてなブログでは「見たまま」編集にしておりHTMLがコピーできるので、そのままQiitaに張り付ければいいじゃんと思っていましたが、Qiitaの記事作成ページを見ると、、

f:id:cask-st:20180614212526p:plain

Markdown記法で書いて共有しよう」って書いてあるやん。。

 

なんですが、ダメ元でHTMLをそのまま張り付けたら普通に表示されました!笑

というわけでコピペした記事はこちらです。

ちなみにもとの記事はこちら。

今後、技術的なものを完全にQiita側にするか、はてなと両方上げていくかは検討中ですが、両方でも手間があまりないことがわかりました。

それにしても Markdown でも HTML でも指定せずにいける仕様ってことで、Qiitaすげぇってなりました。

 

ではでは。

 

はじめての要件定義で読むべきIPAドキュメント

ソフトウェア開発の要件定義をやるにあたって、読んでおいた方が良いIPAのドキュメントを紹介します。

IPAとは、Wikipedia 先生によるとこんな団体です。

独立行政法人情報処理推進機構(じょうほうしょりすいしんきこう、英: Information-technology Promotion Agency, Japan、略称:IPA)は、日本におけるIT国家戦略を技術面、人材面から支えるために設立された、経済産業省所管の中期目標管理法人たる独立行政法人である。

「Wikipedia」先生引用

 

情報処理試験をやってる団体というと一番ピンと来るかもしれません。

ソフトウェア開発の標準化とかをやっているため「IPAのドキュメントにこう書いてあります!」って言うと根拠としては割と強めになります。

そのため、良いドキュメントが多いんですが、公式サイトでは新着順に分類されているため検索がしづらいんです。。(こんな感じ

 

なので、おすすめをピックアップしてみました。

 

おすすめドキュメント4選

① 家づくりで理解する要求明確化の勘どころ

家づくりで理解する要求明確化の勘どころ ~システム構築を成功させる要件定義のポイント~

 

マイホーム購入を例に要件定義のポイントをわかりやすく解説しています。

ソフトウェア開発初心者でもとっつきやすい内容になっています。

 

概要はこちら(引用)。

  • 初期要求(ニーズ)を明確にする
  • どのようなシステムを作るかの前にどのような業務にするかを検討する
  • 現行業務やシステムを把握し、To-Be の変化を明確にする
  • ステークホルダを洗い出す
  • ステークホルダ要求を明確にする
  • 非機能要求など、その他の要求を明確にする
  • 要求を目的展開する ~要求の妥当性を検証~
  • 目的から手段を検討する ~要求の充分性を検証~
  • 要求の価値/効果を判断し、要求を絞り込む
  • 制約・前提条件を明確にする
  • 制約条件や前提条件を考慮した現実案を検討する
  • 要求の優先順位付けを行う
  • To-Be 業務での変化と価値をまとめる
  • ステークホルダと合意形成する
  • 要件(仕様)として定義する

 

② デジタル変革に向けたITモダナイゼーション企画のポイント集 

デジタル変革に向けたITモダナイゼーション企画のポイント集~注意すべき7つの落とし穴とその対策~

 

まずモダナイゼーションとは、、

企業の情報システムで稼働しているソフトウェアやハードウェアなどを、稼働中の資産を活かしながら最新の製品や設計で置き換えること。特に、稼働後数十年経っていることも珍しくないメインフレームを中心とする基幹システムを刷新することを意味する場合が多い。

「IT用語辞典」先生引用

 

既存システムを置き換えるような開発の要件定義で陥りやすいポイントをわかりやすく説明しています。

7つの落とし穴はこちら(引用)。

  1. 「再構築だから」と企画・要件定義フェーズを軽視していませんか?
  2. 「今と同じ」という要件定義になっていませんか?
  3. 現行システムの調査が「表面的」になっていませんか?
  4. 業務部門はメンバの一員として上流工程から参加していますか?
  5. 現行システムが動いているから、品質保証を簡単に考えていませんか?  
  6. 担保すべき「業務継続性」は明確になっていますか?
  7. モダナイゼーションのリスクを甘く見ていませんか?

 

③ 非機能要求グレード

非機能要求グレード

 

非機能要件に記載すべき内容がまとまっています。

非機能要件は、

  • 「可用性」
  • 「性能・拡張性」
  • 「運用・保守性」
  • 「移行性」
  • 「セキュリティ」
  • 「システム環境・エコロジー

の6つの大項目に分類されますが、「06_活用シート.xls」で詳細な項目が一覧化されているため、チェックリストとして使用するのがおすすめ。

 

④ 超上流から攻めるIT化の事例集

超上流から攻めるIT化の事例集:要件定義

 

作成すべきドキュメントのサンプル集になります。

実際にどのようなドキュメントを作成すればよいのかはここを参照すればOK!

もちろん全て作成するのではなく、開発によって作成すべきドキュメントの精査は必要です。

(全部作ったらめっちゃ多くなる。。)

 

さいごに

もともとある観点やフレームワークを使うことで作業効率や精度が上がるので、こういったものはどんどん取り入れていくべきです。

但し、実際のプロジェクトでは思った通りに行かないことも多いので、そこはエンジニアの腕の見せどころ!笑

 

ではでは。

 

職場PCに何もインストールできないので Outlook でタスク管理してみた

客先常駐で作業するお仕事のため、自分の好きなソフトを入れられない環境で働くことが多いです。

普段プライベートでは Google Keep や カレンダーでタスク管理をしているんですが、職場ではもちろんそんなものは使えません。

そのため、Windowsにデフォルトで入っているソフトウェアでなんとかする必要があります。

今の現場ではメーラーOutlook を指定されていることもあり、Outlookでタスク管理もしてしまおうと思い立ちました。

今回は自分がやっているOutlookでのタスク管理方法をご紹介します。

 

※もちろん職場の情報はブログには載せられないので、画面の情報はダミー(個人PCのもの)です。

 

環境

概要

Outlookの仕事(タスク)機能を使用します。

「分類」機能を使用して、

  • 優先度:高(今日のTask)
  • 優先度:中(できれば今日やりたいTask)
  • 優先度:低(今日やる必要のないTask)

に分類・一覧化して管理します。

ルールとしては、

  • 優先度高(今日のTask)が終われば本日の業務終了。定時に帰ってOK。
  • 優先度高が終わった時点で時間が余れば優先度中(できれば今日やりたいTask)をやる。

としています。

優先度高には本当に今日終わらせなければならないTaskだけを入れるのが残業&ストレスを溜めないコツです。

 

タスクの設定方法

「分類」を設定する(初回のみ)
  1.  [分類](※下図の赤枠部分) > [すべての分類項目] から「色分類項目」画面を表示。
  2. 任意の色2つの名前を「今日のTask」「できれば今日やりたいTask」に変更します。

優先度低の分類は作成しません。

全てのタスクにいちいち分類をつけるのは手間なので、何も分類が付いていない=優先度低というルールにしています。

f:id:cask-st:20180611104451p:plain

 

タスク作成
  1. [新規作成]ボタンから新しいタスクを作ります。
  2. 件名、期限等を入力します。
  3. 分類ボタンから先程作成した分類を割り当てます。(優先度低の場合は割り当てない)

ここで、詳細欄に色々とメモ書きできるのが個人的には結構好き。

ファイルやメールをドラッグ&ドロップして挿入する事もできます。

f:id:cask-st:20180611105031p:plain

 

そうすると、Outlook一画面でメールとタスクのチェックが一度に行えます。

こんな感じ。(右下の部分がタスク)

f:id:cask-st:20180611105306p:plain

 

メール画面のタスクの並び順(初回のみ)

メールの横(画面右下)に表示するタスクはラベルごとに表示させるようにしています。

まず「分類項目」順に並び替えるには、

  1. タスクの「並び替え」カラムをクリックして、「分類項目」を選択。

次に「分類項目」ごとのグループで表示させるには、

  1. タスクのカラムを右クリックして、ユーザ設定を表示。
  2. [ビューのカスタマイズ]画面で[グループ化]を選択。
  3. [並び替え方法に従って自動的にグループ化する]にチェックを入れる。

 

仕事(タスク)画面のタスクの並び順(初回のみ)

仕事(タスク)画面では期限順で並ぶようにしています。

並び替え・グループ化の手順は、上記の「メール画面のタスクの並び順(初回のみ)」と同じです。

 

タスクの割り当て・確認ルール

仕事(タスク)画面とメール画面で並び順・グループ分けを変えているのは、以下のようにそれぞれの画面での役割分担しているためです。

  • 仕事(タスク)画面:作業前(朝)に、期限を意識して今日やるべきタスクを決定する。
  • メール画面:作業中に、やるべきタスクを確認する。

 

最後に

以前以下でも書かせてもらってますが、自分はもともとテキストエディタ好きです。

今の現場ではサクラエディタも入れさせてもらえず、、Windows標準のメモ帳ではUndo(元に戻す)が一回しかできなくて不便なのと、気軽にテキストファイルを残して置くことができないため、今回ご紹介させて頂いたような方法を考えました。(メーラーに残るのはグレー笑)

同じような環境の方の少しでも参考になればと思います。

 

 ではでは。

 

Android Studio で Github に Push しようしたら error:1407742E

メモ書き。

環境

Windows10 Pro (64bit)

Android Studio 3.1.2

 

手順

以下手順でAndroid Studio から GitHub へ Push。

メニュー > VCS > Git > Push

 

結果

以下エラーダイアログが表示されて、Pushに失敗する。

f:id:cask-st:20180518220610p:plain

Push Failed
Failed with error: unable to access 'https://github.com/moncheyball/ClipEdit.git/': error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

 

解決方法

f:id:cask-st:20180518221329p:plain

メニュー > File > Settings にて Settings画面を表示。

Version Control > Git の "Path to Git executable:" を

C:\Program Files (x86)\Git\cmd\git.exe

から

C:\Program Files\Git\cmd\git.exe

に書き換える。

※もちろん環境によってパスは違う可能性あり。

 

README.md をプレビューしながら作成する

README.md を作成するには GitHub Preview  が便利。

左側に入力すると右側にプレビューが表示されます。

f:id:cask-st:20180518055635p:plain

 

自分のスタンスを取る時は名詞ではなく動詞で定義すべき

資本主義の世の中では自分のスタンスを明確にした方が戦いやすいとよく言われています。

このスタンスを取る際に「名詞ではなく動詞で定義すべき」というお話です。

 

具体的にどうゆうことかというと、

システムエンジニアの○○です」→「アプリ開発で生計を立てている○○です」

「キーボーディストの○○です」→「バンドでキーボードを弾いている○○です」

などなど。

 

なぜ名詞ではなく動詞の方が良いかと言うと、流動的だから

 

名詞で定義すると周りから「この人は、システムエンジニアやキーボーディストであって、他のことはやらない」という認識になりやすい。

そこを動詞で定義すると「今はこれをやっているけど、別の事をやる可能性もあるな」という認識になりやすくなります。

 

周りからの認識を流動的にする事で自分が流動的に動けるような環境を作ることができます。

 

固定化した方がスタンスを強く取れるため、近代(昭和や平成初期)のような比較的時代の流れが緩やかな時代では、名詞で定義した方が有利でした。

(だから年配の方は人が何をやっているのか、何者であるのかを固定化したがるのだと思っています。)

しかし、これからの変化の激しい時代では、自分のスタンスも流動的にすべきです。そのための環境づくりとしての動詞での定義となります。

 

 

・・・という、以下の動画及び書籍を見ての考察の一つとなります。

 


 

 

日本再興戦略 (NewsPicks Book)

日本再興戦略 (NewsPicks Book)

 

 

以上です。

「アシックス史上最高のテニスシューズ」COURT FF を買い替えました

上の記事を書かせてもらった時に購入したのが 2017年7月。

約10ヶ月経ちましたが、アウトソールがすり減ってオムニで滑りやすくなってきてしまったのでそろそろ買い替えを検討。 

 

 

で、買い替えたシューズですが、、

 

 

 

 

COURT FF の色違いです笑

 

やはりこの「モノソック構造」のフィット感は素晴らしく、今まで履いたどの靴よりも動きやすい!

というのが決め手になりました。

足が命のプレースタイルなので、本当に良い!

これから試合が多くなるシーズンなのでバシバシ使い倒していきたいと思います!

 

 

そういえばこんなモデルも出ててかっこいいなぁとも思ったんですが、

合いそうなウェアを持っていなかったため断念。。

 (黄色系のウェアが多いので。。)