はてなブックマーク

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 初めましてこんにちは。 最近コードレビューの記事書いたら、Excelベースだったことを理由に Qiitaコメントとはてブで徹底的に燃やされたおじさんです。 いやね、僕だって使いたくて使ってるわけではなくてね、 できることなら使いたくないんですよ。 というわけで名誉挽回のために脱Excelできた話、 それも日本の三大悪三大風習に数えられるExcel設計書を抹殺した話を書きます。 (2/25修正：悪は言いすぎました。訂正します。） Growi 最高。 Excel設計書 またの名をExcel方眼紙。 エクセルのセルの縦横を同じくらいの大きさに

はじめましてこんにちは。 みなさんの開発環境におけるテスト環境はどんな感じでしょうか？ TDDで実装し、UTおよびE2EがCIで回り、DXかくあるべしと鼻高々で、 そうでない環境は人権侵害であると思っている環境でしょうか？ それとも、こんなんじゃだめだよくないと思いつつ、 テストをプログラマまかせにしている環境でしょうか？ この記事は後者の環境で 現実に立ち向かい、現実を変えたいと思い、 しかし多くの課題を抱え立ちすくんでしまっている有志への応援歌です。 お前誰？ 某SIerで14年目が終わろうとしているエンジニア兼マネージャです。 僕の開発現場は、強力な営業力をもつ現会長が起こしたコンピュータ機器商社で、 20年くらい前から開発部門を自社内に作った、そういう環境です。 エンジニアリングに優れているか、技術的知見が豊富かどうかというよりも、 顧客営業力があるか、納期遵守力があるかどうかが評

レビューとは システム開発ではレビューはソースコードだけでなく、 要件定義、設計、ソースコード、試験計画、試験項目など、幅広く行われています。 レビューは品質を向上させるために行われるため、 文言の「てにをは」や、表記ゆれの指摘よりも、 システム利用者への不都合が起きる問題・リスクへの指摘のほうが価値が高いといえます。 では、どうすればレビュワーは価値の高い指摘ができるようになるでしょうか？ レビュー価値の向上のためにどうするか 成果物に対する深い知識・経験は必要です。 要件定義でいえば、システムが利用されるビジネスおよび利用者に対する 深い知識と経験がなければ、価値のある指摘は難しいでしょう。 しかし、年々システムは短納期化・複雑化し、人手不足はますます解決困難になり、 レビュワーの熟練を待てる状況にはありません。 手持ちの駒ですこしでもレビュー指摘価値を上げる方法 そんな状況下でレビュ

ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも

はじめに 昨年、自分たちの部署に3人の新卒エンジニアが入ることになりました。 そこで従来とは異なる「多頻度マルチフィードバック」と 内々で呼んでいる育成方法論を試したのですが、 とても良かったので、その実施結果を共有します。 なにをやったのか 従来の方法と比べて、 新人に対して圧倒的に多く回数のフィードバック を 複数人から返すようにしました。 具体的には、 15分ｘ週3回のミニ面談をリーダークラス6人で3人に対して実施 新人は週45分の拘束、リーダーは2週間で3人面談するので、週22.5分の拘束 30分ｘ週2回のミニ勉強会を部署13人で持ち回りで実施 新人は週60分の拘束、講師役は、1.5ヶ月に30分の拘束 という仕組みを組みました。 どうなったのか 幅広いスキルを、まんべんなく身につけられ、早期戦力化できました。 一方で、モチベーションを高く維持でき、 なのに育成に対する負担がむしろ軽

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR 諸般の都合1により、朝会の方法論を言語化する必要が出てきたため、 まず世の中の人が朝会について何を言っているのか調べてみたら、 どうやら流派みたいなものが存在する事がわかったよ。 これから朝会のスキルを身につけようとする人は、 どの流派が自分にあうか選んでみるといいよ。 参考にした投稿・サイト プロジェクトファシリテーション 実践編 朝会ガイド - オブラブ デイリースクラムの開催(朝会)時間 - Qiita スクラムの朝会で毎回意識する5つのこと - Qiita 朝会、夕会を価値あるものにするための観点と方法 - Qiit

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 最近、社内外の多くのプロジェクトマネジメント実態を調べる機会に恵まれた。 その中で、面白いことに気がついた。 問題に直面して、原因を分析しなければ、対策も取ろうとしないマネージャ達。 彼らはマネジメントしていない。ただ祈ってるだけ。 つまり、P"r"aying Manager じゃね？と。 ※Pray ・・・ 祈る Praying Managerの生態 [ケース1] 進捗をPGが自力で回復してくれることを祈る あるプロジェクトでは、3ヶ月の工期のうち、1ヶ月が経過したが、進捗が半月分しか出なかった。 つまりプロジェクトとしては

TL;DR 技術書とかの輪読会でなんども挫折したけど、 エクストリームリーディングだと挫折せず最後まで読めたし、深い理解が得られた。 エクストリームリーディングいいよエクストリームリーディング。 エクストリームリーディングって何？ http://d.hatena.ne.jp/umedamochio/20050114/p4 参照 日本語だと５ページ単位、英語なら２ページ単位くらいを全員が黙々と読みます。 単位が節ごとなど、本の著者が設定した単位であるほうが好ましいです。 読み始める前に、ここまで読みましょうと合意をとります。 読み終わった人は、「終わった」と宣言します。早く読み終わった人は、次を読んだり、自分なりに内容をまとめたりしておきます。 重要な文の切り出し 各人が重要だと思う文を切り出して、その意義を議論する。 まとめ 各節ごとの趣旨をまとめる。 前後関係や本全体の趣旨に対する位置づ

TL;DR 起きた失敗、炎上には名前を付けよう。 名前を付けることで似たような問題が見えやすくなる。 名前を付けることで問題に取り組みやすくなる。 名前を付けないと、見過ごされ対策されずに過ちを繰り返す。 「要望真に受けて無事死亡パターン」という名前の力 システム開発において、ユーザ要望を文字通り実装することは、 バッドノウハウであることは、読者諸賢は十二分にご存じかと思う。 しかし、これが意外と撲滅されない。 特に若手やリーダー1年目が良くやらかすから、組織としてごくありふれた失敗事例となる。 そんなある日、 「それってよくあるパターンで、名付けて”要望真に受けて無事死亡パターン”だよね。」 という話をしたら若手から、 「そういうあるあるパターンにキャッチーなネーミングを付けて普及させたら、 失敗も減るんじゃないですかね？」 という素晴らしい提案を受けた。 ジョシュアツリーの法則 これは

GMOペイメントゲートウェイ社（以下GMOPG）という、クレジット決済代行を取り扱う、 国内最大手の会社がクレジットカード番号を流出させたとして、 3/10以降大きく報道されました。 この事故から、我々エンジニアが学ぶべき事は何でしょうか？ 発生した事象について CVE-2017-5638とはなにか ファイルアップロードにおけるマルチーパートヘッダーの解釈部分に脆弱性があり、 リモートコード実行（RCE）が可能な状態であったらしい 本投稿の趣旨から外れるので、詳しくは調べていません。 経緯・経過 3/6 脆弱性情報が公開されたらしい (Cf. Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について ) 3/8 IPAが情報を掲載 (Cf. Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)