「“変化の拒絶”か“過剰な進化か”——求められるトレードオフ ソフトウェアが進化し続けるために必要なこと」を読んで

[KATO-Hiro]

要約

• 困難な挑戦をみんなで乗り越えることで一体感が生まれる・技術革新を起こす
  • 例: Ruby3.0をRuby2.0よりも3倍高速に
  • ビジョンを示すことの重要性 + 周囲の協力
• 停滞したOSSは廃れる
  • ソフトウェアは老化する
  • 周囲の環境の変化に追随できなくなると段々と魅力がなくなる
  • ユーザ離れ
  • コミュニティが縮小
  • 魅力がなくなる
  • 上記のループ
  • プロダクトが生き延びて進化し続けるためには継続的な進歩が必要
  • トレードオフ
    • 変化しないと魅力がなくなるが、過剰に進化すると巨大化しすぎて発展できなくなる
  • 筆者が好きなのは「水道モデル」
    • 基本的な部分は変えずに(安定した基本機能)
    • 変化が必要な部分は大胆に変化
• リーダーシップ
  • 手を動かすだけでなく、チームの方向性を決める必要がある
  • ビジョンを示して、ベクトルを揃える必要がある
  • 解決すべき課題を正しく把握し、適切な解決策を模索し、トレードオフを検討して、納得可能な解決方法を提示する
  • プロダクトの仕様・未来を高い視座を持って考えないといけない
  • 何をするものか?
  • どう変化すべきか?
  • チームの不要な対立で生産性を低下させないように
• 筆者がOSSで管理がそれほど重要ではないと考えているもの
  • スケジュール (毎年日にちが決まっている)
  • 予算
  • プロジェクト管理
• ビジョンとリーダーシップがプロダクトを作る
  • どんなソフトウェアを作るか?
  • どんな問題を解決するかを具体的に、説得力のある形で提示し続ける
  • 良いプロダクトを作ることで世界を変える、世界を良いものにする

感想

• AtCoder Clansも徐々に・確実に廃れている、という自覚はある
  • 情報量が多すぎて、どこから見て良いかわからない
  • 掲載している内容が古くなっていくので、定期的に更新が必要
  • 1つ追加したら、3〜5つをarchivesに送るくらいの気持ちで
  • 利用者の少ないページは思い切って廃止するのも一つの手
  • そもそも需要が以前ほどないのではないかと思っている→サービス廃止も検討
• 有志のチームで開発する話が始まったが、方向性を確認・自分からも提示できるようにしたい
  • 現時点ではひたすら基本機能を実装している段階

Keep

+

Problem

+

Try

• Clans: 重要なサービス・ツールに限定して情報量を絞る & 利用者の少ない機能は思い切って削除
  • ブログ一覧

出典

https://logmi.jp/tech/articles/329325