読者です 読者をやめる 読者になる 読者になる

今年もおつかれさまでした

今年もお仕事してました確認。来年もがんばるぞい

f:id:karahiyo:20151227142354p:plain

いつなにをやってたのかとかあまりはっきりとは覚えていないのですが、データベースまわりの運用を頑張ってた時期があったのは記憶にあります。お仕事ではScala, PHP, Gaucheなどを書いてました。AWSとはまたちょっと友達になれた気がします。趣味では、Gauche ちょっと Golang, Swiftなど。Ruby最近さわってないなぁ

!

今年仕事をしていて考えてたのが学生の頃に参加したインターンで学んだリーンスタートアップの話。

kotobank.jp

芸歴2年といくらか経験を積んだ今だとあのときのリーンの話はより訴えるものがあります。

"継続的な改善をする。で、必要な時に必要なことをする" (とざっくり解釈してます)

  • 優先順位の確認
    • まず何かしらの課題があること
    • その課題は本当に課題か。今本当に必要なものか。必要なら課題の確認という仕事も出てくる
  • その課題を解決できる機能をつくる
    • 意図が分かりやすいコード
      • そのコードが提供する機能はその課題の解決
        • そのコーダが提供する機能がシンプルならコードの説明のためのドキュメント、コミットメッセージは不要?
    • 認識している課題以外のことを意識しすぎていないか(ついつい色々目に付いてしまう。。
  • 継続的な改善のために
    • あまり将来のことは考えすぎないが、そのときになったらしやすいように
    • 意図がわかりやすいコードなら改善しやすい。意図がわかりやすいコードとは、、、。意図が分かりにくい、というのはまだ分かりやすい。プンプンにおう。
  • 必要な時を把握するために
    • 気づける仕組みを作る
      • test ... コードにバグがあったならそのエラーを再現をするテストを書いてからコードの改修をする、とか
      • 監視 ... コトが起きたときのアラート。コトが起きるとあれなのでその事前のアラート。アラートがあがっても何もしないのならその監視は不要そう
  • 普段意識する必要があることを減らす
    • リーンに働く(?) ... 例えば、「この案件の担当は?」「この機能で質問があるんだけど?」 -> その人しかできない仕事を作らない。であるなら人を選ばずチームに聞けばいい
    • リーンな運用(?) ... アラートがあがったら対応。監視設定の破棄とかの作業もアラート駆動(?)だとしっくりしそう

良いお年を 🙏

© karahiyo