「 プログラマ 」一覧

最近触っている技術

後の自分のためにメモ。
2018年8月時点ではだいたいこんなことをやっている。

・仕事はC++メイン。テンプレートをゴリゴリというより割とシンプルなクラス構成のもの
・ただし開発環境がC++11もフルで使えないくらいのコンパイラバージョンなので少し面倒

・勝手にPythonの勉強も兼ねて開発用ツールを作っている。PythonでCUIツールだったり、Python + FlaskでWebアプリだったり(勝手に作っているとは言っても作ったものはチーム内に公開してる)
・LeafletやGoogleMap APIも入門レベルでは使えるようになった
・CSSフレームワークはBulma。簡単な分、少し手の届かないところもあるがあまり不満はない
・JS関係はVue.jsでSPAを見よう見まねで。ただしVue.jsのコンポーネントは勉強できてないので作れない
・DBはPostgreSQL。ただこれはデータストアのために使っているだけなので、そこまでDB自体を弄り倒してない
・SCMはチームはTFSやSVN。手元では一人ローカルgitで開発ブランチ切ったりして少しだけ導入してる


エンベデッドシステムスペシャリスト受験

朝5時半に起きて、少し早めに会場の名古屋大学へ。刈谷からなのでそこそこ移動に時間がかかる。

DSCN1308

情報処理試験を受験したのは、なんだかんだで4年ぶり。若い頃は春秋ほぼ欠かさず受験していたのに、4年もブランクが空いてしまったのか…。

参考書を買ったのは2月とはいえ、今回も仕事がデスマ気味の中で準備は万端とは言えない状況。まぁ本気で勉強する時間を作ろうと思えばもっと作れたとは思うのだけども…。

前回のエンベデッド受験では午後1で脱落だったわけだけど、今回はどうだったか。

前回受験した時と少し異なる感じがしたのは、ITSS/ETSSに準拠や新シラバス対応になっていて、ESの午前2でも経営系の問題が出るようになった(前回もあったかも?)とかですかね。

午前1

午前試験は、前回受験時でも高得点だったのでそこまで不安視はしていなかったものの、午前1は他区分と共通なので割と幅広い範囲から出題されるので、参考書を読んで一通りは復習しておいた。

ただ最後のほうの経営系、マネジメント系の問題は用語も初見だったりするものもあって自信なし。問19、問23、問26、27、29あたり。

まだ答え合わせしていないけど、ボーダーは超えているはず。

午前2

午前2もそこまで不安視してないけれど、4年も前だと論理回路や計算問題は記憶が怪しかったので、これも参考書読んで復習はしておいた。

けれど、マルチプロセッサ、マルチコア系の問題は参考書でもあまり見かけず、ちょっと面食らった。問2、問4。

過去問そのままの問題もあったりしたものの、すべて覚えてるわけでもないので、問8も過去問で見たような気もするけれど、解答自信なし。問13の半導体の3次元実装技術もちょっと戸惑ったかな…。

おそらく午後2もボーダーは超えてるはず。答え合わせは近々にするつもり。

午後1

前回脱落の午後1。前回はガスメーターとウォシュレットの問題で時間内に全部解答できずに撃沈したわけだけど、前評判を見ても午後1はだいたい時間ギリギリな問題ボリュームなのが常のようだ。

今回の選択問題は問2のポータブルナビを選択。問1と併せて全く正解が思いつかない設問は無かったものの、計算問題でかなり手こずる。昔は電卓使えてたのにね…。筆算でかけ算・割り算なんて普段しないから途中で位取りとか間違えないかヒヤヒヤする。

今回の午後1は時間内に解答は全て書くことができたけど、やっぱり時間はギリギリ。残り5分を切っていたような。

解答した感触からすると、おそらく今回はボーダー超えてるんじゃ無いかと思うのだけどね…。微妙に記述式の解答でキーワードが入っていないとか、そういうミスが無ければだけども。

午後2

今回の鬼門は午後2だった。

問2のヒートポンプ式給湯器を選択したのだけど、正直、全ての解答を埋めることができず、おそらくダメだと思う。どう考えても6割正解できてると思えない。

試験開始前に解答用紙が先に配られた時点で、問1と問2の回答欄の数がけっこう違うのが気になっていたのだけど、それでも解答欄の多い問2のほうがソフトウェア寄りだったので選択。

それが裏目に出たのか、120分という試験時間では足りなかった。計算問題も時間を使ったし、そもそも問題読んでも何を解答すれば良いのかイメージが湧かなかった問題もあったし、解答したものの要求された文字数に達してなく、何か解答漏れがあるパターンなど…散々。

あともう1時間、試験時間があったら9割くらい埋められたかも、というレベル。

120分かけてあれだけ問題を残してしまった、ということが自分でもショックで、実はだいぶ凹んでいるのです…。

ただ、ネットの掲示板とかを見ていると、この問2は難しいと思っている人が多かった模様で、同じ思いをしてる人が多いというのは本当に問題の難易度が高かったのかもということだけど、それでも点数が増えるわけでもないだろうからねぇ…辛い。

午後1までは万全とは言えないまでもボーダーは超えたかな、という感触であとは午後2さえ行ければ!という勢いだったのが、玉砕した感じ。

ふと残り30分で未回答の問題の量と見比べて、この時点でああダメだ間に合わない…と悟ってからの終了までの30分は辛かった。負けが見えてる勝負をやってる感覚。でも途中で投げ出して退出するというのは嫌いで、昔から今までやったことないし悪あがきで1問でも多く解答を書こうとしたけれど、残した問題がどれも大変で…。

問1選んでればいけたのかなぁ…。リレーとか抵抗とか回路系の問題っぽかったのであまり問題見ていないけど。

その他

そういうわけなのでまた来年、ですかね。ちょっと会社関係で資格取って申請すれば色々できたのでそれを狙っていたのだけど…。

せっかくなので秋試験も何か受験する方向で考え中。おそらく午前1免除にもなると思うので、セキュリティスペシャリストかな…。

あと、会場の名古屋大学。行くのは最初で最後だろうけど、綺麗で広いキャンパス。ざっと歩いた感じでは建物も比較的新しいのが多くて綺麗だったね。

4月の新入生シーズンだけあって、掲示板にはサークルの募集ポスターがたくさん。私は専門学校卒なので大学生の経験が無いので、こういう資格試験で大学が会場だったりするといつも物珍しい気分になるのよね。

IMG_20130421_164310


IT系資格受験の遍歴

とある理由で、IT系資格を最後に取ったのはいつだろうと自分のブログを見返していた。

こういう時にブログに書きためてると便利なんだけど、調べてみてそんなことより最後に資格を取ったのが2005年ということに自分自身が驚いた。そんなに前だったのか・・・と。せいぜい4、5年前くらいかと思っていたが。

いちおう2005年の後も受験はしたものの不合格とか、申し込みしたけれど仕事が忙しかったりで欠席したり、しまいには仕事が忙しすぎて申し込みを断念することが増えて今に至る、というところ。

携帯電話関係の仕事をやっていた頃は春・秋の季節はちょうど仕事のピークと重なることが多くて、ただでさえ深夜まで残業、休日出勤も当たり前の状況が数年間続いたので受験どころじゃ無かったというのが大きいかも。

ただ、その間は仕事の忙しさにかまけて勉強することや新しいことをインプットすることが大幅に疎かになっていたのは間違いないし、そのダメージが段々と出始めてるようには感じる。

まぁ今、携帯電話以外の仕事についてからも、なにやら炎上プロジェクトをずっとやってるので状況はあまり変わってなくて、月日だけが過ぎていってるのだけれど。

以下、自分用にブログの過去記事をいろいろ探して受験の履歴をまとめておく。199x年は学生時代。

2000年代前半は、まだ入社5年目未満で実務経験もそれほど無いのに、プロマネやシステム管理やデータベースを受験して玉砕しているのが若かったのかなぁ・・・。たしかに高度区分の試験で受験できそうなのが限られていたとは言え。
------------
1996秋・・・初級システムアドミニストレータ(合格)
1997春・・・第2種情報処理技術者(合格)
1998春・・・第1種情報処理技術者(合格)
1998秋・・・ネットワークスペシャリスト(合格)
2000春・・・データベーススペシャリスト(不合格)
2001春・・・テクニカルエンジニア(データベース)(不合格)
2001秋・・・セキュリティアドミニストレータ(合格)
2002春・・・テクニカルエンジニア(システム管理)(不合格)
2002秋・・・アプリケーションエンジニア試験(合格)
2003春・・・テクニカルエンジニア(データベース)(不合格)
2003秋・・・プロジェクトマネージャ(不合格)
2004春・・・テクニカルエンジニア(データベース)(合格)
2004秋・・・プロジェクトマネージャ(不合格)
2005春・・・テクニカルエンジニア(システム管理)(不合格)
2005秋・・・テクニカルエンジニア(ネットワーク)(合格)
2006春・・・テクニカルエンジニア(セキュリティ)(欠席)
2006秋・・・申し込みせず
2007春・・・テクニカルエンジニア(セキュリティ)(不合格)
2007秋・・・申し込みせず
2008春・・・テクニカルエンジニア(セキュリティ)(不合格)
2008秋・・・申し込みせず
2009春・・・エンベデッドスペシャリスト(不合格)
2009秋・・・申し込みせず
2010春・・・申し込みせず
2010秋・・・申し込みせず
2011春・・・セキュリティスペシャリスト(欠席)
以降、申し込みせず


組み込みの現場でRTOSベースの既存システムをAndroidに移植しようとした時にありがちなこと

今の仕事は、いちおうAndroidをプラットフォームにした仕事ではあるのだけど、もともと組み込みのRTOSベースのシステムを移植するようなプロジェクトでシステムのアーキテクチャはAndroidというより"組み込み"の考え方。過去「スマートフォン開発もやっぱりデスマか」でも書いたのに似ていて以下のような感じ。

  • 他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている
  • RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる
  • Service間やActivityの間でやたらと非同期の呼出しや通知が多い
  • RTOS時代はこの方式で上手くいってたので、と押し切られる

他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている

例えばJavaレイヤに、int xxxFunc(byte[] data) のようなI/Fが提供されて、引数byte[]に自分でバイナリデータを組み立てて(しかもビット単位で)呼び出さないといけない。nバイト目のn~mビット目にはxxを指定する、のような。

システム内で広く使われる予定のコアなモジュールの割にはI/Fが不親切。既存のNativeライブラリがそういうI/Fだからということらしいが、ヘルパーメソッドくらい用意すべきと思う。

こういうケースは、

  • 担当者がAndroid(というかJava)の経験が浅いか無い
  • 単に期間的、工数的に楽になる実装にしたかった(ラップするだけだものね)

であることが多いように思う。

でもそのI/Fの使用者がシステム内の各所にいるような重要なモジュールなら多少はヘルパーなり呼び出しやすいI/Fで提供して欲しいところなのだが、要請しても必要性が分からないとか「今までのシステム(RTOS)はこうだったから」と言われてお終い。

経験上、こういうひどいI/Fを出して来るときの一番多い言い訳が「呼び出し側の実装の自由度を考えた」というのだけど、いちいち引数組み立てたりしないといけない実装を各モジュールで作らせるのが自由度とは思わないけどもね。

こういうひどい設計は、上手く呼び出し側の他社も巻き込んで「使いにくいから考え直せ」と攻めてみるのが筋だろうけども…。

RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる

xxxxTask -> xxxxServiceに名前が変わって再実装。

モジュール分割がRTOSと同じ感覚でちょっと細かすぎやしないだろうか、というケース。AndroidのServiceが乱立するのもね。RTOS時代から関わってる人には同じ感覚で仕事できるからいいのかもしれないけど。

Service間やActivityの間でやたらと非同期の呼出しや通知が多い

RTOSのタスク間メッセージと同じ感覚でI/F設計してしまうから。

→"xx要求"
←"xx受付通知"(相手側が受け付けましたという非同期通知)
←"xx応答"(相手の処理が完了して結果が乗ってくる通知)
でワンセットになってたりするケース。

応答を受けるまでは次の要求を投げてもエラーになります、キューイングはしないので呼び出し側で管理してください、が割合多い。

確かに、ハードウェアまでアクセスするために応答時間が数100msかかる可能性があるので非同期処理、というのは組み込みでは多い。

RTOSならセマフォやシグナルとか駆使して実装するのがセオリーだろうけど、Androidだとメインスレッドはブロックできないし、I/Fを使う側としては呼び出しと応答後の続きの処理がソースコード内の離れたところになってしまう。なのでソースコードを見たときに処理が見通しにくい。

多少、ブロッキングするメソッドであっても同期型でI/Fを用意してもらって、使う側でスレッド立ててその中で呼び出すなりできるけどなぁとは思うけれど正解がよく分からない。

ただ、コールバックやスレッドを上手く設計しておかないと後からバグだらけの懸念。内部の状態管理もきちんとしないといけないだろうし。

RTOS時代はこの方式で上手くいってたので、と押し切られる

…今回のプラットフォームはAndroidなんですけど…?

開発メンバーにRTOS時代からずっと関わってる人が多いと、「今までのやりかたが最強」ということになりがち。上に書いてるように、モジュール構成とかI/Fの考え方を既存のRTOSでのシステムからそっくり持ってくるからってことなんだろうけど。

でもAndroidのアーキテクチャと合わない設計をして無理やり作り込んで後で火を噴かなければいいけども…。ActivityとかServiceのライフサイクルは考え方としてそれなりに特殊だし、Android Frameworkとの兼ね合いもどう付けるのか…。たぶん火を噴いた時にはさらにパッチ的な回避をしてどんどん複雑化していくのだろうな。

こういう感じのシステムだと

もはや作っているものはAndroidというよりRTOSの仕事をしているのと大差が無くなってしまっている。よく分からないxx管理タスクと先にやりとりしないとアプリの起動ができないとか、シーケンスを引いていくとアプリ層やService層でやたらとあちこちの"タスク"に対して複雑なシーケンスをこなさないと処理が進まない仕組みに。

いろいろ改善を試みて一部はとりあってもらったものもあるけど、もう既に各社で設計が進んでしまっててひっくり返すには遅すぎるし、プロジェクト内のパワーバランス的にこちら側の力が足りない。

たぶんこれは結合試験以降の工程で大変なことになりそうだ…。

1つの処理に対してシーケンスが多いからユーザ目線でのレスポンシビリティーが心配だとか、クロスシーケンスを各社どこまで事前にケアできてるかとか(下位レイヤは単なるラッパーレベルでしか作ってこないだろうから期待薄)、どこかにしわ寄せが来そうな気がする。

携帯電話開発の現場でも、ガラケーからAndroidスマホに開発がシフトしていく時に通った道ではあるけど、これからAndroidの採用が見込まれている色んなデバイスの開発現場は「Androidでの初物」の開発では同じ道を通っていくのだろうか。

せっかくAndroid経験のあるメンバーを投入しても、もう少しアーキテクチャや設計の考え方には、既存システムの開発に長けていて自負があったとしても耳を傾けたほうが良いと思う。数年前と違ってAndroidのエンジニアは大きく増えているしAndroidのノウハウを持った人間もたくさんいるのに、その意見を頭から潰していたら良い物はできないと思う。

既存のRTOSの資産やノウハウを流用するとしてもAndroidに載せたときにどうするのが良いのか折衷案は出せると思うし、あとあと火を噴かないために注意すべきこととかは上流工程で検討しておくのが良いはずだけど。

往々にして開発スケジュールに余裕が無いからなどの理由で既存をベースに流用すればなんとかいけるだろう、というのはどこでもある話だけれども、それで進めると設計、実装、単体テストあたりまでは一見うまくいく。けど、各モジュールを結合していくとシーケンスの不備、Android特有の動作、動いてもモッサリ、メモリ食い、Low Memory Killerで殺される現象などにきっと泣くことになる…と思うなぁ。


スマートフォン開発もやっぱりデスマか

VIPPERな俺 : 「は、はじめましてっ!IS04ですっ!REGZAフォンと呼んでください!」

「ARROWS Z ISW11F」は開発が難航?セミナーでの実機展示を取りやめへ | リンゲルブルーメン

スマートフォン端末開発はいろいろと無茶しすぎてると思う。フィーチャーフォン開発のころも大概デスマな感じだったけどあんまり変わってないし、部分的には酷くなってさえいるような。見聞きした範囲だけど。

・メーカー側の人がAndroidについて行ってない(フィーチャーフォンの時の考え方のままの人とか。「Android詳しくないので下請けさん後はよろしく」)
・メーカーの人間に仕様調整や他チームとの調整を頼んでも、知識が無いので調整できない
・下請けもフィーチャーフォンやってたRTOS+C言語ガリガリ部隊がそのままAndroid開発にシフトしてJavaやオブジェクト指向などにハマる
・開発期間はフィーチャーフォンより短いことが多い(実質3~4ヶ月くらい?)
・予算もフィーチャーフォン時代より少ない(割り当てられる要員不足)
・ギリギリまで仕様が決まらない(フィーチャーフォンでも同じか…)
・各アプリがメモリ使いまくって端末のRAMを食いつぶして重い
・メーカーの企画、キャリアの要求レベルはフィーチャーフォン末期の高機能と変わらず(同等+αの機能を要求される)
・AndroidのIntentをRTOSのタスク間メッセージと勘違いしている人が多すぎる(Intentをメッセージ代わりにした設計がチラホラ)
・AndroidのServiceをRTOSのタスクと思っている(何でもServiceにして常駐させればいいってものでは…メモリ食うし)

など。

各メーカーともAndroid初号機はそうとう難産だったんじゃなかろうか。

数機種くらい開発をこなせばある程度、Androidのクセとかノウハウは貯まると思うのだけど、たぶんメーカーに貯まるというより下請けに貯まるほうが多いんじゃないかと。ここ最近のいくつかのメーカーの傾向として下請けに任せっきりで自分たちは興味なし、な風潮が増えてる感があるし。まぁ下請けも技術力があるかというと…全体的に仕事減ってる関係で要員を選ばずにとりあえずプロジェクトに突っ込んで炎上するパターンも。


プロキシ越えのAndroidソースコードダウンロードがrepoのhttpsデフォルト化で楽に。

kernel.orgがクラッキングされた余波を受けて、長い間AOSPのリポジトリも閉鎖されていたのが、Googleが直接リポジトリをホスティングするように変わって再開した。

すでにAOSPのサイトのソースコードダウンロード方法の説明は新しい手順に書き換えられている。

さて、今回のこのリポジトリの変更で地味な変更が一つ。

repoで使うgitリポジトリアクセスのプロトコルが、gitプロトコルからhttpsになったこと。

repo initで指定するURLも、以前はgit://android.git.kernel.org/platform/manifest.gitだったのが、

repo init -u https://android.googlesource.com/platform/manifest

とHTTPSへ。repo syncでもhttpsが使われる。

これは地味にHTTPプロキシが存在するネットワーク環境では嬉しい変更だ。今までは

http only proxy での Source取得 - Google グループ

に書かれているように、repoのスクリプトやmanifestファイルの中に定義してあるリポジトリURLをgit:// から https:// などに手で書き換えたりする必要があったのだが、その手順をしなくてよくなった。ちょっとした手間ではあるけど、社内LAN経由でダウンロードしようとして、ネットワーク周りの知識があまりない人だとプロキシ越えはハマりやすい所だったので。

ただデメリットは、gitリポジトリへのアクセスはgitプロコトルよりhttpsのほうがパフォーマンスが落ちるらしいということ。具体的にはどれくらいか計測したことは無いけれど、少し頭の片隅に入れておいたほうがいいのかも。


「納品しない受託開発」は客先の理解あってこそ

オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 - Social Change!

きちんとエントリを読み込んでいないので、ちゃんと内容を読み取れてないかもしれないけど、こういう事例って既にけっこう存在すると思ってた。

あるメーカー向け案件だと
・作業場所は自社持ち帰り。必要に応じて電話会議もしくは客先へ出張。
・1ヶ月n人月の枠しばりで、その枠内でできる作業を行う。枠から溢れる作業は対応時期の調整もしくはDrop。
・納品は中間成果物を四半期や半期ごとに形式的に納品し、「納品」のために何か無駄に頑張ったりしない
・基本は自担当の機能チームに属し、必要に応じて他のチームの支援に入ったり。
というのがあった。

ただまぁうちの場合は対メーカーというのもあって、かなり無理めな作業を押し込まれたり突然の枠削減なんてのもあって理想的なものとは言いがたかったけど。

しかも、月額定額という金額を決めてしまうことで、新しい機能や要件が出た際に、ベンダの営業担当が持ち帰って見積りを・・・というようなことをしなくて済みます。プログラマに直接依頼すれば良いだけです。こうすることで、見積りをするだけの営業は要らなくなりますし、バッファを積むだけのマネージャも不要になります。

ただ、依頼された作業がその月額の作業に収まるかどうかは結局見積もり(現場レベルでの)しないと分からないのでは・・・。

このビジネスモデルでは、プログラマは技術力を高めて生産性を上げることによって、効率を高めることができ、シェアできる企業を増やしたり、自社作品のサービスを作る時間を増やすことができるようになります。

確かにそういう面もあると思うけれど、お客によっては余裕があるとすぐに作業を差し込もうとしてきたり、仕様変更をいっぱいまでしようとしたりして、結局開発現場に余裕が生まれないというケースも。例えば月初に作業範囲を確定させたら大きくは変更しないとか、ある程度ガードが掛けられる仕組みが無いと問題になるかも。

趣旨をある程度きちんと理解してくれる客であること、またそれを契約時にきちんと説明できることがまず第一歩だと思う。自社と客との間で変な力関係があるとおそらく上手く行かない…。


構造的なWeb開発向け言語 Dart

Dart : Structured web programming

そういやGoogleがWeb向けにDartってプログラム言語を作っているとか聞いたけど、それが公開されていた。

ざっとサンプルコードを見る感じだとJavaっぽい中に少しだけrubyのような書き方もできる、という印象。Scalaに似てるという意見もあって、私がScalaを知らないので何とも言えないけどいずれにしても既存言語の良いところ取りして、あまり変に文法を新しく作らなかったような感じか。

ただ、Googleの作ったプログラミング言語といえばGoもあるけどいまいち広がらない。例えばrubyのように普及するには何が必要なんだろうね…開発環境なのかフレームワークなのか、ドキュメントなのか。

DartはJavaScriptの上を目指しているようだけど、どうなんだろうなぁ。Chromeブラウザでサポートされたとしても一部だし、node.jsとかのライブラリとかが広がらないとわざわざDartで作るメリットは無いような。


クロスプラットフォームなTextMate風エディタ”Redcar”

rubyでスクリプトを書くときに、普段使っている秀丸やサクラエディタだとシンタックスカラーのお気に入り定義が無かったりして、イマイチな感じがしていた。

かといってEclipseのrubyプラグインはちょっと大げさだし…と開発向けのエディタを探していたらRedcarというのを見つけた。

Redcar

Macの世界で有名なTextMateによく似ているエディタで、WindowsやLinuxでも動作するクロスプラットフォームなのが特徴。しかもRedcarがJRubyで作られていたりとそっちも面白い。

本家サイトにもスクリーンショットはあるが、左側に開いているフォルダの内容一覧が表示され、右側にはエディタという構成。

インストールした直後の状態でも、同一ファイル内のメソッド、変数名などの入力補完は機能しているようだ。

Clipboard01

TextMateのプラグインも一部使えるようなので、TextMateっぽいエディタをWindows/Linuxで使ってみたい人には試してみるのも良いかも。起動はちょっと遅いけど起動してしまえばサクサク動く。


無知なリーダーに対してはメンバが自分で判断して動いてしまうことも必要かも

無知なリーダーがもたらす災厄 - Basic

無知というのは恐ろしい。ほんの少しばかりの好奇心を持って書籍を読んだり、ブログを読んだりして勉強していれば当然知っているはずのアタリマエの知識を知らなかったりする。しかもこの人はチームを取りまとめるリーダーという存在なのだ。効率の悪い作業方法をメンバに命じて、結果的に組織へ損失をもたらしているのに、その結果に気がついていないのだ。

無知というのは恐ろしいというのはその通りなんだけど、これはリーダー一人を責めても仕方ない面もあるかなとは思う。

私自身、評判のイマイチなSIerに長く在籍していて技術力や知識の無い人と一緒に仕事したり山ほど見てきたりして麻痺しているのかもしれないけど、上記のようなケースでは配下のメンバーから突き上げが必要なんじゃ無いのかなぁとも思う。

例えば上の例だとコミットメールを引き合いに出しているけど、配下メンバーが誰もSubversionをフックすれば自動化できる、ということを知らないのであればまぁプロジェクト全体として無知の状態で不幸だね、という話なのだけど配下メンバが誰か一人でも自動化の方法を知っていれば、それをリーダーに提案する、もしくは自分で率先してそういう設定をしてしまう、という動きもプロジェクトを考えるとあるべき姿かなとも思う。

この場合はそういうメンバの提案を聞く耳を持つリーダーであること、という条件がついてしまうけども、自分の知らないことこそ、知っている人からの話は上に立つ人間であっても謙虚に聞けないと駄目じゃなかろうか。

もちろん、リーダー自身がいろいろ知識があって効率の良い作業方法を指示できるのであればそれがベストなんだけど、リーダー一人に全知を求めても無理なのかなというのが私の経験上の感想。

まぁ、何も知らなさすぎるリーダーというのも非常に手がかかって厄介なのだけど…。


スポンサーリンク