大前提、過去の積み重ねからできていることから革命は然るべき時に

EXCELはどこまでもEXCEL、設計書に使うな

シートを数珠繋ぎにして得られる利点が無ければ、細かく別ファイル保存にしたほうがマシ。
シートを横に探す時間無駄になってるぞ
ファイルサーバーの共有箇所にはFixしたもの以外置くな。もしくは作業用フォルダ作れ
誰でも弄れる設計書をファイルサーバーで管理する程度の民度の良さやよし。でもシステムエンジニアたるもの怠惰であれ。
打ち消し線で訂正とか赤字にするとかしなくても差分を管理できる仕組みがあるんですよ。

一つのクラスにまとめたら、後の実装者が助かると思うな

シングルトンでもないマネージャークラスに全部詰め込んで、共通化ぶるのは悪性腫瘍みたいなもの。
例えばAPIManager#GetHoge1、GetHoge2 を生やせば生やすほどドメインへの理解の薄さと、コミット履歴ファイル履歴が炎上することは明らか。
HogeAPIService, FugaAPIService など最低限自明な名前を付けてほしい

例えば、APIを管理するクラスであれば接続先ごとにシングルトンを管理することで責務を理解できる。
本質的な共通化図るので有れば、インターフェースとラッパーで済むはず。
APIのリクエストなどをモデルにする時は、フレームワークや上記シングルトン以降の部分を共通化するな。
項目名と中身が一致してる程度で共通化できると思うな。
実装のためのインターフェースを定義するな。

Androidにおいて

常に使える設計理論

基本中の基本
Android が必要な部分と Android を切ることができる部分を分ける
view だけ切り離すところから入門したら良いと思う

markdownなら目標をA1に入れてスイッチが無くなる

デザインできないじゃんと言われるが、むしろHTMLとの親和性が高くて最高にデザインし放題ですけど(俺はやらんけど)

テーブルかけないよね → そこはエクセル使え

シーケンス図、フローチャート とかにエクセル使うことで生産性も技術の成長も起きないし効率が非常に悪いよねって話なの

スプレッドシートでレスバするな、弊社

テストケースに「正しいこと」 とか抽象化極まったこと書くな

「正しい数値を入力する」とか言う記載のテストケースは誰が広めたんだ、レビュー通せ

電子カルテ情報共有は諸々鑑みて、やめといたほうが良い
職業倫理に期待するのはシステムの中で真っ先に排除すべき考え

テストについて

テストケースに書いてはいけない三銃士

テストケースに書いてはいけない三銃士を連れてきたよ
正常に表示されること
適切に入力されること
対応したファイルが読み込まれること

結合テストとユニットテストを区別できない現場は苦痛

固定されるようなロジックや環境に左右されないものはテストが必要

ユーティリティにも予期される動作をテストで表現する

同じような画面のテストケースが存在する場合、ドキュメントを複写したほうがよい→似たような画面ということは細かい差異があるため、並べることで、書く際にも実行する際にも問題を見極めやすいしコンテキストへの負担が減る

進捗率管理について ウォーターフォール

Excelに表で、日時に対する進捗率を入れる作業が不毛
なぜなのか
戻って編集できたりするよね。あと確認と管理が大変。そもそもExcel使うな問題はある。

タスク分割が適切でないままやらすな
何が問題か
進捗率の数字に根拠が示せないです。

EXCEL設計書の改善点を問題から見極める

設計に対する複雑度が上がるほど保守コストが増える
起動が遅い
汎用性のなさ
再利用性の低さ
並列での処理ができない
標準でバージョン管理ができない
印刷や環境で見た目が変わってしまう
コメント、メモ機能が使いにくい
ヘッダー、フッターを見た目で作り込むしかない
付帯する情報を加えるほど保守コストが増える
A1をセンターに入れてクリック、A1をセンターに入れてクリック

WBSを朝会のタスク管理に使うのは間違っている
‐ そもそも、タスク管理に使えるほどの粒度になっているのか？
‐ 担当が変わるタイミングで分けるのではなく、タスクの意味で分けるべき
‐ 主張
‐ タスク管理に使えるほどの粒度であれば、朝会で全員揃えて個別に確認する時間は不要
‐
‐ だが、細かくすればするほど、かかる時間が多い。
‐ WBSベースで話をするのであれば、個人レベルでの確認報告をひとりひとり喋らすの無駄では？

モバイルアプリ高解像度対応Tips
End,Bottom　で要素を寄せないこと