ら」といった理由で記載されないこともある。 しかし日本語での微細な表現変更でも、内容によっては動作に影響を与える修正が必要になる場合もある。 というより、開発側がその判断をする必要がある。 だから古いVersionと新Versionの仕様書差分を毎回確認す…

開発を進める中で仕様変更は結構入る。それ自体は仕方がない。ある程度予想するしかない。 そしてVersionが上がった仕様書が発行される。仕様変更が入った部分を確認する作業が発生する。 もちろん変更履歴欄に変更箇所が明記されてはいる。しかし記載漏れが…

´Д｀)< Markdownで思ったんだけど、仕様書の発行もtext形式の方がありがたいと自分は思う。今まで行った開発現場はどれもPDFでの発行だった。 PDFの何が問題かというと、簡単に差分が取れないところだ。 — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

´Д｀)< 日本の場合、どこの現場でも大抵エクセルで資料を作成し、最終的には納品物の一部としてそれを納品する流れになる。 Wikiサーバーを立てることはできても、納品の時に困ることになるんだよね。 — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

´Д｀)< Wikiをどんな感じに使っているか、までは記載がないが、markdownなりmarkup形式でドキュメントを作っていっているのだろうか。 正直羨ましい。日本のようにエクセルシートでドキュメントを作らなくてもいいということが。 — Takoyaki _umaaaaaa (@Tak…

´Д｀)< SharePoint上のWikiを使っているということ、そしてTeam ServiceにもWiki likeなmarkdownがあるからすぐに始められるよ、とコメントされている。 — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

´Д｀)< そして面白いと思ったのが、ドキュメントの管理方法について。 「MSはドキュメントもGitで管理していますか？」という質問に対して、 「ほとんどの文書をSharePointで管理しています」という回答だった。 — Takoyaki _umaaaaaa (@TakoyakiU) February…

´Д｀)< どうやら今のところ、GVFSを使ったClientが使えるのはVSTSかTFSのみであるらしい。標準的なGitサーバーでは使えないということ。 — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

´Д｀)< そしてGVFSは今のところWindows用のものしかないが、Mac用も検討している。それはiOS向けとWindows向けで大量のソースコードを共有しているから、とのこと。 Office製品などについてだろうか。 — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

´Д｀)< 先日のGVFSについてMicrosoft Blogより、気になるエントリを見つけた。 記事にはGVFS作成の経緯などが記載されている。概要については以前ツイートした通り。 なんだけど、この記事にいくつか気になるコメントがある。 — Takoyaki _umaaaaaa (@Takoya…

Scaling Git (and some back story) https://t.co/UOINkY53qj — Takoyaki _umaaaaaa (@TakoyakiU) February 7, 2017

ログ解析手順書のようなもの。それがあれば新しい人が入ってきたときにその資料を元に解析ができる。緊急事態が発生したときに別チームの誰かに解析を依頼することができるかもしれない。 あとCore解析の準備方法と解析方法についても。開発フェーズ終盤にな…

´Д｀)< 具体的には下記のポートを閉じればいい（SMBの利用ポートを変更していなければ） ・TCP ports 139 and 445 ・UDP ports 137 and 138 — Takoyaki _umaaaaaa (@TakoyakiU) February 6, 2017

´Д｀)< SMBにメモリ破壊を引き起こす脆弱性があるらしい。タイトルにはWindows Server issueとあるが、Client OSでも発生するとのこと。 まだパッチがないので記事ではSMB connectionしない設定にするように推奨している（MS見解ではない） — Takoyaki _umaa…

Microsoft fails to patch serious Windows Server issue, exploit now available on GitHub - https://t.co/mm2fyYfQo4 — Takoyaki _umaaaaaa (@TakoyakiU) February 6, 2017

ことをすると、スケジュールは遅れる一方になってしまう。 だから設計上の疑問点は口頭確認で進めて、エビデンスが必要になりそうな箇所は最低限メール送付という形で残すようにする。 もちろんそのメール（送信でも受信でも）はコピーして取っておくように…

付きでね。そうすれば担当者のメーラーから該当のメールを探すこともできるから。 — Takoyaki _umaaaaaa (@TakoyakiU) February 6, 2017

だけど設計書を書く時間がもったいないのでお互いの認識にズレが出ない程度の記載内容の設計書でいいよ」という意味。 そこを間違えると本当に大変なことになるので要注意。 何も考えずにいきなり実装し始めるとどこかに考慮漏れが出る。炎上しているプロジ…

´Д｀)< 「設計書を書く」ことと「設計する」ことは違う。どちらも必要。そのことを間違えてはいけない。 プロジェクトが炎上したとき、納品先の担当者から「時間がないから設計書は適当でいいよ」と言われることがあると思う。 これは「設計しなくてもいい」…

´Д｀)< このことに気付くには結構な時間がかかった。何年もね。そしてこれは設計書を書く上での、本当に最下層な基本事項。 だから「設計書の書き方」という記事を書こうとしたときにその「最下層の事項」から書き始めると記事内容があまりにも膨大になりす…

内容が自ずと決まる。それまでのように項目の文章だけを読んで、項目を消化するように埋めていくようでは本当に必要な内容を記載することができない。 — Takoyaki _umaaaaaa (@TakoyakiU) February 6, 2017

計するために必要な項目は網羅されているとは限らない。 機能によって調査箇所も異なる。調査方法も異なる。まとめ方・見せ方も異なる。 それぞれの項目について「設計書になぜその項目が必要なのか」を考えられていなかった。そこが一番大きな問題だと思う…

の箇所で指摘を受ける。その数が一向に減らない事態に陥っていたから。 結局何が問題だったのかというと、設計書を作成する上で 「設計書テンプレートに記載されている項目を埋めていく」 という作り方をしていたのが問題。 テンプレートには設計書として必…

´Д｀)< 自分は基礎的なところで今までに結構な数、指摘を受けている。 他の人達と比べたことがないので、それが多いかどうかはわからないが、少なくはない。 当初は指摘を受けた内容について個別に修正していたが、途中から「何かが違う」と感じ始めた。 指…

；´Д｀)< そういえば以前資料作成の基本について記事を書こうかと思って途中で断念していたことを思い出した。 書きたい項目を列挙しただけでかなりの数に上ってしまい、記事化するだけのモチベーションを保てなかったためだ。 — Takoyaki _umaaaaaa (@Takoy…

について合意した上での組み込みになる。 仮に設計漏れによって問題が発覚したとしても、問題の内何割かは責任を被ってもらえる。この差はとんでもなく大きい。 もちろん設計漏れなんて起こさないように作る必要はあるけどね。 そして納品先担当者もそういう…

厳しい指摘をしてくる。ちゃんと内容について確認をしている。 結局は自分のためにやるものなのでレビューを嫌わず、めんどくさがらず、しっかり準備して臨んでほしい。 — Takoyaki _umaaaaaa (@TakoyakiU) February 6, 2017

問題なさそうならチームリーダーに目を通してもらう。それからレビューという形にすればいい。 もちろん一度目を通してもらったからといってレビューの場で指摘が出ないとは限らない。事前確認とレビューとでは見る観点も詳細度も異なるから。だからそこで不…

ぎる。 だからそれぞれの項目について、どこに注目して何を書いたのか要点を説明して進めれば良い。 もしそれでも「文章について細かい指摘を受けることが多い」という場合は、レビューする前に事前に誰かに見てもらうようにするべきだと思う。 同僚に頼んで…

は「見落としがちな部分をケアしているか」「以前と同じ間違いを繰り返していないか」「こちらが注目している箇所にも注目してくれているか」とかかな。 場面にもよるとは思うけど、書いてある文章について全て読んでいると時間がかかりすぎる。参加している…