性懲りもなく「PHPについて語っているBlog」に興味を持ってみる

元ネタ
http://d.hatena.ne.jp/tumf/20110321/1300661187

一部「ネタ」とか書かれているハテブもあるようですが、社長さんですし社名を正面に出して書いているようなBlogですんで、正面から受け取ってみたいと思います。

PHPのエンジニアは同じ単価でもスキルの差がある。マネージャはそれを埋めるために最悪自分で動かねばなりません。以下はその最悪に近いケースの話です。

別に、他の言語でも「同じ単価でスキルの差異」はふつ〜にあると思う。
なので「PHPのエンジニアは」って部分には違和感あり。でもまぁそれ以外はそんなもんだと思う。
「マネージャはそれを埋めるために最悪自分で動かねばなりません」は、おいちゃん的には理想到達点(っつかまぁやってるけど)。ただ、それを「すべてのマネージャに要求してよいのか？」って部分で疑問。…要求したいんだけど(苦笑

逆に、運良く良いエンジニアを集められて場合はマネージャの仕事は本来の顧客に向いたものとなるでしょう。

ん…なんか引っかかる。
よいエンジニアであろうとも、マネージャの向きは常に「顧客とチームの両方」を向いている必要があるんじゃないかなぁ？

1.メンバーの経歴はあてにしない

言語に拠らず、ごく当然。

2.メンバーは定時に出社させ定時に退社させる

ど〜なんだろ？
「週40時間労働」は、諸手を挙げて賛成。…ってなるとまぁ、定時出社、定時退社、になるのか。

3.Subversion利用を徹底させる

うんまぁ特に違和感もなく。

4.PHP5.3専用のフレームワークは使わない

状況次第、ではあるかなぁ。ただ「ど〜しても5.3系が必須」って状況もレアだと思うので、業務ベースで考えると、もうちょっと静観してもよいような…名前空間は欲しいような…でも￥はキライｗ

5.テキストエディタの設定を確認する

文字コードと改行コードはたしかに。
インデントは、個人的には２spaces派ｗ
まぁ「統一ルール」があればよろしいのではないか、と。

6.難しいコードを書かせない

いつもながらに難しいところ。おいちゃん的には「必要なら書く、必要ないなら書かない」。

call_user_func()・SPL・リフレクション

call_user_funcは、基本つかわない。
SPLは…うんやっぱり使わないなぁ。
リフレクションは、使わないってよりもうちょっと踏み込んで「可能な限り忌避する」かなぁ。
なんだおぢちゃんのコード、難しくないぢゃんｗ

7.浮動小数を使わせない

至極当然。

8.switchを使わせない

break忘れってのはどうかと思いますが(苦笑
switchを「小器用に多用する」のは、大抵「ろくでもないコードの臭い」がするので、慎んだほうがよろしいのではなかろうか、と。
「どんなswitchがまずいのか」って部分の議論を、ちゃんとメンバー内でしておくとよいのだと思う。

9.正規表現を書かせない

単純に「重い」からおいちゃんキライ。抜けも多いしね。

10.SQLを書かせない

びみょ〜〜〜。「できればORマッパーを利用しましょう」は元々否定派だし。
SQLは「複雑なSQLが書ける」スキルを持ちつつ「基本、シンプルであることを旨とする」のがよいと思っているので。

11.一行でもブロックの{}を省略させない

これも、言語よらず一緒。

12.無理にコメントを要求しない

やだｗ
コメントは「何があろうとも潤沢に」書いてもらうのがおいちゃん流。

13.関数名を日本語にしたがる人に優しく辞書を渡す

あぁ…うん…(遠い目
おいちゃんは、Web系の辞書と翻訳サイトを多用(苦笑

14.ブランチのマージ

ん…これは「やだ」なぁ。
ちゃんと話をした上で、メンバーを信頼したい。

15.コードレビュー環境を用意する

「管理者は、メンバーが帰った後に大量のコードを読まなくてはいけませんので」いやまぁ居る間に読みますがｗ
自分の手に合ったお道具ってのは、大切ですね。

16.深夜にCIを動かして朝一番にチェックする

引き続き思案中。

17.テストは管理者が書く

テストって「指示書」の代わりにもなるので、ひとつあり。
おいちゃんは「テストを書いてもらって、それをレビューする」ことで、設計のお勉強を兼ねていただくことが多いです。

18.バグはBTSに

よろしいのではないか、と。

19.他の言語の話をしない

そなの？
そこまで深い愛着をPHPに対してもつ人が周囲にはいないっていうかそもそも平気で「PHPってだめぢゃん」とかBlogに書いているおいちゃんがなに言ったって説得力ないよねぇｗ

20.開発環境の話をしない

んむり…ここもそんなに気にしないかなぁ。っつかまぁ、おいちゃんのIDEは「vi」基本だしｗ

私の経験では、コードレビューと修正、明日の分の指示書作成については、1メンバーあたり1時間程度見ておけば十分だと思います。（たとえば5人分なら19:00から5時間なので終電に間に合いますね！）

ここは断固として否定。
「週40時間」は、あらゆる人に適用されるべきだと思っているので。

全体として…「マネジメント」というか「現場指揮官」という感じの印象値。
あとは…端々に、びみょ〜に「現場を信用していない感」が漂うのが、なんとなく気になるのかなぁ。

気になったので、memo。

ペルソナを近づける訓練

んと…「傍から見ると矛盾している」言動ってのは、割合にあちこちで拝見をします。
建前と本音…っていうよりは、どちらも「本音なんだろうけどなぁ」的な、でも「明らかな乖離」。

「定時内に仕事を終わらせることが大切だ」といいつつ「残業時間で評価を算出」とか。
「システムコスト削減」といいつつ「そんな時間でモノが仕上がるはずがないからもっと時間をかけろ」とか。
「共通化が大切」といいつつ「こぴぺしてテキスト置換すればいいじゃないか」とか。
「フレームワークは導入した後の指針ことが大切だ」といいつつ「フレームワークを選定したからもう大丈夫」とか。
「まだまだ知らないことはたくさんある」といいつつ「学ぼうとも教わろうともしない」とか。

多分、状況ごとにバイアスとか場とか色々な「何か」がエフェクトをかけた結果として、色々と乖離するんだろうなぁ、って思う。
その「バイアス」とか「場」とかを認識して、できるだけ「初心」になることができたら。何かが違ってくるんじゃないか、って気がする。

あちこちにある同じ言葉

学びて思わざれば則ち罔し、という言葉は以前にとりあげましたが( http://d.hatena.ne.jp/gallu/20090228/p1 )。
それとほぼ同じような、別の言葉です。

古(いにしえ)の
道を聞いても唱えても
我が行いにせずば甲斐なし

知行合一、なんて言葉もありますが。
学ぶ難しさ、学びを生かす難しさを、あらためてしみじみと考えます。

気をつけないと「学んだことにしがみついて」 http://d.hatena.ne.jp/gallu/20100122/p2 のように「しゅ〜りょ〜な白髪頭」になっちゃいますしねぇ。
腰掛けて、若くして老害になったり、ね( http://d.hatena.ne.jp/gallu/20110327/p1 )。

声はすれども姿は見えず ほんにお前は屁のような

「教育」を、しない、って明言する現場は…いやまぁぢつは結構あるのですが、おいといて。
昨今、多くの現場では「教育/人材育成に力を入れている」と、言わないところはあんまりありません。

でも。

そもそも「な〜んも」やってなかったり。
「本読め」で終わったり。
基礎の基礎、程度の座学を延々２時間、一方通行でしゃべりっぱなしのやりっぱなしだったり。

正直「効果的な人材育成」を、あまり見たことがありませぬ orz

おいちゃんが思うに。
エンジニアを「本当に」育てるんなら
・「今」その子がやっている作業で
・ちょうど「just now」躓いているところを見切って
・その場で15分、躓いているところについて教える
を、１日１回以上(推奨は２〜３回)＊一ヶ月以上、ってのが、基礎を伸ばす上で「一番確実」だと思うんですがねぇ。
「今躓いているところ」を教えるから、聞くほうもおのずから真剣にならざるをえないし。

で。
その辺を意識すると、イヤでも「下の子が今なにをやっているか」を、それこそ「目を皿のようにして」チェックするから。結果、コミュニケーション不足とかってありえなくなるし。
そうやって、初めて「卒啄の機」を伺うこともできるんじゃなかろうか、って思うのですが。

どんなもんなんですかねぇ？

新しいカテゴリ「対立軸」

新しいカテゴリ始めます。
まぁいつものことではあるのですが、これもまた「自分の考察用」のメモです。

んと…「２つの相反する」話があって。
消化できりゃいいんですが、いまひとつ(あるいはまったくもって)消化不良なものについて、書いていこうか、と。

マネジメントの範囲

同じく
http://d.hatena.ne.jp/gallu/20110327/p3
http://d.hatena.ne.jp/gallu/20110401/p1
の続き。

んと…「全体最適」は理想なんだけど、現実問題として「森羅万象のすべてを見通した上での最適」なんて、イエッサのパパぢゃないと無理＠聖☆おにいさん。
スイカ割りであんな「最適解」が出せるあたりが素晴らしい、ってのは余談ｗ

だとすると。
「局所最適」の局所を、少しでも広くすることが必要なんじゃないか、と。

場当たりで「今の自分最適」は、「未来の自分的最悪」だし。
「自分最適」は「チーム的最悪」だし。
「チーム最適」は「部署的最悪」だし。
で、部署から会社、業界、国、なんていう風にスケールがあがっていくんだと思う。

どこまでいけるかはしらないんだけど、とりあえず「会社最適」ないし「業界最適」くらいまでは持ち込むのが、会社にいる「マネージャ」と呼ばれる人の、マネジメント範囲なのではなかろうか？ とか妄想。

マネジメントのベクトル

http://d.hatena.ne.jp/gallu/20110327/p3
http://d.hatena.ne.jp/gallu/20110401/p1
の続き。

んと…とりあえず「マネジメントってなに？」ってあたりから。
対象は複数人。…とはいえ、一人でも「時間が違えば他人」ってのがおいちゃんの原則なので、まぁ一人作業してても「未来の自分へのマネジメント」ってあるんだけどね。

複数人がひとつの仕事を「力を合わせて」やることを前提に。
最悪なのが「お互いがベクトル的にぶつかり合う形で、相手の足を引っ張ることに全力を注ぐ」ケース。一人でやったほうがマシ。
次に「なんの邪魔も入らないけどなんの好影響も与え合わない」。ダメっぽく聞こえるけど、この水準に達していることって珍しいとむしろ思う。っていうか「複数人が完全に摩擦係数０って、ある意味ありえない」ような気もするし。
類似品として「相互作用がマイナスにもプラスにもある」ってところ。プラマイがちょうど０なのが、多分「摩擦係数０」と似たり寄ったり。
で、マイナスが減っていってプラスが増えていくと「まぁべらす」なマネジメントになるのではないか、と。
さらにプラスが増えていくと、いわゆる「シナジー効果」的なものになって。ンなもんが発生した日にゃぁ万々歳、大入り袋が飛びかうってなぁ感じで。

つまり、複数人作業において
・マイナス方向への作用を減らす
・プラス方向への作用を増やす
のがマネジメントなのではなかろうか、っと。

後は「短期的」な見解と「中長期的」な見解を考えてみたい。