ソフトウェア開発、ITインフラ運用、そしてその境界線上にあるトピックをカバーし、特にDevOpsを実現するための自動化、テスト、セキュリティ、組織文化にフォーカスした「DevOpsDays」。ここでウイングアーク１ｓｔ株式会社の高橋氏、荒川氏、内藤氏が登壇。まずは文化的負債についてと、3つの事例を紹介します。全3回。 セッションの内容 高橋裕之氏（以下、高橋）：「文化的負債との戦い」ということで、「老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間」について発表します。よろしくお願いします。 本日お伝えすることとして、我々は老舗ソフトウェアとしての歴史がそこそこあるのですが、そこで溜まっていた文化的負債の利息を解消すべく、ソフトウェアプロセス改善というアプローチを取ってきました。 とはいっても、CMMIやPMBOK、SAFeなどの大きな何かを導入した苦労の話ではなくて、現場で起きてい

業務プロセスとは、各組織におけるさまざまなタスクの進め方や流れを指します。 例えば、営業活動というタスクを分解すると、リード（見込み顧客）の獲得や初回のコンタクト、案件化後の商談設定、成約後の手続きなど、さらに細かなタスクに分解されます。これらタスク同士をスムーズにつなぐことがビジネス推進の原動力となる、という考え方もあります。 この記事では「業務プロセスの改善」に着目し、その目的や具体的な進め方なども含め解説します。 業務プロセスの改善とは？BPRとの違いとあわせて解説 業務プロセスの改善とは、業務間のつながりや各作業の流れを整理して、より効率化することを指します。現状の業務プロセスでビジネスが問題なく進行していれば良いのですが、残念ながらすべての組織がそのような健全な状態であるわけではなく、何らかの問題を抱えていることが多いようです。 なお、業務プロセスの改善と近しいものに「BPR（ビ

業務プロセスは本来、企業の事業目標達成のためのもっとも効率的な手順や工程が提示されているべきです。また、一度完成すれば終わりではなく、時代の流れや新たな課題に応じて定期的に見直していく必要があります。 働き方改革の推進やパンデミックによるテレワークの増加で、企業における業務プロセスの見直しが急務となっています。しかし、業務改善のために業務プロセスやフローを可視化すると言っても、具体的に何から着手すればいいのか悩む人も多いのではないでしょうか。そこで、業務プロセスの可視化から効率的な改善方法、自社に合ったKPIの設定まで、詳しく解説します。 業務プロセス可視化の考え方 業務プロセスの可視化とは、企業のなかでどの業務がどのようなプロセスで実行されているのか、一連の流れを目に見えるようにすることです。 特定の業務に関して、担当者しか手順を把握していなかったり、なんとなく業務の流れがあっても、最新

1.概要 ソフトウェア開発を改善する上で、プロセスの改善は最も基本となる活動だと思っております。今回はそのプロセス改善の基本となる考え方や、進め方を記載したいと思います。 2.なぜプロセスを改善するのか 改善活動は大きく2つの活動に分かれると思っております。 プロセス改善（手順書を作る、運用フローを作る、ドキュメントフォーマットを作るなど） プロダクト改善（新しいフレームワークを導入する、技術者に勉強会に参加してもらうなど） このうち基本となるのがプロセスです。なぜプロセス改善が大事かというと、改善することで以下のような効果があるからです。 一度作れば何度でも使える 誰か一人ではなく複数人に効果があるので、費用対効果が高い フォーマットがあればすぐに導入可能（即日実施可能） そのため、コンサルタントが改善を行う場合、目に見えて効果が表れやすい「プロセス」から改善していくことが多いです。 た

ソフトウェア開発をしているとデバッグは必須の作業です。とはいうもののデバッグ作業に苦しみたくはないはずです。 テスト駆動開発をしていないプロジェクトで、しかも単体テストを重視していないプロジェクトの場合、モグラたたき開発になっている可能性があります。 モグラたたき開発は、きちんとした自動化した単体テストを積み重ねていくのではなく、そのつど、気になった不具合を、気になった順番に解決しようとするアプローチです。 プロジェクト・マネジャーが知るべき97のこと　モグラたたき開発を避けよう モグラたたき開発の特徴 ソフトウェアの世代が変わったときに、一度は枯れたバグが復活している バグを再発させない仕組みをソフトウェア開発の中に入れていないので、一度は枯れたはずのバグが次のバージョンのソフトウェアで復活してしまっている。 実装の仕様がふらふらしている 何をどう実装すべきか、じゅうぶん明確化できていな

こんにちはmatinanaです。 融資型クラウドファウンディングのサービス開発を行っています。 今日は、来年3人目のエンジニア1をチームに迎えるにあたり準備しているドキュメントの話をします！ この記事はCAMPFIRE Advent Calendar 2021の13日目の記事です。 本記事の目的 この記事では、小さな開発チームである自分たちが用意している（or 用意しようと思っている）開発関連のドキュメントを共有することで、 同じような他の小さなチームの方にとって 明日から開発チームに入るドキドキのエンジニアにとって 「こういう情報があれば・分かれば」不安なく開発進められそうだな！という指針の一つになればと思っています😊 また、ドキュメントを準備している自分たちにとっても、「なんでこのドキュメントって必要なんだっけ？」という問いへの整理の意味も込めています。 目次 1. オンボーディング

営業一課で使っている PHPアプリを保守してくれないかな？ ○○さんが１人で作ってメンテしてたやつなんだけど 皆さんは上司からこんな仕事を振られたことはないでしょうか？私は過去に何度か経験した1のですが、こういった仕事はなぜか： 正確な仕様を知っている人はいない（知ってた人は辞めた） テスト計画書・デプロイ手順書・仕様書といったドキュメントは無い ソースコードはもちろんスパゲッティ でも、業務ではガッツリ使われているので廃止できない というレガシープロジェクトばかりでした。この記事では、レガシープロジェクトを引き継いでしまった時に、最初に何をするべきか書いていきたいと思います。 なお、ここで最悪なのは「とりあえず、緊急の不具合から直してしまおう」と、いきなりコードの修正にかかることです。 ※おことわり： この記事では「遵法的な職場の」「PHPやRailsで書かれた」「社員25人が使う」「業