Rubyが好きなプログラマーの日記。日々の生活、開発に関するメモとか考えとか。
読み終わってたのに記録してなかったので、忘れないうちに書き残しておく。
<iframe style="width:120px;height:240px;" marginwidth="0" marginheight="0" scrolling="no" frameborder="0" src="//rcm-fe.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=satoryudiary-22&o=9&p=8&l=as4&m=amazon&f=ifr&ref=as_ss_li_til&asins=4798024716&linkId=b9c81ff2243f42fb2e7b4c2eae68a9a4"></iframe>本のタイトルの通り、管理会計の基本について丁寧に解説されていた。財務会計と管理会計との違いや管理会計の際のキャッシュ・フローの算出方法の基本的な考え方は、そういった勉強を一切してこなかった自分でもとてもわかりやすいと思った。
読んで思うのは、こういうことをビジネスに関わる人達全員が理解しておくと、色々動き方が変わってくるんじゃないかと思った。単に、予算があるのでその予算内であれこれやる、と開発側が考えてしまうのは危ない。それよりも、予算内に収めるは当然として、ランニングコストや販管費がどれくらいで、いつからキャッシュが生まれそうなのか、そのためには何をいまのうちに機能として積むか、リリース前
のコストをどこまで抑えるべきなのか、といったことを開発側も考えながらヒトやモノに投資しないといけないんだと思う。
今調べたら第2版が出ていて、そちらでは「業務改善の効果」という章が加筆されているそうだ。
作ったソフトウェアのコードに、リリース後に変更が入らないなんてことは、まずありえないだろう。自分の経験上、運用なんかで1回限りの実行しか無いものでも、それをベースにして作り変えたりしなが再利用することがあったり、書いたコードの寿命が意外と長かったりする。せっかくなら、変更が起きるなら変更が起きやすいようにコードを書きたい。
そんなことを今年の始めに考えていた時に、この本をいただいた。
まさに変化に対応するためのコード設計について書かれていた。
前半は、変化が生まれるのはなぜか、そのためのチームのプロセスとしてScrumが紹介されている。チームとして柔軟に対応できるためには、コードベースもそれに合わせて柔軟でなければならない、というコンテキスト。
その方法として、SOLID原則に基づいて設計することが大切と書いている。各原則の紹介を、C#で書かれたサンプルコードも掲載されているので、とても読みやすかった。自分はC# はほんの少ししか書いたことが無いのだけれど、公式のドキュメントを片手に読めた*1。個人的には、終盤になると、UnityやASP.NETなど、ある程度はC#をベースとした開発経験があると、なお読みやすそうに感じた。
この本を頂いたのが出版直前くらいだったので、およそ6ヶ月ほどかかった…
一応、スクラムでの開発経験があったので前半はサクサクと読めたのだけれど、後半のSOLID原則が長かった。読んでみて、デザインパターンやオブジェクト指向について、ある程度は学んでいることを前提にしているようなので、再度勉強してから読み返したい。