現場で活かそう！みんなのシステム開発体験談・お役立ち情報の記事まとめ

開発現場は実に千態万様で、開発手法やプロジェクトの推進方法など、多様な成功例・失敗談があるかと思います。初めてプロジェクト推進を任される、新しい開発手法に挑戦するといった場合、「開発するうえで気をつけるべき点や、プロジェクト推進中に直面した課題などを知りたい」と思われるのではないでしょうか。
本記事では、開発業務の体験談やお役立ち情報について綴られている記事を紹介します。今後の開発現場に活かせる内容となっていますので、興味がある方はぜひ一読してみてはいかがでしょうか？

※尚、こちらはPR記事ではございません。編集部が独自にテーマを選び、サイト担当者に許可を頂いて作成している記事です。また、記載中の内容は、執筆時の情報になります。

スクラムマスターがいるチームで学んだスクラム開発のこと（パンダのプログラミングブログ）

開発には、ウォーターフォール、アジャイル、スパイラル、DevOpsなど、さまざまな手法がありますね。どの開発手法を経験するかは、開発内容や所属しているチーム次第なので、人によって異なるでしょう。
そんな中、プログラミングをするパンダさんは、スクラムマスターがいるスクラムチームで開発を経験した時のことをブログに綴っています。
《@Panda_Program》の『スクラムマスターがいるチームで学んだスクラム開発のこと』という記事によると、プログラミングをするパンダさんはこれまで、アジャイルに詳しいテックリードと同じチームでの開発、スクラムマスターではないけれどスクラムに詳しい先輩エンジニアとの開発経験があるのだそうです。
そのような経験から、Do AgileではなくBe Agileな開発ができていた実感があるそうですが、その後スクラムマスターがいるスクラムチームで開発した時に「スクラムというフレームワークの有用性」を感じたと語っています。

スクラムマスターは、「スクラムの原則」と「目の前の現象をスクラムの原則から捉え直す」ことを徹底していたそうです。
例えば、デイリースクラムの15分について、スタート時は必要性に疑問を持つ声がメンバーから挙がったそうですが、後に開発が進むと時間が足りないという意見に変化したそうです。それでも、スクラムマスターはスクラムの原則から変更しなかったのだとか。
その後スクラムマスターの提案で「デイリーは15分で終え、その後15分を議論や雑談の時間に使おう」となり、その形に落ち着いたそうです。
プログラミングをするパンダさんは、この経験から「プラクティスを徹底することへの理解が深まった」と語っています。

プログラミングをするパンダさんは、スクラムマスターから「このチームは不確実性の高いところから自発的に手をつけていっているので、普通だったら1ヶ月先になってやっと明るみに出るような新しい課題が前倒しで認識できているので安心感がある。」という言葉をかけられて嬉しかったそうです。SNSのポストへの反響が大きかったことで、この記事を書くことにしたと語っています。
スクラム開発の経験者はもちろん、関心を持っている方にも読み応えのある内容なので、ぜひサイトを訪れて記事を読んでみてください。

■スクラムマスターがいるチームで学んだスクラム開発のこと
https://panda-program.com/posts/scrum-team-development-and-scrum-master

優れたアジャイルチームは壁を越えてコラボレーションする！(株式会社ラジコード)

アジャイル開発は、システムやソフトウェア開発におけるプロジェクト開発手法の一つです。素早い開発を行える手法として認知度が高いので、経験したことがある方も多いでしょう。
そこで、今回は株式会社ラジコードが運営するブログの《優れたアジャイルチームは壁を越えてコラボレーションする！》という記事に注目してみました。こちらの記事では、アジャイル開発の特徴やメリットなどを紹介しています。
記事によると、アジャイル型の開発では、機能ごとに工程を細かく区切り、それぞれの工程を繰り返して完了させる特徴があるのだそう。一方で、ウォーターフォール型の開発は、プロジェクトのスタート時に決めた要件に基づいて段階的にプロダクトを開発していくという違いがあるそうです。
また、優秀なアジャイルチームを作るためには、主語の認識合わせも重要とのこと。「私」ではなく「私たち」で合わせることで、結束したチームを形成し、開発を進められるそうです。また、アジャイルチームの成長には個人の成長よりも時間がかかるため「タックマンモデル」を参考にした成長モデルを理解することが重要だと語っています。タックマンモデルについての記事もあるので、気になる方はぜひサイトを訪問してみてください。

アジャイル開発では、開発、販売、運用の3つのフェーズに専門家が協力し、迅速にプロジェクトを推進します。チームは常に状況を把握し、顧客ニーズに合わせて製品を改善して成長させることで、ユーザーに価値の高いプロダクトを提供できると記事に記述されています。
同社では、定額制受託開発でアジャイル開発を採用していることもあり、記事は非常に説得力のある内容です。
ほかにも、IT業界・新規事業開発関連について書かれた記事がたくさんありますので、興味がある方はぜひ一度サイトをご覧ください。

■優れたアジャイルチームは壁を越えてコラボレーションする！
https://blog.radicode.co.jp/development/2834
コーポレートサイト
https://radicode.co.jp/

システム開発のしくじり経験から学ぶ、ユーザ側と開発側の埋められない溝とは何か？（株式会社すまいる顔）

皆さんはこれまでの開発経験で、開発側とユーザー側で見ている視点の違いを意識したことはありますか？
開発過程では、「ユーザーの了解をとり仕様を確定させたい開発側」と「巻き込まれたくないユーザー側」の構図が生まれやすいのだそうです。
そこで今回、株式会社すまいる顔が運営するブログの『システム開発のしくじり経験から学ぶ、ユーザ側と開発側の埋められない溝とは何か？』という記事に注目。これから経験するかも…という方も参考になる内容です。

こちらの記事では、株式会社すまいる顔がシステム開発に携わったユーザー企業の方へ、インタビューをした内容を紹介しています。
インタビューを受けた金融系企業に勤務しているIさんは、入社3年目の若手社員の時に、社内システムの新規開発プロジェクトのリーダーを経験したのだとか。Iさんはこの経験の中で、「目の前のことでいっぱいな若手社員より、業務経験がある人や会社全体の課題と捉えて動ける人が主導となったほうがいい」と感じたそうです。コストや課題解決の視点からも、会社全体の課題と捉えてやらなければ迷走すると語っています。

一方で筆者は、開発担当者としての立場とユーザ側の立場両方を経験。仕様を確定したい開発サイドと巻き込まれたくないユーザーサイドの構図はどんな開発プロジェクトにおいても見られると語っています。
それも踏まえ、Iさんは筆者の「なぜユーザー側と開発側に溝が生じてしまうのでしょうか？」という質問に下記のように回答しています。

・ユーザ側はシステム開発に協力することが仕事の一部として認識していない
・関わっても評価される仕組みがない

上記の課題は、ユーザ側にとって協力するメリットが何かを明確にすることで、解決できるかもしれないと語っています。
そのほか、「システム外注の落とし穴」や「業務をシステムに合わせる」ことについても記事内で言及。業務管理をサポートするサービスを提供している同社ならではの目線から、パッケージシステムの導入についても触れています。
開発側とユーザー側に起こる評価の違いに関心がある、違う視点から開発を考えてみたい…など、興味がある方はぜひご一読ください。

■システム開発のしくじり経験から学ぶ、ユーザ側と開発側の埋められない溝とは何か？
https://smilekao.com/news/5160
トップページ
https://smilekao.com/