Q&A
思わずクリップしてしまうほど参考になりそうな質問に対して横槍すみません。タグ「PHP」でいいんでしょうか？
自身の生産性の変化を記録したいと考えています。
プロとして自身の生産性を把握するのは重要な事だと思いますが、みなさんはどのような方法で、生産性を確認されているのでしょうか？
プロジェクト単位で管理する場合は、拘束時間が一つの基準となると思いますが、個人で見たときには、あまり適切な基準ではないと思います。
思いつきですが、例えば、以下のような基準があると思います。
・コミットしたコードの量
・記述したステップ数
・打鍵した数
マネジメントサイドからみた生産性ではなく、どちらかと言うと自己管理用のため、生産性を確認したいです。
どのような方法で、どういったものを確認するのが適切でしょうか？
また、その方法を確認するためのツール等があれば合わせてご紹介いただけると助かります。
いやぁ。多分ダメですね＾＾；良いのがあれば推して頂けると助かります。適切なのが思い浮かびませんでしたｗ
マネジメントがあればいいんですけど、なさそうですね・・・。開発とか設計とか・・・追加依頼します？。既存ではよさげなのが見当たらないですね。せっかく質問も回答も多くの人の参考になる内容なので埋もれないようにしたいところです。
微妙ですけど、タグ追加してみました。自己管理歴の長そうな人がいそうな言語追加ですｗ
ちなみに私もがっつり該当します(・＿・)ノ
ってことは、いい選択でしたかね？回答、お願いしますｗ
回答13件
0
私は、マーチン・ファウラーさんのあれで、生産性について考えないようにしました。
とはいえ、しいていうならコミットした回数（１回１チケット分）が一番近いかもです。
チケットによって重さが違うので、ゆれはありますが、タスクが終わったー！！でカウントするしかないかと思ってます。
そもそもプログラムって、問題解決のための手段ですよね。
コードの量で成果をはかるのでなく、課題・問題に対処した数で成果をはかるのが、しっくりくるかなぁ。
あまり回答になってませんが・・・
以下、リンク先の抜粋
生産性は計測できない
生産性とは、インプットとアウトプットで決定されるものです。 ソフトウェアの生産性を測るには、ソフトウェア開発のアウトプットを見なくてはいけません……が、そのアウトプットを計測できないからこそ、ソフトウェア開発の生産性が計測できないのです。
コード行数は短くなる
同じことをやるのにいくつものやり方があり、それによってコード行が変わってくることくらいご存知ですよね。しっかり設計され、きちんとリファクタリングされたコードほど、コード行は短くなるものです。
投稿2017/06/23 01:28
編集2017/06/23 01:53
総合スコア4820
リンク先確認しました。どちらかと言うと、マネジメントサイドから見た生産性に関する記事になるのでしょうか？
今回は、「俺サボってない？」「今日はちゃんと働けた？」「なんでこんなに進んだんだっけ？」みたいな事を振り返れるような、統計が取れたらイイと思って質問しました。
コミットした回数を指標にするのは、達成感ともリンクするので、良さそうですね＾＾
ありがとうございました。
0
マネジメント的な生産管理しかしていない中堅サラリーマンSEです。
諸兄姉の回答を拝見し、逆の視座・視点から回答をしたくなりました。
「逆」に立った回答になりますので、諸兄姉の回答を否定する部分がありますこと、ご容赦願います。
（投稿時、9件の回答をもってしてもte2jiさんの悩まれていることも回答をする動機であります。）
生産性を測るにあたって欠くべからざる情報は「定量的情報」です。
定量的の定量とは、「定まった方法で定めた対象に対する量を」を意味します。
これを満たせば、その情報はどんなものでも良く、また満たされなければ本来の意味を成し得ません。
諸兄姉の回答において下記の情報は生産性の評価にあたり意味がないという意見が多くありました。
・コミットしたコードの量
・記述したステップ数
・打鍵した数
これら情報には価値があります。この中のうちで、「記述したステップ量」は欠くべからざる情報です。
意味をなさないのは、「これら情報に他の情報を組み合わせる発想がないから」です。
生産性を求めるには情報を組み合わせる必要があります。
また、時勢（情報の採取した時刻）も大事な要素です。
■生産性の求め方
私なりの生産性の測り方を以下に示します。
●量的生産性（＝生産性の内の量的評価）
・記述したステップ数 ÷ 記述に要した時間数 ＝ 量的生産性
・作成したファイル数 ÷ 作成に要した時間数 ＝ 量的生産性 ※作成＝未作成時点～現時点
・作成したモジュール数 ÷ 作成に要した時間数 ＝ 量的生産性
・作成したソフトウェア数 ÷ 作成に要した時間数 ＝ 量的生産性
→作成した〇〇数÷作成に要した時間。つまり、物量÷時間ですね。
※スパゲッティコードであろうが全然OKです。量的生産性なので質の観点はここで評価しません。
※”マーティン・ファウラーさんのあれ”で生産性が測れないのは、評価基準をソフトウェア数にしたから。
※「技量が上がればステップ数は少なくなるから当てにならない」話は生産性ではなく成長度の話。
●質的生産性（＝生産性の内の質的評価）
・作成したソフトウェア数 ÷ 発生した障害数 ＝ 質的生産性（存続期間考慮なし）
・作成したモジュール数 ÷ 発生した障害数 ＝ 質的生産性（存続期間考慮なし）
・作成したファイル数 ÷ 発生した障害数 ＝ 質的生産性（存続期間考慮なし）
・記述したステップ数 ÷ 発生した障害数 ＝ 質的生産性（存続期間考慮なし）
（さらには…）
・作成したソフトウェア数 ÷ 発生した障害数 × （現時点 － 作成日時） ＝ 質的生産性
※質の評価はここで評価するんです。
●貢献的生産性（＝ユーザへの貢献度＝どれだけ使われたか。akabeeさん回答の趣旨）
・作成したソフトウェア数 ÷ 実行された回数 ＝ 直接的な量的貢献度
・作成したモジュール数 ÷ 実行された回数 ＝ 直接的な量的貢献度
・記述したステップ数 ÷ 実行された回数 ＝ 直接的な量的貢献度
●付加価値的生産性（＝第三者への貢献度。Chironianさんの言う寄与度）
・公開してからの経過時間（ソフトウェア） ÷ ダウンロード数 ＝ 対外的な量的貢献度
・公開してからの経過時間（モジュール） ÷ ダウンロード数 ＝ 対外的な量的貢献度
・公開してからの経過時間（ファイル） ÷ ダウンロード数 ＝ 対外的な量的貢献度
（ほかにも）
・公開してからの経過時間（ソフトウェア） ÷ アクセス数 ＝ 対外的な量的貢献度
・公開してからの経過時間（モジュール） ÷ アクセス数 ＝ 対外的な量的貢献度
・公開してからの経過時間（ファイル） ÷ アクセス数 ＝ 対外的な量的貢献度
●生産性
それぞれの生産性を積算等することで、総合的な生産性を数値化することが可能です。
積算する対象が増える＝評価軸が増えることを意味します。
・量的生産性 × 質的生産性
・量的生産性 × 質的生産性 × 貢献的生産性
・量的生産性 × 質的生産性 × 貢献的生産性 × 付加価値的生産性
■生産性を求める手段やツール
確認するための手段やツールには何を使えば良いのか。
それに対する答えの”イメージ”は以下の通りです。
データの計測・取得・加工はいくらか行う必要があります。
手に付けやすい情報から少しづつ取り組むのが良いと思います。
▼量的生産性
・ファイル数カウンタやステップ数カウンタ
・チェックアウト時刻とチェックイン／コミット時刻
▼質的生産性
・障害管理一覧。もしくは、Bugzilla等のBag Tracking System。数が分かればよろし。
・ファイルの更新日時と作成日時や、最新リビジョンとリビジョン1のタイムスタンプ。
▼貢献的生産性
・ログファイル（代表的なのはアクセスログ。タイムスタンプ<時間情報>も出ているとより有益）
自分で作り込んだログじゃなくたっていいんです。WebアプリならApacheのログだっていいんです。
自分が作ったものがどの程度（何回、何時）動作したかがわかれば良く、それ以上は必要ないです。
▼付加価値的生産性
・GitHubのアクセス解析機能など（パブリック）
・Maven + TheNEXUS で Maven Repositoryをローカルで立て、ログからアクセス解析するなど
■技量向上（熟達）による生産性への影響を測る（＝成長度を測る）
「技量が上がればステップ数は少なくなるから当てにならない」話は成長度の話だと書きました。
これも定量的に求めることはできます。
・リファクタリング後のステップ数 ÷ 同前のステップ数 ＝ 量的生産性の成長
・リファクタリング後の処理時間 ÷ 同前の処理時間 ＝ 質的生産性の成長
・〇〇ステップ記述の所要時間 ÷ 同過去時点の所要時間 ＝ 量的生産性の成長
・〇〇日間における障害発生数 ÷ 同過去時点の障害発生数 ＝ 質的生産性の成長
などなど。
ほかにも求められるものはあるでしょう。
ポイントは「後」「前」とあるように、時勢が大事です。ある時点と現在を比較するのです。
定量的（ある時に測った内容を、その時と同じ方法で）に測り比較するのです。
成長度を求める手段やツールは、生産性を求めるものとほぼ同じと思います。
■最後に
過去最高の長文となりました。「読まれない文章」になってますね。書いちゃったので投稿します。
多くの回答者が言う
「技量が上がればステップ数は少なくなるから当てにならない」
とは
「前提が変わる（技量が上がる）のだから、計測する対象（ステップ数）に意味はない」
というのが「無理だ」という主張の趣旨です。
この認識と主張はプログラムを対象にしなくとも、あらゆる分野で行われています。
しかし、これこそが生産性を測るにあたっての最大の誤解であり、間違いなのです。
最も大きな間違いが、「前提が変わる（技量が上がる）」という部分です。
前提（技量）は状態や状況を示すものであり、定量的に対して「定性的」と言われる情報です。
定性的な情報は数値化することができません。ゆえに「無理だ」という主張になるのですが、
「生産性を把握する」とは、生産”性”という言葉が示す通り、「定性的情報の定量的把握」
に他なりません。そして、この”性”とは「ある対象と比較してどっち寄りか（善し悪し）」
を意図・意味します。
ここで主張を読み替えてみます。
「技量が上がればステップ数は少なくなるから当てにならない」とは
「生産性（技量）が上がるなら定量的情報（ステップ数）が変わるから生産性は測れない。」
「生産性を求めたいって言ってるけど、生産性が変わるんだからわからないよ。」
と言っているわけです。
定量的情報を比較して定性的情報を導きだすべきところを、
定性的情報を理由に定量的情報を捨てた形になってしまっています。
「無理だ」という主張は、その主張にこそ原因があったのです。
生産性の話が出ると、どのような情報を得れば評価に意味があるのかに目が行ってしまいます。
その時、多くの場合において個々の情報を見て有効か無効か判断しようとしてしまいます。
しかし、
生産性とは何か一つの情報があれば正しいものが得られるというものではない認識に至りました。
時間をかけて何かを作る以上、その間に発生したあらゆる情報に価値があります。
重要なことは
・どんな定量的情報が採取可能であり
・採取した定量的情報からどんな評価軸を得ることができて
・どれだけの評価軸を生産性を指標として採用するか
にあると考えます。
…朝です。長文ここに極まれり。駄文失礼いたしました。（誤字脱字あると思います。ご容赦。）
投稿2017/06/23 19:43
編集2017/06/23 20:01
総合スコア804
皆さんからの回答を受け、ちょうど量的生産性と質的生産性を分離して管理する方法を考えていたので、大変納得行く回答でした。
貢献的生産性、付加価値的生産性に関しては、後回しにしていたのですが、こうして記述いただいた内容を見ると、そんなに難しく考える必要はないですね。
ありがとうございます！
技量向上はちょっとイメージが固まらないので、もう少し悩む必要がありそうですが、それ以外はなんとなくイメージが出来ました。
計測方法や、アウトプットを試行錯誤すれば、意図したものが管理できる気がします。
ちなみに少し気になったのですが、質的生産性/貢献的生産性/付加価値的生産性の計算式、分母/分子が逆じゃないですか？
コメントありがとうございます。計算式は夜な夜な書いたので間違えたかもしれません。
私の意図は伝わったと思うので、修正して活用いただければ良いかなと思います。
技術向上については、目的そのものが漠然としたものなので
知りたいことを計測してみようと行動してみるのが理解が早いかもしれません。
例えば、
定量的情報をどう判断するかなので、単純に作成したステップ数の期間別集計でも良いでしょう。
四半期に1回、作成したステップ数を計測するとします。
・4～6月 ＝ 1000Step
・7～9月 ＝ 500Step
・10～12月 ＝ 700Step
・1～3月 ＝ 600Step
これも"定量的"には成長を示します。
ピンとこないかもしれないですが、「時間経過と共に記述ステップ数が減少傾向にある」からです。
こんな程度からでも十分だと私は思います。
注意したいのは、「難易度が違う」「案件が違う」というような定性的なものを考慮してしまうこと。
定性的なものを考慮し始めたら、それを定量的に測れるかを考えて、可能ならば評価指標に使います。
定量的に測れないものは、測れるような仕組みでも思いつかない限り、捨ててしまいましょう。
生産性を測るために計測した情報でも、
使い方を変えることで別の情報が見えることに気付くことがあるので、
生産性の観点から手をつけて、得た情報から成長度を測れるものがあるかを見てみるのも良いでしょう。
コメントありがとうございます。
個人で行う振り返りのための仕組みなので厳密なことは考えていないのですが、考え方として非常に参考になりました。
管理って難しいですね＾＾；
新規に回答がついたのでte2jiさんのコメントにレスしておきます。
私が言いたいことは「管理って難しい」「ステップ数は当てにならない」「ステップ数は営業やマネジメントの指標」という考えそのものが「生産管理をするにあたり最もそれを邪魔しているものだ」ということです。
生産性とは「インプット量に対するアウトプットの量」こそが真理で、逆説的に「アウトプット量に対するインプット量」が同じ意味を持ちます。それを知るためには数値化することが必須。プログラマにとって数値化できるものは、かかった時間とステップ数だけです。このことに同意いただけないのであれば、画期的な考え方でもない限り、生産管理をすることは叶わないでしょう。そう言い切れるほどに。
あともう一つ。多くの識者の回答を拝見し、te2jiさんのコメントを見てこう思いました。
「これは生産性の話なのか？」と。
実は知りたいのは「品質そのもの」や「生産性と品質の両方」なんじゃないですか？そんな風に思いました。
もしそうであれば識者の回答やコメントにも納得します。品質を測るには確かにステップ数は意味をなさないので。
0
コードの量は必ずしも生産性に比例しない（適切に共通化されたコードがあれば総量は減る）ので、行数や打鍵数は妥当な数値になるとは思いません。
あえて数値で指標をというなら「通したテストの数」ではないかな、と思います。※ただしコードがひどいとテスト項目が無駄に増えますが（後述）
自己管理というならば「今日はここまで実装しよう」でいいような気も。
※昔、Cでcharを16進二桁に変換する、とんでもないコードを見たことが……if～else if が16個、その一つのブロックごとにさらにif～else ifが16個…計272個のif文という……
確かに動きますが、当然、書き直しました。
どうも元が COBOLer の人が（かなり昔に）書いたものらしかったですが
投稿2017/06/23 01:38
総合スコア13703
通したテスト数ですか。
確かに、「１つ完了した」という目安としては最適そうですね。
元々は、「今日はここまで実装しよう」という目標をどうやって立てるか、統計的に管理できないかと思って質問しました。
皆さんの回答を見ると、なかなか難しそうです＾＾；
ありがとうございます。
0
GitHub の Contribution Status も選択肢の一つとして良いのではないでしょうか。
こちらですとリクルータの方が見てくれたり、企業面接での参考の一つになる事もあります。出来るだけ毎日何かしらのアウトプットを出すという目標として良いと思います。
投稿2017/06/23 00:48
編集2017/06/23 00:50
総合スコア5030
回答ありがとうございます。GitHub はあまり使ったことがないので、Contribution Status がどのような指標に基づき表示されているのか、理解していませんが、年単位でグラフィカルに確認できるのは良いですね。
Contribution Status がどのような値を元にしているのか、確認してみます！
0
そういうことではないんだろうけどなぁと思いつつ、意見させて頂きます。
話がずれているかもしれませんが、「みなさんはどのような方法で、生産性を確認されているのでしょうか？」とのことでしたので、自分の考え方を書いてみます。ご容赦下さい。
プログラマの生産性（成果と言ったほうがいいかも）を何で図っているかというと、その人の作ったプログラムが役に立っているかどうかです。
例えばAさんが10日かけて作ったプログラムが、年に4回ほどしか動いていなかったとします。
それに対してBさんが1時間かけて作ったプログラムは毎日のように動いていて色んな人の役に立っていたとします。
上記の書き方ですと言うまでもなくBさんのほうが生産性が良いことになります。
しかしながら、よく調べてみると実はAさんのプログラムは四半期に１度しか動作しない処理で、年に4回しか動作しないことは当然、かつ非常に複雑な処理を不具合なく行っており、それによって大きな効果があることが分かったとすると、Aさんの生産性も非常に高いということが分かります。
プログラマ、エンジニアの価値というのはそうやって決まっていくものではないかなと考えています。
大事なのは、上記のようなことが後で把握できるように計画してコードを書き、しっかりと個人別の成果を追っていくことだと思います。
勿論、言語への習熟度をはかるという意味では時間あたりに書けたコード量の計測等（commitの数）に意味はあるはずですが、極端な話コピペでもコード量が稼げてしまいますし、最終的にそのコードは削除するようなこともあるかもしれないので、そこに十分な意味を見出せるかどうかはコードを書く人次第かなと思います。（自分の生産性であれば、意味を見出せるようにコードを書き、後にそれに従って分析もできるので計測することはできると思いますが）
どういうことを解決したいと思ってプログラムを書いて、どういう人をターゲットにしていて、実際にターゲットの人がプログラムを動かしてくれたか？それをどうやって計測するか？問題があればいつ頃対処するか？使ってくれていればもっと良くすることはできるか？もっと良くしたときにどのぐらい動く回数が増えるか？
私の場合は、そういうことを自身の生産性として気にしながらプログラムを書いています。
投稿2017/06/23 09:28
総合スコア1947
生産性を気にしているけれども、数値化できるものではないので、感覚的なもので振り返っているという理解で正しいでしょうか？
プログラミングをはじめて、そろそろ2年になるのですが、自身の成長を振り返ることのできる指標があればなぁ。。。と思い、今回質問をしています。
質と量を同時に見なくては評価できないプログラミングという技術を、生産性って側面で記録していくっていうのは難しいですかね？
以降のメンテナンス性まで加味しなくては、意味が無い！というのは非常に記録しにくいですね＾＾；
悩ましいです。ありがとうございます！
いえ、ちょっと違います。感覚ではなくて明確に数値化しています。
例えば自分の作ったプログラムが他者に動かされた回数を記録するようにして、今月は何回動いた＝どれだけ利用価値があったか、を測定します。
自己評価ではなく他者評価を成果の目安にしているわけです。
例えば１ヶ月かけて作ったプログラムと１日かけて作ったプログラムがあったとします。
自分としては前者のほうが力作だと思っていても、１年間に利用された回数を比べたときに、前者は100回、後者は10万回利用されたとします。
そうすると後者のプログラム(プロダクト)の価値のほうが高いと言えると思います。
そういう風に、後で成果を測定できるように工夫してプログラムを作っています。
２年経って、どれほど他者の役に立つプログラムが書けるようになったか。
私ならそういう観点で生産性というものを測定したいなと思います。
ありがとうございます。理解できました！
0
・コミットしたコードの量
・記述したステップ数
・打鍵した数
これは勘弁してもらいたい。
残業する人ほど仕事がんばってる的な。
私はダメプログラマなので生産管理などしていません。
投稿2017/06/23 05:37
総合スコア16731
回答、ありがとうございます。
今回質問してみて、改めて思ったんですけど、質と量の両方を自己管理するのって、かなり難しいことみたいですね＾＾；
> 残業する人ほど仕事がんばってる的な。
こうならないように、自分の生産性を把握しておけば、異常値が発生したときも分かるかなぁ。。。というのが、質問をしたきっかけでもあるので、そういった観点で何かあれば、また教えてください。
0
プログラマーの生産管理は手段であって、
目的は個人（te2jiさん）の成長（の記録）でしょうか。
であれば、他の回答とは違う視点から、
上記目的を達成できそうな方法を以下の前提で回答しますね。
・コミットしたコードの量
・記述したステップ数
・打鍵した数
⇒（打鍵した数を管理する現場は見たことがないですが）
これらを管理する部署・グループ・チーム・上司等が
te2jiさんの現場には居ない事を前提に回答しますね。
（品質管理とか品質保証等のチームで管理する現場があったりします）
色々と勝手に前提を置いてしまいましたが、
目的や現場の状況等をもう少し詳しく教えて頂ければ、
より的確な回答が出来る（もしくはもらえる）かもしれません。
たとえば、長期的なプロジェクトに参画しているのか、
単発的なプロジェクトをたくさん参加しているのか、
ドキュメント・品質を重視している現場なのか、
スピード・費用対効果を重視している現場なのか、
尊敬できたり見本となる先輩・上司がいるのか、
一番得意としたい言語は何なのか、
そもそも個人なのか、チームなのか、プロジェクトなのか、
新規システム開発なのか、既存システムの改修なのか、
etc...によっても回答内容は変わってきそうです。
さて、生産性が向上している事の可視化ですが、
「プログラマーとして」であれば、以下はいかがでしょう？
●●●バグ（障害）を出したときの振り返りを記録する●●●
現場によってはバグ記録票・障害処理票とか言ったりするので、
その辺のキーワードで調べてみても良いかもしれません。
また、バグ記録に欠かさない方が良い内容としては、
直接的な原因と本当の原因と対策を繰り返し自問自答するとなお良いと思います。
・時間がなかった⇒なんで？⇒調整すべきだったetc...
・仕様の把握漏れがあった⇒なんで？⇒定期的な勉強会をetc...
・伝達ミス⇒なんで？⇒チェックリストをetc...
・体調不良だった⇒なんで？⇒定期的な健康管理対策をetc...
etc...
※本当のバグの原因の対策を本気で考えると、
かなりの時間がかかりますが、成長するきっかけになると思います。
自分自身だけでは限界があったりするので、関係者に報告するのも良いかもしれません。
あと、「バグを出したときの管理方法」はこれはこれで色々な方法があるので、
もし、このような方法を選ばれるなら、別途質問を出してみても良いかもしれません。
ちなみに、バグ記録を利用して、数値化するために、
こんな感じのイメージを持っても良いかもしれません。
（後で、ちゃんとした数値化も記載します）
＝＝＝＝
同じようなバグを何度も繰り返していたら3流。
他人のバグを鼻で笑ったら2流。
同じような原因のバグを2度と出さなければ1流。
他人のバグをもフォローできれば1流。
他人のバグをもフォローでき、同じような原因のバグを2度と出さなければ超1流。
＝＝＝＝
（極稀に、似たようなバグは出しつつも、
作業がものすっごく早い人も居ますが、それはそれで。
上記の数値化は適当です。2流3流に当てはまってもお気になさらず、
te2jiさんが思うイメージで補って頂ければ。）
バグ記録を利用した数値化のもう１つとして、
定期的（工程単位でもプロジェクト単位でも）に、
コードの量とバグの量と時間軸を適当な組み合わせで比較すれば、
この難易度にして、このバグの量はすごい！とか
よくこんな短期間で、バグがこれだけだった！とか
思えるようになると思います。
たとえば、
「昔は1000行コーディングしたら、
バグが10件・障害が2件あって、1ヶ月かかり、
今回は1000行コーディングしたら、
バグが1件・障害が0件あって、１日で終わった。」
という明らかな成長も記録できると思います。
（数値は出るので、グラフ化の内容はお任せ。）
ついでに、得意となる言語を１つ身に着けると、
他の言語を触った時に、コード量や時間とバグの量で、
あぁ、この言語はまだまだ不得意だな、という認識も出来ると思います。
（得意分野ができれば、他言語については感覚で分かるとは思いますが）
あとは、最終的に、どの現場に行っても「恐ろしい生産性」と言われるようになり、
バグもほとんどでなくなり、他人のバグを指摘・フォローできるようになれば、
記録の必要はないかもしれませんね。
ちなみに、なぜ、生産性の指標にバグ数を用いるのか？について、
いくつかの参考URLにも記載がありましたが、
バグの量と生産性は比例の傾向にあります。
（クリティカルのバグがあれば、最悪やり直しですからね。）
プログラマーの成長というのは、
まずはバグを極力埋め込まないようにすることだと思います。
また、要件定義（や設計書のドキュメント）を作るのが上手い人は、
要件を聞いた時点で、頭の中でプログラムが完成し、
起こり得る不具合・障害を事前に防いでいます。
センスを問われる部分もありますが、
プログラマーとしてバグの埋め込みが少ない人は、
要件定義や設計をする上でもバグの埋め込みが少ない傾向もあります。
バグを記録する事はプログラマーとして成長するための有効な手の１つだと思いますので、
やってみて損はないかと思います。
投稿2017/07/11 18:02
編集2017/07/11 18:08
総合スコア760
コードの質をバグの量で測るということですね。
幾つかの指標を鑑みて、総合的に質を測ることを考えていましたが、一つの指標に絞り、単純化するのも、こういった計測には良いかもしれませんね。
現在は個人で開発しており、バグの管理も危ういですが、工夫していきたいと思います。
回答ありがとうございます。
個人開発でしたか。
であれば、回答を読んで頂いたのに申し訳ないですが、
バグ管理はオススメできないですね。
個人でバグ管理しても、メリットである成長できる要素が少ないので。
（te2jiさんが考えるバグの本当の原因が正しいのか、
間違ってるのかの第3者チェックができないため）
ただ、バグの管理が危ういとのことなので、バグの数や質を指標にせずとも、
最低限のバグ管理くらいはするようにしても良いかもしれませんね。
というのも、バグを出したら、必ず「横展開」が必要になります。
たとえば、「仕様の確認不足」が原因であれば、
「他に仕様の確認不足はないか」を確認するきっかけになります。
展開でもバグは出てくるものです。
また、開発中に気付いたバグ(変数名の誤字等)であれば、
完成後の再チェックリストとかに含めてあげたりして、品質をあげる事もできます。
（と、、、質問の意図から離れすぎてしまうので、この辺で。。。個人開発でバグ管理ってどうしてますか？という質問を別途してみても色々な回答をもらえると思います）
というわけで、私の回答としては、
プログラマーとして成長したいと考えているのであれば、
個人開発には限界があると思います。
まずは、（できれば初心者歓迎の）
チーム・グループ・プロジェクトの現場に行かれる事をおすすめします。
（初心者を歓迎するところには、見本にできるすごい人が居る可能性が高いため）
個人開発の限界は随分前から見えているので、参加できるチームを模索中なのですが、なかなか。。。おっさんかつ未経験なもので＾＾；
参加できるチームがあれば、ご紹介下さいｗ
コメントありがとうございます。
得意としている言語（誰にも負けない、もしくはトップクラス）はありますか？
そういう武器があれば、チームに入るのは難しくないかと思います。
もし、そういう武器がない場合、
LancersやCrowdWorks等で
師匠にしたいようなプロフィールの方に
直接お願いしてみるのも良いかもしれません。
４００人くらいに声かければ、
１００人くらいから応答があり、
４０人くらいがチームに所属していて、
２・３人にチームの勧誘があるかもしれません。
もしくは、個人ではなく、法人で登録している方に声を掛ければ、
案件を紹介してくれる可能性があるかもしれません。
（一般的な案件に応募しても、採用される可能性が低ければ、
直接声を掛けた方がライバルが少ない分、早いという考え方です）
道を極めるには2年じゃ短すぎますｗ
コメントありがとうございました。
根気よく探してみます＾＾
0
ベストアンサー
パーソナルソフトウェアプロセス（PSP) なんてものがありました。
https://codezine.jp/article/detail/3937
本もいくつか出版されているのですが、ガチすぎて自分自身では実践できていません。
投稿2017/06/26 00:21
総合スコア304
パーソナルソフトウェアプロセス なんてワードがあるんですね。知りませんでした。
いくつか調べてみましたが、非常に良い参考になりそうです。
切り口としては以下の目次が参考になりました。
http://www.kyoritsu-pub.co.jp/bookdetail/9784320120136
ご紹介ありがとうございます。
いろいろあさってみたのですが、本質的にはこれが1番求めていた斧に近いようです。
ただ、環境が整ってないんですよねぇ。。。
ツール類も、あまり洗練されていないようで、そのへんで手を出しにくい。
http://www.jaspic.org/event/2004/SepgJapan/proceedings/1C2.pdf
資料が2004年のもののようですが、あまり進化していないようですね。
気になったキーワードだけ、メモしておきます。
「The Software Process Dashboard」
「Watts S. Humphrey」
大変参考になりました！ありがとうございます。
0
こんにちは。
ある特定のチームの「生産性」を測る場合、そのチームがもたらした経済効果を計測することが考えられますね。会社にもたらした利益などがありがちな基準と思います。（寄与率を決定する基準はなかなかないと思うので、寄与率を想定しないで良い単位でないと困難ですが。）
しかし、te2jiさんが計りたいのはその意味の生産性ではなく、ご自身の技術者としての生産性と理解しました。
技術者の生産性ってmomon-gaさんがリンクされている資料にかかれているように難しいですね。
量と質の両方を問う必要があるからですが、まず「質」の定量化が困難です。
例えば、名前がついているようなデザイン・パターンやアルゴリズムを使った、よりメンテナンスしやすいプログラムであるなどでしょうか。名前がついていたら、それをリスト化してある程度は管理できそうですね。しかし、後者は評価のしようがない気がします。
また、量も意外に難しいです。質が大差ないと言う条件であれば行数で管理して良いと思います。同じ人であれば質を保つことは本人の心がけ次第と思います。
しかし、試行錯誤を繰り返す必要がある場合もあるし、学習に多量の時間をつぎ込む場合もあります。そのような時は仮にアウトプットの品質が同程度でも行数で比較できません。しかし、充実した中身の濃い業務を行ってます。
結論としては、定量的な管理は無理なように感じます。
以前できなくて、新しくできるようになったことを記録するくらいでしょうか。
私は記録はしてないですが、肌で感じることはあります。以前は、C++の参照やconst使えなかったけどいつの間にか使えるようになったなぁとか。
投稿2017/06/23 10:07
総合スコア23272
質と量の計測が、非常に難しいとは理解していたのですが、なんかうまい方法でみんな自己管理しているんだろうと思っていました。
かなり、難しそうですね＾＾；
成長をグラフ化したいなぁ。。。ｗ
ありがとうございます！
0
プログラミングの生産性についてどこかの書籍で統計データが出ていたな・・・と探したらトム・デマルコの「ピープルウェア」でした
チームの生産性、プロジェクト管理についてのお話しなので、自己管理というのとはちょっと違いますが、知らない人がいたらおもしろいのでおすすめします
・コミットしたコードの量
・記述したステップ数
・打鍵した数
これらは当てにならないでしょう
まんじゅう屋が１日に何個まんじゅうを作れるか、と同様の指標に思います
一定の繰り返し作業を毎日続けるような労働であれば「慣れ」によって変わるでしょうけど、毎日まったく同じコードを書くことってないですよね、ないはずです
なので「慣れ」ることはなく、こういったものでの生産性の測定は困難です
それでも自分がどのくらいできてるかを知りたいなら、機能をなんらかの指標によって点数化し、一定期間にいくつの機能を実装したか「今日は何点取れたか」を記録管理するくらいでしょうか
というのが私の意見です
ちなみに、紹介した本の中に「プログラムは夜できる」というのがあります
本自体が古いので今となっては常識的な事かもしれませんが、「プログラミングコンテスト」によって明らかになった企業比較による生産性の違いについての事実がおもしろいです
投稿2017/06/23 09:14
総合スコア3111
ご紹介いただいたリンク先を確認しました。
面白そうです。
「割り込み無しの時間数」÷「肉体労働時間」 = (環境係数) と実際の労働時間をうまく組み合わせて指標とするのは、一つのやり方かもしれないです。
§5 パーキンソンの法則の改訂 にある生産性の算出方法も気になりました。
今、ちょっと手を出せないですが、読んでみたい本として、記録しておきます。
ありがとうございます。
コーディング、ドキュメント作成時間 / ドキュメントを確認する時間
が、何を示す指標となっているのか、ちょっとわからないですけど、面白い切り口ですね。
もうちょっと、理解を深めてみたい方法です。
ありがとうございました。
適当に書いたのであまり深く考えられると恥ずかしいのですが、プログラマーの成果物(アウトプット)がコード、ドキュメントに対してアウトプットするために必要な情報や前提とする知識(インプット)で割れば入力に対する出力の比が出るのかなと。単位として時間を取ったのは単に他に定量的なものを思いつかなかったからです。知識量が増えればインプットが少なくなるor早くなり産性は上がってくることは直感的に正しそうなので何かしら意味の有りそうな指標だと思います。
効率的に作業をできるかという観点は含んでなさそうですけどね・・・。
コメントありがとうございます。
コメントいただいたとおり、直感的に何らかの意味がありそうな気がして、面白く感じました。
他の回答とあわせて考えてみます。
0
コメントでもいただいた「自己管理歴の長そうな人（主にPHP）」に該当するものの、
どういう回答を書こうかと悩んでいるうちに良い回答が浮かばない内に時間が経ちすぎてしまいました。すみません・・
基本的に回答がある皆様と質問者様の意見・やりとりに「うんうんそうだな」「参考になるな」と頷いて満足してしまってました。
ステップ数だったりコード数だったりはあくまで営業さんやマネージャークラスが見積もりを作るときの指標にすぎないと思っています。
基本は同等規模の案件から見積もりは作られますが、成果物に対してもどれくらいの規模になったかを把握する必要があるため、
マネージャーから「最終的に何ステップになった？」と確認されたときにざっくり申告はするものの、
結局ある程度大きい値に丸められて（例：9800と申告→10000）しまうので、実際はステップ数を計るフリーツールでカウントはするもののこちらも丸めて申告しているのが実状です。
で、自身としてはやはり同程度の規模の案件が指標になってしまいますね。
それもざっくり指標なのであてにならないといえばあてにならないし、
案件をこなしていくことで自身も成長していっている（中にはやってる最中でも成長をしていっている）ので、
同程度の案件が同程度の生産性かというとそうでもないですしね。
既に回答があるように単純作業ではないし、参考にはしても全く同じコードを書くとはほぼないので、
引かれたスケジュールに対しどこまでできてどこまで溢れそうか・・・を日々の進捗を確認しながら進めている感じです。
（あれ？結局、管理らしい管理をしていない？）
ただ、残作業がどれだけあってどのような予定で進めていて、遅れがあるのか、ないのかくらいはどんなに切羽詰ってても、自作のスケジュール（Excelでもなんでも）に残すようにはしてますね。。。それの更新すらも置きっぱなしになっていたら本当にまずい状況ってことになります。
（あれ？結局、管理らしい管理をしていない？）
投稿2017/07/10 05:00
総合スコア80850
回答、お待ちしていましたｗ
ありがとうございます。
やはり、自身の生産性の変化を記述するのって、大変そうですね。
皆さんの回答で、質/量の両側面をまとめて記録するのは難しいらしいと判断して、今は別管理にしたものを、どう統合すると生産性の変化が確認できるか、模索しているところです。
先輩回答者の皆さまが悩んだ上で、ベストの方法が見つかっていないと言うのはなかなか悩ましい状態ですが、あがいてみます＾＾
0
ステップ数とか入力した数はあてにならないというのは皆さんがおっしゃっている通りだと思います。
個人的には、かかった時間やステップ数は生産性とは無関係と思います。
個人的には、各タスクをどのぐらいの工数（時間）でできそうかを見積もり、実際かかった時間を比較したり、タスクをどこまで昇華したか程度しかしませんね。
投稿2017/06/23 09:29
総合スコア1939
・各タスクをどのぐらいの工数（時間）でできそうか
ここがポイントですね。
私が今できる方法は、感覚的なざっくり試算しか無いのですが、なにかうまいやり方はあるでしょうか？
・タスクをどこまで昇華したか
この評価基準も、かなり重要な気がします。
皆さんからの回答で、理解は進んできたのですが、混乱度合いも進んでしまいましたｗ
回答、ありがとうございます。
>私が今できる方法は、感覚的なざっくり試算しか無いのですが、なにかうまいやり方はあるでしょうか？
これに関しては感覚的なものになってしまうと思います。実装する人のスキルによっても時間は変わってきてしまうでしょうし。自己管理用ということであれば問題ないのではないかと思います。
コメントありがとうございます。
> これに関しては感覚的なものになってしまうと思います
そうですか。。。なんとか定量化出来ないかなぁ。。。
もう少し悩んでみます。
あなたの回答
tips
プレビュー
